The Man Who was Too Lazy to Fail

will code for foodRobert Heinlein in his “Time Enough for Love” tells the story of the man who was too lazy to fail. The basic idea behind this story is that if you fail in something you want to do, you have to do it over again – double the work – thus not the right thing for a truly lazy person.

I remembered this story when the article A Guide to Hiring Programmers: The High Cost of Low Quality crossed my desk. A little bit of an excerpt…

I was invited to a wonderful dinner party (I swear it wasn’t too spicy Sarah!) with some St. Louis Perl peoples this week while I’m here on business. At one point we were talking about hiring programmers, specifically Perl programmers.

We agreed on the following:

  • Finding good programmers is hard in any language. And that a good programmer can be as effective as 5-10 average programmers.
  • Average pay rates between equivalent programmers are out of sync and are based more on the language used than the skill of the programmer.
  • You don’t need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.
  • You should seriously consider allowing your expert developers to telecommute full-time. Restricting your search to programmers who live in your area or are willing to move limits the talent you can acquire. Arguments regarding “face time”, productivity, etc. can easily be nullified when you look at how some of the largest and most successful Open Source projects such as Linux, Apache, and Firefox are developed by individuals rarely living in the same time zone or even country.

That is something I could agree with as well!

On the hand I had been always very curious why many bosses want bodies in the shop. It’s highly inefficient and certainly does not raise the morale or anything in this arena.

On the other hand I can see that if there is a boss who does not really understand what is going on wants at least something he can measure and understand. And I am able to see that this could be a bunch of busy bodies in the cubicled office space.

Now, if you are in this business for a while you know that being busy is counter-productive in the field of programming. Maybe during the time when you type in some program the impression of a busy programmer is appropriate. But what is the percentage of time where a good programmer actually types some original code?

Five percent – four – less? Certainly not more.

We are talking about good programmers here, just to make sure. The not so good one will be typing a lot more because he will re-invent the wheel every time the task is a bit different. The good one will re-use already tested code. It might take him a while to find it – a time during which he might be looking lazy to a manager, but this the time where he is, in effect, 5 to 10 times more productive than the low quality programmer.

I remember this one guy – forgot his name, and if I did not would not tell anyways – was a little weasel, always busy running around and typing like a maniac. When he finally left, pretty much everything needed to be re-done.

And to imagine that he got paid nearly the same money I did!

It is, and I can truly appreciate this, very difficult for a manager to determine what is and what is not a good programmer. My principle has been “Let me show you!’ and that has worked very well during the days when I hired myself out as a labor slave.

I either offered to work a month for free but then asked for so much money that I made up for that loss, or I negotiated a deal where the contract amount was rather low, but a big bonus was to be paid if all the requirements of the slave master were met in time and on budget.

To close one more little excerpt from the above article…

What is an expert programmer?

Experience is key, but not necessarily in ways you might imagine. Time in the saddle, with a particular language is not as important as diversity of experience. Someone who has worked in several disparate industries, a generalist, is often a much better developer than one who has spent years in the same industry. There are exceptions to this, but in general I have found this to be the case. Bonus points if your developer was a systems administrator in a former life.

Some of the best developers I know were originally trained as journalists, mathematicians, linguists, and other professions not normally associated with software development.