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

Re:Software application development comes down to.

[Xugumad]

Another point to keep in mind that not all your programmers have to the above average, or even average. For example, we have a student helping out over summer. She just doesn't have the breadth of experience for us to trust her with architecture design or the most complex programming tasks, but there are lots of simpler, straight forward jobs that she can do. And working at around half my salary (per hour), she's a hell of a lot cheaper than hiring a graduate programmer with several years experience.

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.

Re:Cost of Quality

[Brandybuck]

If you want to add bodies, let them do review work.

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:The answer depends

[mcrbids]

Where you go wrong is that people don't actually know what they want!

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!)