Skimming : Smart & Gets Things Done

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent

Hitting The High Notes

• The formula for Fog Creek Software, the company I started with Michael Pryor in September 2000, can be summarized in four steps:
  Best working condition -> best programmers -> best software -> profit
  (p.2)
• So, why isn’t there room in the software industry for a low-cost provider, someone who uses the cheapest programmers available? ... Here’s why: duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. ... Or, roughly speaking, if you try to skimp on programmers, you’ll make crappy software, and you won’t even save that much money. (pp 3-4)
• The fastest students were finishing three or four times faster than the average students and as much as ten times faster than the slowest students. (p.6)
• The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.(p.11)
• The mediocre talent just never hits the high notes that the top talent hits all the time. The number of divas who can hit the F6 in Mozart’s “Queen of the Night” is vanishingly small, and you just can’t perform “Queen of the Night” without that famous F6.(p.12)
• Sadly, this doesn’t really apply in nonproduct software development. Internal, in-house software is rarely important enough to justify hiring rock stars ... That’s why the most satisfying careers, if you’re a software developer, are at actual software companies, not doing IT for some bank.(p.16)

Finding Great Developers

• The great software developers, indeed, the best people in every field, are quite simply never on the market. (p.20)
• Think about where the people you want to hire are hanging out. What conferences do they go to? Where do they live? What organizations do they belong to? What websites do they read?(p.23)
• 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)

A Field Guide to Developers

• I had to agree with him: Peopleware is a great book. One of the most important, and most controversial, topics in that book is that you have to give programmers lots of quiet space, probably private offices, if you want them to be productive.(p.42)
• If the office space is crowded, if the carpets are ratty and the walls haven’t been painted and there are posters up with pictures of rowing teams and the word TEAMWORK in large print, they’re going to have Dilbert thoughts.(p.48)
• Basically, if you’re going to hire smart people, you’re going to have to let them apply their skills to their work. ... 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)
• The world of programming is very just and very strictly ordered, and a heck of a lot of people go into programming in the first place because they prefer to spend their time in a just, orderly place: a strict meritocracy where you can win any debate simply by being right. (p.55)
• Most programmers aren’t just looking for a gig to pay the rent. They don’t want a “day job”: they want to feel like their work has meaning.(p.60)
• 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)

Sorting Resumes

• We look for evidence that the applicant is passionate about computers and really loves programming.(p.69)
• The fact that they took the time to learn about Fog Creek and wrote a custom cover letter just for us means that they have a lot of confidence in their abilities, so they’re applying to a select few employers, not bulk mailing a thousand. (p.70)
• That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler.(p.71)
• In this category we’re looking for evidence that a candidate is, well, smart, or at least the kind of nerdy brainiac who went to math camp. (p.72)
• Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. ... but getting into a very selective school does at least mean that someone, somewhere judged you using some kind of selection process and decided that you were pretty smart. (p.73)
• so for the purpose of sorting resumes, difficult technologies tend to float you to the top, while claiming competence in, say, Microsoft Word tends to float you toward the bottom. (p.74)
• For someone who is basically a good software developer, learning another programming language is just not going to be a big deal.(p.80)
• If you’re hiring an architect or head developer— that is, the chief software engineer who is going to have to lay out the initial code and figure out how things work together—you probably want to hire someone with a lot of experience in the technology that you’re using.(p.81)
• Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on.(p.81)

The Phone Screen

• The great thing about a phone interview is that it’s much harder to form these kinds of snap judgments; you actually have to listen to what the person is saying and decide if that corresponds to what a smart person might say.(p.84)
• My phone interviews have three parts. In the first part, I ask the candidate to describe their career history and basically tell me about themselves. (p.85)
• The second part of the phone screen is the technical problem. What would be a good data structure for a photo editor? (p.87)
• The third and final part of the interview is letting the candidate interview me.(p.88)

The Guerrilla Guide to Interviewing

• You should always try to have at least six people interview each candidate, including at least five who would be peers of that candidate (that is, other programmers, not managers). (p.93)
• Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. (p.94)
• It’s because it is much, much better to reject a good candidate than to accept a bad candidate. (p.96)
• In principle, it’s simple. You’re looking for people who are
  1. Smart, and
  2. Get things done.
  (p.97)
• 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. (p.97)
• 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.(p.98)
• What should you look for during the open-ended questions?
  One: look for passion.
  Two: good candidates are careful to explain things well, at whatever level.
  Three: if the project was a team project, look for signs that they took a leadership role.
  (pp.104-105)
• Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.(p.105)
• You see, if you can’t whiz through the easy stuff at 100 mph, you’re never gonna get the advanced stuff.(p.108)
• A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart.(p.116)
• The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you’ll remember.(p.116)
• Finally, if you do have to say no to someone, do it quickly and respectfully. You are, of course, under no obligation to tell people why they’re not the right fit, but you do have to tell them, and you have to do it promptly. It’s just common decency to let them move on to the next opportunity.(p.119)

Fixing Suboptimal Teams

• The bottom line is that cleaning house, as long as it’s done all at once, can often result in improved morale.(p.130)
• If you want to lead a team, a company, an army, or a country, the primary problem you face is getting everyone moving in the same direction, which is really just a polite way of saying “get- ting people to do what you want.”(p.133)
• Intrinsic motivation is your own, natural desire to do things well. ... Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.(p.142)
• Management, in general, needs to set up the system so that people can get things done, it needs to avoid displacing intrinsic motivation with extrinsic motivation, and it won’t get very far using fear and barking out specific orders.(p.146)
• The real trick to management is to make people identify with the goals you’re trying to achieve.(p.147)
• Seriously, though, a method I’m pretty comfortable with is eating together.(p.148)
• In general, Identity Management requires you to create a cohesive, gelled team that feels like a family, so that people have a sense of loyalty and commitment to their coworkers. … The second part, though, is to give people the information they need to steer the organization in the right direction.(p.149)