Smart & Gets Things Done - Joel Spolsky

About the author

Joel Spolsky is a software engineer and writer, creator of Trello, Glitch, Project Manager of Microsoft Excel, co-founder of Stack Overflow.

About the book

• Buy on Amazon
• Goodreads reviews
• Pages: 182
• My one-liner review: a quick and concise guide to understand, become, find and manage great software engineers.

Contents:

• Introduction
• Chapter 1: Hitting the High Notes
• Chapter 2: Finding Great Developers
• Chapter 3: A Field Guide to Developers
• Chapter 4: Sorting Resumes
• Chapter 5: The Phone Screen
• Chapter 6: The Guerrilla Guide to Interviewing
• Chapter 7: Fixing Suboptimal Teams
• Appendix: The Joel Test

Quotes

Some random quotes from beginning to end order. For the full context, please buy and read the book. I do this to help myself to quickly get the main ideas of the book.

Introduction

Imagine, if you will, a course with ten obstacles. For simplicity, assume that each obstacle successfully stops 50% of the runners. In fact, if you want to get just one person to pass all ten, you are going to start out with 2^10 runners on the start line. That's 1024 runners.

The process of hiring great technical talent is an elimination course.

Chapter 1: Hitting the High Notes

Best Working Conditions > Best Programmers > Best Software > Profit!

Essentially, design adds value faster than it adds cost.

The quality of work and amount of time spent are simply uncorrelated.

Adding manpower to a late software project makes it later (from The Mythical Man-Month).

The mediocre talent just never hits the high notes that top talents hit all the time.

Chapter 2: Finding Great Developers

The great software developers, indeed, the best people in every field, are quite simply never on the market.

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.

The standard bit of advice on finding great software developers is to ask your existing developers.

Chapter 3: A Field Guide to Developers

When a candidate comes to your company for the day of interviews, they're going to look around at where people are working, and try to imagine themselves working there.

One thing programmers pay close attention to in the day of interviewing is the people they meet.

Developers want to be hired for their skills, and treated as experts, and allowed to make decisions within their own realm of expertise.

To some extent, one of the best ways you can attract developers is to let them work on something interesting.

As a recruiter, your job is to identify the idealistic aspects of your company, and make sure candidates are aware of them.

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.

Chapter 4: Sorting Resumes

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. In two years, you may need them to do something completely different in a programming language which hasn't even been invented.

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.

Chapter 5

The bottom line in my interviewing technique is that smart people can generally tell if they're talking to other smart people by having a conversation with them on a difficult or highly technical subject, and the interview question is really just a pretext to have a conversation on a difficult subject so that the interviewer's judgement can form an opinion on whether this is a smart person or not.

Chapter 6: The Guerrilla Guide to Interviewing

Don't try to interview a bunch of people at the same time. It's just not fair.

I can also tell from my extensive experience that if you spend less than one hour on an interview you're not going to be able to make a decision.

There are only two possible outcomes to this decision: Hire or No Hire.

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 complete impractical.

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.

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.

But in general, the way to learn most about a person is to let them do the talking.

One: look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly and get animated.

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.

If you have to say no to someone, do it quickly and respectfully. It's just common decency to let them move on to the next opportunity.

Chapter 7: Fixing Suboptimal Teams

Inheriting an existing system is sort of like being a dentist with a patient who hasn't been to see a dentist for about twenty years, and various teeth are start to hurt.

It's going to be rather painful and you're going to have to put your fingers in peoples' mouths, but after a few weeks of painful work, they'll have a nice smile again. And if you're doing your sacred duty as a dentist, you will have scared them into avoiding all dentists for another twenty years.

An extremely popular and seemingly scientific way to improve a team is with performance measurements and incentives. This is a common management technique, and it's devastating ineffective.

You still need to triage the team into three categories: Great developers; Needs specific improvements and Hopeless. If you're a new manager on a team, the fastest way to do this is by peer evaluation.

The bottom line is that cleaning house, as long as it's done all at once, can often result in improved morale.

As a team leader, your ultimate goal is to improve the performance of the team.

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 "getting people to do what you want."

Here are three common approaches you might take: The Command and Control Method; The Econ 101 Method and The Identity Method.

Appendix: The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily build?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quite working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you hallway usability testing?

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've go serious problems.

If you find the book interesting, buy it on Amazon