[A picture of private offices at Fog Creek Software]

Joel on Software

A Field Guide to Developers

by Joel Spolsky
Thursday, September 07, 2006

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

Hmm.

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

Toys

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 Amazon.com 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.


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Next:

Sorting Resumes



Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Trello and Fog Creek Software, and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky