I'm not convinced by TDD though, I do it but I've never really needed it in all the years of coding I've been doing. I prefer to write up test harnesses that exercise more of the system in a larger granularity. ie, instead of writing tests that exercise a method, I prefer to exercise a class - and then the test I write can be an example of how to use that class if it involves setting up, configuring it to whatever task you want, and then making it do work.
I also find this helps find more bugs than traditional TDD, eg the time I had a network class that had methods to set ip address and port, but if you set the port first, it would fail (as setting ip would first initialise the entire internal address variables). TDD doesn't find those bugs, and they're the ones I'm more interested in.
Test driven development dictates when you write test cases (before the next increment of product code which can be validated) not what they test or the abstraction level at which they operate. When you're applying the methodology for it's benefits (other than getting you consulting income or giving you a religion to follow) that can be one method, a stack of programs, a class, or whatever point of the spectrum makes the most sense in terms of coverage provided and difficulty reproducing and fixing any bugs that are uncovered.
For reliable non-trivial systems with state (real world examples I've done include replicated NOSQL and block storage appliances using shared nothing clusters) this can take even take the form of a software model describing correct operation, mock environment providing deterministic execution order, and event/timing (including faults) combinations which vary according to a state search strategy and/or pseudo-random approach so you cover situations that you do not anticipate.
As a tangent that sort of testing is uncommon although neglecting to do it leads to huge problems. Google replaced a commercial replicated light weight database because it did not work and mentions the issue in passing in _Paxos made live_. In _MODIST: Transparent model checking of unmodified distributed systems_ Microsoft research applies model checking to three production systems with one running commercially on 100,000 machines and finds protocol errors in all three. I once found a five year old data loss bug in a shipping storage product when I did that and had a new guy fix it in his first week on the job.
The advantage is when you write the test in relation to the product code. Developed up front it's more likely to influence product code encapsulations and APIs to make test easier so you get better coverage and spend less time tracking down root causes. Since testing the code you just wrote doesn't block on writing the test the context switch overhead to fix the bugs you introduce the total cost to fix them is lower.
When misguided managers think "we'll add quality later" and try to cut corners on test development (they often get demoted and replaced after ship dates slip too much, but that can take a long time whilst your life is made unpleasant) it's not possible for them to ship a product prematurely (the product code is not done) and harder for them to damage the release.
As your software becomes more trivial the importance of doing this is less; although such simple work is easier to outsource or delegate to lower paid junior employees so more senior engineers might not have to deal with such situations for too long.
tech support! I used to dream of tech support interruptions!
Now I'm doing a bastard child of agile that the company has brought in and I cannot do anything for longer than 2 hours without having to go back to the scrum board for more work. Don't they know they can just point me at a problem and I'll get it solved - it is what I've been doing for several decades after all.
I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.
You need a better job. You may be able to change what's going on there (after a CEO change I got a 2 hour scrum reduced to a brief meeting every-other day with most updates happening electronically via Agilo for trac) to make it tolerable. That may be impossible or exceed your patience in which case you need a different employer.
Agile is awesome especially test driven development.
It's like when you where metaphorically young, made some trivial program not many orders of magnitude more complex than "hello world," ran it, saw everything worked, and were happy except it applies to non-trivial problems like replicated storage that still smells like a single copy of data.
Writing a test, making a change (which can be entirely non-trivial), knowing whether it works within 30 seconds, and being able to iterate until it does over minutes or an afternoon is far more pleasant than making months worth of changes which cursory experiments suggest work, dumping the pile on your QA organization, getting feedback that something's broken, making a change, getting feedback that something else is broken a day or two later, making a change, etc. as the release date slips.
Agile is great for business especially in startup environments where you need to get customers before running out of money and release cycles measured in hours are more conducive to that than ones taking six months.
Burn-down lists and velocity measurement are great for engineering and business. While engineers are good at estimating the size of things they're bad at mapping that to wall clock time in real world environments where tactical (customer support issues) and environmental (your open floorplan is too noisy for people to think 9am - 5pm) issues exist beyond their control. With feeedback on velocity you can come up with more realistic numbers for release dates so there's less stress for everyone involved and a better idea of what you can fit into releases on some periodic schedule so customers don't suffer as the release date and/or quality slip.
Micro-managing and calling it "agile" is bad for both engineers and profits.
Scrum is bad because you loose productivity when you force human context switches for daily meetings. Where you make the meeting early to avoid that engineers stop working exactly eight hours after the meeting start so they're not too tired the next day even though that may mean hours to get back to where they were instead of minutes to finish. If they do stay late to get something done they come to the mandatory meeting tired and the quality of their work is as bad as if they were drunk.
Scrum is even worse when mis-applied. People can and do turn the daily meetings into 1-2 hour affairs totaling 50-100 man-hours a week for a team of 10 people which can be $200 - $500K/year in fully burdened costs when you have senior people in high-wage areas.
Some managers like to use one burn-down list for the entire organization where engineers are fungible commodities that do whatever is the highest priority regardless of scope and how far along they are in their career. That's a huge waste of money (in large technology companies some one with 15-20 years of experience doing meaty things can have a compensation package twice the size of some one with 1/10th that experience), reduces quality, and robs people of their self-actualization.
No. Learn two words instead: Flexibility. Autoreformatting. Then you can stop worrying so much about the style of the damn code, and get your ideas into the computer without fussing over adhering to your own style.
That sounds intriguing to me.
How do I apply auto-reformating to JIRA, gmail, bugzilla, Coverity, enscript, and the plethora of other tools which get used in the software development process?
And I've never been on a project that didn't have the oddest mixture of coding styles.
I have.
A pre-commit hook in your revision control software to bounce changes which won't confirm does the job nicely with a
make style
target making achieving pre-checkin compliance painless.
Occasionally you need something which technically violates the style checker, although the need for a manual override via something embedded in comments like/* BEGIN CSTYLED *//* END CSTYLED */
Want to run the school game? Get your B. S. and hit the law schools. Pass the bar, and you have a career for life.
That's a horrible idea if you can't get into the top 7 or so law schools.
About half of law school graduates can't get jobs as lawyers and many end up shuffling papers for $15 an hour. That might not be so bad in the grand scheme of things, although the average law graduate finishes their education with $150,000 on which student loan interest can run $1000/month so you'd need to live off $8.50 an hour to keep the principle from increasing which is poverty level.
"Like some Slashdot users, I began attending university last month for computer science.
Conversing with my college computer science peers (many of whom are quite nerdy), I have noticed that many of them are extremely arrogant. Upon introspection, I have come to the realization that I am also very similar to them and am very curious, but worried."
While a few of you are assholes for whom there's no hope, most of you are that way because you're young and not done growing up.
Your situation may be exacerbated by the college admissions process, where kids compete amongst each other to be in the top x% or 0.xx% to get in. Appearing to be better than the remaining xx.x% seems critical to your life.
Most of the real world doesn't work that way - you just need to get your work done well enough on time whatever that means.
"I have noticed similar personality characteristics on Slashdot. Where does this nerd arrogance come from?"
Many people are more obnoxious on-line where it's entertaining for them than in real life where it'd be a problem that gets in the way of relationships and promotions.
In reality doing things "right" will mean less cost the entire life of the product. Yes, initial profits will be delayed, but over the life profits will be higher due to lower maintenance costs (and maintenance is the majority of a software's life cycle).
Having done software professionally for 20 years, delivered five non-trivial products built from scratch to customers for business critical applications (things like block storage on a shared nothing cluster of x86 boxes and a highly available cellular base station billing interface), and worked on at least a dozen other products I disagree (three big company re-orgs in 18 months and some consulting exposed me to a lot).
Fast or good is a false dichotomy. You can have both or neither and as an added bonus choosing "fast and good" also nets "less expensive" which is the mythical holy trinity.
Do things right and you'll make your initial profits sooner - either because customers start buying that product sooner or you pivot and get your next try out there in less time.
Software (whether packaged that way, as a service, or as a hardware appliance) products are about nested feedback loops within the larger business cycle of market needs leading to customers paying you repeating as you flesh out a complete product, build a surrounding ecosystem ecosystem, go vertical, etc.
Within that are the loops surrounding things engineers identify with like writing software, writing tests, fixing bugs, and making releases.
The things you do to make maintainable code reduce the time it takes to deliver a viable product to customers on the first AND following cycles.
Unit and regression tests reduce the time to fix the bugs you inevitably introduce. There's much less wasted effort when you write code, the relevant tests find a problem immediately (as opposed to waiting for a release to drop to QA or going through multiple release candidate - QA cycles followed by shipping to a customer that finds the problem), you have more information which leads to a quicker fix, and you have no context switch overhead. They also give you more latitude in what the people you have work on because there's little risk added by people working on unfamiliar code when there's enough pre-checkin coverage to make getting bugs to QA or customers unlike.y
Meaningful comments surrounding what you're doing facilitate neural pathway formation leading to a deeper understanding, more "aha!" moments, and fewer bugs. They get you back on track sooner after the inevitable context switch for tactical issues.
Refactoring reduces your bug count and time spent on problems because non-existing lines of code can't have bugs.
Things continue to improve as you get nuttier:
I was turned on to simulation (link your shipping product code to mock objects at a low level gaining control over scheduling (make it deterministic and get atypical timings via pseudo random or state search methods)) and model checking by a Digital Systems Research Center alumni I was working with on another clustered block storage appliance. It seemed neat and useful until I spent an afternoon moving a lower piece of the stack into the simulated environment and found the buffer reuse problem which had been holding up our release for a month. "Neat" became "you'd be dumb not to" for some class of software. In a subsequent commercial life I did the right things again and solved memory corruption problems which showed up under certain event orderings in hours where co-workers did not and took weeks for the same sorts of issues.
Tool building can pays huge dividends too:
A good logging system is not core to your business and something which people usually skip. However in practice it takes much less time to build a system which logs 300,000,000 (on a four year old pre-production dual socket Nehalem box) entries a second via a printf API into a circular shared memory buffer which survives process termination and allows development trace level logg
>Any other ways to find out code quality beforehand?
Absolutely.
That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).
When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.
You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.
One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.
This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.
In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.
I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)
1. Salary is a smaller subset of compensation in larger companies and becomes less significant as you move up the food chain.
At the last big company I worked for I took home $35K less salary than at the startup which followed, although if neither stock prices nor salary went up salary would have been less than 60% of my total compensation over 4 years and I'd have done $52K/year better.
2. Salary is highly dependent on where you are in your career making the average within an organization largely a function of typical job level. At the least startup I worked for I was the only early hire under 40 and we were all at the principal engineer / director experience level. At the last big company only three of the engineers I worked with (maybe 1 in 5) were over 30 and lots of people were in their first job after school with matching entry level titles and compensation. When you need six engineers who'll each be responsible for a component you need seniority, can hire that many senior guys, and will have a higher average salary. When you need thousands of engineers and most groups/projects have 4-8 people you don't need the experience, couldn't hire it, will be lucky to make one senior hire after 6-12 months of trying, and will have a lower average salary.
3. Aptitude (Demarco and Lister comment on this in Peopleware if you want a formal cite) is usually fairly consistent within organizations and that can be worth another 25 - 30% (although IIRC Demarco and Lister only report a 10% pay delta). Exceptions exist in good organizations where you might get a few stars that are much better and bad organizations where B grade people hire C grade people to limit competition.
>What does the Slashdot crowd see as the best path to fame, wealth and full employment for gray-haired old coots who love to program?"
Those are orthogonal goals.
Fame: Free software. Wealth is not likely to follow. You can probably make a career out of it though.
Wealth: Startup with exponential growth. $1000 of monthly revenue is $25M/month after four years at a 5% weekly growth rate. In some one else's venture funded company just 0.5% of a 1B market cap is $5M in long term capital gains. 25% left of your own company which is not trying for VC sized returns with a $20M liquidity event is the same.
Full employment with a good salary (mid-career you can break $200K if you're willing to work for large companies): do something hard well which leverages your decades of experience that let you compete against youngsters even though you cost more. My thing is systems software for business critical applications with an emphasis on distributed systems and high availability. I've done cellular base station infrastructure, digital video for the broadcast market, block storage on a clusters of x86 PCs, light weight key-value storage on spinning disks and flash, and am now doing enterprise grade cloud backup. Although I confess to having worked on one C# project and a couple in Java the rest has been evenly split between C and C++. Language and libraries are not the hard part and I've worked in groups where nearly everyone is over 40.
A paycheck now: Join a contracting/consulting shop which takes a third off the top.
While learning new technologies is fun and neat, with anything trendy where the meat is in the mechanics of how you do things not what you're doing you will be competing with young guys who can get the job done well enough and are more enthusiastic, compliant, and willing to work for less money.
Most people could learn to do trivial (count 1 to 10 in a loop) and simple things.
OTOH less than 1% of professional programmers whose resumes are filtered by recruiters paid on contingency have all the aptitudes necessary to do well in the commercial environments I work on (I think a larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal and not go through a recruiter).
Those aptitudes are
1. The ability to think logically, identify edge conditions, and express that
2. The ability to deal with indirection
3. The ability to apply knowledge to engineering problems.
4. The ability to grasp parallelism
I have a set of questions covering these which changes some with time. There aren't any trick questions here - engineers which do well tend to make it through the first question in under 10 minutes and the rest under 5 after which we can talk about their work history and other things. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer.
Such things should be pre-requisites for a computer science degree but aren't because too many people fail when they are and that's bad for the department's cash flow.
My favorite professor taught data structures with her TAs linking students code into their automated test suites with grades based on whether their code actually worked. Supposedly 1/3 of the class failed. Graduates of that program were generally worth hiring.
She was replaced by a more lax instructor that didn't do that and our hire rate went way down.
Where are you guys seeing 6 figure pay? The only positions companies seem to have are very junior positions, for $60k at best. Often they want so much experience and so many skills that the position isn't really junior, but they call it that so they can pay less.
Starting compensation packages at the big silicon valley companies (Apple, Google, Facebook) for new graduates are breaking $100K
Every mid-career position doing systems software I've talked to people about over the last decade in Boulder, CO; Seattle, WA; and Silicon Valley has paid better than that.
Senior staff and principal engineer roles (actual as opposed to title inflation side effects, with technical leadership responsibilities and 15+ years of experience getting there) are breaking $200K in Seattle and the SF Bay Area - often with much of that stock, although with privately held companies it can be all cash.
Key differentiators here are
1. It's all core not context using Moore's (as in _Crossing the Chasm_) definitions. Core is what your business is where doing it better confers a competitive advantage, like where you sell storage appliances and they're faster/more reliable/easier to backup than the competition's products. Context are other things that you need to do although doing them better doesn't confer a competitive, like having an on-line shopping site. If it takes 10 ms to complete a user checkout instead of 100ms you won't sell any more product.
2. Meaty. Some things are harder to do well enough than others. Scattering enterprise data over a shared nothing cluster and not ever loosing any is harder than a smart phone app to play Pictionary (TM).
3. It's all in geographic areas where lots of that sort of thing is going on. I'd recommend Silicon Valley because being here radically increases your chances of finding a good combination of product life cycle, interesting technical challenges, and viable business plan. The weather is great too - I wear shorts year round. Of course, $100K doesn't go as far where apartment rent can run $2000-$3000. I bought myself a nice double wide mobile home so I could have a nice place to live without a cash flow situation I objected to.
Such positions being open to you are a separate issue. About 1 in 200 resumes received from recruiters paid on contingency filtered for people who do meaty things belongs to some one worth hiring due to deficiencies in things that seem to be aptitudes not skills and should be pre-requisites for a computer science degree although weeding people out there cuts the department budget. Those aptitudes are
1. The ability to think logically, identify edge conditions, and express that
2. The ability to deal with indirection
3. The ability to apply knowledge to engineering problems.
4. The ability to grasp parallelism
I think a much larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal.
1. 100% binary compatibility with Windows binaries. Many people have some "killer app" that they need to run which is Windows and/or Mac only.
As it stands, I need to boot into Windows to run Sketchup.
2. 100% binary compatibility with Windows device drivers.
My Linux wifi driver often flakes out talking to one access point with a panic which requires manual intervention. The last Fedora I tried progressively increased my fan speed running X until I had a jet engine until the next reboot. My Windows drivers don't do that.
3. 100% binary compatibility with Linux, including 32 bit binaries on 64 bit systems.
It's a pain in the butt as a company to deal with multiple Linux versions in terms of builds, test, and support. It's a pain as user where the software you want has the wrong flavor.
I have 32 bit Firefox (with 32 bit only plugins that I need for reliability) mostly working on a 64 bit Debian, although some of the libraries have hard-coded paths in them which produce frightening error messages and I never got the Java plugin to work which I'd need to use my company VPN.
The (non) viability of this (as a hobbyist I don't want to waste my life reverse engineering Microsoft APIs, and as a business I don't care whether my servers run desktop applications) is a separate issue.
When time is short and changes are being made fast and furiously, or prototyping is being done, time spent commenting comes out of time getting something completed under a harsh deadline...
That's a naive simplification that's not really true. Software development is _not_ a zero sum game and time doing things which "don't ship to customers" both reduce total time and make it more predictable so your time commitments are less likely to become harsh.
Your milestone is _not_ code complete. It's delivering a product to customers which meets some requirement set including quality. The time to get there is something like
Requirements + Functional spec + Write and comment tests + Design + Write & comment code + Manual test execution + New feature bug count * (interrupt overhead + average time to fix new bugs) + Regression count * (interrupt overhead + average time to fix regressions) + Bug count from previous releases * (interrupt overhead + average time to fix previously latent bugs)
where some steps may be trivial and there are nested feedback loops around others.
The terms are neither constant, functions with project size as the only input, nor independent.
Generating a good comment causes your ideas to flow through other parts of your brain so you develop a better understanding of what's going on thus reducing the defect rate in terms of new bugs.
Having done so before means you have a better understanding of what was already going on, so you have fewer regressions and where they happen there's less context switch overhead figuring out what was going on so you can fix them.
The reduced bug count from previous releases multiplied by lower interrupt overhead means you loose less time there.
Better test coverage means more bugs are found early where the time to figure out what you were doing when you caused them is lower. Lower level test coverage means everything is more isolated so the time to correct each one is lower.
Designing for validation so that's manageable encourages better encapsulation within components and smaller component size which reduces both bug count and the time to correct each one.
Seriously. Where exactly does experience as a developer get you, other than more dead end jobs as a developer?
Interesting problems to solve, flexible hours, and six figure compensation packages where willingness to work for a big company can make the first digit more than '1'.
I can't name any other profession where you can get most of that with a four year degree (or less; almost every place you want to work cares more about you knowing the things you should have learned in engineering school than having the degree) where being a doctor or lawyer could net the pay and interesting problems.
That is somewhat better than most entrepreneurial experiences which lead to zero.
>This "building an app is like mass producing a chemical" philosophy is one reason why most software shops have insane amounts of unneeded documentation and overhead
In 20 years working as a software engineer I've yet to encounter a software shop with insane amounts of unneeded documentation. The majority of software organizations I've dealt with had inadequate documentation and process which led to lower quality for customers, lower developer throughput, and unpredictable release schedules.
Usually this comes from deep seated religious beliefs among executive teams and mid-level managers. To quote one CEO "Test code doesn't ship to customers." He practiced what he preached, directing employees to build product and not test too much. Another company managed a two billion dollar market cap from a product very similar to one the he abandoned because the schedule kept slipping and it never worked well enough (although engineering staff kept strongly suggesting hardware validation).
Nothing can change that religion. You can apply better process to your own projects and illustrate order-of-magnitude lower defect rates and time to fix bugs that result from that compared to similar sized projects in the organization without the process. You can talk about the business benefits from positive experiences in other companies. You can sometimes get them to read books like _The Clean Coder: A Code of Conduct for Professional Programmers_. You can share your amusing anecdote about the company you didn't work for because one of the founders did not believe in unit tests so you knew they were going to crater due to low quality and long unpredictable release cycles which had their VCs rescind funding due to customer issues with quality and long and unpredictable delays for bug fixes. You can get other executive team members on the right side and attempt an intervention although the same skills of persuasion which get tens of millions from investors work to move them back. You can go to the board of directors although they're friends with the executive team and it doesn't end well.
Occasionally it's just ignorance. Software engineers can go through a lot of positions without stumbling across someplace that does a good job. This is easily fixed - once competent people have seen how much tedium process removes from their lives and how it lets them focus on interesting problems they get with the program.
While software development is an art, there are accepted processes not too different from mass production that make higher quality, shorter delivery times, and more predictable schedules likely. Although that doesn't sound like fun they do allow the engineer to spend more time on art (which is fun) and less on mechanics so it's a win-win-win for customers., company, and coder.
I have encountered unneeded overhead which can be another facet of the same problem or something else. Sometimes companies grow too fast and create extra positions filled by people that need to justify their jobs. Sometimes the executives who direct less testing become unhappy with the unpredictable product cycles which result and decide to apply the daily meeting (except for 1-2 hours) from the agile world without the things which make agile work.
Although the failure modes differ, 'C' and its interactions with its typical user isn't less safe than Java.
'C' programmers know that they need to free their resources and make a habbit of it. Half decent ones even use a naming convention which implies dynamic allocation (ex: message_alloc) and suggests that code readers remember to apply a corresponding function when they're done (message_free).
Java programmers generally assume that their resources will be garbage collected soon enough. While often true for memory, failures involving non-memory objects like file descriptors are not uncommon.
'C' programmers almost never use a goto to get out of the middle of a function. Java programmers both do so regularly (in the form of exceptions) and neglect to catch/cleanup non-memory resources/rethrow.
1920x1080 on a 15" screen is good for a pair of 80 column x 60 line text areas at a nice size and three 80 column x 70 line text areas at a legible size with space left over at the top of the screen for icons + useless window title bar.
Opened on the same source file that's 120 lines and 210 lines respectively.
If that's still too limiting your code needs to be refactored into smaller more abstract pieces.
>There is a big downside to this. There is a very high risk when you work into startups. You could be rolling in success one month, and the next month you could be forced to shutdown. TFA and most comments on startups looking inside out, don't often write about the stress that comes with this kind of risk.
After 19 years in industry including five full time startup jobs I don't think there's a quantitative difference in job stability between working at a startup and working at a big company. Only the details vary. Some details are important - how much warning you have and potential for a severance package in the unlikely event you don't retain "a" job. Some are less important - your project, perhaps team, and maybe office end when the product is "complete" and sent off-shore for sustaining engineering, a competing group with better political connections has your product slated for end of life, your group gets re-organized to deal with issues on other products, the company built the wrong product and/or sold it in the wrong way and/or had the wrong target market so it either pivots (most likely end of project) or runs out of money (read on).
I suspect keeping a job when a startup runs out of money isn't appreciably less likely than at a big company. Two out of five of the startups I worked for ran out of money and had substantially all of their assets acquired by larger companies (one was acquired for more than corporate debt and VC investments, one pivoted and has yet to run out of money, and the current one is doing well). You show up at work, are told you no longer have a job, and get an offer letter from the acquiring company (you can't actually sell people) with a raise.
>And you know what? We have a lot of fun, but we have plenty of 60 hour weeks too, when shit hits the fan.
That's a software industry problem that's not unique to startups. Software engineering groups almost never architect things in a way that facilitates testing and validation. Combined with insufficient automated testing that leads to release cycles that are both long and unpredictable. Feature sets often change without schedule changes.
All of that is completely unnecessary, but neither anecdotal evidence from personal experience, book cites, nor examples within the company are enough to convince people that the choice between quality and speedy delivery usually is both or neither not either.
Daily stand-up meetings are a huge productivity drain compared to communication via e-mail where high bandwidth is not required with ad-hoc meetings scheduled as needed with defined agendas structured to require as few people as possible. I like to add my agenda to the white board with any other issues that come up which aren't on the list discussed later with just the people who are required and interested.
You have the direct costs (12 engineers *.25 hours / day * 5 days/week * ( 52 weeks - 10 company holidays) * $100/hour fully burdened costs = $75K/year), the impact on work happening about that time (it can take another 20 minutes to get back into a flow state so to over-simplify that meeting is costing you a full-time employee), and what you loose due to employee morale (nearly all of a scrum group I worked with left within a minute or two of eight hours after the morning meeting).
Some of the things which go with scrum are good, like feedback on progress against the schedule, visibility into what other people are working on and their blocking issues but can be handled in other ways without being a scheduled interruption for the entire group (there are plugins for Trac and JIRA, you can e-mail summaries out to your group with whatever frequency works, you probably should be talking to anyone you're blocked on before tomorrow's standing meeting)
Find a job with better management and more interesting technical challenges, quit your current job, and re-discover your love for programming.
I screen resumes for signs that a candidate has done non-trivial things which may have required original thought and application of data structures, although I don't care whether that was at a day job, in a free software project, or in an interesting project class at school like compiler construction. I figure that people 10 years into their career who haven't managed to do that either lack the aptitude (and aren't going to learn it) or interest (in which case I don't want them either).
Once I bring them in we ask a simple programming question (about as hard as reversing a C string, doable in a single for loop although the most obvious solution uses a pair of inner loops inside a while loop, nearly all candidates worth hiring manage a linear time solution in not much over five minutes), a simple data structures question, a simple design question, another data structure/multi-threaded question design question, for some thoughts on software process, and the usual background questions.
As a competent programmer you'd have no problem getting through that (it's surprising how bad nearly all job candidates are).
My last encounter with trees, threads, priority queues, condition variables, and mutexes was this afternoon and any one I hired could be doing the same thing on their first day of work.
I don't risk giving guys their first job, although I include free software and interesting project classes the equivalent.
I ask every candidate regardless of seniority (you can get surprisingly far in industry without much skill beyond high-level hand waving)
1) A simple programming question with a couple of edge conditions. It can be solved in one loop although I'm very happy with candidates who use an obviously correct solution with a pair of inner loops which totals 17 lines including braces where not technically needed added in the K&R style. I don't mind pointing out an edge condition that's been missed, just that they address it in the end (in the real world a test would find it).
2) A simple data structure question. I give an API with three functions, ask what data structures the candidate would use, and what the operational complexity on the three functions would be. I don't want an optimal answer, just something workable, and don't mind answers like "some sort of" that would lead to a book or web lookup. I'd be happy enough with an STL container answer; although pretty much everyone without the basics doesn't do well at that abstraction level either.
Candidates worth hiring in my opinion and the majority who've passed hours of less hands-on interviews take about five minutes for each (maybe ten minutes for the first problem if they've been withering away as a project manager which is fine) after which I ask a five minute thread question and spend the remainder of the time talking about what they've done and assessing whether they have attitudes about software test and process commensurate with time in industry.
Ones not worth hiring can spend an hour on the first problem and still fail to get it when I explain how it would work in English with diagrams.
I ask all of those questions and then quantify the quality of code, build system, and test effort by getting a code+test walk through plus demonstration of a build+test cycle.
It still fails 1) Following re-organizations into other groups with less lax standards
2) Following organizational pivots where upper management decides they don't have time for reasonable development processes (even though they make schedules both shorter and more predictable!) and spineless engineers go along with it.
>Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.
Nope.
1. In some cases the decision to eschew good test automation comes from the top in an effort to reduce time to market by reducing total lines of code. To quote one CEO I worked with, "We'll add quality later" followed by mumblings about how engineering would rewrite the code a bunch of times and would to save time by getting to the final product and then testing." No number of personal anecdotes, quotes from papers and books, reasoned arguments, supporting arguments from executive staff, etc. showing that a smarter and more thorough test effort makes time to market shorter and more predictable will change things. The best you can do is take care of your own corner of the product, point out the places where you fixed certain types of bugs in X hours versus X weeks by group members not doing that, hope your co-workers join you, and hope for a leadership change that will be more receptive to your input before the company tanks.
2. Most developers can make it a decade into their career without both grasping the utility (fewer bugs reaching users that become irate, less effort to fix the bugs you do find, more predicable schedules so that death marches are less likely, less integration pain with fewer errors) of and choosing to apply good test automation and continuous integration. They can be impervious to talk, management buying people copies of relevant books (The Clean Coder, XP: Extreme Programming Explained, etc.) in their choice of print or Kindle edition and telling them to read it at work whenever they want, a rubber chicken or toilet plunger for whoever last broke things, etc. You need to get management buy in with leadership willing to hire and fire if people won't get in line.
In both cases you may be better off finding a more sensible job.
While at most half on home-row, Control-[ is a much smaller stretch than Escape which is so far up the left side you probably can't hit it without moving your entire left hand.
Slashdot Mirror
I'm not convinced by TDD though, I do it but I've never really needed it in all the years of coding I've been doing. I prefer to write up test harnesses that exercise more of the system in a larger granularity. ie, instead of writing tests that exercise a method, I prefer to exercise a class - and then the test I write can be an example of how to use that class if it involves setting up, configuring it to whatever task you want, and then making it do work.
I also find this helps find more bugs than traditional TDD, eg the time I had a network class that had methods to set ip address and port, but if you set the port first, it would fail (as setting ip would first initialise the entire internal address variables). TDD doesn't find those bugs, and they're the ones I'm more interested in.
Test driven development dictates when you write test cases (before the next increment of product code which can be validated) not what they test or the abstraction level at which they operate. When you're applying the methodology for it's benefits (other than getting you consulting income or giving you a religion to follow) that can be one method, a stack of programs, a class, or whatever point of the spectrum makes the most sense in terms of coverage provided and difficulty reproducing and fixing any bugs that are uncovered.
For reliable non-trivial systems with state (real world examples I've done include replicated NOSQL and block storage appliances using shared nothing clusters) this can take even take the form of a software model describing correct operation, mock environment providing deterministic execution order, and event/timing (including faults) combinations which vary according to a state search strategy and/or pseudo-random approach so you cover situations that you do not anticipate.
As a tangent that sort of testing is uncommon although neglecting to do it leads to huge problems. Google replaced a commercial replicated light weight database because it did not work and mentions the issue in passing in _Paxos made live_. In _MODIST: Transparent model checking of unmodified distributed systems_ Microsoft research applies model checking to three production systems with one running commercially on 100,000 machines and finds protocol errors in all three. I once found a five year old data loss bug in a shipping storage product when I did that and had a new guy fix it in his first week on the job.
The advantage is when you write the test in relation to the product code. Developed up front it's more likely to influence product code encapsulations and APIs to make test easier so you get better coverage and spend less time tracking down root causes. Since testing the code you just wrote doesn't block on writing the test the context switch overhead to fix the bugs you introduce the total cost to fix them is lower.
When misguided managers think "we'll add quality later" and try to cut corners on test development (they often get demoted and replaced after ship dates slip too much, but that can take a long time whilst your life is made unpleasant) it's not possible for them to ship a product prematurely (the product code is not done) and harder for them to damage the release.
As your software becomes more trivial the importance of doing this is less; although such simple work is easier to outsource or delegate to lower paid junior employees so more senior engineers might not have to deal with such situations for too long.
tech support! I used to dream of tech support interruptions!
Now I'm doing a bastard child of agile that the company has brought in and I cannot do anything for longer than 2 hours without having to go back to the scrum board for more work. Don't they know they can just point me at a problem and I'll get it solved - it is what I've been doing for several decades after all.
I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.
You need a better job. You may be able to change what's going on there (after a CEO change I got a 2 hour scrum reduced to a brief meeting every-other day with most updates happening electronically via Agilo for trac) to make it tolerable. That may be impossible or exceed your patience in which case you need a different employer.
Agile is awesome especially test driven development.
It's like when you where metaphorically young, made some trivial program not many orders of magnitude more complex than "hello world," ran it, saw everything worked, and were happy except it applies to non-trivial problems like replicated storage that still smells like a single copy of data.
Writing a test, making a change (which can be entirely non-trivial), knowing whether it works within 30 seconds, and being able to iterate until it does over minutes or an afternoon is far more pleasant than making months worth of changes which cursory experiments suggest work, dumping the pile on your QA organization, getting feedback that something's broken, making a change, getting feedback that something else is broken a day or two later, making a change, etc. as the release date slips.
Agile is great for business especially in startup environments where you need to get customers before running out of money and release cycles measured in hours are more conducive to that than ones taking six months.
Burn-down lists and velocity measurement are great for engineering and business. While engineers are good at estimating the size of things they're bad at mapping that to wall clock time in real world environments where tactical (customer support issues) and environmental (your open floorplan is too noisy for people to think 9am - 5pm) issues exist beyond their control. With feeedback on velocity you can come up with more realistic numbers for release dates so there's less stress for everyone involved and a better idea of what you can fit into releases on some periodic schedule so customers don't suffer as the release date and/or quality slip.
Micro-managing and calling it "agile" is bad for both engineers and profits.
Scrum is bad because you loose productivity when you force human context switches for daily meetings. Where you make the meeting early to avoid that engineers stop working exactly eight hours after the meeting start so they're not too tired the next day even though that may mean hours to get back to where they were instead of minutes to finish. If they do stay late to get something done they come to the mandatory meeting tired and the quality of their work is as bad as if they were drunk.
Scrum is even worse when mis-applied. People can and do turn the daily meetings into 1-2 hour affairs totaling 50-100 man-hours a week for a team of 10 people which can be $200 - $500K/year in fully burdened costs when you have senior people in high-wage areas.
Some managers like to use one burn-down list for the entire organization where
engineers are fungible commodities that do whatever is the highest priority regardless of scope and how far along they are in their career. That's a huge waste of money (in large technology companies some one with 15-20 years of experience doing meaty things can have a compensation package twice the size of some one with 1/10th that experience), reduces quality, and robs people of their self-actualization.
No. Learn two words instead: Flexibility. Autoreformatting.
Then you can stop worrying so much about the style of the damn code, and get your ideas into the computer without fussing over adhering to your own style.
That sounds intriguing to me.
How do I apply auto-reformating to JIRA, gmail, bugzilla, Coverity, enscript, and the plethora of other tools which get used in the software development process?
And I've never been on a project that didn't have the oddest mixture of coding styles.
I have.
A pre-commit hook in your revision control software to bounce changes which won't confirm does the job nicely with a
make style
target making achieving pre-checkin compliance painless.
Occasionally you need something which technically violates the style checker, although the need for a manual override via something embedded in comments like /* BEGIN CSTYLED */ /* END CSTYLED */
limits that to rare intentional occurrences.
Want to run the school game? Get your B. S. and hit the law schools. Pass the bar, and you have a career for life.
That's a horrible idea if you can't get into the top 7 or so law schools.
About half of law school graduates can't get jobs as lawyers and many end up shuffling papers for $15 an hour. That might not be so bad in the grand scheme of things, although the average law graduate finishes their education with $150,000 on which student loan interest can run $1000/month so you'd need to live off $8.50 an hour to keep the principle from increasing which is poverty level.
"Like some Slashdot users, I began attending university last month for computer science.
Conversing with my college computer science peers (many of whom are quite nerdy), I have noticed that many of them are extremely arrogant. Upon introspection, I have come to the realization that I am also very similar to them and am very curious, but worried."
While a few of you are assholes for whom there's no hope, most of you are that way because you're young and not done growing up.
Your situation may be exacerbated by the college admissions process, where kids compete amongst each other to be in the top x% or 0.xx% to get in. Appearing to be better than the remaining xx.x% seems critical to your life.
Most of the real world doesn't work that way - you just need to get your work done well enough on time whatever that means.
"I have noticed similar personality characteristics on Slashdot. Where does this nerd arrogance come from?"
Many people are more obnoxious on-line where it's entertaining for them than in real life where it'd be a problem that gets in the way of relationships and promotions.
In reality doing things "right" will mean less cost the entire life of the product. Yes, initial profits will be delayed, but over the life profits will be higher due to lower maintenance costs (and maintenance is the majority of a software's life cycle).
Having done software professionally for 20 years, delivered five non-trivial products built from scratch to customers for business critical applications (things like block storage on a shared nothing cluster of x86 boxes and a highly available cellular base station billing interface), and worked on at least a dozen other products I disagree (three big company re-orgs in 18 months and some consulting exposed me to a lot).
Fast or good is a false dichotomy. You can have both or neither and as an added bonus choosing "fast and good" also nets "less expensive" which is the mythical holy trinity.
Do things right and you'll make your initial profits sooner - either because customers start buying that product sooner or you pivot and get your next try out there in less time.
Software (whether packaged that way, as a service, or as a hardware appliance) products are about nested feedback loops within the larger business cycle of market needs leading to customers paying you repeating as you flesh out a complete product, build a surrounding ecosystem ecosystem, go vertical, etc.
Within that are the loops surrounding things engineers identify with like writing software, writing tests, fixing bugs, and making releases.
The things you do to make maintainable code reduce the time it takes to deliver a viable product to customers on the first AND following cycles.
Unit and regression tests reduce the time to fix the bugs you inevitably introduce. There's much less wasted effort when you write code, the relevant tests find a problem immediately (as opposed to waiting for a release to drop to QA or going through multiple release candidate - QA cycles followed by shipping to a customer that finds the problem), you have more information which leads to a quicker fix, and you have no context switch overhead. They also give you more latitude in what the people you have work on because there's little risk added by people working on unfamiliar code when there's enough pre-checkin coverage to make getting bugs to QA or customers unlike.y
Meaningful comments surrounding what you're doing facilitate neural pathway formation leading to a deeper understanding, more "aha!" moments, and fewer bugs. They get you back on track sooner after the inevitable context switch for tactical issues.
Refactoring reduces your bug count and time spent on problems because non-existing lines of code can't have bugs.
Things continue to improve as you get nuttier:
I was turned on to simulation (link your shipping product code to mock objects at a low level gaining control over scheduling (make it deterministic and get atypical timings via pseudo random or state search methods)) and model checking by a Digital Systems Research Center alumni I was working with on another clustered block storage appliance. It seemed neat and useful until I spent an afternoon moving a lower piece of the stack into the simulated environment and found the buffer reuse problem which had been holding up our release for a month. "Neat" became "you'd be dumb not to" for some class of software. In a subsequent commercial life I did the right things again and solved memory corruption problems which showed up under certain event orderings in hours where co-workers did not and took weeks for the same sorts of issues.
Tool building can pays huge dividends too:
A good logging system is not core to your business and something which people usually skip. However in practice it takes much less time to build a system which logs 300,000,000 (on a four year old pre-production dual socket Nehalem box) entries a second via a printf API into a circular shared memory buffer which survives process termination and allows development trace level logg
>Any other ways to find out code quality beforehand?
Absolutely.
That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).
When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.
You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.
One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.
This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.
In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.
I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)
This isn't interesting news.
1. Salary is a smaller subset of compensation in larger companies and becomes less significant as you move up the food chain.
At the last big company I worked for I took home $35K less salary than at the startup which followed, although if neither stock prices nor salary went up salary would have been less than 60% of my total compensation over 4 years and I'd have done $52K/year better.
2. Salary is highly dependent on where you are in your career making the average within an organization largely a function of typical job level. At the least startup I worked for I was the only early hire under 40 and we were all at the principal engineer / director experience level. At the last big company only three of the engineers I worked with (maybe 1 in 5) were over 30 and lots of people were in their first job after school with matching entry level titles and compensation. When you need six engineers who'll each be responsible for a component you need seniority, can hire that many senior guys, and will have a higher average salary. When you need thousands of engineers and most groups/projects have 4-8 people you don't need the experience, couldn't hire it, will be lucky to make one senior hire after 6-12 months of trying, and will have a lower average salary.
3. Aptitude (Demarco and Lister comment on this in Peopleware if you want a formal cite) is usually fairly consistent within organizations and that can be worth another 25 - 30% (although IIRC Demarco and Lister only report a 10% pay delta). Exceptions exist in good organizations where you might get a few stars that are much better and bad organizations where B grade people hire C grade people to limit competition.
>What does the Slashdot crowd see as the best path to fame, wealth and full employment for gray-haired old coots who love to program?"
Those are orthogonal goals.
Fame: Free software. Wealth is not likely to follow. You can probably make a career out of it though.
Wealth: Startup with exponential growth. $1000 of monthly revenue is $25M/month after four years at a 5% weekly growth rate. In some one else's venture funded company just 0.5% of a 1B market cap is $5M in long term capital gains. 25% left of your own company which is not trying for VC sized returns with a $20M liquidity event is the same.
Full employment with a good salary (mid-career you can break $200K if you're willing to work for large companies): do something hard well which leverages your decades of experience that let you compete against youngsters even though you cost more. My thing is systems software for business critical applications with an emphasis on distributed systems and high availability. I've done cellular base station infrastructure, digital video for the broadcast market, block storage on a clusters of x86 PCs, light weight key-value storage on spinning disks and flash, and am now doing enterprise grade cloud backup. Although I confess to having worked on one C# project and a couple in Java the rest has been evenly split between C and C++. Language and libraries are not the hard part and I've worked in groups where nearly everyone is over 40.
A paycheck now: Join a contracting/consulting shop which takes a third off the top.
While learning new technologies is fun and neat, with anything trendy where the meat is in the mechanics of how you do things not what you're doing you will be competing with young guys who can get the job done well enough and are more enthusiastic, compliant, and willing to work for less money.
It depends on how you define 'programmer'.
Most people could learn to do trivial (count 1 to 10 in a loop) and simple things.
OTOH less than 1% of professional programmers whose resumes are filtered by recruiters paid on contingency have all the aptitudes necessary to do well in the commercial environments I work on (I think a larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal and not go through a recruiter).
Those aptitudes are
1. The ability to think logically, identify edge conditions, and express that
2. The ability to deal with indirection
3. The ability to apply knowledge to engineering problems.
4. The ability to grasp parallelism
I have a set of questions covering these which changes some with time. There aren't any trick questions here - engineers which do well tend to make it through the first question in under 10 minutes and the rest under 5 after which we can talk about their work history and other things. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer.
Such things should be pre-requisites for a computer science degree but aren't because too many people fail when they are and that's bad for the department's cash flow.
My favorite professor taught data structures with her TAs linking students code into their automated test suites with grades based on whether their code actually worked. Supposedly 1/3 of the class failed. Graduates of that program were generally worth hiring.
She was replaced by a more lax instructor that didn't do that and our hire rate went way down.
Where are you guys seeing 6 figure pay? The only positions companies seem to have are very junior positions, for $60k at best. Often they want so much experience and so many skills that the position isn't really junior, but they call it that so they can pay less.
Starting compensation packages at the big silicon valley companies (Apple, Google, Facebook) for new graduates are breaking $100K
http://www.netpaths.net/blog/starting-salaries-of-top-technology-companies-apple-google-microsoft-facebook/
Every mid-career position doing systems software I've talked to people about over the last decade in Boulder, CO; Seattle, WA; and Silicon Valley has paid better than that.
Senior staff and principal engineer roles (actual as opposed to title inflation side effects, with technical leadership responsibilities and 15+ years of experience getting there) are breaking $200K in Seattle and the SF Bay Area - often with much of that stock, although with privately held companies it can be all cash.
Key differentiators here are
1. It's all core not context using Moore's (as in _Crossing the Chasm_) definitions. Core is what your business is where doing it better confers a competitive advantage, like where you sell storage appliances and they're faster/more reliable/easier to backup than the competition's products. Context are other things that you need to do although doing them better doesn't confer a competitive, like having an on-line shopping site. If it takes 10 ms to complete a user checkout instead of 100ms you won't sell any more product.
2. Meaty. Some things are harder to do well enough than others. Scattering enterprise data over a shared nothing cluster and not ever loosing any is harder than a smart phone app to play Pictionary (TM).
3. It's all in geographic areas where lots of that sort of thing is going on. I'd recommend Silicon Valley because being here radically increases your chances of finding a good combination of product life cycle, interesting technical challenges, and viable business plan. The weather is great too - I wear shorts year round. Of course, $100K doesn't go as far where apartment rent can run $2000-$3000. I bought myself a nice double wide mobile home so I could have a nice place to live without a cash flow situation I objected to.
Such positions being open to you are a separate issue. About 1 in 200 resumes received from recruiters paid on contingency filtered for people who do meaty things belongs to some one worth hiring due to deficiencies in things that seem to be aptitudes not skills and should be pre-requisites for a computer science degree although weeding people out there cuts the department budget. Those aptitudes are
1. The ability to think logically, identify edge conditions, and express that
2. The ability to deal with indirection
3. The ability to apply knowledge to engineering problems.
4. The ability to grasp parallelism
I think a much larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal.
1. 100% binary compatibility with Windows binaries. Many people have some "killer app" that they need to run which is Windows and/or Mac only.
As it stands, I need to boot into Windows to run Sketchup.
2. 100% binary compatibility with Windows device drivers.
My Linux wifi driver often flakes out talking to one access point with a panic which requires manual intervention. The last Fedora I tried progressively increased my fan speed running X until I had a jet engine until the next reboot. My Windows drivers don't do that.
3. 100% binary compatibility with Linux, including 32 bit binaries on 64 bit systems.
It's a pain in the butt as a company to deal with multiple Linux versions in terms of builds, test, and support. It's a pain as user where the software you want has the wrong flavor.
I have 32 bit Firefox (with 32 bit only plugins that I need for reliability) mostly working on a 64 bit Debian, although some of the libraries have hard-coded paths in them which produce frightening error messages and I never got the Java plugin to work which I'd need to use my company VPN.
The (non) viability of this (as a hobbyist I don't want to waste my life reverse engineering Microsoft APIs, and as a business I don't care whether my servers run desktop applications) is a separate issue.
When time is short and changes are being made fast and furiously, or prototyping is being done, time spent commenting comes out of time getting something completed under a harsh deadline...
That's a naive simplification that's not really true. Software development is _not_ a zero sum game and time doing things which "don't ship to customers" both reduce total time and make it more predictable so your time commitments are less likely to become harsh.
Your milestone is _not_ code complete. It's delivering a product to customers which meets some requirement set including quality. The time to get there is something like
Requirements
+ Functional spec
+ Write and comment tests
+ Design
+ Write & comment code
+ Manual test execution
+ New feature bug count * (interrupt overhead + average time to fix new bugs)
+ Regression count * (interrupt overhead + average time to fix regressions)
+ Bug count from previous releases * (interrupt overhead + average time to fix previously latent bugs)
where some steps may be trivial and there are nested feedback loops around others.
The terms are neither constant, functions with project size as the only input, nor independent.
Generating a good comment causes your ideas to flow through other parts of your brain so you develop a better understanding of what's going on thus reducing the defect rate in terms of new bugs.
Having done so before means you have a better understanding of what was already going on, so you have fewer regressions and where they happen there's less context switch overhead figuring out what was going on so you can fix them.
The reduced bug count from previous releases multiplied by lower interrupt overhead means you loose less time there.
Better test coverage means more bugs are found early where the time to figure out what you were doing when you caused them is lower. Lower level test coverage means everything is more isolated so the time to correct each one is lower.
Designing for validation so that's manageable encourages better encapsulation within components and smaller component size which reduces both bug count and the time to correct each one.
Etc.
Seriously. Where exactly does experience as a developer get you, other than more dead end jobs as a developer?
Interesting problems to solve, flexible hours, and six figure compensation packages where willingness to work for a big company can make the first digit more than '1'.
I can't name any other profession where you can get most of that with a four year degree (or less; almost every place you want to work cares more about you knowing the things you should have learned in engineering school than having the degree) where being a doctor or lawyer could net the pay and interesting problems.
That is somewhat better than most entrepreneurial experiences which lead to zero.
>This "building an app is like mass producing a chemical" philosophy is one reason why most software shops have insane amounts of unneeded documentation and overhead
In 20 years working as a software engineer I've yet to encounter a software shop with insane amounts of unneeded documentation. The majority of software organizations I've dealt with had inadequate documentation and process which led to lower quality for customers, lower developer throughput, and unpredictable release schedules.
Usually this comes from deep seated religious beliefs among executive teams and mid-level managers. To quote one CEO "Test code doesn't ship to customers." He practiced what he preached, directing employees to build product and not test too much. Another company managed a two billion dollar market cap from a product very similar to one the he abandoned because the schedule kept slipping and it never worked well enough (although engineering staff kept strongly suggesting hardware validation).
Nothing can change that religion. You can apply better process to your own projects and illustrate order-of-magnitude lower defect rates and time to fix bugs that result from that compared to similar sized projects in the organization without the process. You can talk about the business benefits from positive experiences in other companies. You can sometimes get them to read books like _The Clean Coder: A Code of Conduct for Professional Programmers_. You can share your amusing anecdote about the company you didn't work for because one of the founders did not believe in unit tests so you knew they were going to crater due to low quality and long unpredictable release cycles which had their VCs rescind funding due to customer issues with quality and long and unpredictable delays for bug fixes. You can get other executive team members on the right side and attempt an intervention although the same skills of persuasion which get tens of millions from investors work to move them back. You can go to the board of directors although they're friends with the executive team and it doesn't end well.
Occasionally it's just ignorance. Software engineers can go through a lot of positions without stumbling across someplace that does a good job. This is easily fixed - once competent people have seen how much tedium process removes from their lives and how it lets them focus on interesting problems they get with the program.
While software development is an art, there are accepted processes not too different from mass production that make higher quality, shorter delivery times, and more predictable schedules likely. Although that doesn't sound like fun they do allow the engineer to spend more time on art (which is fun) and less on mechanics so it's a win-win-win for customers., company, and coder.
I have encountered unneeded overhead which can be another facet of the same problem or something else. Sometimes companies grow too fast and create extra positions filled by people that need to justify their jobs. Sometimes the executives who direct less testing become unhappy with the unpredictable product cycles which result and decide to apply the daily meeting (except for 1-2 hours) from the agile world without the things which make agile work.
Although the failure modes differ, 'C' and its interactions with its typical user isn't less safe than Java.
'C' programmers know that they need to free their resources and make a habbit of it. Half decent ones even use a naming convention which implies dynamic allocation (ex: message_alloc) and suggests that code readers remember to apply a corresponding function when they're done (message_free).
Java programmers generally assume that their resources will be garbage collected soon enough. While often true for memory, failures involving non-memory objects like file descriptors are not uncommon.
'C' programmers almost never use a goto to get out of the middle of a function. Java programmers both do so regularly (in the form of exceptions) and neglect to catch/cleanup non-memory resources/rethrow.
1920x1080 on a 15" screen is good for a pair of 80 column x 60 line text areas at a nice size and three 80 column x 70 line text areas at a legible size with space left over at the top of the screen for icons + useless window title bar.
Opened on the same source file that's 120 lines and 210 lines respectively.
If that's still too limiting your code needs to be refactored into smaller more abstract pieces.
>There is a big downside to this. There is a very high risk when you work into startups. You could be rolling in success one month, and the next month you could be forced to shutdown. TFA and most comments on startups looking inside out, don't often write about the stress that comes with this kind of risk.
After 19 years in industry including five full time startup jobs I don't think there's a quantitative difference in job stability between working at a startup and working at a big company. Only the details vary. Some details are important - how much warning you have and potential for a severance package in the unlikely event you don't retain "a" job. Some are less important - your project, perhaps team, and maybe office end when the product is "complete" and sent off-shore for sustaining engineering, a competing group with better political connections has your product slated for end of life, your group gets re-organized to deal with issues on other products, the company built the wrong product and/or sold it in the wrong way and/or had the wrong target market so it either pivots (most likely end of project) or runs out of money (read on).
I suspect keeping a job when a startup runs out of money isn't appreciably less likely than at a big company. Two out of five of the startups I worked for ran out of money and had substantially all of their assets acquired by larger companies (one was acquired for more than corporate debt and VC investments, one pivoted and has yet to run out of money, and the current one is doing well). You show up at work, are told you no longer have a job, and get an offer letter from the acquiring company (you can't actually sell people) with a raise.
>And you know what? We have a lot of fun, but we have plenty of 60 hour weeks too, when shit hits the fan.
That's a software industry problem that's not unique to startups. Software engineering groups almost never architect things in a way that facilitates testing and validation. Combined with insufficient automated testing that leads to release cycles that are both long and unpredictable. Feature sets often change without schedule changes.
All of that is completely unnecessary, but neither anecdotal evidence from personal experience, book cites, nor examples within the company are enough to convince people that the choice between quality and speedy delivery usually is both or neither not either.
Daily stand-up meetings are a huge productivity drain compared to communication via e-mail where high bandwidth is not required with ad-hoc meetings scheduled as needed with defined agendas structured to require as few people as possible. I like to add my agenda to the white board with any other issues that come up which aren't on the list discussed later with just the people who are required and interested.
You have the direct costs (12 engineers * .25 hours / day * 5 days/week * ( 52 weeks - 10 company holidays) * $100/hour fully burdened costs = $75K/year), the impact on work happening about that time (it can take another 20 minutes to get back into a flow state so to over-simplify that meeting is costing you a full-time employee), and what you loose due to employee morale (nearly all of a scrum group I worked with left within a minute or two of eight hours after the morning meeting).
Some of the things which go with scrum are good, like feedback on progress against the schedule, visibility into what other people are working on and their blocking issues but can be handled in other ways without being a scheduled interruption for the entire group (there are plugins for Trac and JIRA, you can e-mail summaries out to your group with whatever frequency works, you probably should be talking to anyone you're blocked on before tomorrow's standing meeting)
Find a job with better management and more interesting technical challenges, quit your current job, and re-discover your love for programming.
I screen resumes for signs that a candidate has done non-trivial things which may have required original thought and application of data structures, although I don't care whether that was at a day job, in a free software project, or in an interesting project class at school like compiler construction. I figure that people 10 years into their career who haven't managed to do that either lack the aptitude (and aren't going to learn it) or interest (in which case I don't want them either).
Once I bring them in we ask a simple programming question (about as hard as reversing a C string, doable in a single for loop although the most obvious solution uses a pair of inner loops inside a while loop, nearly all candidates worth hiring manage a linear time solution in not much over five minutes), a simple data structures question, a simple design question, another data structure/multi-threaded question design question, for some thoughts on software process, and the usual background questions.
As a competent programmer you'd have no problem getting through that (it's surprising how bad nearly all job candidates are).
I do systems software.
My last encounter with trees, threads, priority queues, condition variables, and mutexes was this afternoon and any one I hired could be doing the same thing on their first day of work.
I don't risk giving guys their first job, although I include free software and interesting project classes the equivalent.
I ask every candidate regardless of seniority (you can get surprisingly far in industry without much skill beyond high-level hand waving)
1) A simple programming question with a couple of edge conditions. It can be solved in one loop although I'm very happy with candidates who use an obviously correct solution with a pair of inner loops which totals 17 lines including braces where not technically needed added in the K&R style. I don't mind pointing out an edge condition that's been missed, just that they address it in the end (in the real world a test would find it).
2) A simple data structure question. I give an API with three functions, ask what data structures the candidate would use, and what the operational complexity on the three functions would be. I don't want an optimal answer, just something workable, and don't mind answers like "some sort of" that would lead to a book or web lookup. I'd be happy enough with an STL container answer; although pretty much everyone without the basics doesn't do well at that abstraction level either.
Candidates worth hiring in my opinion and the majority who've passed hours of less hands-on interviews take about five minutes for each (maybe ten minutes for the first problem if they've been withering away as a project manager which is fine) after which I ask a five minute thread question and spend the remainder of the time talking about what they've done and assessing whether they have attitudes about software test and process commensurate with time in industry.
Ones not worth hiring can spend an hour on the first problem and still fail to get it when I explain how it would work in English with diagrams.
I ask all of those questions and then quantify the quality of code, build system, and test effort by getting a code+test walk through plus demonstration of a build+test cycle.
It still fails
1) Following re-organizations into other groups with less lax standards
2) Following organizational pivots where upper management decides they don't have time for reasonable development processes (even though they make schedules both shorter and more predictable!) and spineless engineers go along with it.
>Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.
Nope.
1. In some cases the decision to eschew good test automation comes from the top in an effort to reduce time to market by reducing total lines of code. To quote one CEO I worked with, "We'll add quality later" followed by mumblings about how engineering would rewrite the code a bunch of times and would to save time by getting to the final product and then testing." No number of personal anecdotes, quotes from papers and books, reasoned arguments, supporting arguments from executive staff, etc. showing that a smarter and more thorough test effort makes time to market shorter and more predictable will change things. The best you can do is take care of your own corner of the product, point out the places where you fixed certain types of bugs in X hours versus X weeks by group members not doing that, hope your co-workers join you, and hope for a leadership change that will be more receptive to your input before the company tanks.
2. Most developers can make it a decade into their career without both grasping the utility (fewer bugs reaching users that become irate, less effort to fix the bugs you do find, more predicable schedules so that death marches are less likely, less integration pain with fewer errors) of and choosing to apply good test automation and continuous integration. They can be impervious to talk, management buying people copies of relevant books (The Clean Coder, XP: Extreme Programming Explained, etc.) in their choice of print or Kindle edition and telling them to read it at work whenever they want, a rubber chicken or toilet plunger for whoever last broke things, etc. You need to get management buy in with leadership willing to hire and fire if people won't get in line.
In both cases you may be better off finding a more sensible job.
While at most half on home-row, Control-[ is a much smaller stretch than Escape which is so far up the left side you probably can't hit it without moving your entire left hand.