Some Facts about Working

Achieving Productivity
Re-use instead of Start-over

Do you honestly believe that if you employ someone for 9 hours, you’ll get an average of close to 9 hours worth of code writing a day? Probably not. Programmers tend to get distracted. They find it hard to start coding. They need to think about what they do. They need to take breaks for various things (like drinking, eating, talking with their co-workers, etc.).

Furthermore, actual code writing is not the most productive activity, as surprising as it sounds. That’s because if one writes code exclusively for too long, his mind will run in circles and he’ll lose his edge. And there’s something that is even more productive than actually producing output.

That thing is revolutionary decisions. Decisions that make one more productive in the future, restructure one’s code (or one’s text or whatever) in completely better ways, or allow the worker to do something in a better way. The more such decisions he reaches, the more productive he is, and the more value he is to his company. He’s no longer just a code monkey - he’s a “Rosh Gadol” and innovative programmer, who is of much more value to the company than just someone who writes the code that other people told him how it should behave.

Achieving Productivity

If you want your programmers to be as productive as possible, make sure you hire good programmers, who can reflect on what they do, learn more, and who are enthusiastic about writing code and like it. Only they can be of value to you.

Paul Graham called these developers “Great Hackers” in an essay he wrote. As I said before, I can testify I’m a good (or “above-average”) programmer (and other things), but not that I’m a great one. That’s because the baker cannot testify for the quality of his dough. However, I know some people whom I can tell are great hackers.

Who are they? They are people who come up with wonderful ideas. Who are interested in many things inside or outside computers. They often can write a lot of good code, but often their code is wonderfully ugly, but still very functional, mostly bug-free, feature-rich and efficient.

Re-use instead of Start-over

Another important factor, that is not always present in nascent programmers, is their desire or even necessity to re-use code, however ugly it may seem. Eric Raymond wrote about it in “the Cathedral and the Bazaar”:

So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself “Which one is closest to what I want?” Because:

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).

While I don’t claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.

Later on Joel Spolsky expanded on it in “Things You Should Never Do, Part I”, and “Rub a dub dub”, and it’s also been extensively documented elsewhere.

If your programmer is keen on labelling a code as “ugly”, “unusable” or “I’d like completely rewrite it from scratch”, then he’ll waste your time and be unhappy and under-productive.

Instead he should say: “give me some time to whip this code back into shape, by refactoring it [= cleaning it up]”. Believe it or not, but refactoring actually saves time, as Joel demonstrates in “Rub-a-dub-dub” and Martin Fowler in his “Refactoring” book.

So if you hire a beginning programmer with a good potential who’s full of this (bad) attitude, give him or her this reading list. It will be faster and more fun to improve the quality of the code, rather than to rewrite it from scratch.