Smart & Gets Things Done by Joel Spolsky

• The process of hiring great technical talent is an elimination course.
• But there’s a silver lining, if you will: a bright side to all this meandering mathematical moroseness. And that is this: if you can eliminate one obstacle--just one!--you can double the number of people you hire. Eliminate two obstacles, and you quadruple the number that make it past the remaining obstacles. And so on, and so forth.
• But there is no silver bullet. There is no magical single thing you can do to solve all your hiring problems and get great developers working for you tomorrow.
• What you have to do is look at the whole process as an obstacle course and start to think about how to eliminate as many obstacles as possible.
• Duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.
• Essentially, design adds value faster than it adds cost.
• The quality of the work and the amount of time spent are simply uncorrelated.
• A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time.
• 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.
• The mediocre talent just never hits the high notes that the top talent hits all the time.
• People like to feel in control. It makes people happy to feel in control.
• It’s not just a matter of “10 times more productive”. It’s that the “average productive” developer never hits the high notes that make great software.
• The software marketplace, these days, is something of a winner-take-all system.
• The great software developers, indeed, the best people in every field, are quite simply never on the market.
• The average great software developer will apply for, in total, maybe four jobs in their entire career.
• The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs.
• The corollary of that rule--the rule that the great people are never on the market--is that the bad people--the seriously unqualified--are on the market quite a lot. They get fired all the time, because they can’t do their job.
• Numerically, great people are pretty rare, and they’re never on the job market, while incompetent people, even though they are just as rare, apply to thousands of jobs throughout their career.
• Think about where the people you want to hire are hanging out.
• The corollary of this rule is to avoid advertising on general-purpose, large job boards.
• One good way to snag 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.
• Even though only about one in three applications who make it to the in-person interview stage passes all our interviews, it’s really important that the ones who do pass have a positive experience.
• An internship program creates a pipeline for great employees, but it’s a pretty long pipeline, and a lot of people get lost along the way.
• We basically calculate that we’re going to have to hire two interns for every full-time employee that we get out of it, and if you hire interns with one year left in school, there’s still a two-year pipeline between when you start hiring and when they show up for their first day of full time work.
• That means we hire just about as many interns as we can physically fit in our offices each summer.
• No programmer in their right mind should ever sign a non-compete agreement, but most of them do because they can never imagine that it would be enforced, or because they are not in the habit of reading contracts, or because they already accepted the employment offer and moved their families across the country and the first day of work is the first time they’ve seen this agreement and it’s a little bit too late to try to negotiate it. So they sign, but this is one of the slimiest practices of employers, and they are often enforceable and enforced.
• [...] if the great programmers don't want to work for you, they ain’t gonna come work for you.
• Peopleware is a great book.
• 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.
• No matter what you think about productivity, and no matter what you think about egalitarian workspaces, two things are incontrovertible:
• Private offices have higher status.
• Cubicles and other shared space can be socially awkward.
• A lot of tech people are remarkably unaware of the general condition of their office.
• There is simply no reason not to get your developers top-of-the-line computers, at least two large (21”) LCD screens (or one 30” screen), and give them free rein on Amazon to order any technical book they want.
• These are obvious productivity gains, but more importantly to our discussion here, they’re crucial recruiting tools, especially in a world where most companies treat programmers as interchangeable cogs, typists. Really, why do you need such a big monitor and what’s wrong with 15” CRTs?
• Software developers are not really all that different from regular people.
• All else being equal, developers are going to prefer an organization that treats them like stars.
• Keep reminding yourself that when your candidate goes home and has to make a decision about where to work, if everyone they met was glum, they are not going to have such a positive memory of your company.
• By the way, the original hiring rule for Fog Creek, stolen from Microsoft, was “smart, and gets things done.” Even before we started the company, we realized that we should add a third rule: “Not a jerk.”
• Who wants to work at a company where jerks are tolerated?
• 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 experience.
• Actually, politics happens everywhere that three or more people congregate, and it can be completely harmless.
• Programmers have very well-honed senses of justice. Code either works, or it doesn’t.
• And this is the kind of environment you have to create to attract programmers.
• When a programmer complains about “politics”, they mean--very precisely--any situation in which personal considerations outweigh technical considerations.
• Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it.
• Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit.
• Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.
• All in all, focusing on the social dynamics of your organizations is crucial to making a healthy, pleasant place to work that will retain programmers and attract programmers.
• To some extent, one of the best ways you can attract developers is to let them work on something interesting.
• If you can find ways for developers to get experience with newer languages, frameworks, and technologies, they’ll be happier.
• As a recruiter, your job is to identify the idealistic aspects of your company, and make sure candidates are aware of them.
• The real point of this section is to think of what your company stands for, how it’s perceived, and how it could be perceived. Managing your corporate brand is just as important for recruiting as it is for marketing.
• They don’t care about money, actually, unless you’re screwing up on the 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.
• You do have to pay competitively, but all said, of all the things that programmers look at in deciding where to work, as long as the salaries are basically fair, they will be surprisingly low on their list of considerations, and offering high salaries is a surprisingly ineffective tool in overcoming problems like the fact that programmers get 15” monitors and salespeople yell at them all the time and the job involves making nuclear weapons out of baby seals.
• Sometimes a resume gives pretty strong negative clues that allow you to screen out applicants without going much further.
• We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
• We look for evidence that the applicant is passionate about computers and really loves programming.
• 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.
• Brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution.
• Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past.
• Our company criterion for selectivity is usually getting into a school or program that accepts less than 30% of its applications, or working for a company that is known to have a difficult application process, like a whole day of interviews. Getting into highly selective courses in the military or getting into highly selective units like the Marines, indicates someone who has made it through some kind of difficult application/selection procedure, and all in all this is a positive sign.
• People who have worked on operating systems or compilers are more hardcore than  people who have worked on simple database front-ends.
• Remember angina that I said that resume are a very weak way of judging programmers, and you only get the faintest signals from them; that said, some technologies are just harder than other technologies, and if you happened to have worked with them successfully, there’s a smidgen more evidence that you might be the right person to hire, so for the purposes 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.
• To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords. The entire industry of professional headhunters and recruiters is bizarrely fixated on the simple algorithm of matching candidates to positions by looking for candidates who have the complete list of technology acronyms that the employer happens to be looking for.
• It becomes especially infuriating to realize that most of these recruiters have no idea what any of these technologies are.
• The reason recruiters do this is because it’s easy, it can be computerized, and it’s the only way they know how to judge developers. For almost all software development positions, though, it is the worst possible way to hire.
• 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.
• A phone screen has distinct advantages over a normal in-person interview. First, it’s cheap. [...] More importantly, it’s more fair.
• 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 so that the interviewer’s judgement can form an opinion on whether this is a smart person or not.
• The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process.
• 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).
• It’s too easy to fake out one interview, especially when a non-programmer interviews a programmer.
• If even two of the six interviewers think that a person is not worth hiring, don’t hire them.
• Don’t try to interview a bunch of people at the same time. It’s just not fair. Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard.
• In software, things change so often and so rapidly that you need people who can succeed at just about any programming task that you throw at them.
• Just say no! If you are on the fence, that means no hire.
• Don’t lower your standards no matter how hard it seems to find those great candidates.
• In principle, it’s simple. You’re looking for people who are:
• Smart, and
• Get things done
• 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.
• 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.
• How do you detect smartness in an interview? The first good thing is that you don’t have to explain things over and over again. The conversation just flows.
• Remember, smart does not mean “knows the answer to trivia questions.” Anyway, software teams want to hire people with aptitude, not a particular skill set.
• Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it’s better to hire people who are going to be able to learn any new technology rather than people who happen to now how to make JDBC talk to a MySQL database right this minute.
• Here’s a typical plan for interviewing a programmer:
• Introduction
• Question about recent project candidate worked on
• Easy programming question
• Pointer/recursion question
• Are you satisfied?
• Do you have any questions?
• 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. Being passionately negative can be just as good a sign.
• Bad candidates just don’t care and will not get enthusiastic at all during the interview.
• Good candidates are careful to explain things well, at whatever level. I often reject candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand.
• If the project was a team project, look for signs they took a leadership role.
• The only way you’re going to be able to tell if somebody gets things done is to see if historically they have tended to get things done in the past.
• Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.
• If the basic concepts aren’t so easy that you don't have to think about them, you’re not going to get the big concepts.
• 15 years of experience interviewing programmers has convinced me that the best programmers all have aptitude for dealing with multiple levels of abstraction simultaneously.
• I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude.
• 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.
• If you’re having trouble deciding; there’s a very simple solution. No hire. Just don’t hire people that you aren’t sure about.
• Remember: most normal recruiting in our society is structured as if the company has something precious (a job) that the individual wants. But when you’re recruiting top developers, the situation is completely reversed. Pay very, very close attention to the details of the entire recruiting, interviewing, and hiring process to make sure there are no accidental parts of the procedure that send any message other than “We’re not worthy!” to your star candidates.
• Great people are much, much more valuable than average people. In programming, they are three to ten times as productive, while only costing 20% to 30% more. And they hit high notes that nobody else can hit.
• An extremely people and seemingly scientific way to improve a team is with performance measurements and incentives. [...] This is a common management technique, and it’s devastatingly ineffective.
• In software development teams, everybody is working on something else, so attempts to micromanage turn into hit-and-run micromanagement. That’s where you micromanage one developer in a spurt of activity and then suddenly disappear from that developer’s life for a couple of weeks while you run around micromanaging another developer.
• The Econ 101 manager assumes that everyone is motivated by money, and that the best way to get people to do what you want them to do is to give them financial rewards and punishments to create incentives.
• Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job.
• Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.
• Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things they actually want to do. That’s not very controversial.
• When you use Econ 101 management, you’re encouraging developers to game the system.
• Developers are clever this way. Whatever you try to measure, they’ll find a way to maximize, and you’ll never quite get what you want.
• The biggest problem with Econ 101 management is that it’s not management at all: it’s an abdication of management. A deliberate refusal to figure out how things can be made better.
• 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.
• The real trick to management is to try to make people identify with the goals you’re trying to achieve.
• To be an Identify Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.
• In general, Identify 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 secondary part, though, is to give people the information they need to steer the organization in the right direction.
• The Joel Test
• Do you use source control?
• Can you make a build in one step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before writing new code?
• Do you have an up to date schedule?
• Do you have a spec?
• Do programmers have quiet working conditions?
• Do you use the best tools money can buy?
• Do you have testers?
• Do new candidates write code during their interview?
• Do you do hallway usability testing?
• If the [build] process takes any more than one step, it is prone to errors.
• Breaking the build is so bad (and so common) that it helps to make daily builds, to ensure that no breakage goes unnoticed.
• You absolutely have to keep track of bugs formally.
• “Zero defects” means that at any given time, the highest priority is to eliminate bugs before writing any new code.
• In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
• There are extensively documented productivity gains provided by giving knowledge worker space, quiet, and privacy.
• Productivity depends on being able to juggle a lot of little details in short-term memory all at once. Any kind of interruption can cause these details to come crashing down.
• Top-notch development teams don't torture their programmers.
• Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.
• To add to all this...programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying them competitive salaries!
• Do whatever you want during interviews, but make the candidate write some code.
• A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you unjustly wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
• Good user interface design is not as hard as you would think, and it’s crucial if you want customers to love and buy your product.