
This is a very quick read on how to hire programmers. It’s full of insights and interesting thoughts from someone who has been in the trenches of being a programmer and hiring programmers for years, who has succeeded at both tasks, and who has thought deeply about why. He has great points on how to find programmers (hint: job boards don’t work) and how to build an environment where programmers can be productive. For those reasons, it’s worth reading.
However, while I respect Spolsky and have followed his blog for years, I don’t agree with a number of key points in the book:
-
Spolsky makes most of his arguments about hiring as if they are scientific facts, whereas most of what he says actually consists of anecdotes, correlations, and guesses. For example, when he makes the claim that interview questions about pointers can be used to distinguish between good programmers and great programmers, he has nothing but anecdotal evidence to back that up. It’s entirely possible that the programmers he rejected who failed his pointers interview question would’ve actually been great employees. Without a controlled experiment, we don’t really know. Obviously, I don’t expect Spolsky to be spending his time on controlled scientific experiments, but I do expect him to present his stances as conjectures rather than absolute truths. The sad truth about hiring is that we all suck at it and not acknowledging that does a lot of harm to this industry.
-
As an example of the harm this “trust me, I know what I’m doing” attitude can have is Spolsky’s claim that programming ability, such as understanding pointers, is innate, and cannot be taught. I call BS on that. No one is born understanding pointers. And if a large percentage of people can’t learn pointers, my guess is that has more to do with the ability of the teachers than of the students. But that’s just my guess and I prefer to label it as such. Spolsky presents it as a hard fact. The either you-have-it-or-you-don’t, fixed-mindset is, IMO, harmful to the software industry. We need to encourage more people to take up programming rather than scaring them away because they might have been born a muggle.
-
Sposky recommends white board coding. I would argue this is a horrifically ineffective way to evaluate programmers that this industry should have abandoned long ago. Working on artificial problems from CS 101 that can fit in a 45 minute slot, writing code by hand with no compiler, no syntax checking, no auto complete, no Google or StackOverflow (yes, every programmer uses these constantly while coding), no libraries, no ability to incrementally build/run the code, no quiet time to do thinking (instead, speak all your thoughts out loud because that’s totally natural!), and a ridiculous pressure to prematurely optimize the shit out of a tiny piece of code is NOT my idea of an effective interview process. A book like this recommending it as a “best practice” does harm to the industry.
In short: if you’re going to hire programmers, it’s worth reading this book, but don’t take it as gospel.
As always, some of my favorite quotes from the book:
“Duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold. Essentially, design adds value faster than it adds cost.”
“The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.”
“It’s not just a matter of “10 times more productive.” It’s that the “average productive” developer never hits the high notes that make great software.”
“The great software developers, indeed, the best people in every field, are quite simply never on the market […] The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot.”
“When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.”
“In a high-tech company the individual contributors always have more information than the “leaders,” so they are really in the best position to make decisions. When the boss wanders into an office where two developers have been arguing for two hours about the best way to compress an image, the person with the least information is the boss, so that’s the last person you’d want making a technical decision.”
“The military uses Command and Control because it’s the only way to get 18-year-olds to charge through a minefield, not because they think it’s the best management method for every situation.”
Rating: 3 stars
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.