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

Company Name = Quality Jobs

Wow, I have never seen such developers all over the world so unanimous on any issue. If anything, I underestimated how much people hate job boards clogged with anonymous posts put up by commission- and resume-fishing recruiters.

The jobs board policy will remain: We will continue to require a company name and take down posts that don’t disclose the actual company.

Recruiters can use it if they post the name of the company that is actually hiring. This, I think, will only be of interest to recruiters doing exclusive searches (also known as “retained searches”).

Finally, summer intern Noah has added a feature to display the Joel Test score on the main page for companies that choose to fill it out, which seems to be quite a lot of them. Thanks, summer intern Noah!

Commissioned Headhunters on the Job Board: Good or Bad?

It was only a matter of time before the new job board got its first policy violation: a recruiter posting a job without disclosing the name of the company that it was for.

The reason we require a company name, as opposed to a recruiter’s name, is because I think that job seekers are sick of looking at generic lists of seemingly anonymous companies. The reason recruiters don’t like to post company names is because they don’t get a commission unless they refer the employee, so they don’t want to take any risk that the candidate will go directly to the company and cut them out of their commission. Also, once the recruiter establishes a relationship with you, they can convince you to apply to all their other jobs, further increasing the chance that they’ll get a commission. And they want to build up their resume-files so they can do their job well in the future.

There’s a place for recruiters; many of them are very ethical and do great work for their clients on both sides. However, I think there’s also a place for a more open market where people can look directly at jobs, then jump to the company’s website and decide if that’s the kind of company they might want to work for. As I wrote earlier, top developers have a choice of where to work, and they’re not very enchanted with the prospects of working for a “leading developer of software products” that needs a “C/C++/XML/HTTP/HTML” to fill a slot.

This is something of a dilemma. I’m pretty sure that job seekers have no interest in a seeing list of pseudo-jobs that are often nothing more than invitations to call a headhunter. On the other hand, headhunters are probably the biggest single spenders on job boards, so I might be antagonizing my biggest potential audience of paying customers.

What should I do?

Field Guide to Developers

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

— from today’s installment in the Guerrilla Guide to Hiring: the Field Guide to Developers.

Introducing jobs.joelonsoftware.com

August is the month where everything screeches to a halt. So many people are away on vacation that the people who are left behind can never get ahold of the people they need to do their own work.

But, alas, August is over. Labor Day weekend, which just ended, marks the traditional end of summer vacation on the American calendar. So today, I’m opening a new section on Joel on Software, a jobs listing page creatively named jobs.joelonsoftware.com.

The idea of a niche job board was not my own, and it has taken me a while to figure out why this is a better idea than those huge job boards bringing millions of companies together with millions of job seekers. A niche job board has modest goals, no grander than to bring a dozen or so companies that are great places to work together with a dozen or so great programmers.

The traditional way of applying for a job, sending a cover letter and a resume, just does not give the employer enough useful information to separate the “maybes” from the “maybe nots.” Many employers despair of placing a job listing on Monster or Yahoo! HotJobs or Craigslist and getting the inevitable flood of undifferentiated resumes.

For the job seeker, the problem is the same: when they look on giant job boards they see a bunch of undifferentiated jobs, often posted by clueless headhunters that provide all kinds of information you don’t need (“A leading provider of whatever”) and none of the information you do need (what’s the name of the company? Do they make nuclear bombs? Will they give me a private office and a big monitor? Free M&Ms? Are they sloppy hacks or quality hackers? Can I use Ruby on Rails?)

So it seems to me that both the employers and the job seekers would be better served by a quiet, more exclusive club with a few select listings that tell you the actual name of the company you’d be working for, and, if you’re lucky, how they did on the Joel Test, combined with a community of the best software developers on earth, that being you.

And, yes, it’s not for everybody, and no, you won’t see ads on the sides of buses for jobs.joelonsoftware.com, but you will find great jobs and great programmers there.

That’s the theory at least. There are a lot of these niche job boards showing up. 37signals has one with an emphasis on web design jobs. CrunchBoard is all about Web 2.0 jobs. There’s even a company called JobThread that offers tools to set up your own niche job board, which Salon and others are rolling out. Do we need a scrillion tiny job boards? I’m not sure, but I do agree with JobThread’s Eric Yoon that “while the big three job boards have 70% of the $2 billion online recruitment ad market, recruiters and companies have been fairly unhappy with their job posting experience.”

Jason Fried over at 37signals has been evangelizing the idea. “Big sites take a shotgun approach. You post a job. Anyone can see it. There’s no targeting, no like-mindedness. Our feeling is, if you want to hire the right people, you have to go where the right people hang out.”

Credit also goes to Fog Creek summer intern Noah Weiss, who just would not shut up about job boards this and job boards that until we agreed to try it out. And to all my friends through the years who regularly pestered me to help them find great software developers for them among the regular readers of Joel on Software.

Now, for some details. In order to keep the quality of the listings high this is not going to be a free job listing board. Listings cost $350. That only gets you three weeks; my theory is that nobody wants to apply for stale jobs, anyway. Unlike every other job board I know of, I’ve decided to keep Fog Creek’s usual 90 days, no-questions-asked money-back guarantee. If you don’t find anyone, you can have your money back. If you find someone but they quit to join the Bolshoi you can have your money back. If you get a bunch of lousy resumes, you can have your money back. If you hire someone and they turn out to be really, really attached to their cat who comes to work with them and makes Lizza in Accounts Payable sneeze so hard that she goes to an allergist driving up your health insurance premiums, well, you should have asked them about cats in the interview, but, yeah, you can have your money back.

If you’re a legit charity or educational institution, contact the kind customer service people (yes, there’s customer service, with a toll-free phone number) and they’ll work something out.

Now, about the rule we made that you have to post the company name. A lot of recruiters are working on a contingency basis. They don’t get paid unless they fill an opening. These recruiters generally don’t want to post a company name, because then applicants could go straight to the employer and the recruiter would be cut out of their commission. That’s why you see so many job ads in traditional places like classifieds that are totally vague about the specific company where you’d be working.

That, unfortunately, is not going to work for us. Every good software developer I know has a choice of where to work. They don’t want to work for a “TOP INVESTMENT BANK”. Some investment banks are really nice places to work. Others are sweatshops. Some are ethical. Many are ethically challenged. Some require suits. Others are business casual. That’s why we want to know the name of the company that’s hiring, and unfortunately that means that recruiters who don’t want to reveal the company name are really barking up the wrong tree. Try Craigslist, shugah.

Starting today, there are going to be small text links to the job board showing up in various places on the site. I’m going to experiment with showing one random job listing on the home page of Joel on Software, and links will be included in the discussion board, the RSS feed, and the email list. Also, there will be a gigantic flashing dancing hamster that appears on the home page singing the flashing hamster song and holding up a sign proclaiming the job board, and you have to find his little hat and click on it before you can go on.

Just kidding about the hamster.

Right now, as you can see, the software behind jobs.joelonsoftware.com is quite rudimentary. Yes indeedy what you’re seeing here is AGILE DEVELOPMENT IN THE WILD! Noah and I designed and coded the whole site over the course of three weeks, which included two weeks of vacation–each. There’s no searching or sorting feature. There’s no easy way to post several jobs at once. I want to see how it goes yet, see if we get any interest, and mostly see if the revenues generated by this thing would support a programmer to make it better.


I think some people thought I was joking earlier today when I said that we have our own compiler, Wasabi, for FogBugz.

Yes, Wasabi is real. Because FogBugz is sold to customers who run it on their own servers, it has to run on hundreds of thousands of web servers “in the wild,” unlike most web apps where the programmer completely controls the deployment environment. We have to ship code that runs out-of-the-box, which means lowest common denominator.

This is kind of unusual. Most web developers are either building things for one customer, or they’re building web apps that they will host themselves. That’s a nice position to be in. But most FogBugz customers don’t want their proprietary project data on someone else’s servers, so we have to sell them the source code to install on their own server.

In most deployed servers today, the lowest common denominators are VBScript (on Windows), PHP4, and PHP5 (on Unix). If we try to require anything fancier on the server, we increase our tech support costs dramatically. Even though PHP is available for Windows, it’s not preinstalled, and I don’t want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I’d have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn’t quite ubiquitous on Windows servers.

Since we don’t want to program in VBScript or PHP4 or even PHP5 and we certainly don’t want to have to port everything to three target platforms, the best solution for us is a custom language that compiles to our target platforms.

Since we are not blub programmers, we like closures, active records, lambdas, embedded SQL a la LINQ, etc. etc. and so those are the kinds of features we put into Wasabi.

And since FogBugz goes back many years and was originally written in VBScript, Wasabi is 100% backwards-compatible with VBScript but includes obvious improvements. “””Multiline strings.””” Dim a = 0. And so on.

Most people don’t realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn’t have to be a general-purpose compiler. It doesn’t have a math library, for example.

And we have the ability to add any feature to the language that we want easily… this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros.

It’s very easy to add a new back-end to Wasabi. Our plan is that when .NET gets a little bit more predominant on our clients’ Windows servers, we’ll add a CLR back-end and generate bytecode or something which will run a lot faster.

Another neat thing is that when you want to do something on the client (the web browser) you can write the code once, in Wasabi, and compile it to JavaScript for the browser and get identically functioning VBScript or PHP code for the server. So for example if you want to do some kind of Ajax-like “preview” feature where a button on the web browser renders some complicated HTML without going back to the server, but you also need the server to be able to render the same complicated HTML in the first place, you don’t have to write the rendering code twice in two different languages.

That said, there are major drawbacks. The documentation is a little bit thin and disorganized, because we’ve only documented the diffs to VBScript, not the whole language. Programmers that join Fog Creek might take a little bit longer getting up to speed. Our edit-compile-test loop got slower because there’s one more step.

Should you write your own compiler? Maybe, if you’re doing something that’s different enough from the mainstream and if there’s no good off-the-shelf technology for your problem. There’s a good chance that the domain you’re working in could really use a domain-specific language. If you want to write a program for filling out tax forms, for example, you probably want to create a language optimized for describing forms with calculated fields, and then all you have to do is encode each tax form in your custom language. If you want to write a program for playing a 3D game, you’ll want to create a language optimized for describing maps and levels and then design each level in that language. If there’s something off the shelf you can use, by all means, use it, as long as you’re not going to get yourself in trouble down the line when you discover that that the off-the-shelf tool doesn’t work and you can’t modify it.

Language Wars

An old friend emailed me to ask:

“I wanted to get your response to some basic questions concerning technologies available for creating an enterprise level application that is built upon a Web Server, Web based applications, and a large distribution model and collection model. The project is starting from scratch and so there is no legacy code involved but other than that I won’t bore you with the details…

“Would you head down the .NET route or J2EE?

“Which Web Server (Apache, IIS, or something else) should we use and why?

“Which Web development language (ASP.NET, Ruby, Ruby on Rails, Java, Python, etc.) would you recommend and why?

“What do you use at your company and why?”

Ah, an excellent question, simultaneously impossible to answer and very easy to answer!

Sorry, I should stop speaking in riddles. A while ago I wrote an article called Lord Palmerston on Programming in which I claimed that some of these programming worlds, like .NET and Java, were so huge and complicated that you never could really tell if they were going to be good enough for your needs until it was too late. In particular, a debate between the C#/.NET/IIS stack and the Java/J2EE/Apache/Solaris stack and the PHP/Apache/Linux stack could go on and on for years and years and you’d never find the right answer. That’s because there are so many pros and cons of all these platforms that advocates of each side can debate and debate and never get any closer to the Truth, but it sure as heck is a fun debate.

You might think that if you could find someone with extensive experience in multiple platforms, they would be the right person to ask. I haven’t found a lot of people like that. What I do know for sure, though, is two things:

  1. People all over the world are constantly building web applications using .NET, using Java, and using PHP all the time. None of them are failing because of the choice of technology.
  2. All of these environments are large and complex and you really need at least one architect with serious experience developing for the one you choose, because otherwise you’ll do things wrong and wind up with messy code that needs to be restructured.

Last summer when we had a group of interns build Copilot, we had to decide what language to use for new code. I know that typically on new projects there’s a long evaluation period where you decide what technology to use, along with lots of debates that include some crazy person actually wasting quite a lot of time evaluating Squeak and Lisp and OCaml and lots of other languages which are totally, truly brilliant programming languages worthy of great praise, but just don’t have the gigantic ecosystem you need around them if you want to develop web software. These debates are enormously fun and a total and utter waste of time, because the bottom line is that there are three and a half platforms (C#, Java, PHP, and a half Python) that are all equally likely to make you successful, an infinity of platforms where you’re pretty much guaranteed to fail spectacularly when it’s too late to change anything (Lisp, ISAPI DLLs written in C, Perl), and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I’m sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I’m sure you’ll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I’m really not sure that you won’t hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot. So while Ruby on Rails is the fun answer and yes I’ve heard of 37 Signals and they’re making lovely Ruby on Rails apps, and making lots of money, but that’s not a safe choice for at least another year or six. I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it’s known to be slow, so if you become The Next MySpace, you’ll be buying 5 times as many boxes as the .NET guy down the hall. Those things might eventually get fixed but for now, you can risk Ruby on your two-person dormroom startup or your senior project, not for enterprisy stuff where Someone is Going to Get Fired. Python get a half because it’s on the border, about to cross the line from an “interesting” choice to a “safe” choice.

Oh and I know Paul told you that he made his app in Lisp and then he made millions of dollars because he made his app in Lisp, but honestly only two people ever believed him and, a complete rewrite later, they won’t make that mistake again.

The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there’s so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they’re not life-threatening problems.

How do you decide between C#, Java, PHP, and Python? The only real difference is which one you know better. If you have a serious Java guru on your team who has build several large systems successfully with Java, you’re going to be a hell of a lot more successful with Java than with C#, not because Java is a better language (it’s not, but the differences are too minor to matter) but because he knows it better. Etc.

What we ended up doing with the interns was just telling them that they had to build it in C# and ASP.NET. In particular, one intern, who wrote the website part of Copilot, had enough experience with ASP.NET to know what things to avoid (like viewstate) and knew to avoid the gotchas that make it impossible to have two <forms> in one page, etc. etc., so he did a beautiful job architecting the ASP.NET code exactly the right way to begin with so we didn’t get into trouble later. And the benefit was that not one minute was spent debating the merits of programming languages, a fruitless debate if I’ve ever seen one.

Finally — as to what we use — Copilot is C# and ASP.Net, as I mentioned, although the Windows client is written in C++. Our older in-house code is VBScript and our newer in-house code is C#. FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.