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

Common Sense

[Tweak232]

Is it really that hard to find out that if someone who is good at what they do will do a better job than someone who is not as good? That seems to be common sense.

I guess it is just me... move along now, nothing to see.

Re:The answer depends

[anthony_dipierro]

Not really. You'll spend far more money building an application with poor programmers regardless of the quality of the application. That is, if the poor programmers are ever able to finish at all.

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.

Re:Who is Joel?

[not_anotherFanBoy]

He jumped out of airplanes for the IDF, wrote the spec for VBA while he was the project manager for Excel in the early nineties, started http://www.fogcreek.com/ [fogcreek.com] and made an assload of money.

You can read the rest of his resume here: http://joel.spolsky.com/resume.htm [spolsky.com]

Re:Elitist Programmers

[Tim Browse]

He's not so smart, otherwise he wouldn't be talking about people being asked to "implement a ZLW file compressor" :-)

Re:Who is Joel?

[istartedi]

Shutup. He's cool. Thousands of slashdotters who never had a chance to be cool in any other context now have a priceless opportunity to mimic the in-crowd in highschool by pretending that their pundits of choice have something to say that isn't obvious to anyone with an IQ of 90. Don't blow it for them. These nerds are desperately deprived of coolness and there's no telling what they might do if they don't get their fix.

Re:Elitist Programmers

[Skasta]

He makes a note on another post saying that in the original paper Ziv was first author, which is way he lists it as ZLW.

Re:The answer depends

[Javagator]

Check out Petzold's Windows Programming in C#. Hello World is copyrighted. Seriously.

Re:Elitist Programmers

[Vengie]

Original paper was Ziv and Lempel, later (window refresh) refinement by Welsh. I took CS323. I wrote this code. I'm pretty surprised by the number of people here that have NFC and are posting......thanks for not being one of them. (Them being those that lack the FC)

Re:The answer depends

[Savantissimo]

Joel is clearly right about the quality and speed of the programming depending entirely on the quality of the programmers. But then he pulls a fast one and assumes that those same people are the best at anticipating what users want and designing the parts of the software that the user interacts with, and that is a rather questionable assumption. How many times have you seen a beautiful interface with unstable code (many media players come to mind) or a crappy interface with code that is like Bach in bytes (TeX, anyone?). There's a lot more that's important in making great software than coding.

My pet theory - and I admit I'm talking out my ass here - is that managing new software development ought to go like this:

1. Decide what you are going to make. Get a reality check from the intended audience. Don't assume that everyone likes or needs what a super-programmer thinks is spiffy.

2. Design and mock-up all the static parts of the user interface and informally specify user-visible behaviors. Have someone who understands visual design and industrial psychology take the lead in directing the UI design with the programmers in a supporting role and management only there to back up the designer's decisions when requested. Get the best such person you can find, even if you think you can't afford her. This person is as important as everybody else on the project put together. Come up with as many radical variations as possible the first couple times through. Be bold and elegant and try to come up with things the user didn't even know she wanted. Have the UI design person get user feedback with the programmers present but with the understanding that they are there to find ways to make what the designer wants and the user needs happen and not to raise problems that programmers can solve on their own. The UI guy needs to be ruthless in excluding things that will get in the way, no matter how cool the programmers think the feature is. Repeat step 2 until the programmers start to lose their minds or the design converges in detail.

3. Formally specify all user-visible behavior by writing the complete user documentation before the first line of code gets written. Have the UI designer and the tech writer work together on the outline and have the programmers looking over the writer's shoulder as the bulk of the text is written. If there is no tech writer, get the UI person to do it, if possible. Check with real users again to make sure it makes sense to them.

4. Then let the programmers do their thing. Having hired good people, don't tell them how to factor or comment or code or what languages they should use. Let them add things only so long as it does not affect the user. (General solutions for specific problems, for example.) Before they start, make them hash out whatever rules they like to ensure quality and maintainability - but hold them to their own rules when things get hairy. Make a significant part of their pay (20%-50%) depend on matching the design and documentation to the UI designer's satisfaction, passing testing and meeting or beating target dates they agreed to when they got full control of the project.

5. Short of correcting a thermonuclear fuckup that would otherwise cripple the software, don't allow any changes, additions or deletions to the design by anybody until the whole thing is out the door as planned.

Is this a stupid or impractical way of doing things? What am I missing?

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

[Anonymous Coward]

Obviously this guy (modded up to 5) has not actually worked in the real world. While these are ideals, the difference between a good programmer and a bad programmer is actually none of these (I guess that's why this author is not the one cited orginally) but the ability to produce what is needed in spite of each of these points.

Re:Software application development comes down to.

[scotty]

I think Joel is arguing that, by having your average cheap programmers, you will *never* accomplish that "fully functional" stage, no matter how long it takes.

Joel headed up the excel team at Microsoft

[autopr0n]

Joel was the lead developer of Excel at microsoft for a long time, and he also had a hand in the development of VBScript.

Anyway, his articles are the main reason for his fame these days. His company also has a third product, CoPilot, that lets people fix software problems remotely.

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

[humankind]

Obviously you disagree.

I could respond to your arguments tit-for-tat, but I don't really think it's necessary. If I hired you, I suspect I'd end up having to re-do a lot of what you did, because you seem to be very good at coming up with excuses, which is what a good programmer doesn't do. Anyone who thinks that not documenting code is practical in any environment is not someone I'd respect as a "good programmer". Obviously, your milage does vary. Talk to me when you've developed commercial software that has sold millions of copies and recieved numerous honors and awards. I know what that's like.