I was listening to the Stack Overflow podcast the other day and the discussion turned to hiring. I then thought about an ongoing issue with my family, basically it is endemic to good software engineers, “Why can’t you just stop when you get off work?”
The reason finally dawned on me today. The answer is that we are hired for what we are as opposed to what we do. This is what causes problems when companies hire people who think programming is something they do. Writing software is something that I can’t stop doing. I honestly feel depressed if I have some idea that I don’t work on.
As far as hiring is concerned, it makes sense for these companies to view hiring these types of programmer in the same way you would hire an actor, or an athlete. You are looking for someone who not only has talent, but who also has a natural obsession for solving problems. IMHO talent is useless without practice. I’d take a hardworking programmer with little to no talent over a talented programmer with no work ethic 10 times out of 10.
Realistically, companies don’t need for their whole programming staff to be of this type, but their lead programmers should be. Programmers who only work from 8 to 5 will be fine implementers, but no matter how much schooling they have, they just won’t have the experience to design great software, likewise they aren’t likely to have the passion to dream up the most creative solutions for your toughest problems.
This is why it doesn’t always make sense to pay all of your programmers the same amount, unless you hire only essential programmers, Google strikes me as a company like this. These programmers aren’t necessarily paid for their output, but more for their ideas, so they might often not appear to be doing much of anything. Then suddenly they will be taken with something and will work day and night on it.
In most organizations, the essential programmers are like lead actors, rockstars, and top artists, usually they are a pain, and you may often wonder if they are worth what you are paying them, but the project just wouldn’t go without them.
The key with all of this is to not mistake essential programmers for normal programmers and vice-versa. You will have problems retaining the essential programmer if you hire them to just be a programmer, and you will not get the performance you expect from a regular programmer in a role that should be occupied by an essential programmer.