Hiring Good Programmers Matters 681
Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."
And exactly what is a 'good' programmer? (Score:2, Interesting)
Lord knows that applies to artists, look at the paintings that Botticelli did of me back when I was still alive compared to the ones done all of those other greasy creeps.
But programming is supposed to be a science and a process. If you prepare a precision algorythm and carefully test it before coding with all manner of valid and absurd inputs, then it shouldn't matter what level of so called skill a programmer has when the coding proceeds.
Oh, you mean a 'good programmer' is one who by lucky accident gets working code without using developing a complete algorythm first? What do you guys do, design microwave ovens for a living?
There's no such thing as a good vs average programmer. There's only those who follow the algorythm and the lucky artists.
Thank you,
Simonetta Vespucci 1454-1476 Florence, EU
my own experiences (Score:3, Interesting)
The first, and the majority at our company, are school trained programmers. These are people whose main experience with coding has been either class related (where the emphasis is usually on theoretical applications) or employement related (where the emphasis is usually along the lines of "just get it done").
The second group of programmers, which I'm in, is the hobbyist turned professional. We are people that began programming for fun, and often program on weekends on side-projects. Data structures and interface definitions become part of our regular vocabulary, and it's often hard to talk to programmers in the first group regarding projects.
Also, from my own experiences at work, I can say that it's the smaller second group of programmers that end up carrying most of a software project, both in code output and internal design. Although the first group of programmers tend to do a better job at testing.
Re:I Couldn't Agree More (Score:3, Interesting)
I agree that easier-to-use tools are making it easier for poor programmers to both sneak in and through their careers without being caught for the frauds they are. But at the same time, at least some of the easy-to-use tools are... easier to use. For experts, too.
I actually have a thought on this: Requiring applicants to write something in a pseudo-language. The language is defined on a handful of pages given to him, and he has to solve a couple simple problems in that language. I think it would be a great barrier to block idiots from getting in.
Re:Software application development comes down to. (Score:5, Interesting)
Re:my own experiences (Score:4, Interesting)
Re:The answer depends (Score:5, Interesting)
Re:The full saying is... (Score:4, Interesting)
software development costs (Score:2, Interesting)
kind of circular (Score:3, Interesting)
"Good" can mean many things. Joel largely represents mainstream views of Windows and Macintosh programmers--the kind of views you might find among Microsoft Office, Microsoft Windows XP kernel, Safari, or even Mozilla developers. If you want to be like one of those developers, then follow his advice. If you think that there is something seriously wrong with that kind of software (as I do), then you would do well to read Joel's writings more critically and assume that some of it is bad advice. Thinking about those issues will still make you a better programmer.
Re:Cost of Quality (Score:5, Interesting)
Let them do process busy work as well.
A few months back we were too crunched on the schedule, but another project had cancelled so there were loads of bodies available. But putting them to work coding would have destroyed the project. As always, upper management didn't understand that. So when I was asked where I could best use some extra help, I answered truthfully: have someone else write all the freaking documentation and attend all the freaking meetings so I dont' have to. Tada! They listened and I ended up with four extra hours per day to get the work done.
p.s. Of course, management never learns. Another project is slipping and they're throwing people at it as fast as they can cancel projects. Sigh.
Re:I hope he's wrong (Score:3, Interesting)
Re:PLEASE mod parent up! (Score:1, Interesting)
If you've ever heard Arlo Guthrie's "Alice's Restaurant", and missed the day the muse dragged me from my cubicle to spend an afternoon doing a parody called Natalie's Restaurant [slashdot.org]... well, not to brag, but you're in for a treat.
(Arlo still did it better, though - I couldn't have come up with it except for having his original to work from :)
Re:Can't Go Wrong (Score:2, Interesting)
Interesting that you say this given that a raging debate on JOS during the release week of this article featured an endless stream of readers mortally offended that Joel casually dismissed service type developers (e.g. the financial industry, etc). The vast majority of "developers" out there don't work for shrinkwrap shops, but rather get their bread and butter making VB forms and so on, and many of these people were offended by Joel's article.
But do you want to be a great programmer? (Score:2, Interesting)
After forty years of programming, was it worth it? Often I wonder. I've tried very hard to do good work, whether anyone cared or not. Sometimes it paid off. Sometimes it didn't. But always good work.
But I haven't had much of a life. I spent the Summer of Love in a mainframe computer installation. I've never married. Had a few girlfriends, but wasn't really into it. I'm not into nerd culture, either; I hate Star Trek, and haven't seen the new Star Wars. Nor am I a gamer, although I get royalties from technology in games you've probably played.
And not because I'm the sterotypical overweight geek. I work out, and took jazz dance for years. That's not it. It's just my destiny to program. Whether I want to or not.
Good programmer? (Score:2, Interesting)
Social skills (Score:2, Interesting)
When working in a group it's the productivity of the group that counts - not the amount of code that a single member can dish out. And to a large degree I find the group productivity to be unrelated to the individual coding skills of its members.
A good programmer helps develop an atmosphere where:
Of cause I'm just your average XP hippie...
Speaking from experience... (Score:3, Interesting)
Reuse of code (Score:1, Interesting)
Some superguru perl coder writes an snmp application from the ground up in 2 weeks. The less experienced perl coder uses the modules available on cpan and fixes the job in a day.
Just a thought.
Re:The answer depends (Score:5, Interesting)
I've written projects with HIGHLY detailed specs. I've talked to people high and low. I've gotten signatures in triplicate.
And, those are the projects that BOMB QUICKLY AND PAINFULLY.
The last time I tried that approach, I was told on the DAY OF ROLLOUT after 1.5 months of full-time development that it "wouldn't work" and had to be "totally redone".
I screamed, bitched, complained, waved contracts, specifications and all, before spending another 2.5 months rewriting the application. (while people were using it!)
So, now I do things differently. I spend a bit of time, get a spec, and send out an email to all involved, and wait for 24 hours. Then I write it, knowing full well that it will suck upon delivery, and I make this knowledge apparent, obvious, and common.
Then, the comments come. The text is hard to read. It doesn't include N-ARCANE-FEATURE. When you click the button called "Save", it saves it, but it's not obvious what you are saving.
Whatever. The feedback comes in spades.
So, focus on making updates quick and easy, and listen. That's the Linux way: release early, release often.
People will tell you what they like and don't like. Listen, and release an update when you add new features.
In my flagship product, I've released over 40 releases in a single year. It'd be painful, except that the product updates itself, and it takes me all of about 10 minutes to release. Really.
It costs each user about the same - 5-10 minutes, and they can do it whenever they like.
So, I release early, I release often, and I listen closely to the feedback. Users get what they want, and I get what I want. (Users' money!)
Re:The answer depends (Score:4, Interesting)
In the UK that means that there is a bid. The lowest bidder gets it, they employ the cheapest coders on the planet, farm as much off shore as possible, and then waste millions supporting crappy software. We're now in a situation where we can't trust the government with ANY software creation. They got the passport software wrong (well to start with), they got the tax software wrong (New Tax Credits was a fiasco) and they got the air traffic control wrong (fortunately nobody has died... yet).
What Joel says rings so true that its scary to think that the really important software will NEVER be written like this. But what can you do to remedy the situation? Because there is no market, you can't expect competition to improve the quality of the code, the only incentive being fines to companies when they get it wrong - thats no incentive, that just makes accountants want to do just a good enough job not to get fined.
Do you open source the problem? While I agree that security through obscurity is not security at all, you will never get a country that thinks its a good idea to ahve its tax software open to all to see. There is also Brookes law to deal with and there is still no guarentee that you will attract the best of the best.
Anyways... fascinating article!
In fact you really CAN have BOTH "qualities" (Score:1, Interesting)
In fact, there are many huge companies making billions and billions of dollars that will go to India or a struggling Eastern European country, and hire GREAT programmers/gurus for something like 10 times less money than their peers working in the headquarters.
I find this insulting for both programmers: one is forced to work cheaper or even loses his/her job, while the other is paid way less even though they may be working for the same company, and producing the same quality/ammount of code.
Just my 2 cents.
Take a look at Siemens (Score:1, Interesting)
They have like 45k of developers (more then Microsoft or Oracle, if I'm not mistaken) and I don't think that many of you can name some good software product that came from Siemens.
Being a Siemens employee I can tell you that things are quite the opposite of what Joel believes software development should look like.
On the other hand Siemens is so mind bogglingly big that perhaps there are departments for which the above does not hold. It also means that they can sell crappy software.
And get catastrophe code like this? (Score:3, Interesting)
The corporation I work for had at some point decided to replace an existing, working system with a monstrosity that had more buzzwords. So a team from a BIG corporation contracted the work, and took a couple of years at it, until finally the project was scrapped.
By the time it was scrapped, the code they had produced, although it did compile, had major problems, including fatal security issues. (And it also needed a cluster of two dozen servers to serve the same number of users as the old system did on 1 server. And took several hours to even start or stop. Literally.) Among other problems:
- they consistently assumed that the _only_ way to reach a page was to click on a link, so they didn't have to check rights again when rendering it. The user wouldn't have gotten the link to it, if he didn't already have the rights, right?
Wrong. By such trivial means as just editing the user id in the URL to 0, you could become super-user or change anyone else's password. (E.g., the super-user's.) And basically gain full admin rights to a corporate site.
- they failed _repeatedly_ to quote text displayed on the site. So you could simply type some JavaScript code in a text box, and have it execute (e.g., on mouse-over) in the browser of whoever views that post or offer. Again, one possible and demonstrated use was to steal or change someone's data, including an admin's.
- they failed _repeatedly_ to quote text used in SQL queries. So basically you just needed to input something like '" OR "1"="1' in the search field, and you'd get all the records on the system.
- they failed to even conside "non-repudiation". If a user cancelled their account, a cascaded delete would ensue, deleting _all_ the data about that user or from that user, including contracts. It was suddenly as if that user had never even existed, ordered or paid anything.
Etc.
We're talking about a B2B e-commerce site, with contracts worth millions, not about someone's blog about their cats. And it had gapping holes bigger than the goatse guy, for f**k's sake. As they wanted to ship it, it _literally_ allowed anyone to access any data and escalate their privileges to the max, in just a few kestrokes.
_That_ is a problem with making software with a team of incompetent monkeys. It's not just that they take longer to produce the code, or that it might need more debugging. It's that they just don't have the skill or knowledge to judge (or even consider) the implications of the choices they're doing at each step.
Re:That's such a bunch of bullshit (Score:3, Interesting)
That's a matter of perspective. If a "good" dev produces work that does the same thing in the same amount of time as an "average" dev, why is he a good dev? (Obviously this has to hold in the long run, and not just at the time of first writing, and usually this is where the difference lies. Clean designs and good documentation practices usually exhibit their greatest benefits during maintenance.)
Or that your algorithm is inherently complicated. I work with deeply nested logic all the time, yet the project I work on is very successful, and the developer team here has a good reputation. People who assume we're not good at design because we don't agree with their dogma annoy me.
Re:The answer depends (Score:2, Interesting)
Then you might be doing it the wrong way. To make the drudgery interesting again, you generalize to an interesting problem, then solve the original problem as a special case. In the case of UIs, you should probably write a tool that makes writing UIs easier.
"I'd rather write code to write code than write code."
Not just programmers (Score:3, Interesting)
I used to run the mechanical engineering section for a small project. We used a lot of contract CAD guys. A good CAD guy was about 4 times more productive than an average one, and would cost 0-30% more, per hour.
With engineers my experience is that the best engineers are roughly 4-10 times faster and more accurate than the average guy, and the bad ones have a negative effect on productivity.
War story: two of us redesigned a system and saved 200 bucks per unit. We make 100 000 units per year. So that's $20 million a year.
Somebody redesigned one of my parts, saving $0.30 per unit. We had to recall several tens of thousands of units because the new design was unsafe. Total cost in excess of 10 million dollars.
I have seen parts with identical functionality. One was designed by an idiot and cost twenty bucks. The other was designed by a competent engineer. $3
conclusions and data seem totally unrelated (Score:2, Interesting)
- programming seems to take almost arbitrarily long; there appears to be next to no limit on maximum time and deviation (except hard deadlines)
- there is no correlation at all between the time used and the quality of the result
The question is whether quality correlates with other variables than time, more specifically, with the programmer.
So the next step should be: when looking at the scores of individual programmers, do we see consistency? Is there such a thing as a "good" programmer, who scores consistently better quality than the average programmer?
Joel's report becomes a little ambiguous at this point. He selects "the top 25% programmers" without saying how. I'm confident he selected the programmers who took the first 25% of overall (averaged) quality scores. I do not believe he selected the first 25% of results for every exercise, but the wording doesn't completely exclude it.
He reports that, collectively, these top 25% of programmers take almost exactly as much time as the rest (both in maximum and in deviation).
He then leaves the data and starts about the difference between good and average programmers. This is a total non sequitur. Nothing he says about that difference is supported by his analysis.
It might seem at first glance that the analysis supports the notion that there is such a thing as "the good programmer". But it doesn't. Joel doesn't give us any information on whether some programmers perform better than others. He looks at the ones that came out in the top 25% and *calls* them the "best programmers". For all we know, the quality scores were completely random and the programmers that came out on top just got lucky this time. To see if quality of code is correlated with the programmer writing it, we should see if there is any consistency in the difference between individual programmers' scores across exercises. Joel didn't do this. He committed the classical logical error of assuming what he wanted to demonstrate, namely, that there is a difference between "good" and "average" programmers.
For now, let's gloss over this fatal weakness and go along with Joel's (plausible) hypothesis that there is such a thing as a difference between "good" and "average" programmers. We now come to the strong point of the article. Joel was, of course, hoping to find that the programmers who produced (on average) the best quality code were also the faster ones. But they aren't: they are just as slow as the average programmer.
It's to Joel's credit that he doesn't hesitate to report these findings, since in my eyes they are fatal to the hypothesis he started out with.
What these figures prove is that the good programmers (those with good results on average) are just as slow as the average ones. The difference in productivity solely consisted of the fact that the top 25% got better results - but that is not exactly surprising, since it is how they were selected.
Amazingly, Joel draws the opposite conclusion: these same figures are supposed to demonstrate a 5-10 times speed difference between programmers! But that is only when measuring on individual exercises. It is completely unwarranted to draw any conclusions on the speed difference across exercises.
OK, so we don't really see any difference in productivity. "But wait, there is more! (...) No matter how long (mediocre programmers) work, they never produce something as good as what the great programmers can produce."
Um, where exactly did we see this? Did the data provide any evidence that some programmers never find good solutions? Nope. Do some programmers arrive at good solutions all the time? No idea. if they did, I would think they would also work faster than the average programmer, and they don't. SO again, Joel is pulling his statement out of thin air, and the relationship with the data is no more than suggestion.
On the whole, an interesting, but flawed article.
Deadlines are killing quality... (Score:1, Interesting)
In most cases, someone says "we need something NOW", and it is a scramble to just barely come up with something working by the deadline. Documentation or testing are certainly out the window.
And clients don't care about anything they can't see (meaning, they will have a 6 hour meeting on the color scheme of a web app, but don't care if the code is so convoluted that no-one else will be able to work on it without reverse engineering it). The sad thing is in the long run it costs them more time and money.