Joel on Software is a technical blog with topics such as software development, management, business, and the Internet; this book is a collection of some of the better essays. While he tends towards hyperbole and narcissism, Spolsky has a tongue-in-cheek style that I wish I had; a recent column, for instance, used a great quote: “Don’t fall for it. [Developers] also want M&Ms for breakfast and a pony.” Good stuff.
Probably due to the fact that the columns were written over about five years, Spolsky does tend to contradict himself. At one point he gives a rant showing a disdain for abstraction with which I don’t agree. (From his examples I think his real problem is with head-in-the-cloud architects and not abstraction itself, but it doesn’t come off with quite that message.) Later, though, he says that software design is extremely important which seems a very different direction. Another discrepancy is with bloatware; at first he makes very good arguments as to why it isn’t that big of a deal (as disk space gets cheaper and bandwidth becomes a commodity larger programs aren’t a problem; your annoying and useless gizmo is my must-have feature) but then later he laments the absence of a linker in .NET causing his software to be larger than it really needs to be. Hmmm.
A topic on which we don’t agree is interviewing. He likes candidates to write code during an interview and tends to use puzzle questions. To me, design ability is much more important than coding; good designers can always be taught to code while the converse isn’t always true. Puzzle questions while fun strike me as trivia questions; “How many gas stations are in LA?” is only useful the very first time a candidate hears it and the chances of catching someone that hasn’t seem slim. If you are going to ask trivia questions, at least make them technology specific to see how deep of an understanding someone has on a given topic.
Despite how it may seem from the preceding paragraphs, I agree with much of what Joel has to say. Daily builds, a commitment to testing, simple and clear documentation, and humor in the workplace are all important factors of a strong team. I’d recommend this book to any software developer or manager; even if you don’t agree with what Spolsky has to say you will at least think about it.
Why do developers choose one programming language over another for a given task?