Review : Smart & Gets Things Done

I just finished a quick read titled, "Smart and Gets Things Done" that reaffirmed many of the things I currently believe and introduced a few new points to ponder as I move forward in my pursuit to make the future better -- wherever I end up. After sharing my CliffsNotes version with a trusted co-worker, he pressured me to share my review via this platform. In fact, he went so far as to say that I wouldn't be "hard-core" if I didn't, so, to avoid being viewed as soft, here it is ... enjoy:

1. The process of hiring great technical talent is an elimination course (p. Introduction X).

2. From the very beginning, we were always totally convinced that our number one priority was hiring great people, even before we knew what kind of software we would make. (p. Introduction XIV).

3. The common belief is that when you're building a software company, the goal is to find a neat idea that solves some problem which hasn't been solved before, implement it, and make a fortune. We'll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works (p. 1).

4. ... design adds value faster than it adds cost (p. 4).

5. Adding manpower to a late software project makes it later (p. 10).

6. You can't afford to be number two, or to have a "good enough" product. It has to be remarkably good, by which I mean so good that people remark about it (p. 17).

7. THE PLAN: Best Working Conditions --> Best Programmers --> Best Software --> Profit!

8. The great software developers, indeed, the best people in every field, are quite simply never on the market (p. 20).

9. Think about where the people you want to hire are hanging out (p. 23).

10. One good way to snag the great people who are never on the job market is to get them before they even realize there is a job market: when they're in college (p. 25).

11. There's a strong culture in Silicon Valley that requires you to jam a lot of programmers into a big open space, despite a preponderance of evidence that giving them private offices is far more productive (p. 43).

12. You're not going to get great developers if you don't respect them (p. 52).

13. Who wants to work at a company where jerks are tolerated (p. 53)?

14. Basically, if you're going to hire smart people, you're going to have to let them apply their skills to their work. Managers can advise, which they're welcome to do, but they must be extremely careful to avoid having their "advice" interpreted as a command, since on any given technical issue it's likely that management knows less than workers in the trenches, especially, as I said, if you're hiring good people. Developers want to be hired for their skills, and treated as experts, and allowed to make decisions within their own realm of expertise (p. 54-55).

15. [Programmers] don't care about money, actually, unless you're screwing up on other things. If you start to hear complaints about salaries where you never heard them before, that's usually a sign that people aren't really loving their job (p. 63).

16. It is really, really important to remember that these categories – Passion, Pickiness, English, Brains, Selectivity, Hard-Core, and Diversity – are not hiring criteria (p. 74).

17. For someone who is basically a good software developer, learning another programming language is just not going to be a big deal. In two weeks, they'll be pretty productive (p. 80).

18. People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem than ship on time. These people can be identified because they love to point out the theoretical similarity between two widely divergent concepts (p. 97).

19. People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people's time (p. 98).

20. How do you detect Smart in an interview? The first good sign is that you don't have to explain things over and over again. The conversation just flows (p. 98).

21. The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks smart means "knows a lot of facts." They just ask a bunch of trivia questions about programming and give points for correct answers (p. 99).

22. ... software teams want to hire people with aptitude, not a particular skill set (p. 99).

23. You see, if you can't whiz through the easy stuff at 100 mph, you're never gonna get the advanced stuff (p. 108).

24. I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails does read your mind and build a complete Web 2.0 social collaborative networking site for you with just three clicks of the mouse (p. 111).

25. In the past, I've used "impossible questions," also known as "back of the envelope questions." A classic example of this is "How many piano tuners are there in Seattle?" The candidate won't know the answer, but smart candidates won't give up, and they'll be happy to try and estimate a reasonable number for you (p. 115).