I mentioned in Can you play baseball/softball? Are you a pro? that I was recommending the new book from Joel Spolsky at the time I was ordering it as opposed to after having read it. As I noted I said I would revisit this book again once I had a chance to read it.
Yesterday I needed to take the train from Oceanside an approx. 110 minute trip (just under 2 hours) and since the MetroLink trains that traverse Orange Country don’t have electrical outlets – I took a couple books. (My currently laptop has approx. a 45 minute battery life).
The one I read on the way up was “Smart and Gets Things Done”. It is a relatively short book, in that although it is hard cover it’s has pages about the size of a paperback and only goes for about 150 pages. This was good in that hopefully some managers (who haven’t been able to focus long enough to get through a book like Joel on Software ) can actually be convinced to sit down and go through this book. (I'm not targeting my current employer with that statment, but would like to focus across the entire IT landscape.) The key is even more so then Joel on Software - this isn't a book on software - it's a book about your "most important resources" your people - what it takes to find them and to a limited extent to keep them.
As this comment implies; I stand by my original recommendation, and I’d like to now expand on that recommendation.
I wish I could say that the company I work for follows all of the recommendations outlined in this book. The book covers tips for people who will be interviewing, tips on screening resumes, why services like Monster or Career Builder have limitations in terms of what candidates you will see. Overall, while in theory Joel has the ability to state – “I founded a successful company called ‘Fog Creek Software’, my success acts in part as justification for what I write.”, that isn't his main approach. Joel uses information both from within and from outside his organization to better illustrate his primary concepts.
The first chapter focuses on the intrinsic value associated with hiring only the ‘best’ programmers. As I noted in my original post, anyone can claim to be a developer – but there are some people who are truly professionals. Joel points out that software engineering can be associated with a natural ability or affinity. As I noted when I said there are some professional baseball players who have an innate ability which can be nurtured on the way to becoming a professional, the same is true for the people who are the best at designing and creating software. Joel goes beyond just using his personal observations and actually takes some data collected by a university professor to demonstrate how those people who really excel in software development may solve the same problem much more quickly then someone who for lack of a better word, struggles to pull together the logical pieces.
Chapter two focuses on finding those resources. As Joel notes – the best software engineers are rarely on the market for any length of time, and once they get to a new location they tend to stay for a long period of time. This is because over a period of time such individuals are easy to recognize. Joel points out that internships are a great way of identifying and ‘locking in’ such performers and describes his system for doing so. Additionally this is where he focuses on why so many of the resume’s a potential employer sees aren’t actually from the developers that employer should really be looking to hire.
Chapter three focuses on things that employers need to do to really attract and retain the best developers. This contains important tips that cover everything from how damaging politics can be to why in the right scenario money is rarely the driving factor motivating your engineers and what it probably means if money is the driving factor for your developers.
Chapter four focuses on things like sorting resumes. Returning to my baseball analogy from my previous post, the majority of organizations don’t have what I would describe as a farm organization. This is the collection of minor league teams that feed their best talent into the pro's and which are common in Major League Baseball. Instead of having talent pulled from the organization companies are going to do the majority of hiring off what is essentially the free agent market. So while Joel leverages a farm system via his intern program - other companies are scanning job services looking for people. This means scanning resumes and since maybe one half of one percent of the resumes you get from such sites and headhunters actually highlight worthwhile hires how do you spot even the top five percent of such candidates when looking through resumes.
Chapter five relates to phone screening and chapter six relates to the actual interview process. In short if you are interviewing potential developers you need to read these chapters. His process tends to model my ideal, unfortunately I know in my current company there are few who manage to come close to mirroring his suggested processes. I’ve seen hires who should have been screened out much earlier in the process by following his suggestions.
Chapter seven talks about how to work with teams and fixing ‘suboptimal’ teams as Joel phrases it. I actually consider this chapter to be an extension of Chapter three in that developers won’t be happy for long if the team they are on is dysfunctional. More importantly he points out many of the mistakes that companies typically make when attempting to make such teams successful.
Finally Joel reviews his 12 rules for rating a software team. This is offered as an appendix and reviews many of the things that you as a developer or as a manager should be asking if you are trying to quickly gauge whether or not your team is positioned to be successful. There are some very detailed and well documented ways to measure an organizations performance in terms of software development. However, I can state from experience that such methods often cause more problems than they identify, Joel’s informal system on the other hand can quickly get you on the right track without ever getting into those details or even getting huge push back from your employees.
So there it is my review of Joel’s new book and hopefully enough info so that even those who think they are too smart to need to read a software book that isn’t about writing code, will recognize it has some value and items they don’t know. While I did recognize one or two chapters from having followed Joel’s posts – I found the updated read a great refresher and took away good information from each chapter. I’ll be keeping this book available and whenever I’m preparing to conduct a series of interviews I’m sure I’ll review a couple of key chapters.