Smart and Gets Things DoneI've long been a fan of the succinct and insightful thoughts of Joel Spolsky ( Joel is a Yale-educated ex-Microsoft employee running his own software development company, Fog Creek, in New York.

I recently came across a book he wrote, Smart and Gets things Done, and decided to invest time in reading it. It's only 150-odd pages so you can easily get through it in less than a week - Bill Clinton biography-sized bricks don't endear themselves to me that much.

According to the blurb on the back of the book it is "a guide to attracting, recruiting, interviewing, and hiring the best technical talent."He covers this topic skilfully with useful insights, though I must say that I don't agree with all his observations. As with most of Joel's writing, and as can be seen from the long list below, there are numerous gems to be found in this book. For the record, here are the more critical issues Joel identifies that I feel strongly about (both positively and negatively).

Things that Joel mentions that I think are important and strongly agree with him on:

  • Good design adds value faster than it adds cost. Joel bases this observation on the fact that software duplication is essentially free thus development costs can be apportioned over the units sold resulting in negligible per unit incremental cost.

  • There no place in the software industry for low-cost providers, for the reasons given above. And industries that need to develop good software should not be trying to reduce the cost of programmers.

  • The difference between good and average programmers is significant. Great programmers are 3 to 10 times more productive whilst only costs 20-30% more. (And kudos to Joel for providing empirical productivity data from a reasonably well controlled experiment to backup this notion). On that topic- I'm a firm believer that data should drive the decision making process! If you don't have the necessary data, think about how you can get it. Hint: hallway usability tests, split A-B testing, customer involvement, web server log files, etc.

  • There are benefits to using the smallest possible team, since co-ordination and communication is overhead for the team.

  • For companies whose success is dependent solely on the quality of the products/service they develop, you'll need rock-star programmers who can "hit the high notes". If you work for an Internet startup this applies to you! If you're an executive at an Internet startup tattoo "quality is critical, ergo great people are critical" to your left fore-arm but you needn't go for David Beckham's kanji script.

  • The software marketplace these days is somewhat of a winner-takes-all system. That is, it's a hits-driven business rather than a long tail play.

  • If great programmers don't want to work for you they won't. So learn what they want and go about trying to give them it. The book details these issues fairly well.

  • You're not going to get great programmers if you don't respect them.

  • Programmers pay close attention to the intellect of the interviewer. Dead right. Talent attracts talent! Great programmers have a yearning for learning and being surrounded by smart, successful people as this helps them believe they will learn new tricks, which of course they will.

  • Programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can't.

  • Some technologies are just harder than others. If a developer can write assembly code, or is a whiz at pointer arithmetic in C++ they are going to be able to pick up <insert-desired-high-level-technology-here>.

  • Requiring programming and/or logic assignments on application are an unnecessary obstacle.

  • Aptitude is more important than experience, since the software industry moves relentlessly fast. I'd add that the only allowable exception to this is when you are hiring short-term contractors that need to be up-to-speed in the technology being used for the project.

  • Look for programmers who are smart AND who get things done. Both attributes are important here! I know it sounds elitist, but this expression, which is also the title of the book, essentially sums up the whole recruitment process nicely!

  • Being a blow hard or quiz-master interviewer is highly ineffective. These days we all have a Google search engine at our fingertips, so knowing the process is more important that the detail. If the applicant knows the Karatsuba algorithm is a slightly more efficient way to do multiplication of large numbers don't penalize them for not being able to recite the precise approach! The key point is knowing what the algorithm does on a general level and when to use it. 

  • Smart people are passionate about the projects they work on.If they aren't they would have quickly left the project and subsequent discussions about it become critiques of their former boss's lack of management / technical skills and why they couldn't wait to get out of the project.

  • Most of the time at an interview should be left for the candidate to prove they can write code (on a white board or paper). Speaking from experience :-)great programmers like to show off their skills and will relish the opportunity to write code for you.

  • If the basic concepts aren't so easy that you fly through them, you're not going to get the big concepts. The corollary to this is that a candidate that can confidently talk to you about more advanced topics, say for instance... why lexically-scoped closure makes anonymous delegates in C# way cool, is more than likely going to be able to understand simpler concepts.

  • The best programmers have an aptitude for dealing with multiple levels of abstraction simultaneously. I agree, and it's for this reason I am biased towards programmers who come from a mathematics or physics background because in the course of their undergraduate study they've already had to deal with copious amounts of abstract concepts.

  • Most recruiting is structured as if the company has something precious (a job) that the individual wants. When hiring great developers the situation is completely reversed. That's simple economics. The demand for great programmers outweighs the supply of them. Remember that!

Things I can't say I agree with Joel on:

  1. Joel is still adamant that a software company needs to be adept at "converting capital into software that works", rather than pursuing an idea that solves some problem which hasn't been solved before. I don't completely agree with this and here's why....Without a good idea, great execution is all you have. In some cases that, and first-mover advantage is good enough to succeed. i.e. Amazon selling books online. In other cases it's not. But a company with BOTH a great idea and superior execution is far more likely to succeed than a company without both components, so why wouldn't you pursue both? "converting capital into software that works" sounds very much like Joel suggests focusing on user-driven execution which is a great thing to do but if it's based on a lousy idea you'll end up with a product/service no-one wants or needs.

  2. Great software developers are rarely on the market. Don't agree. Many great programmers are attracted to the life of an independent contractor, for financial reasons, for the benefit of selecting what work they undertake and for the ability to jump from industry-to-industry and organization-to-organization sucking up as much new knowledge as they go. Due to the short-term, project-specific nature of this work, these folks are on the market a great deal more often than "rarely".

  3. Private offices make software developers more productive. Although Joel cites several respected publications, I can't say I agree with these findings from the viewpoint of optimizing the team throughput rather than the individual productivity. Because most software is developed by teams with no one individual having complete knowledge of the system in his or her head, team members need to communicate to share the collective knowledge of the system. Putting developers in private offices, whilst giving them a bit more quiet time for uninterrupted development work, actually inhibits the free transfer of information and ideas between the team. Developers packed into relatively close confinement will mix more freely. Yes that does bring in the opportunity for more distractions but that's better than having each developer being an island unto themselves.

For the mathematically astute you'll notice that I'm agreeing with Joel far more than I'm not - well OK you don't need to be George Danzig to figure that out. So in summary I can confidently recommend this book to anyone who is engaged in the practice of hiring programmers for a company that need to produce great products. It's not a difficult read and is choc-full of gems you want flowing through your hippo-campus.

Great job Joel ! Hits the mark nicely.

PS. Here's a link to it on Amazon

Bookmark and Share