In my previous post I reviewed Joel Spolsky’s Joel on Software:…
- More Joel on Software: Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and To Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
- The Best Software Writing I: Selected and Introduced by Joel Spolsky (v. 1)
- User Interface Design for Programmers
A lot of the content in Smart and Gets Things Done
In this book, Joel explains how to get the best programmers but it seems to lean more towards hiring the best college grads. Joel argues that the best programmer’s are so highly productive it is worth the extra pay and effort to bring them in as opposed to a mediocre programmer. I agree with this to some degree. I am not sure I totally agree with some of his techniques for evaluating who the best programmers are though.
Joel is an advocate of spending some extra dollars on perks for his interviewees and employees. One example is that he has a uniformed limo service pickup interviewees at the airport. At first this sounds ludicrous but the more I thought about it, the more it started to make sense. If you have gone through the labor of filtering all those resumes and conducting all those phone interviews to find the best candidates to interview in person then perhaps it is worth it to give them the treatment to sell the job. I checked and uniformed limo service from JFK to Manhattan runs less than $150. Considering a typical NYC IT salary, that is a drop in the bucket if it will help land a top notch programmer.
The book mentions purchasing a $900 chair for employees. I am not sure I could sit in a $900 chair without feeling a like a total snob but a $300 one seems to make sense. A comfortable programmer is likely a productive one. Nothing says you don’t care about your employees like an old, broken, stained, $100 office chair. The other thing the book mentions is giving employees dual monitors and top end computers. I think this is good advise and it probably isn’t expensive as you might think. For example, say you spend less than a $1000 to buy a new office chair, second monitor, dual head video card, and an extra 2GB stick of RAM for each employee and you expect those extras to last three years. That is about $27 a month per employee. I think that is a small price to pay for happy employees that feel valued. If that chair is super comfy you might even make up the cost in overtime work because they won’t be in such a hurry to get out of the chair at the end of the day. 😉
There are a few things in the book that I disagree with and this might be just because I don’t have enough experience to know better yet. The first is that the book says incentive pay doesn’t work. I disagree. I already talked about this in my review of Joel on Software and I won’t delve into it further here.
Another item in the book I don’t agree with is the concept that you don’t need an idea to build a software company. I suppose you don’t but it probably helps! I don’t have an MBA but I think that it is good business practice to identify a discrepancy or problem and build a product to fulfill it. Good programmers are great and all but I don’t think “best working conditions” + “best programmers” + “best software” always equals profit. You could build the best software but it won’t be profitable if the market is too small (you need the best sales people to pull that off). Perhaps I just misunderstood the first part of chapter 1.
One of the suggested interview questions to help separate the wheat from the chaff if is a pointer recursion question. I think it is more important to evaluate the skills that the interviewee claims to have. If they put in their resume that they have experience in a specific language then ask them to write something in that language. An outstanding web developer may never have touched pointers before because they simply never had to. Yes, there are leaky abstraction cases but typically those result in looking something up on Google rather than re-writing a module in C. Also, just because someone understands recursion and pointers doesn’t mean that they will be the best programmer for the job. They might have no understand of object oriented languages because all they have used is a procedural language such as C although admittedly that is less likely in this day and age.
The book goes on to say that pointers in C is more of an aptitude than a skill. Over the last year I have had a crash course in C/C++ and based on my own experience I argue that it is not that only a few people have an aptitude for pointers. The problem is that pointers are often poorly explained in many references and the syntax is a bit deceiving because the * symbol has a completely different meaning depending on if you are declaring a pointer or using it (“this is a pointer” and then “dereference this pointer”). If 90% of a computer science class isn’t getting something (as mentioned in the book) then I would say the professor should consider a different instruction strategy. Fortunately I had a pretty good instructor.
Despite some of my misgivings I think this book is worth the money especially if you don’t have any of the Joel on Software books already. There are many helpful tips including where to go looking for candidates, how to help employees feel at home in your organization, and how to turn around an existing team that is on the rocks.
