Fog Creek Professional Ladder

The Fog Creek Professional Ladder determines your base salary. It is recalculated every August, and new base salaries go into effect September 1st (you’ll see it on the September 15 paycheck).

Currently, the professional ladder is used for:

  • Software developers
  • Software QA/Testers
  • System Administrators

Your career level at Fog Creek is determined as a function of three things: experience, the scope of your job, and your skills.


Definition: Years of full-time experience developing and testing software or administering computer systems.

This includes things like:

software development/programming
user interface design
managing software teams
software testing using scripting/programming tools
marketing software
selling software
system administration
1 year for completing a PhD

It does not include:

anything that happens in school, before school, or during school
technical positions that are not software development


Low level / highly repetitive tasks (rote tech support, manual black box testing) are collapsed into one year. (You don’t have three years of experience, you have the same year experience three times over).


Definition: What your current job entails

Scope Software Development System Administration Test/QA
Summer interns and Co-ops Summer interns and Co-ops Summer interns and Co-ops
Does development work but does not own any specific area of the code. Works on non-shipping code or on other people’s areas, for example, fixing bugs, making small modifications, and implementing very small features. Does small system administration projects as directed by someone else. Most work is on internal systems which are not customer-facing. Not much coding. Executes test defined by someone else
Owns a major functionality area in a product, where they do or lead most of the development. Owns a major area of system administration functionality, where they lead or do most development and work. Job must require coding, managing critical customer-facing systems, and responsibility for high-availability systems Designs tests and test strategies for a major area of functionality in a product. Generally given an area to test and expected to come up with a test plan independently
Owns the development for a major project (an entire product), for example, FogBugz or Copilot. Owns multiple major areas of system administration functionality, which they run with little supervision. Responsible for all QA for a major project. Designs test plans, allocates resources, signs off on shipping versions.
Owns or oversees multiple major projects Overall responsibility for all Fog Creek systems, internal and external Overall responsibility for all Fog Creek QA.


Definition: your skill level, regardless of actual responsibility.


Skills Software Development System Administration Test/QA
0 Summer interns and Co-ops Summer interns and Co-ops Summer interns and Co-ops
1 Learning the basic principles of software engineering; works under close supervision; not expected to write production code Learning the basic principles of system administration; works under close supervision; not expected to work on customer-facing or mission-critical systems independently Learning the basic principles of software testing; works under some supervision and occasionally responsible for developing tests.
2 Works under some supervision and occasionally writes production code Works under some supervision and occasionally works on customer-facing or mission-critical systems Extensive background in non-automated QA and test, qualified to develop test plans independently for most software. Has learned the practices, methods, conventions, and standards of software QA and test.
3 Some background in software engineering, qualified to write production code without much supervision, although they probably aren’t designing anything. Will be expected to learn the software development lifecycle practices, methods, conventions, and standards of the computer industry. Understands and practices the skills of The Joel Test. Some background in system administration, qualified to administer most types of systems we have in production without much supervision, although they probably aren’t designing anything. Extensive experience with both Windows and Unix systems and most major Internetworking technologies.

Will be expected to learn the practices, methods, conventions, and standards of system administration.

Extensive experience with automated and code-based testing. Writes scripts and creates unit tests. Mostly works on fully-automated tests. Will be expected to learn the software development lifecycle practices, methods, conventions, and standards of the computer industry. Understands and practices the skills of The Joel Test.
4 Familiar with industry practices and therefore can work independently as necessary. Proposes design approaches for review and agreement from peers and his or her supervisor. Has worked on one or more shipping projects, and has experience in each of the basic software development lifecycle steps needed to ship a product. Very competent in nearly all code-centered, detailed-design centered, and task-centered areas, and demonstrates additional competencies in other software lifecycle areas. Teamwork skills are excellent. Software development skills equivalent to a programmer at Level 4. At this level no distinction is made between someone who primarily writes code used in testing vs. code used in production.
5 Has consistently had major success during their participation in all aspects of small and large projects and has been essential to those projects’ successes. Has a track record of consistently rendering clear technical judgment and routinely considers architecture-level and project-planning issues. They ensure that projects are conducted in ways that benefit the project objectives, the people participating in the project, and Fog Creek’s long-term interests. Innovative, consistent, and contributes beyond the assigned tasks. Mentors others. Actively seeks accountability. Has achieved mastery of The Joel Test. Competence extends to architecture, user interface design, project planning, documentation, fit and finish, and other project-level issues. Teamwork skills are excellent. Committed to a self-study program, reading books and journals.

A developer at skill level 5 delivers complete, fully-baked products, from specs and prototypes, complete with documentation, management interfaces, polished user interfaces, automatic build routines, marketing collaterals, etc., which have been tested internally and externally.

6 Has been critical to shipping a world-class product. Takes total ownership for all aspects of their project and makes many unique contributions. Decisions have a significant impact on Fog Creek’s profitability and overall well-being. Routinely provides technical direction to other groups and people. Their competence extends well beyond project-level issues to company-level issues.


Level is determined as a function of (a) experience (b) the average of scope and skills (rounded using normal math rules, so 3.5 becomes 4) using this chart:


How the StackOverflow Podcast is produced

The Stack Overflow Podcast is a weekly conversation between me and Jeff Atwood. He lives in California and I’m in New York City, so it has been a bit of a technical challenge to get the audio quality up to FM radio quality.

We went through several different iterations trying to find the perfect setup to record the podcast.

The first few shows were done by phone. Our office Asterisk phone system includes a feature to record any conversation by pressing ** during a call. The sound quality was really low (sample [MP3]).

For a few months we used a combination of Skype and Pamela. Pamela has a feature that allowed me to record Skype conversations as a high quality WAV file. The sound quality was great, but there was one problem: if Jeff and I spoke at the same time, the recording would, for some reason, drop both of us (sample [MP3]). We had to learn to be careful not to speak over each other and not to interrupt each other. This made the conversation sound stilted, and sometimes interesting things got lost. Another problem was that sounds from my computer weren’t recorded as a part of the podcast unless I prepared them as Pamela sound effects.

I knew that we needed a system that could record my voice locally, directly from the microphone, while recording the Skype conversation separately. I took some inspiration from Leo Laporte’s podcasting setup and Doug Kaye’s suggested setup in building my own, which we started using in episode #25.

Here’s the basic schematic:

Here’s what it looks like:

HEADSET: The headset there is a Sennheiser HMD-281-13, very high quality studio mic and headphone, which does a terrific job of cutting out noise.

STUDIO MIXER: I’m using a small DJ mixer that we happened to have sitting around to mix my voice with any sounds coming out of the computer, which I use to play audio files submitted by users. If you’re building your own setup, any kind of mixer will work as long as it has an XLR input with a preamp for the mic, and a line-level input for computer sound. I’m taking advantage of the fact that this mixer is stereo, even though everything I do is mono, so I can record from the left channel while sending the (identical) right channel over Skype to Jeff.

RECORDING MIXER: I got a Fostex MR16HD from Zzounds:

This mixes together the studio mixer (my voice and computer sound) with Jeff’s voice from Skype, and records it all on a big internal hard drive.

I’m using two separate M-Audio MobilePre USB preamps. These are basically external, high quality sound cards, connected to the computer (and drawing power) via USB.

The first one provides an audio input and output channel to the computer used exclusively for the Skype conversation. The second one is simply a high-quality replacement for the crappy sound card built into the computer; it feeds sounds from the computer to the studio mixer and also to a set of speakers, which I turn off while recording to avoid feedback.

Skype, like most Windows programs, is pretty flexible about letting you choose which signal goes to which sound card when you have several installed:

This is especially convenient when you want Skype to ring on the speaker, while playing sound through the headset.

Once the podcast is over, I transfer the audio file (in uncompressed WAV format) from recording mixer to the computer, where I edit it in Audacity. I don’t do much editing; usually just chopping off the beginning and the end of the recording, and, occasionally, removing things that one of us really regretted saying. Finally, I run the whole WAV file through The Levelator, a fantastic little app developed by the folks at The Conversations Network (who host the podcast). The Levelator takes an entire podcast and adjusts the volumes automatically so that every speaker comes out at the same volume. It’s pretty much magic and eliminates any need to monitor or adjust levels during the recording.

The setup works great. We can talk over one another without dropouts (sample [MP3]), which makes for a much livelier show, and the sound is near FM quality.

Can’t this all be done in software?

Yes! All the cables and analog mixers seem like a ridiculous way to set this up. I’m sure it can all be done with software, which, indeed was something I spent many many hours trying to get to work. There are a lot of little apps that cost $20 that claim to allow you to create virtual sound cards and virtual cables between them, all in software. I couldn’t figure any of them out, but I am pretty handy with an XLR cable, so this is the big hardware kludge I came up with. But it is a big kludge… I’d love to see step by step instructions for doing this properly in software.

The Phone Screen

It happens all the time: we get a resume that everyone thinks is really exciting. Terrific grades. All kinds of powerful-sounding jobs. Lots of experience. Speaks seventeen languages. And saved over 10,000 kittens!

Look! kittens!

And then I call them up, and I can’t stand talking to them. Within ten minutes, I realize they are not going to make it as programmers. I’ve had people with great resumes tell me a pointer should fit in one byte. Sometimes they just can’t answer the simplest questions, or you feel like you have to wrestle the answers out of them.

Before moving on to a full-fledged in-person interview, we usually use a phone screen to make sure that we’re not wasting time and money on someone who is just seriously not smart.

A phone screen has distinct advantages over a normal in-person interview. First, it’s cheap. It takes 45 minutes to an hour and actually does eliminate about half of the people who looked really, really good on paper.

More importantly, it’s more fair.

With a phone interview, because you can’t see the person, it’s easier to focus on the quality of what they’re saying rather than other external factors not relevant to their job, like their appearance, or their nervousness. Ever since Malcolm Gladwell wrote Blink, I’ve been terrified of the prospect that we might be judging candidates too quickly based on things which are not relevant to their ability to do their job—their appearance or confidence or height or general nerdy demeanor might make us way more apt to look on everything else that happens during the interview with rose-colored glasses.

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. This isn’t completely true, of course: you may have prejudices about certain accents or dialects. But at least you are moderately less susceptible to appearance prejudice.

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. This is mainly intended to get them loosened up and feeling comfortable, to eliminate any nervousness, and to let them sort of present themselves the way they want to be presented. During this stage, you should be looking for evidence that the candidate is a problem solver: the kind of person who gets things done. You’re also looking for passion. You want people who care about the stuff that they did.

During this part I’ll drill down on two kinds of things: technology and politics.

Technology. If someone tells me that they implemented such-and-such a project, I’ll ask detailed questions about the technology they used and how they used it. I’ll also ask specifically what role they played. Sole developer? Developer on a team? I’ll tend to go into these questions in great detail, because this is where you uncover the people who either didn’t know what they were doing, or have made things up, or have exaggerated their own roles. If someone’s resume implies that they spent two years coding in Python, for example, I’m going to drill down until I’m pretty confident that it sounds like they really have two years of Python experience.

Don’t hesitate to use trick questions. I might say, “I hate Python, because it’s really tedious to declare all your variables. That’s why I like C better.” Python doesn’t make you declare variables (and C does). Don’t be afraid that the candidate will feel pressured to agree with your false assertion. Smart programmers have a certain affinity for the truth, and they’ll call you on it. As Dave Winer says, “You can’t lie to a compiler.” If they’re really good, they’ll find a way to be diplomatic about it. But they’re going to be passionate enough that they’ll almost forget that they’re in an interview. That’s a good sign.

Politics. Behind the boring list of past employers on the resume, there’s always a story. What I’m looking for is the story of how the candidate handled challenges in the past. I’m looking for people that got things done, even in the face of opposition. I’m looking for people who challenged the status quo, who overcame objections, and who made things happen. So when the resume says, “drove the adoption of .NET,” I want to hear what drove means. In detail. When the resume says that they “founded a company,” I want to hear everything. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?

The second part of the phone screen is the technical problem. I usually ask the same question for years and years before switching it, because this makes it easier to compare candidates. The question is a wide-ranging, open design question: how would you design a data structure or a block of code to do x? Where x is something kind of big and complicated. I usually have a series of questions ready to guide the candidate down a particular path in the design of this data structure or block of code, because it’s such a big question, and I can often tell how smart the candidate is by how far they get down that path in a fixed amount of time.

Here are some ideas to get you started:

  • How might you design a program that lets people play Monopoly with each other over the internet?
  • What would be a good data structure for a photo editor?
  • How would you implement code to operate the elevators in a high rise?
  • How would you implement the rendering engine of a web browser?

The ideal question takes something where the interviewee is deeply familiar with how the thing works from having used it, but is unlikely to have ever implemented it themselves. You want something that can be done over the phone, without too much writing, so “how would you write the code for quicksort” is a bad question, because we don’t expect programmers to be able to recite code over the phone. You want to have a conversation about algorithms and data structures, really, the meat and potatoes of programming, where the goal is not to find the best possible answer, necessarily, but simply to give you the opportunity to talk about code, to talk about time/space tradeoffs, to talk about performance characteristics of code, all of which will add up to giving you a pretty good idea in your mind whether the person you’re talking to is actually pretty good at programming and whether they’re smart or not. If you find yourself explaining everything three times, either you’re terrible at explaining things, or you’re talking to someone who is not that smart.

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 judgment can form an opinion on whether this is a smart person or not.

The third and final part of the interview is letting the candidate interview me. Remember, the whole philosophy of recruiting is predicated on the idea that smart candidates have a choice of where to work, and if that’s true, the interview process is as much a way for the candidate to decide if they want to work for us as it is a way for us to decide if we want to hire the candidate. “Do you have any questions about Fog Creek, about working at Fog Creek, or anything else you want to ask me?”

Sometimes this part of the interview reveals a frightening lack of preparation by the candidate. “So, what exactly does Fog Creek do? And where are you located?” Failing to do even the most basic homework before the interview, by spending five minutes on our web site, does not give me a great deal of confidence in the candidate’s ability to be smart or to get things done.

By this point I’ve already decided if this person seems smart enough to score an in-person interview. So I treat the third part of the phone interview as if I were the one being interviewed, and the candidate was the one that had to be sold on Fog Creek. Which they do.

Passing a phone screen is never enough to get hired. It’s nothing more than a simple filter designed to save time and expense on in-person interviews, and to eliminate candidates who will never make it before you’ve flown them all the way across the country and put them up in a fancy hotel. Still, even with the phone screen, probably only about one in three candidates makes it all the way through the in-person interview.

Sorting Resumes

The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.

Sometimes, though, a resume gives pretty strong negative clues which allow you to screen out applicants without going much further. Once I got a resume from someone who claimed to be an expert in Microsoft Window [sic] programming. Another time the only experience listed on the application was a job at Dunkin’ Donuts. That resume did a pretty good job of following all the suggestions that high school career-guidance advisors love to give out (this guy “managed trays of donuts”) but there was not a smidgen of evidence that the applicant had ever seen a computer.

Other than that, though, it can be extremely hard to tell much about a candidate from a resume. Our policy at Fog Creek, then, has three parts:

  1. We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
  2. We certainly don’t hire based on resumes; we only screen out based on resumes to reduce the number of people whom we have to interview.
  3. In order to sort the remaining resumes to decide what order to interview people, we use a strictly objective system of reviewing and scoring them, so at least we are being fair and consistent in our interpretation of that very weak signal that comes from resumes.

There are several fairly objective measures that we look at, again, solely for the purpose of sorting resumes so that the first people we call are the ones that are most likely to work out.

Passion. We look for evidence that the applicant is passionate about computers and really loves programming. Typical evidence of this:

  • Jobs with computers or experience programming going back to a very early age. Great programmers are more likely to have spent a summer at computer camp, or building an online appointment scheduler for their uncle the dentist, rather than working at Banana Republic folding clothes.

  • Extra-curricular activities. People who love programming often work on their own programming projects (or contribute to an open-source project) in their spare time.

  • Waxing rhapsodic in their cover letter about how they were moved to tears by The Structure and Interpretation of Computer Programs.

  • Sometimes certain programming languages or technologies on a resume indicate evidence of someone who loves programming enough to explore new technologies. At the time I’m writing this, seeing Ruby on a resume is a good sign of the kind of programmer who loves to check out the latest thing and try to improve their skills because they’re passionate about programming, because not so many employers are really demanding Ruby yet. You have to be careful here; in 1996 Java on a resume was a sign of the same passion, but today it adds almost no information.

Pickiness. We look closely at the cover letter for evidence that the applicant really wants to work for us. We don’t want to see a generic cover letter talking about me, me, me: we want to see a coherent argument as to why they’ve thought about this seriously and concluded that Fog Creek is the place they want to work. There are two reasons for using this as a clue. First, it’s a sign that the candidate is not applying to hundreds of jobs at the same time. 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. A bulk-mailed resume can be a symptom of desperation. More importantly, a custom cover letter is a sign that if we do make this candidate an offer, they’re likely to accept it. That improves our yield. If I only have time to interview six people, all else being equal, I’d rather interview six people who really want to work for Fog Creek, not generic smart people that are also applying to a hundred other jobs. All else being equal.

English. Scoring resumes by English skills was a hard decision for us to make, because computer programming is one of those fields where an immigrant who doesn’t speak English can still be a brilliant programmer. 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. It is crucial for documenting code, it is crucial for writing specifications and technical design documents that other people can review, and it’s crucial even for those meetings where you sit around discussing how to do something best: brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution. In this particular category, we also consider the neatness and orderliness of their resume. A disorganized resume rife with grammatical errors where nothing lines up is a pretty big red flag for a disorganized thinker or just general sloppiness; for many jobs this can be fine but not for software development. In particular we usually completely disqualify resumes that are full of English mistakes. It’s not that hard, even for a non-native speaker, to find someone to check your resume, and failure to do that usually reflects a profound lack of concern over the quality of the things that you do. That said, we try to be considerate of non-native speakers who are nonetheless excellent communicators: leaving out articles in that charming Eastern European way, or starting every paragraph with “So” in charming Pacific Northwestian way, is not a showstopper.

Brains. In this category we’re looking for evidence that a candidate is, well, smart, or at least, the kind of nerdy brainiac that went to math camp. Signs of this include high GPAs, high standardized test scores, honors societies like Phi Beta Kappa, people who participate in Top Coder competitions, play competitive chess, or go to ACM Programming contests.

Selectivity. Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. Not everyone at Ivy League schools is worth hiring, and not everyone at community college is worth avoiding, 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. Our company criterion for selectivity is usually getting into a school or program that accepts less than 30% of its applicants (there are about 60 schools in the US that meet this standard), or working for a company which is known to have a difficult application process, like a whole day of interviews. Highly selective branches of the military like officer’s training or pilot’s courses, or even just getting into the Marines indicates someone that has made it through some kind of difficult application/selection procedure and all in all this is a positive sign.

Hard-core. For experienced programmers, there are certain technologies that are considered somewhat more hard-core than others, simply because they are, well, harder to do well. Again, this is a pretty weak indicator, but all else being equal, I’m more impressed by someone who has done work in OCaml than someone who has worked in Java. Assembler or device-driver or kernel work is somewhat more impressive than Visual Basic or PHP. C++ with ATL is harder than Perl. People who have worked on operating systems or compilers are more hard core than people who have worked on simple database front-ends.

I’m sure that this will be seen as incendiary; after all, most of my personal programming experience in the past five years is with VBScript, which is sort of like a version of Visual Basic dumbed down for people with severe brain trauma. Remember again that I said that resumes 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 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.

Diversity. Before I start a massive flame war of international scope by using the loaded term “diversity,” let me carefully define what I mean by this. Specifically, I’m looking for people who come from enough of a different background than the existing team that they are likely to bring new ideas and new ways of thinking to the team and challenge any incipient groupthink that is likely to keep us boxed into our own echo-chamber way of thinking about things. When I say different background, I mean culturally, socially, and professionally. Someone who has a lot of experience with enterprise software may bring useful diversity to a team of internet programmers. Someone who grew up poor is going to bring useful diversity to a startup full of Andover preppies. A stay-at-home mom rejoining the workplace may bring useful diversity to a team of recent graduates. An electrical engineer with Assembler experience may bring useful diversity to a team of Lisp hackers. A recent college graduate from Estonia may bring useful diversity to a team of experienced management consultants from the midwest. The only theory here is that the more diverse your team is, the more likely that someone on the team will have some experience in their background that allows them to come up with a different solution.

It is really really important to remember that these categories—Passion, Pickiness, English, Brains, Selectivity, Hard-Core, and Diversity—are not hiring criteria. They are just too weak for that. There are way too many excellent people who would score low on this test or poor programmers who would score high. Before you go off ranting about how Joel only thinks you should hire from the Ivy League, or that I have some kind of GPA fetish, or whatnot, it’s important to understand that this list is just not a list of reasons to hire someone or reject someone. All it is is an objective and fair way to sort a big pile of resumes to find the candidates who are most likely to work out so that you can interview them first, and then decide if they’re worth hiring.

If resumes are so weak, can’t we add some other hoops?

This is certainly not, by any stretch of the imagination, the ideal set of rules for sorting resumes. I’d much rather be able to sort resumes by the candidate’s ability to implement a recursive algorithm, how long it takes them to find a bug in code, or whether or not they can keep nine items in short term memory, all of which are better indicators of success as programmers than things like whether you got past an elite college’s admissions committee. Unfortunately, those things aren’t on resumes.

One temptation of recruiters is to try and add a few extra hoops to the application process. I’ve frequently heard the suggestion of including a programming quiz of some sort in the application procedure. This does work, in the sense that it reduces the number of applications you get, but it doesn’t work, in the sense that it doesn’t really improve the quality. Great developers have enough choices of places to work that only require the usual cover letter/resume application to get started; by inventing artificial hoops and programming tests and whatnot simply to apply, you’re just as likely to scare away good programmers as weak programmers. Indeed, you may be more likely to scare away the best programmers, who have the most alternatives, and get left with a pool of fairly desperate candidates who are willing to do extra work to apply simply because they don’t have any alternatives.

Don’t look for experience with particular technologies

Once I was on a panel at NYU giving students advice on careers in I.T. My advice, excerpted from this article, was that before graduating you should make sure to learn how to write well, maybe by taking a creative writing course, and take a class in Econ so that the business side of the business isn’t a mystery. I also recommended at least one low-level programming course in C or Assembler just to help you understand how computers work at a lower level.

On the panel with me was a nice chap from a local headhunter, in fact, one of the better tech recruiters in the city. His speech consisted of 15 minutes of tedious alphabet soup. “We’re seeing a lot of XML, some C++, SOAP and WSDL are getting hot but you’re not seeing as much COM or even ATL.” And on, and on, until my eyes were spinning. This was a fellow who entirely thought of the world in terms of keywords on resumes.

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 that 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. “Oh, you don’t have MSMQ experience? Never mind.” At least when real estate agents prattle on about Subzero refrigerators and Viking stoves, they at least know what these things are (although any stainless steel refrigerator counts as “Subzero” these days). The easiest way to catch-out a technical recruiter is when they inevitably insist on 5 years of experience with Ruby on Rails, or refuse to consider someone for a “Windows API” job when they only have “Win32” on their resume.

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.

Our philosophy is that we’re hiring for the long term, and any technology you happen to know right now may well be obsolete next year. Furthermore, some of these technologies are very easy to learn. If I needed to hire someone to do Ruby development, someone with extensive Smalltalk and Python experience who had never even heard of Ruby would be a lot more likely to be successful than someone who read a book about Ruby once. 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.

The keywords section of a resume can’t be trusted much, anyway: every working programmer knows about these computer programs that filter resumes based on keywords, so they usually have a section of their resume containing every technology they have ever touched, solely to get through the filters.

There is, I think, one exception to this rule. 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. A team developing GUIs for Windows using C++ and MFC is going to need at least one Windows/MFC guru somewhere on the team who can make sure that the code is organized correctly in the first place and who has enough experience to know how to solve the really hard problems that might come up.

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. If you have a choice of platforms, use the one your team has the most skills with, even if it’s not the trendiest or nominally the most productive. Occasionally, this may mean you interview to find a candidate with really extensive experience in a particular set of technologies (not keywords, mind you: the whole stack, such as LAMP or .NET or J2EE). But most of your software developers should not be hired by keyword matching.

Sorting resumes is only one aspect of the hiring process, which includes making an environment that is attractive to programmers, attracting good resumes in the first place, and using a rigorous interview process that helps you hire the programmers who can hit the high notes.

A Field Guide to Developers

Unfortunately, you can advertise in all the right places, have a fantastic internship program, and interview all you want, but if the great programmers don’t want to work for you, they ain’t gonna come work for you. So this section will serve as a kind of field guide to developers: what they’re looking for, what they like and dislike in a workplace, and what it’s going to take to be a top choice for top developers.

Private offices

Last year I went to a Computer Science conference at Yale. One of the speakers, a Silicon Valley veteran who had founded or led quite an honor roll of venture-capital funded startups, held up the book Peopleware.

“You have to read this book,” he said. “This is the bible of how to run a software company. This is the most important book out there for how to run software companies.”

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. The authors, DeMarco and Lister, go on and on about that subject.

After the speech I went up to the speaker. “I agree with you about Peopleware,” I said. “Tell me: did you have private offices for your developers at all your startups?”

“Of course not,” he said. “The VCs would never go for that.”


“But that might be the number one most important thing in that book,” I said.

“Yeah, but you gotta pick your battles. To VCs, private offices look like you’re wasting their money.”

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 private offices are far more productive, something which I’ve covered repeatedly on this site. I’m not really getting through to people, I don’t think, because programmers kind of like being social, even if it means they are unproductive, so it’s an uphill battle.

I’ve even heard programmers say things like, “Yeah, we all work in cubicles, but everyone works in a cubicle—up to and including the CEO!”

“The CEO? Does the CEO really work in a cubicle?”

“Well, he has a cubicle, but actually now that you mention it there’s this one conference room that he goes to for all his important meetings…”

Mmmm hmmm. A fairly common Silicon Valley phenomenon is the CEO who makes a big show of working from a cubicle just like the hoi polloi, although somehow there’s this one conference room that he tends to make his own (“Only when there’s something private to be discussed,” he’ll claim, but half the time when you walk by that conference room there’s your CEO, all by himself, talking on the phone to his golf buddy, with his Cole Haans up on the conference table).

Anyway, I don’t want to revisit the discussion of why private offices are more productive for software developers, or why just putting on headphones to drown out the ambient noise has been shown to reduce the quality of work that programmers produce, and why it doesn’t really cost that much more in the scheme of things to have private offices for developers. I’ve talked about that already. Today I’m talking about recruiting, and private offices in recruiting.

No matter what you think about productivity, and no matter what you think about egalitarian workspaces, two things are incontrovertible:

  1. Private offices have higher status
  2. Cubicles and other shared space can be socially awkward.

Given these two facts, the bottom line is that programmers are more likely to take the job that offers them a private office. Especially if there’s a door that shuts, and a window, and a nice view.

Now, it’s an unfortunate fact that some of these things that make recruiting easier are not really within your power. Even CEOs and founders can be prevented from establishing private offices if they’re dependent on VCs. Most companies only move or rearrange their office space every five to ten years. Smaller startups may not be able to afford private offices. So my experience has been that a number of excuses all pile up until it’s virtually impossible to get private offices for developers in any but the most enlightened of companies, and even in those companies, the decision of where to move and where people should work is often taken once every ten years by a committee consisting of the office manager’s secretary and a junior associate from a big architecture firm, who is apt to believe architecture-school fairy tales about how open spaces mean open companies, or whatever, with close to zero input from the developers or the development team.

This is something of a scandal, and I’ll keep fighting the good fight, but in the meantime, private offices are not impossible; we’ve managed to do it for all of our full-time programmers, most of the time, even in New York City where the rents are some of the highest in the world, and there’s no question that it makes people much happier about working at Fog Creek, so if you all want to keep resisting, so be it, I’ll just let this remain a competitive advantage.

The physical workspace

There’s more to the physical workspace than private offices. 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. If the office space is pleasant, if it’s bright, if it’s in a nice neighborhood, if everything is new and clean: they’ll have happy thoughts. 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.

A lot of tech people are remarkably unaware of the general condition of their office. In fact, even people who are otherwise attuned to the benefits of a nice office may be blinded to the particular weaknesses of their own office, since they’re so used to it.

Put yourself in your candidate’s heads, and think honestly:

  • What will they think of our location? How does Buffalo sound, compared to, say, Austin? Do people really want to move to Detroit? If you’re in Buffalo or Detroit, can you at least try to do most of your interviewing in September?
  • When they get to the office, what is the experience like? What do they see? Do they see a clean and exciting place? Is there a nice atrium lobby with live palm trees and a fountain, or does it feel like a government dental clinic in a slum, with dying corn plants and old copies of Newsweek?
  • What does the workspace look like? Is everything new and shiny? Or do you still have that gigantic, yellowing TEAM BANANA sign up, the one that was printed on fanfold paper on a dot matrix printer back when there used to be a thing called fanfold paper and a thing called dot matrix printers?
  • What do the desks look like? Do programmers have multiple large flat screens or a single CRT? Are the chairs Aerons or Staples Specials?

Let me, for a moment, talk about the famous Aeron chair, made by Herman Miller. They cost about $900. This is about $800 more than a cheap office chair from OfficeDepot or Staples.

They are much more comfortable than cheap chairs. If you get the right size and adjust it properly, most people can sit in them all day long without feeling uncomfortable. The back and seat are made out of a kind of mesh that lets air flow so you don’t get sweaty. The ergonomics, especially of the newer models with lumbar support, are excellent.

They last longer than cheap chairs. We’ve been in business for six years and every Aeron is literally in mint condition: I challenge anyone to see the difference between the chairs we bought in 2000 and the chairs we bought three months ago. They easily last for ten years. The cheap chairs literally start falling apart after a matter of months. You’ll need at least four $100 chairs to last as long as an Aeron.

So the bottom line is that an Aeron only really costs $500 more over ten years, or $50 a year. One dollar per week per programmer.

A nice roll of toilet paper runs about a buck. Your programmers are probably using about one roll a week, each.

So upgrading them to an Aeron chair literally costs the same amount as you’re spending on their toilet paper, and I assure you that if you tried to bring up toilet paper in the budget committee you would be sternly told not to mess around, there were important things to discuss.

The Aeron chair has, sadly, been tarnished with a reputation of being extravagant, especially for startups. It somehow came to stand for the symbol of all the VC money that was wasted in the dotcom boom, which is a shame, because it’s not very expensive when you consider how long it lasts; indeed when you think of the eight hours a day you spend sitting in it, even the top of the line model, with the lumbar support and the friggin’ tailfins is so dang cheap you practically make money by buying them.


Similar logic applies for other developer toys. 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 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? When I was a kid, …

The social life of developers

Software developers are not really all that different from regular people. Sure, I know, it’s popular these days to think of developers as stereotypical Asperger’s geeks, totally untuned to interpersonal things, but that’s just not true and even Asperger’s geeks care about the social aspect of a workspace, which includes these issues:

  • How are programmers treated inside the organization?

    Are they hotshots or typists? Is company management made up of engineers or former programmers? When developers go to a conference, do they fly first class? (I don’t care if that seems like a waste of money. Stars go first class. Get used to it.) When they fly in for an interview, does a limo pick them up at the airport or are they expected to find their own way to the office? All else being equal, developers are going to prefer an organization that treats them like stars. If your CEO is a grouchy ex-sales person who doesn’t understand why these prima donna developers keep demanding things like wrist pads and big monitors and comfortable chairs, who do they think they are?, your company probably needs an attitude adjustment. You’re not going to get great developers if you don’t respect them.

  • Who are their colleagues?

    One thing programmers pay close attention to in the day of interviewing is the people they meet. Are they nice? More importantly: are they smart? I did a summer internship once at Bellcore, a spinoff of Bell Labs, and everybody I met kept telling me the same thing, again and again: “The great thing about working for Bellcore is the people.”

    That said, if you have any grouchy developers that you just can’t get rid of, at least take them off the interview schedule, and if you have cheerful, social, cruise-director types, make sure they’re on it. 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.” In retrospect, at Microsoft not being a jerk is not a requirement to get the job; although I’m sure they would pay lip service to how important it as for people to be nice to one another, the bottom line is that they would never disqualify someone for a job just because they were a jerk, in fact, being a jerk sometimes seems like a prerequisite for getting into upper management. This doesn’t really seem to hurt from a business perspective, although it does hurt from a recruiting perspective and who wants to work at a company where jerks are tolerated?

  • Independence and autonomy

    When I quit my job at Juno, back in 1999, before starting Fog Creek Software, HR gave me a standard exit interview, and somehow, I fell into the trap of telling the HR person everything that was wrong about the management of the company, something which I knew perfectly well could have no possible benefit to me and could only, actually, hurt, but I did it anyway, and the main thing I complained about was Juno’s style of hit-and-run management. Most of the time, you see, managers would leave people alone to quietly get their work done, but occasionally, they would get themselves involved in some microscopic detail of something which they would insist be done exactly their way, no excuses, and then they’d move on to micromanage some other task, not staying around long enough to see the farcical results. For example, I remember a particularly annoying period of two or three days where everyone from my manager to the CEO got involved in telling me exactly how dates must be entered on the Juno signup questionnaire. They weren’t trained as UI designers and didn’t spend enough time talking to me about the issues to understand why I happened to be right in that particular case, but it didn’t matter: management just would not back down on that issue and wouldn’t even take the time to listen to my arguments.

    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 the 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.

  • No politics

    Actually, politics happen everywhere that more than two people congregate. It’s just natural. By “no politics” I really mean “no dysfunctional politics.” Programmers have very well-honed senses of justice. Code either works, or it doesn’t. There’s no sense in arguing whether a bug exists, since you can test the code and find out. 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.

    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.

    Nothing is more satisfying than winning an argument on its technical merits even when you should have lost it on political merits. When I started working at Microsoft there was a major, misguided project underway called MacroMan to create a graphical macro programming language. The programming language would have been very frustrating for real programmers, because the graphical nature didn’t really give you a way to implement loops or conditionals, but would not have really helped non-programmers, who, I think, are just not used to thinking in algorithms and wouldn’t have understood MacroMan in the first place. When I complained about MacroMan, my boss told me, “Nothing’s gonna derail that train. Give up.” But I kept arguing, and arguing, and arguing—I was fresh out of college, about as unconnected as anyone could be at Microsoft—and eventually people listened to the meat of my arguments and the MacroMan project was shut down. It didn’t matter who I was, it mattered that I was right. That’s the kind of non-political organization that delights programmers.

All in all, focusing on the social dynamics of your organization is crucial to making a healthy, pleasant place to work that will retain programmers and attract programmers.

What am I working on?

To some extent, one of the best ways you can attract developers is to let them work on something interesting. This may be the hardest thing to change: doggone it, if you’re in the business of making software for the gravel and sand industry, that’s the business you’re in, and you can’t pretend to be some cool web startup just to attract developers.

Another thing developers like is working on something simple enough or popular enough that they can explain to Aunt Irma, at Thanksgiving. Aunt Irma, of course, being a nuclear physicist, doesn’t really know that much about Ruby programming in the gravel and sand industry.

Finally, many developers are going to look at the social values of the company they’re working for. Jobs at social networking companies and blog companies help bring people together and don’t really pollute, it seems, so they’re popular, while jobs in the munitions industry or in ethically-challenged accounting-fraud-ridden companies are a lot less popular.

Unfortunately I’m not really sure if I can think of any way for the average hiring manager to do anything about this. You can try to change your product lineup to make something “cool,” but that’s just not going to go very far. There are a few things, though, that I’ve seen companies do in this area:

  • Let the top recruits pick their own project

    For many years, Oracle Corporation had a program called MAP: the “Multiple Alternatives Program.” This was offered to the college graduates whom they considered the top candidates from each class. The idea was that they could come to Oracle, spend a week or two looking around, visiting all the groups with openings, and then choose any opening they wanted to work in.

    I think this was a good idea, although probably someone from Oracle knows better whether this worked out.

  • Use cool new technologies unnecessarily

    The big investment banks in New York are considered fairly tough places for programmers. The working conditions are dreadful, with long hours, noisy environments, and tyrannical bosses; programmers are very distinct third-class citizens while the testosterone-crazed apes who actually sell and trade financial instruments are corporate royalty, with $30,000,000 bonuses and all the cheeseburgers they can eat (often delivered by a programmer who happened to be nearby). That’s the stereotype, anyway, so to keep the best developers, investment banks have two strategies: paying a ton of money, and allowing programmers basically free reign to keep rewriting everything over and over again in whatever hot new programming language they feel like learning. Wanna rewrite that whole trading app in Lisp? Whatever. Just get me a goddamned cheeseburger.

    Some programmers couldn’t care less about what programming language they’re using, but most would just love to have the opportunity to work with exciting new technologies. Today that may be Python or Ruby on Rails; three years ago it was C# and before that Java.

    Now, I’m not telling you not to use the best tool for the job, and I’m not telling you to rewrite in the hot language-du-jour every two years, but if you can find ways for developers to get experience with newer languages, frameworks, and technologies, they’ll be happier. Even if you don’t dare rewrite your core application, is there any reason your internal tools, or less-critical new applications, can’t be written in an exciting new language as a learning project?

Can I identify with the company?

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. They want to identify with their company. Young programmers, especially, are attracted to ideological companies. A lot of companies have some connection to open source or the free software movement (these are not the same thing), and that can be attractive to idealistic developers. Other companies line up with social causes, or produce a product which, in some way, can be perceived or framed as benefitting society.

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

Some companies even strive to create their own ideological movements. Chicago-area startup 37signals has strongly aligned themselves with the idea of simplicity: simple, easy to use apps like Backpack and the simple, easy to use programming framework Ruby on Rails.

For 37signals, simplicity is an “-ism”, practically an international political movement. Simplicity is not just simplicity, oh no, it’s summertime, it’s beautiful music and peace and justice and happiness and pretty girls with flowers in their hair. David Heinemeier Hansson, the creator of Rails, says that their story is “one of beauty, happiness, and motivation. Taking pride and pleasure in your work and in your tools. That story simply isn’t a fad, it’s a trend. A story that allows for words like passion and enthusiasm to be part of the sanctioned vocabulary of developers without the need to make excuses for yourself. Or feel embarrassed about really liking what you do.” Elevating a web programming framework to a thing of “beauty, happiness, and motivation” may seem like hubris, but it’s very appealing and sure differentiates their company. In propagating the narrative of Ruby on Rails as Happiness, they’re practically guaranteeing that at least some developers out there will be looking for Ruby on Rails jobs.

But 37signals is still new at this identity management campaign thing. They don’t hold a candle to Apple Computer, which, with a single Superbowl ad in 1984, managed to cement their position to this day as the countercultural force of freedom against dictatorship, of liberty against oppression, of colors against black and white, of pretty women in bright red shorts against brainwashed men in suits. The implications of this, I’m afraid, are ironically Orwellian: giant corporations manipulating their public image in a way which doesn’t even make sense (like, uh, they’re a computer company—what the hell does that have to do with being against dictatorships?) and successfully creating a culture of identity that has computer shoppers around the world feeling like they’re not just buying a computer, they’re buying into a movement. When you buy an iPod, of course, you’re supporting Gandhi against British Colonialism. Every MacBook bought takes a stand against dictatorship and hunger!

Anyway. Deep breath… 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.

One thing that programmers don’t care about

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. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”

That doesn’t mean you can underpay people, because they do care about justice, and they will get infuriated if they find out that different people are getting different salaries for the same work, or that everyone in your shop is making 20% less than an otherwise identical shop down the road, and suddenly money will be a big issue. 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.

Sorting Resumes

This series continues with an article on how to sort resumes, so that the first people you interview are the most likely to work out well.

Finding Great Developers

Where are all those great developers?

The first time you try to fill an open position, if you’re like most people, you place some ads, maybe browse around the large online boards, and get a ton of resumes.

As you go through them, you think, “hmm, this might work,” or, “no way!” or, “I wonder if this person could be convinced to move to Buffalo.” What doesn’t happen, and I guarantee this, what never happens is that you say, “wow, this person is brilliant! We must have them!” In fact you can go through thousands of resumes, assuming you know how to read resumes, which is not easy, and I’ll get to that on Friday, but you can go through thousands of job applications and quite frankly never see a great software developer. Not a one.

Here is why this happens.

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, 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. If they leave that company, it’s often to go to a startup with a friend, or to follow a great boss to another company, or because they decided they really want to work on, say, Eclipse, because Eclipse is cool, so they look for an Eclipse job at BEA or IBM and then of course they get it because they’re brilliant.

If you’re lucky, if you’re really lucky, they show up on the open job market once, when, say, their spouse decides to accept a medical internship in Anchorage and they actually send their resume out to what they think are the few places they’d like to work at in Anchorage.

But for the most part, great developers (and this is almost a tautology) are, uh, great, (ok, it is a tautology), and, usually, prospective employers recognize their greatness quickly, which means, basically, they get to work wherever they want, so they honestly don’t send out a lot of resumes or apply for a lot of jobs.

Does this sound like the kind of person you want to hire? It should.

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. Their companies fail—sometimes because any company that would hire them would probably also hire a lot of unqualified programmers, so it all adds up to failure—but sometimes because they actually are so unqualified that they ruined the company. Yep, it happens.

These morbidly unqualified people rarely get jobs, thankfully, but they do keep applying, and when they apply, they go to and check off 300 or 1000 jobs at once trying to win the lottery.

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. So now, Sparky, back to that big pile of resumes you got off of Craigslist. Is it any surprise that most of them are people you don’t want to hire?

Astute readers, I expect, will point out that I’m leaving out the largest group yet, the solid, competent people. They’re on the market more than the great people, but less than the incompetent, and all in all they will show up in small numbers in your 1000 resume pile, but for the most part, almost every hiring manager in Palo Alto right now with 1000 resumes on their desk has the same exact set of 970 resumes from the same minority of 970 incompetent people that are applying for every job in Palo Alto, and probably will be for life, and only 30 resumes even worth considering, of which maybe, rarely, one is a great programmer. OK, maybe not even one. And figuring out how to find those needles in a haystack, we shall see, is possible but not easy.

Can I get them anyway?


Well, Maybe!

Or perhaps, It Depends!

Instead of thinking as recruiting as a “gather resumes, filter resumes” procedure, you’re going to have to think of it as a “track down the winners and make them talk to you” procedure.

I have three basic methods for how to go about this:

  1. Go to the mountain
  2. Internships
  3. Build your own community*

(Build your own community comes with a little asterisk that means “hard,” like the famous math problem that George Dantzig solved because he came into class too late to hear that it was supposed to be unsolvable).

You can probably come up with your own ideas, too. I’m just going to talk about three that worked for me.

To the mountain, Jeeves!

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? Instead of casting a wide net with a job search on, use the Joel on Software job board and limit your search to the smart people that read this site. Go to the really interesting tech conferences. Great Mac developers will be at Apple’s WWDC. Great Windows programmers will be at Microsoft’s PDC. There are a bunch of open source conferences, too.

Look for the hot new technology of the day. Last year it was Python; this year it’s Ruby. Go to their conferences where you’ll find early adopters who are curious about new things and always interested in improving.

Slink around in the hallways, talk to everyone you meet, go to the technical sessions and invite the speakers out for a beer, and when you find someone smart, BANG!—you launch into full-fledged flirt and flattery mode. “Ooooh, that’s so interesting!” you say. “Wow, I can’t believe you’re so smart. And handsome too. Where did you say you work? Really? There? Hmmmmmmm. Don’t you think you could do better? I think my company might be hiring…”

The corollary of this rule is to avoid advertising on general-purpose, large job boards. One summer, I inadvertently advertised our summer internships using MonsterTRAK, which offered the option to pay a little extra to make the internship visible to students at every school in the USA. This resulted in literally hundreds of resumes, not one of which made it past the first round. We ended up spending a ton of money to get a ton of resumes that stood almost no chance at finding the kind of people we wanted to hire. After a few days of this, the very fact that MonsterTRAK was the source of the resume made me think the candidate was probably not for us. Similarly, when Craigslist first started up and was really just visited by early-adopters in the Internet industry, we found great people by advertising on Craigslist, but today, virtually everyone who is moderately computer-literate uses it, resulting in too many resumes with too low of a needle-to-haystack ratio.


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.

Some hiring managers hate the idea of hiring interns. They see interns as unformed and insufficiently skilled. To some extent, that’s true. Interns are not as experienced as experienced employees (no. Really?!). You’re going to have to invest in them a little bit more and it’s going to take some time before they’re up to speed. The good news about our field is that the really great programmers often started programming when they were 10 years old. And while everyone else their age was running around playing “soccer” (this is a game that many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux kernel to compile. Instead of chasing girls in the playground, they were getting into flamewars on Usenet about the utter depravity of programming languages that don’t implement Haskell-style type inference. Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access WIFI point, all the images on the web appeared upside-down. BWA HA HA HA HA!

So, unlike, say, the fields of law or medicine, over here in software development, by the time these kids are in their second or third year in college they are pretty darn good programmers.

Pretty much everyone applies for one job: their first one, and most kids think that it’s OK to wait until their last year to worry about this. And in fact most kids are not that inventive, and will really only bother applying for jobs where there is actually some kind of on-campus recruiting event. Kids at good colleges have enough choices of good jobs from the on-campus employers that they rarely bother reaching out to employers that don’t bother to come to campus.

You can either participate in this madness, by recruiting on campus, which is a good thing, don’t get me wrong, or you can subvert it, by trying to get great kids a year or two before they graduate.

I’ve had a lot of success doing it that way at Fog Creek. The process starts every September, when I start using all my resources to track down the best computer science students in the country. I send letters to a couple of hundred Computer Science departments. I track down lists of CS majors who are, at that point, two years away from graduating (usually you have to know someone in the department, a professor or student, to find these lists). Then I write a personal letter to every single CS major that I can find. Not email, a real piece of paper on Fog Creek letterhead, which I sign myself in actual ink. Apparently this is rare enough that it gets a lot of attention. I tell them we have internships and personally invite them to apply. I send email to CS professors and CS alumni, who usually have some kind of CS-majors mailing list that they forward it on to.

Eventually, we get a lot of applications for these internships, and we can have our pick of the crop. In the last couple of years I’ve gotten 200 applications for every internship. We’ll generally winnow that pile of applications down to about 10 (per opening) and then call all those people for a phone interview. Of the people getting past the phone interview, we’ll probably fly two or three out to New York for an in-person interview.

By the time of the in-person interview, there’s such a high probability that we’re going to want to hire this person that it’s time to launch into full-press recruitment. They’re met at the airport here by a uniformed limo driver who grabs their luggage and whisks them away to their hotel, probably the coolest hotel they’ve ever seen in their life, right in the middle of the fashion district with models walking in and out at all hours and complicated bathroom fixtures that are probably a part of the permanent collection of the Museum of Modern Art, but good luck trying to figure out how to brush your teeth. Waiting in the hotel room, we leave a hospitality package with a T-shirt, a suggested walking tour of New York written by Fog Creek staffers, and a DVD documentary of the 2005 summer interns. There’s a DVD player in the room so a lot of them watch how much fun was had by previous interns.

After a day of interviews, we invite the students to stay in New York at our expense for a couple of days if they want to check out the city, before the limo picks them up at their hotel and takes them back to the airport for their flight home.

Even though only about one in three applicants who make it to the in-person interview stage passes all our interviews, it’s really important that the ones that do pass have a positive experience. Even the ones that don’t make it go back to campus thinking we’re a classy employer and tell all their friends how much fun they had staying in a luxury hotel in the Big Apple, which makes their friends apply for an internship the next summer, if only for the chance at the trip.

During the summer of the internship itself, the students generally start out thinking, “ok, it’s a nice summer job and some good experience and maybe, just maybe, it’ll lead to a full-time job.” We’re a little bit ahead of them. We’re going to use the summer to decide if we want them as a full-time employee, and they’re going to use the summer to decide if they want to work for us.

So we give them real work. Hard work. Our interns always work on production code. Sometimes they’re working on the coolest new stuff in the company, which can make the permanent employees a little jealous, but that’s life. One summer we had a team of four interns build a whole new product from the ground up. That internship paid for itself in a matter of months. Even when they’re not building a new product, they’re working on real, shipping code, with some major area of functionality that they are totally, personally responsible for (with experienced mentors to help out, of course).

And then we make sure they have a great time. We host parties and open houses. We get them free housing in a rather nice local dorm where they can make friends from other companies and schools. We have some kind of extra-curricular activity or field trip every week: Broadway musicals (this year they went crazy about Avenue Q), movie openings, museum tours, a boat ride around Manhattan, a Yankees game, and believe it or not one of this year’s favorite things was a trip to Top of the Rock. I mean, it’s just a tall building where you go out on the roof in the middle of Manhattan. You wouldn’t think it would be such an awe-inspiring experience. But it was. A few Fog Creek employees go along on each activity, too.

At the end of the summer, there are always a few interns who convinced us that they are the truly great kinds of programmers that we just have to hire. Not all of them, mind you—some are merely great programmers that we are willing to pass on, and others would be great somewhere else, but not at Fog Creek. For example we’re a fairly autonomous company without a lot of middle management, where people are expected to be completely self-driven. Historically it has happened a couple of times where a summer intern would be great in a situation where they had someone to guide them, but at Fog Creek they wouldn’t get enough direction and would flounder.

Anyway, for the ones we really want to hire, there’s no use in waiting. We make an early offer for a full time job, conditional on their graduating. And it’s a great offer. We want them to be able to go back to school, compare notes with their friends, and realize that they’re getting a higher starting salary than anyone else.

Does this mean we’re overpaying? Not at all. You see, the average first year salary has to take into account a certain amount of risk that the person won’t work out. But we’ve already auditioned these kids, and there’s no risk that they won’t be great. We know what they can do. So when we hire them, we have more information about them than any other employer who has only interviewed them. That means we can pay them more money. We have better information, so we’re willing to pay more than employers without that information.

If we’ve done our job right, and we usually have, by this point the intern completely gives up and accepts our offer. Sometimes it takes a little more persuading. Sometimes they want to leave their options open, but the outstanding offer from Fog Creek ensures that the first time they have to wake up at 8:00am and put on a suit for an interview with Oracle, when the alarm goes off, there’s a good chance that they’ll say “why the heck am I getting up at 8:00am and putting on a suit for an interview with Oracle when I already have an excellent job waiting for me at Fog Creek?” And, my hope is, they won’t even bother going to that interview.

By the way, before I move on, I need to clarify something about internships in computer science and software development. In this day and age, in this country, it is totally expected that these are paid internships, and the salaries are usually pretty competitive. Although unpaid internships are common in other fields from publishing to music, we pay $750 a week, plus free housing, plus free lunch, plus free subway passes, not to mention relocation expenses and all the benefits. The dollar amount is a little bit lower than average but it includes the free housing so it works out being a little bit better than average. I thought I’d mention that because every time I’ve talked about internships on my website somebody inevitably gets confused and thinks I’m taking advantage of slave labor or something. You there—young whippersnapper! Get me a frosty cold orange juice, hand-squeezed, and make it snappy!

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 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. The first three summers, we tried to limit our internship program to students with one year left in school, but this summer we finally realized that we were missing out on some great younger students so we opened the program to students in any year in college. Believe it or not, I’m even trying to figure out how to get high school kids in here, maybe setting up computers after school for college money, just to start to build a connection with the next generation of great programmers, even if it becomes a six year pipeline. I have a long horizon.

Build the community (*hard)

The idea here is to create a large community of like-minded smart developers who cluster around your company, somehow, so you have an automatic audience to reach out to every time you have an opening.

This is, to tell the truth, how we found so many of our great Fog Creek people: through my personal website, the one you’re reading right now. Major articles on this site can be read by as many as a million people, most of them software developers in some capacity. With a large, self-selecting audience, whenever I mention that I’m looking for someone on the home page, I’ll usually get a pretty big pile of very good resumes.

This is that category with the asterisk that means “hard,” since I feel like I’m giving you advice that says, “to win a beauty pageant, (a) get beautiful, and (b) enter the pageant.” That’s because I’m really not sure why or how this site became so popular or why the people who read it are the best software developers.

I really wish I could help you more here. Derek Powazek wrote a good book on the subject (Design for Community). A lot of companies tried various blogging strategies and unfortunately a lot of them failed to build up any kind of audience, so all I can say is that what worked for us may or may not work for you and I’m not sure what you can do about it. I did just open a job board on the site ( where, for $350, you can list a job that Joel on Software readers will see.

Employee referrals: may be slippery when wet

The standard bit of advice on finding great software developers is to ask your existing developers. The theory is, gosh, they’re smart developers, they must know other smart developers.

And they might, but they also have very dear friends who are not very good developers, and there are about a million land mines in this field, so the truth is I generally consider the idea of employee referrals to be one of the weakest sources of new hires.

One big risk, of course, is non-compete agreements. If you didn’t think these mattered, think about the case of Crossgain, which had to fire a quarter of its employees, all ex-Microsoft, when Microsoft threatened them with individual lawsuits. 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.

The point being, non-compete agreements may mean that if you rely too heavily on referrals and end up hiring a block of people from the same ex-employer, which is where your employees know the other star programmers from in the first place, you’re taking a pretty major risk.

Another problem is that if you have any kind of selective hiring process at all, when you ask your employees to find referrals, they’re not going to even consider telling you about their real friends. Nobody wants to persuade their friends to apply for a job at their company only to get rejected. It sort of puts a damper on the friendship.

Since they won’t tell you about their friends and you may not be able to hire the people they used to work with, what’s left is not very many potential referrals.

But the real problem with employee referrals is what happens when recruiting managers with a rudimentary understanding of economics decide to offer cash bonuses for these referrals. This is quite common. The rationale goes like this: it can cost $30,000 to $50,000 to hire someone good through a headhunter or outside recruiter. If we can pay our employees, say, a $5000 bonus for every hire they bring in, or maybe an expensive sports car for every 10 referrals, or whatever, think how much money that will save? And $5000 sounds like a fortune to a salaried employee, because it is. So this sounds like a win-win all-around kind of situation.

The trouble is that suddenly you can see the little gears turning, and employees start dragging in everyone they can think of for interviews, and they have a real strong incentive to get these people hired, so they coach them for the interview, and Quiet Conversations are held in conference rooms with the interviewers, and suddenly your entire workforce is trying to get you to hire someone’s useless college roommate.

And it doesn’t work. ArsDigita got a lot of publicity for buying a Ferrari and putting it in the parking lot and announcing that anyone who got 10 referrals could have it. Nobody ever got close, the quality of new hires went down, and the company fell apart, but probably not because of the Ferrari, which, it turns out, was rented, and not much more than a publicity stunt.

When a Fog Creek employee suggests someone that might be perfect to work for us, we’ll be willing to skip the initial phone screen, but that’s it. We still want them going through all the same interviews and we maintain the same high standards.

A Field Guide to Developers

What do developers look for in a job? What makes one job more appealing to them than another? How can you become the employer of choice? Read on!

The Development Abstraction Layer

A young man comes to town. He is reasonably good looking, has a little money in his pocket. He finds it easy to talk to women.

He doesn’t speak much about his past, but it is clear that he spent a lot of time in a soulless big company.

He is naturally friendly and outgoing, and quietly confident without being arrogant. So he finds it easy to pick up small gigs from the job board at the local Programmer’s Cafe. But he rapidly loses interest in insurance database projects, vanity web pages for housewives, and financial calculation engines.

After a year, he calculates that he has saved up enough money to pay his modest expenses for a year. So, after consulting with his faithful Alsatian, he sets up a computer in a sunfilled room in his rented apartment above the grocery store and installs a carefully-chosen selection of tools.

One by one, he calls his friends and warns them that if he seems remote over the next months, it is only because he is hard at work.

And he sits down to spin code.

And what code it is. Flawless, artistic, elegant, bug free. The user interface so perfectly mimics a users’ thought process that the people he shows it to at the Programmer’s Cafe hardly notice that there is a user interface. It’s a brilliant piece of work.

Encouraged by the feedback of his peers, he sets up in business and prepares to take orders.

His modesty precludes any pretensions, but after a month, the situation in his bank account is not looking encouraging. So far only three orders have been taken: one from his mother, one from an anonymous benefactor at the Programmer’s Cafe, and the one he submitted himself to test the commerce system.

In the second month, no more orders come in.

This surprises him and leaves him feeling melancholy. At the big company, new products were created on a regular basis, and even if they were inelegant and homely, they still sold in reasonable quantities. One product he worked on there went on to be a big hit.

After a few more months pass, his financial situation starts to look a little bit precarious. His dog looks at him sadly, not quite certain what is wrong, but aware that his face is looking a little bit gaunter than usual, and he seems to be unable to get up the energy to go out with friends, or go shopping to restock the dangerously low larder, or even to bathe.

One Tuesday morning, the local grocer has refused to extend him any more credit, and his banker has long since refused to return his calls.

The big company is not vindictive. They recognize talent, and are happy to hire him back, at a higher salary. Soon he is looking better, he has some new clothes, and he’s got his old confidence back. But something, somewhere, is missing. A spark in his eye. The hope that he might become the master of his own destiny is gone.

Why did he fail? He’s pretty sure he knows. “Marketing,” he says. Like many young technicians, he is apt to say things like, “Microsoft has worse products but better marketing.”

When uttered by a software developer, the term “marketing” simply stands in for all that business stuff: everything they don’t actually understand about creating software and selling it.

This, actually, is not really what “marketing” means. Actually Microsoft has pretty terrible marketing. Can you imagine those dinosaur ads actually making someone want to buy Microsoft Office?

Software is a conversation, between the software developer and the user. But for that conversation to happen requires a lot of work beyond the software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

But what do software developers do? They design and write code, they layout screens, they debug, they integrate, and they check things into the source code control repository.

The level a programmer works at (say, Emacs) is too abstract to support a business. Developers working at the developer abstraction layer need an implementation layer — an organization that takes their code and turns it into products. Dolly Parton, working at the “singing a nice song” layer, needs a huge implementation layer too, to make the records and book the concert halls and take the tickets and set up the audio gear and promote the records and collect the royalties.

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

Most new software managers miss this point. They keep thinking of the traditional, Command-and-Conquer model of management that they learned from Hollywood movies.

According to Command-and-Conquer, managers-slash-leaders figure out where the business is going to go, and then issue the appropriate orders to their lieutenants to move the business in that direction. Their lieutenants in turn divide up the tasks into smaller chunks and command their reports to implement them. This continues down the org-chart until eventually someone at the bottom actually does some work. In this model, a programmer is a cog in the machine: a typist who carries out one part of management’s orders.

Some businesses actually run this way. You can always tell when you are dealing with such a business, because the person you are talking to is doing something infuriating and senseless, and they know it, and they might even care, but there’s nothing they can do about it. It’s the airline that loses a million mile customer forever because they refuse to change his non-refundable ticket so he can fly home for a family emergency. It’s the ISP whose service is down more often than it’s up, and when you cancel your account, they keep billing you, and billing you, and billing you, but when you call to complain, you have to call a toll number and wait on hold for an hour, and then they still refuse to refund you, until you start a blog about how badly they suck. It’s the Detroit automaker that long since forgot how to design cars that people might want to buy and instead lurches from marketing strategy to marketing strategy, as if the only reason we don’t buy their crappy cars is because the rebate wasn’t big enough.


Forget it. The command-hierarchy system of management has been tried, and it seemed to work for a while in the 1920s, competing against peddlers pushing carts, but it’s not good enough for the 21st century. For software companies, you need to use a different model.

With a software company, the first priority of management needs to be creating that abstraction for the programmers.

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It’s impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there’s a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don’t steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

Programmers need a Subversion repository. Getting a Subversion repository means you need a network, and a server, which has to be bought, installed, backed up, and provisioned with uninterruptible power, and that server generates a lot of heat, which means it need to be in a room with an extra air conditioner, and that air conditioner needs access to the outside of the building, which means installing an 80 pound fan unit on the wall outside the building, which makes the building owners nervous, so they need to bring their engineer around, to negotiate where the air conditioner unit will go (decision: on the outside wall, up here on the 18th floor, at the most inconvenient place possible), and the building gets their lawyers involved, because we’re going to have to sign away our firstborn to be allowed to do this, and then the air conditioning installer guys show up with rigging gear that wouldn’t be out of place in a Barbie play-set, which makes our construction foreman nervous, and he doesn’t allow them to climb out of the 18th floor window in a Mattel harness made out of 1/2″ pink plastic, I swear to God it could be Disco Barbie’s belt, and somebody has to call the building agent again and see why the hell they suddenly realized, 12 weeks into a construction project, that another contract amendment is going to be needed for this goddamned air conditioner that they knew about before Christmas and they only just figured it out, and if your programmers even spend one minute thinking about this that’s one minute too many.

To the software developers on your team, this all needs to be abstracted away as typing svn commit on the command line.

That’s why you have management.

It’s for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

You’ve got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales. These companies can be identified in the wild because they build version 1.0 of the software (somehow) and then completely lose interest in developing new software. Their development team is starved or nonexistent because it never occurred to anyone to build version 2.0… all that management knows how to do is drive more sales.

On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

Both of these companies can easily be wiped out by a company that’s driven by programmers and organized to put programmers in the driver’s seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that’s so comfortable you don’t feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can’t see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1. (Here’s something Pradeep Singh taught me today: if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?)

Management’s primary responsibility to create the illusion that a software company can be run by writing code, because that’s what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it’s unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.

Microsoft does such a good job at creating this abstraction that Microsoft alumni have a notoriously hard time starting companies. They simply can’t believe how much went on below decks and they have no idea how to reproduce it.

Nobody expects Dolly Parton to know how to plug in a microphone. There’s an incredible infrastructure of managers, musicians, recording technicians, record companies, roadies, hairdressers, and publicists behind her who exist to create the abstraction that when she sings, that’s all it takes for millions of people to hear her song. All the support staff and management that make Dolly Parton possible can do their jobs best by providing the most perfect abstraction: the most perfect illusion that Dolly sings for us. It is her song. When you’re listening to her on your iPod, there’s a huge infrastructure that makes that possible, but the very best thing that infrastructure can do is disappear completely. Provide a leakproof abstraction that Dolly Parton is singing, privately, to us.

Micro-ISV: From Vision to Reality

Micro-ISV: From Vision to RealityThis is my foreword to Bob Walsh’s new book, Micro-ISV: From Vision to Reality.

How the heck did I become the poster child for the MicroISV movement?

Of all people. Sheesh.

When I started Fog Creek Software there was gonna be nothing “micro” about it. The plan was to build a big, multinational software company with offices in 120 countries and a skyscraper headquarters in Manhattan, complete with a heliport on the roof for quick access to the Hamptons. It might take a few decades–after all, we were going to be bootstrapped and we always planned to grow slowly and carefully–but our ambitions were anything but small.

Heck, I don’t even like the term MicroISV. The “ISV” part stands for Independent Software Vendor. It’s a made-up word, made up by Microsoft, to mean “software company that is not Microsoft,” or, more specifically, “software company that for some reason we have not yet bought or eliminated, probably because they are in some charming, twee line of business, like wedding table arrangements, the quaintness of which we are just way too cool to stoop down to, but you little people feel free to enjoy yourselves. Just remember to use .NET!”

It’s like that other term, legacy, that Microsoft uses to refer to all non-Microsoft software. So when they refer to Google, say, as a “legacy search engine” they are trying to imply that Google is merely “an old, crappy search engine that you’re still using by historical accident, until you bow to the inevitable and switch to MSN.” Whatever.

I prefer “software company,” and there’s nothing wrong with being a startup. Startup software company, that’s how we describe ourselves, and we don’t see any need to define ourselves in relation to Microsoft.

I suppose you’re reading this book because you want to start a small software company, and it’s a good book to read for that purpose, so let me use my pulpit here to provide you with my personal checklist of three things you should have before you start your Micro… ahem, startup software company. There are some other things you should do; Bob covers them pretty well in the rest of the book, but before you get started, here’s my contribution.

Number One. Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain. The other day I went to a presentation of six high tech startups and not one of them had a clear idea for what pain they were proposing to solve. I saw a startup that was building a way to set a time to meet your friends for coffee, a startup that wanted you to install a plug-in in your browser to track your every movement online in exchange for being able to delete things from that history, and a startup that wanted you to be able to leave text messages for your friend that were tied to a particular location (so if they ever walked past the same bar they could get a message you had left for them there). What they all had in common was that none of them solved a problem, and all of them were as doomed as a long-tailed cat in a room full of rocking chairs.

Number Two. Don’t start a business by yourself. I know, there are lots of successful one-person startups, but there are even more failed one-person startups. If you can’t even convince one friend that your idea has merit, um, maybe it doesn’t? Besides, it’s lonely and depressing and you won’t have anyone to bounce ideas off of. And when the going gets tough, which it will, as a one-person operation, you’ll just fold up shop. With two people, you’ll feel an obligation to your partner to push on through. P.S., cats do not count.

Number Three. Don’t expect much at first. People never know how much money they’re going to make in the first month when their product goes on sale. I remember five years ago, when we started selling FogBugz, we had no idea if the first month of sales would be $0 or $50,000. Both figures seemed just as likely to me. I have talked to enough entrepreneurs and have enough data now to give you a definitive answer for your startup.

That’s right, I have a crystal ball, and can now tell you the one fact that you need to know more than anything else: exactly how much money you’re going to make during the first month after your product goes live.



In the first month, you are going to make,


$364, if you do everything right. If you charge too little, you’re going to make $40. If you charge too much, you’re going to make $0. If you expect to make any more than that, you’re going to be really disappointed and you’re going to give up and get a job working for The Man and referring to us people in startup-land as “Legacy MicroISVs.”

That $364 sounds depressing, but it’s not, because you’ll soon discover the one fatal flaw that’s keeping 50% of your potential customers from whipping out their wallets, and then *tada!* you’ll be making $728 a month. And then you’ll work really hard and you’ll get some publicity and you’ll figure out how to use AdWords effectively and there will be a story about your company in the local wedding planner newsletter and tada! You’ll be making $1456 a month. And you’ll ship version 2.0, with spam filtering and a Common Lisp interpreter built in, and your customers will chat amongst themselves, and tada! You’ll be making $2912 a month. And you’ll tweak the pricing, add support contracts, ship version 3.0, and get mentioned by Jon Stewart on The Daily Show and tada! $5824 a month.

Now we’re cooking with fire. Project out a few years, and if you plug away at it, there’s no reason you can’t double your revenues every 12-18 months, so no matter how small you start, (detailed math formula omitted – Ed.), you’ll soon be building your own skyscraper in Manhattan with a heliport so you can get to that 20 acre Southampton spread in 30 minutes flat.

And that, I think, is the real joy of starting a company: creating something, all by yourself, and nurturing it and working on it and investing in it and watching it grow, and watching the investments pay off. It’s a hell of a journey, and I wouldn’t miss it for the world.

The Perils of JavaSchools

Lazy kids.

Whatever happened to hard work?

A sure sign of my descent into senility is bitchin’ and moanin’ about “kids these days,” and how they won’t or can’t do anything hard any more.

“You were lucky. We lived for three months in a brown paper bag in a septic tank. We had to get up at six in the morning, clean the bag, eat a crust of stale bread, go to work down the mill, fourteen hours a day, week-in week-out, and when we got home our Dad would thrash us to sleep with his belt.” — Monty Python’s Flying Circus, Four Yorkshiremen

When I was a kid, I learned to program on punched cards. If you made a mistake, you didn’t have any of these modern features like a backspace key to correct it. You threw away the card and started over.

When I started interviewing programmers in 1991, I would generally let them use any language they wanted to solve the coding problems I gave them. 99% of the time, they chose C.

Nowadays, they tend to choose Java.

Now, don’t get me wrong: there’s nothing wrong with Java as an implementation language.

Wait a minute, I want to modify that statement. I’m not claiming, in this particular article, that there’s anything wrong with Java as an implementation language. There are lots of things wrong with it but those will have to wait for a different article.

Instead what I’d like to claim is that Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers. It may be a fine language to work in, but that’s not today’s topic. I would even go so far as to say that the fact that Java is not hard enough is a feature, not a bug, but it does have this one problem.

If I may be so brash, it has been my humble experience that there are two things traditionally taught in universities as a part of a computer science curriculum which many people just never really fully comprehend: pointers and recursion.

You used to start out in college with a course in data structures, with linked lists and hash tables and whatnot, with extensive use of pointers. Those courses were often used as weedout courses: they were so hard that anyone that couldn’t handle the mental challenge of a CS degree would give up, which was a good thing, because if you thought pointers are hard, wait until you try to prove things about fixed point theory.

All the kids who did great in high school writing pong games in BASIC for their Apple II would get to college, take CompSci 101, a data structures course, and when they hit the pointers business their brains would just totally explode, and the next thing you knew, they were majoring in Political Science because law school seemed like a better idea. I’ve seen all kinds of figures for drop-out rates in CS and they’re usually between 40% and 70%. The universities tend to see this as a waste; I think it’s just a necessary culling of the people who aren’t going to be happy or successful in programming careers.

The other hard course for many young CS students was the course where you learned functional programming, including recursive programming. MIT set the bar very high for these courses, creating a required course (6.001) and a textbook (Abelson & Sussman’s Structure and Interpretation of Computer Programs) which were used at dozens or even hundreds of top CS schools as the de facto introduction to computer science. (You can, and should, watch an older version of the lectures online.)

The difficulty of these courses is astonishing. In the first lecture you’ve learned pretty much all of Scheme, and you’re already being introduced to a fixed-point function that takes another function as its input. When I struggled through such a course, CSE121 at Penn, I watched as many if not most of the students just didn’t make it. The material was too hard. I wrote a long sob email to the professor saying It Just Wasn’t Fair. Somebody at Penn must have listened to me (or one of the other complainers), because that course is now taught in Java.

I wish they hadn’t listened.

Think you have what it takes? Test Yourself Here!

Therein lies the debate. Years of whinging by lazy CS undergrads like me, combined with complaints from industry about how few CS majors are graduating from American universities, have taken a toll, and in the last decade a large number of otherwise perfectly good schools have gone 100% Java. It’s hip, the recruiters who use “grep” to evaluate resumes seem to like it, and, best of all, there’s nothing hard enough about Java to really weed out the programmers without the part of the brain that does pointers or recursion, so the drop-out rates are lower, and the computer science departments have more students, and bigger budgets, and all is well.

The lucky kids of JavaSchools are never going to get weird segfaults trying to implement pointer-based hash tables. They’re never going to go stark, raving mad trying to pack things into bits. They’ll never have to get their head around how, in a purely functional program, the value of a variable never changes, and yet, it changes all the time! A paradox!

They don’t need that part of the brain to get a 4.0 in major.

Am I just one of those old-fashioned curmudgeons, like the Four Yorkshiremen, bragging about how tough I was to survive all that hard stuff?

Heck, in 1900, Latin and Greek were required subjects in college, not because they served any purpose, but because they were sort of considered an obvious requirement for educated people. In some sense my argument is no different that the argument made by the pro-Latin people (all four of them). “[Latin] trains your mind. Trains your memory. Unraveling a Latin sentence is an excellent exercise in thought, a real intellectual puzzle, and a good introduction to logical thinking,” writes Scott Barker. But I can’t find a single university that requires Latin any more. Are pointers and recursion the Latin and Greek of Computer Science?

Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it’s downright dangerous in production code. OK. That’s fine. And functional programming is just not used much in practice. Agreed.

But it’s still important for some of the most exciting programming jobs. Without pointers, for example, you’d never be able to work on the Linux kernel. You can’t understand a line of code in Linux, or, indeed, any operating system, without really understanding pointers.

Without understanding functional programming, you can’t invent MapReduce, the algorithm that makes Google so massively scalable. The terms Map and Reduce come from Lisp and functional programming. MapReduce is, in retrospect, obvious to anyone who remembers from their 6.001-equivalent programming class that purely functional programs have no side effects and are thus trivially parallelizable. The very fact that Google invented MapReduce, and Microsoft didn’t, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world’s largest massively parallel supercomputer. I don’t think Microsoft completely understands just how far behind they are on that wave.

But beyond the prima-facie importance of pointers and recursion, their real value is that building big systems requires the kind of mental flexibility you get from learning about them, and the mental aptitude you need to avoid being weeded out of the courses in which they are taught. Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer.

Nothing about an all-Java CS degree really weeds out the students who lack the mental agility to deal with these concepts. As an employer, I’ve seen that the 100% Java schools have started churning out quite a few CS graduates who are simply not smart enough to work as programmers on anything more sophisticated than Yet Another Java Accounting Application, although they did manage to squeak through the newly-dumbed-down coursework. These students would never survive 6.001 at MIT, or CS 323 at Yale, and frankly, that is one reason why, as an employer, a CS degree from MIT or Yale carries more weight than a CS degree from Duke, which recently went All-Java, or U. Penn, which replaced Scheme and ML with Java in trying to teach the class that nearly killed me and my friends, CSE121. Not that I don’t want to hire smart kids from Duke and Penn — I do — it’s just a lot harder for me to figure out who they are. I used to be able to tell the smart kids because they could rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as they could write on the whiteboard. But with a JavaSchool Grad, I can’t tell if they’re struggling with these problems because they are undereducated or if they’re struggling with these problems because they don’t actually have that special part of the brain that they’re going to need to do great programming work. Paul Graham calls them Blub Programmers.

It’s bad enough that JavaSchools fail to weed out the kids who are never going to be great programmers, which the schools could justifiably say is not their problem. Industry, or, at least, the recruiters-who-use-grep, are surely clamoring for Java to be taught.

But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design (and I don’t mean OO “design”, where you spend countless hours rewriting your code to rejiggle your object hierarchy, or you fret about faux “problems” like has-a vs. is-a). You need training to think of things at multiple levels of abstraction simultaneously, and that kind of thinking is exactly what you need to design great software architecture.

You may be wondering if teaching object oriented programming (OOP) is a good weed-out substitute for pointers and recursion. The quick answer: no. Without debating OOP on the merits, it is just not hard enough to weed out mediocre programmers. OOP in school consists mostly of memorizing a bunch of vocabulary terms like “encapsulation” and “inheritance” and taking multiple-choice quizzicles on the difference between polymorphism and overloading. Not much harder than memorizing famous dates and names in a history class, OOP poses inadequate mental challenges to scare away first-year students. When you struggle with an OOP problem, your program still works, it’s just sort of hard to maintain. Allegedly. But when you struggle with pointers, your program produces the line Segmentation Fault and you have no idea what’s going on, until you stop and take a deep breath and really try to force your mind to work at two different levels of abstraction simultaneously.

The recruiters-who-use-grep, by the way, are ridiculed here, and for good reason. I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.

But what about the CS mission of CS departments? They’re not vocational schools! It shouldn’t be their job to train people to work in industry. That’s for community colleges and government retraining programs for displaced workers, they will tell you. They’re supposed to be giving students the fundamental tools to live their lives, not preparing them for their first weeks on the job. Right?

Card Punch -- yes, I learned Fortran on one of these when I was 12.Still. CS is proofs (recursion), algorithms (recursion), languages (lambda calculus), operating systems (pointers), compilers (lambda calculus) — and so the bottom line is that a JavaSchool that won’t teach C and won’t teach Scheme is not really teaching computer science, either. As useless as the concept of function currying may be to the real world, it’s obviously a prereq for CS grad school. I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs. Oh wait. Never mind. Maybe I do understand.

Actually if you go back and research the discussion that took place in academia during the Great Java Shift, you’ll notice that the biggest concern was whether Java was simple enough to use as a teaching language.

My God, I thought, they’re trying to dumb down the curriculum even further! Why not spoon feed everything to the students? Let’s have the TAs take their tests for them, too, then nobody will switch to American Studies. How is anyone supposed to learn anything if the curriculum has been carefully designed to make everything easier than it already is? There seems to be a task force underway (PDF) to figure out a simple subset of Java that can be taught to students, producing simplified documentation that carefully hides all that EJB/J2EE crap from their tender minds, so they don’t have to worry their little heads with any classes that you don’t need to do the ever-easier CS problem sets.

The most sympathetic interpretation of why CS departments are so enthusiastic to dumb down their classes is that it leaves them more time to teach actual CS concepts, if they don’t need to spend two whole lectures unconfusing students about the difference between, say, a Java int and an Integer. Well, if that’s the case, 6.001 has the perfect answer for you: Scheme, a teaching language so simple that the entire language can be taught to bright students in about ten minutes; then you can spend the rest of the semester on fixed points.


I’m going back to ones and zeros.

(You had ones? Lucky bastard! All we got were zeros.)

Are you a Junior in college who can rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as you can write on the whiteboard? Check out our summer internships in New York City! Applications are due February 1st.

Reading List: Fog Creek Software Management Training Program

The management training program we’re starting up here at Fog Creek will take about three years and will be relatively intensive. Among other things, there will be a required reading list consisting of about 75 books (we’re working on the theory here of one book every two weeks). We’re trying to collect a combination of

  • the best business books of all time
  • the best software management books of all time
  • and every worthwhile history of a software/computer company that we can find.

This is my very first-draft list. By the time we get started a lot of these books will be replaced with better books, I hope; if you have any suggestions please feel free to email them to me. I haven’t attempted to sort them or rank them yet; the order is completely arbitrary.

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition Don't Make Me Think: A Common Sense Approach to Web Usability Growing a Business Dec Is Dead, Long Live Dec: The Lasting Legacy of Digital Equipment Corporation Applied Cryptography: Protocols, Algorithms, and Source Code in C Philip and Alex's Guide to Web Publishing Testing Computer Software Design for Community: The Art of Connecting Real People in Virtual Places Version Control with Subversion The Non-Designer's Design Book The Pragmatic Programmer: From Journeyman to Master Measuring and Managing Performance in Organizations Facts and Fallacies of Software Engineering The Autodesk File: Bits of History, Words of Experience Hackers and Painters: Big Ideas from the Computer Age Competing On Internet Time: Lessons From Netscape And Its Battle With Microsoft The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity The Design of Everyday Things The Difference Between God and Larry Ellison: *God Doesn't Think He's Larry Ellison Breaking Windows: How Bill Gates Fumbled the Future of Microsoft Just for Fun: The Story of an Accidental Revolutionary On a Roll: From Hot Dog Buns to High-Tech Billions First $20 Million Is Always the Hardest:, The: A Silicon Valley Novel Random Excess Show Stopper! The Breakneck Race To Create Windows NT And The Next Generation at Microsoft The Leap: A Memoir of Love and Madness in the Internet Gold Rush Digital Hustlers: Living Large and Falling Hard in Silicon Alley In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters Startup: A Silicon Valley Adventure Peopleware: Productive Projects and Teams The Macintosh Way Microsoft Rebooted: How Bill Gates and Steve Ballmer Reinvented Their Company Speeding the Net: This Inside Story of Netscape and How It Challenged Microsoft How Steve Case Beat Bill Gates, Nailed the Nethead, and Made Millions in the War for the Web dot.bomb: My Days and Nights at an Internet Goliath The New New Thing: A Silicon Valley Story Burn Rate: How I Survived the Gold Rush Years on the Internet Accidental Empires Revolution in The Valley The Anatomy of Buzz: How to Create Word of Mouth Marketing Death March Secrets of Consulting: A Guide to Giving and Getting Advice Successfully Rules For Revolutionaries: The Capitalist Manifesto for Creating and Marketing New Products and Services Positioning: The Battle for Your Mind The Manager Pool: Patterns for Radical Leadership Ben & Jerry's: The Inside Scoop : How Two Real Guys Built a Business with a Social Conscience and a Sense of Humor The 22 Immutable Laws of Marketing : Exposed and Explained by the World's Two The Goal Critical Chain Microserfs The Product Marketing Handbook for Software Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency The Art of the Start: The Time-Tested, Battle-Hardened Guide for Anyone Starting Anything The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad A Random Walk Down Wall Street 21 Dog Years: A Cube Dweller's Tale Inside Intuit: How the Makers of Quicken Beat Microsoft and Revolutionized an Entire Industry Direct from Dell: Strategies that Revolutionized an Industry Making the Technical Sale Selling Air Crossing the Chasm Four Days with Dr. Deming: A Strategy for Modern Methods of Management Amazonia The PayPal Wars; Battles with eBay, the Media, the Mafia, and the Rest of Planet Earth The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture The Tipping Point: How Little Things Can Make a Big Difference The Fall of Advertising and the Rise of PR High St@kes, No Prisoners The E-Myth Revisited The One Minute Manager Getting to Yes Essentials of Accounting Influence Geeks: How Two Lost Boys Rode the Internet Out of Idaho The Portable MBA The Little Red Book of Selling How to Win Friends and Influence People