Hiring Good Programmers Matters

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."

Comments

The answer depends

[SpaceCadetTrav]

Are you trying to build a good application or a cheap application?

Re:The answer depends

[TurtleQ]

As Joel points out, you can have both. He states that, unlike physical products, adding quality to software does not make the software expensive. This is because the cost of "super-programmers" can be divided among the thousands/millions of software licenses sold. The programming cost is fixed, so making it high quality may cost only pennies per sale.

Re:The answer depends

[dusik]

Yeah, you'll notice that a team of cheap programmers writes it like:

printf("Hello world!\n");

// 3 cheap coders x $0.05 = $0.15

A single programming Guru will write it as:

/*
* Hello world!
* Copyright (c) 2005 John "Code Guru" Doe
*
* This programme tells the computer to say hello
* to the world, using correct Engligh grammar.
* It should look like:
*
*     Hello, world!
*
* NOTES
*
*  The programme is limited to one way in which
* it greets the world.  In version 2.0 we may
* include another variant of the phrase.  We
* will need an advanced AI engine for the task.
*
* BUGS
*
*  The punctuation is not entirely correct.
* The programme skips the comma between
* "Hello" and "world".
*
* TODO
*
*  Needs more testing.
*/

// Greet the world.  To do that, we make the
// computer say "Hello, world!".
printf("Hello world!\n");

// 1 guru coder x $80/hr x 8 hours = $640.00

Re:The answer depends

[Marc Rochkind]

Well, many people would call me a "guru programmer," and there's no way I would do this for anything like $80 x 8 hours.

You need error-checking on printf and an error log for the error message, you need to internationalize and localize the string, you need both user and maintenance documentation, and you need a client-server architecture. Not to mention that you seem to have jumped into the project without written requirements, a specification, and usability testing.

This would take about a month at my standard rate of $200/hr.

Re:The answer depends

[heatdeath]

Actually, in some kinds of applications, poor programmers are actually on par or better than smarter programmers. Usually you do your best when you're writing code that is easy enough to understand, but hard enough to keep you interested. I, for one, have no patience for writing simple test UIs, for example, or webpages. But some other people find it challenging enough to keep them interested.

Can't Go Wrong

[Anonymous Coward]

... sucking up to the egos of your readers.

Yes, you're all great programmers, much better than all the others out there. Especially because you read my posts. We need more people just like you.

Cost of Quality

[overshoot]

The argument applies across the board with techies in the design end of things. Throwing bodies at a problem generally makes schedules slip even in the design state; what it does to the test and qualification stages is much worse.

My experience with this is in the IC design part of the world, but the rule remains: you're better off with half the people but good ones.

If you want to add bodies, let them do review work. It actually does contribute to quality, and has the added benefit of making better engineers out of the reviewers (and, IMNSOHO, of those who know that their work is going to be reviewed, too.)

Yes, but...

[TheOtherAgentM]

Can the good programmer create code that compiles with a message, "Error: Too many errors." like I did in college? Now THAT is hard to do.

Software application development comes down to...

[tokengeekgrrl]

1. You can have it done fast.
2. You can have it done cheap.
3. You can have it fully functional

Now pick 2.

Fast and cheap = means using average and inexpensive programmers and is not fully functional

Fast and fully functional = exceptional programmers and will cost an arm and a leg

Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it

The timeline for the application, whether you need it tomorrow or can wait a few years, in addition to the budget determines what kind of programmers you can afford and need to hire.

  - tokengeekgrrl

What does 'best' REALLY mean ?

[haute_sauce]

It is not enough to have 'star' engineers, you MUST have dedicated and motivated individuals. Being a good programmer does not imply willingness to work towards a common goal or play well with others. In some ways I would rather have a team of mediocre programmers who were reliable and worked well together than a couple of 'stars' who had thier own agenda.

Yeah, but

[rsilvergun]

bad programming saves money now. Good managers save money now, and use this success when moving on to a better job. In this day and age of lateral movement and massive layoffs, where odds are you're not gonna be at that job long enough for hiring good programmers to pay off, why bother?

Re:And exactly what is a 'good' programmer?

[humankind]

Here's what I think is the difference between a good programmer and a bad programmer:

1. It has nothing to do with money. You can find good quality developers at both ends of the pay spectrum. In fact, I adamantely believe that the further you get towards the high end of the pay spectrum, the worst the quality is. Too cheap is bad too, but not as bad as too expensive.

2. A good programmer isn't limited to a narrow set of tools or technologies. He will pick the best platform and language/tools based on the application's needs. A bad programmer is one who only knows a small subset of technology and ends up forcing applications to operate within the confines of resources which limit stability, flexibility, performance and productivity.

3. A good programmer spends a lot of time researching the project before ever writing a single line of code. A good programmer demands the client/employer be as detailed as possible regarding the specs of the application. A bad programmer is comfortable with ambiguity relating to product specs. A good programmer, in lieu of getting detailed specs from the client, will create his own outline of what the application will involve and make it finite before coding even starts and make sure the client signs off. Good programmers don't tolerate ambiguity in specs.

4. A good programmer/sub-contractor is more likely to charge a flat rate for the development of the project than an ambiguous time-based wage (but all sub-contractors have to have provisions to deal with project creep and problem clients).

5. Good programmers expose bugs in applications and platforms. Bad programmers create them where they didn't exist.

6. Good programmers always exceed the client's expectations in terms of flexibility and versatility. Bad programmers tend to literally interpret feature lists and make program structure more finite than modular.

and last but by no means least...

7. Good programmers ALWAYS DOCUMENT THEIR CODE WELL! Bad programmers take great pride in making sure nobody can understand what they're doing.

Good programmer = terrible teacher?

[Anonymous Brave Guy]

This was an interesting observation:

I guess the main drawback of this is that most good programmers are often terrible teachers, but that might reflect the lack of a tradition in the field.

Something I've found in many aspects of life is that the people who are really good at something tend to be able to explain it, clearly and accurately, to someone less experienced. This is true of almost any field I've ever studied, from mathematics to martial arts, from driving to dancing.

It's interesting that in Japanese, there is little distinction between being very good/experienced at something, and being a teacher of it. If someone in Japan asks you whether you teach programming, and you're the 20 year veteran Senior Software Engineer at your company, the answer is yes even if you don't teach in the English sense. It's simply implicit that by being good at something, you will be teaching those around you as you do it.

I think the difference between someone who's really good at something and someone who's just OK usually comes down to a depth of understanding. One can follow a cookbook of techniques, or regurgitate information they've been fed in the past. The other writes the cookbook, because they've understood the information and worked out how it all fits together.

A corollary of this is that those who truly understand a subject tend to be better able to convey their understanding to others. Because they can see it from more than one point of view, they can adapt their explanation and examples to fit the knowledge and learning preferences of the person they're trying to teach. Those who never reach that level of understanding can repeat what they were told when they were learning themselves, perhaps even in multiple ways they learned from multiple sources, but they can't adapt it, can't see it from different perspectives and present it in different and original lights.

Thus I'm rather surprised that you think most good programmers are terrible teachers. Most programmers may be terrible teachers, but I question whether a good programmer who is unable to pass on that knowledge is really that good at all. It's unwise to generalise completely, because of course teaching requires skills all of its own, but I've met very few great practitioners in any field who weren't also outstanding teachers.

Other news

[Frankie70]

In other news,
1) Good Carpenters build good furniture
2) Good Architects architect good structures
3) Good Authors write good books