How to treat Great Developers

The Best Equipment Money can Buy
Leave Your Developers Alone
Be Honest with your Developers
Let Them Grow
Take Some Good Advice
Respect and Cherish Your Developers

So you want to hire a great hacker. That’s great! What should you do? Great hackers, are not too concerned with getting an exceptional salary. They probably won’t work for free, but they will often prefer a better job with a smaller pay than an abusive job with a higher pay. But what do they like?

Great Developers like to work on stable, well-proven platforms that are preferably open-source. In today’s world it means either C or C++ using gcc and g++; Perl, Python, Ruby and to a lesser extent PHP; Java and possibly also .NET on Windows 2003 or the open-source and cross-platform Mono. If your platform doesn’t work, has bugs that delving into the source won’t reveal (if the source can be read at all) - they’re not going to be happy.

At a workplace I worked for a few days, I was given a task to automate a buggy Hebrew windows application written using PowerBuilder, which was incredibly quirky. It took me three or four days to write less than a hundred lines of Perl code. I was never so unproductive. After answering the wrong question in an interrogation, I was fired, and was heavily relieved. Such applications should not be tested - they should be rewritten using a more modern and less quirky technology.

Another thing great developers hate is to forced to be consumed by their work. In Israel, some workplaces require at least 9 hours of daily work. How can you work like that, and still work on open-source projects, have a girlfriend or a boyfriend, go to the meetings of social or technical clubs, hang with your friends in coffee shops, restaurants, or pubs, and other activities like that. All of these things are not strictly part of work, but they are what make great developers productive. That’s because coding happens in your mind, not in your editor or IDE, and because the more inspired a developer is, the more happier he is, the better code he writes, and the better ideas he has. A programmer who just works all week, without leisure time is heavily underproductive.

Here’s another thing: in Israel the law mandates at least 12 paid vacation days per year. At my previous workplace, I received 14 paid vacation days? Thank you, Workplace!!

But guess what? Fog Creek software, best known as the company co-owned by Joel Spolsky from the “Joel on Software” site gives people 6 weeks of paid vacation annually. And they’re doing very fine, and people there are super-happy and productive. So, why should I work for you if all I get are 14 stupid days? Get real!

The Best Equipment Money can Buy

The Joel Test specifically says that you should give your developers the best tools and equipment money can buy - from hardware to software, to office conditions, to food, to location, to everything else. Many workplaces don’t understand that.

In a previous workplace of mine, I was given a recycled computer - it was still fast but its hard-disk was only 40 GB. It was a pain to get some Windows XP virtual machines running there. Another computer we developed on still had a 40 GB hard disk too. We ran out of space there because we had a huge checkout of the Subversion version control system there. And the only hard-disks that our lab had were whopping 80 GB ones, bought because they were the cheapest ones, which probably wouldn’t have been sufficient for too long, either.

The most amazing thing was that the computer’s sole CD drive, was just a CD drive - no CD writing, no DVD reading or writing - a CD drive. It gave me a lot of grief. I had to copy a few DVDs I burned at home on my supervisor’s computer, and copy them over the network, and could not install a Linux distribution from its installation DVD even if I wanted to.

Some people can still happily use old hardware or play with relatively buggy software. But good developers should not be concerned with this. They want a hardware with enough space, RAM, and processing power. They want a screen that they can easily move around (a flat-panel LCD screen). They want good food in the kitchen. They want talkative, interesting and benevolent people to talk with. They want a spacious office. They want Internet connectivity so they can surf the web and search for answers, chat with their friends, ask people on the IRC for help, and contact some people who know more about the software they are using than they do.

Leave Your Developers Alone

At a previous workplace of mine, my bosses did not like the fact that I sometimes played card solitaire games or Sokoban. I’m not much of a gamer and don’t spend hours on end playing high-end games. But they didn’t like that people who passed by saw me not working at that very moment.

I needed these games to bring my mind back into cycle. I was also labelled as a “strange bird”, because I often stood and looked at our building’s garden and lawn through the window. As Paul Graham notes there’s a large difference between “pretend work” and “real work”. Playing games and looking through the window do not make you less productive. If you’re just writing code for the same codebase all the time, your mind will soon run in circles, and you won’t be productive.

In a mission statement to an innovative software company, I said that I expected developers to work for only 20% of the time? Why? They:

  1. Usually won’t work more anyhow.

  2. Since so little is expected of them, they will feel willing to work more than that. (Assuming they are indeed great developers with a wonderful character).

  3. The things they’ll do in the rest of the time will inspire them and allow them to be more productive.

Another issue are the working hours. Make sure your developers can normally come to the office when they want and go when they want. If you sometimes need more time or better attendance, then great developers will be happy to comply - temporarily. But crunch mode is a recipe for disaster - your developers will be over-worked, under-productive, and unhappy. And if they’re smart, they will soon quit.

And here’s another anecdote: at a previous workplace, I was instructed to fulfil my hours quota at least precisely, so they can get enough benefits from the Israeli Chief Scientist. But what is more beneficial for them: a happy, productive developer who does very good work, or a few extra shekels? I can never understand this skewed logic.

Be Honest with your Developers

The first thing about being honest with your developers is telling them exactly why they weren’t hired if this was indeed the case. Most companies I’ve been to, either rejected me after an otherwise seemingly successful interview, or even sent me an uninformative rejection letter before any interview. This will cause the exceptional developer to wonder what has he done wrong, or what’s wrong with him.

As an employer, you should have the minimal decency to inform the star developers what they did wrong and how to further improve. Otherwise, you’re not being fair with them, and they also may tell all their friends how pointless it was to try to apply for you. (Or tell their friends how good a different company that’s also looking for great hackers treated them.)

Honesty is also telling your developers when they did something right, like finding bugs, fixing bugs, having good ideas, implementing something on schedule, handling a situation properly, etc. and when they did not do something properly. Even the greatest developers make mistakes, but you should be honest enough to evaluate their total performance so far and not just their isolated mistake. A great developer who’s worked for you for a few months, made a mistake recently learned from it, and is determined not to repeat it, is a better asset than a new developer who still has a lot to learn at the company.

Obviously, honesty goes in both ways. Great developers should be honest enough to tell their future employers, present employers, and co-workers what they think about them, or if they believe themselves or the latter are doing something wrong or exceptionally well. Honesty is both liberating, and makes sure one avoids problems and problematic patterns.

Let Them Grow

Here’s another insight: let your developers grow. If you know they have potential, then hire them regardless if they have the appropriate experience you’re looking for. No-one is born a kernel developer, an experienced mod_perl developer, a Java developer with 5 years of experience, or a C/C++ systems programmer. But many people who are fresh out of college or even high school, and who like to program for fun, are capable of becoming that by being given an appropriate chance.

On the IRC, I’ve been talking to someone who graduated in Electrical Engineering from a British university. Since he doesn’t want to work for the defence industry, he became a system administrator at a high school. Now he knows Perl and uses it extensively, but he doesn’t think he can get a more lucrative job as a Perl programmer (of which there’s a lot of demand for in England) because he doesn’t have a lot of mod_perl experience.

The reason people want experience is not because the people with experience are more productive, but because they know how to handle problems they encounter better. I don’t claim experience is not important. However, if you’re using a platform which is both reliable and predictable (it just works), give your programmers access to the Internet (with the Web, search engines, and IRC), to good searchable books, and to fellow developers who are more experienced than them in that platform, you can make sure they overcome such problems easily.

A different programmer, also from the UK, testified that while he started working with Perl and liked it and was good, no one was willing to give him a chance to grow. What is important about great hackers is not their knowledge or experience but their potential, attitude and autodidacticism. Given proper conditions they will accumulate a lot of knowledge, and surpass “medium-level” techs with a small amount of experience.

So when hiring, don’t ask them highly specialised questions. Otherwise, not only you won’t find too many “experienced developers”, but you will also reject many great developers, who will be excellent for what you do. Training a great hacker is cheap. But hiring an experienced mediocre programmer, is a bad idea.

Take Some Good Advice

Here is some good advice I found about software management:

  1. Eric S. Raymond’s The Cathedral and the Bazaar series. Also see his “How to Become a Hacker” document. Concentrates on open-source hacking.

  2. Joel on Software - a collection of articles and essays and a weblog by Joel Spolsky. Concentrates on writing commercial, marketplace software.

  3. Paul Graham - many essays on different topics including Lisp, language design, dynamic languages, startups, and general philosophy.

  4. Extreme Programming - a software management methodology intended primarily for developing in-house software, but with some good, general ideas.

After reading all of those you’ll become much more clueful about good software management than without it. Reading them taught me a lot, and even if I disagreed with some of the opinions they voiced, they were still good food for thought.

Respect and Cherish Your Developers

The final advice I can give you is to respect and cherish your developers. If you lose one great developer, you’ll have a very hard time finding an adequate replacement for him, if you ever can. So listen carefully to what they say, and instruct them to tell you everything that bothers them. Make sure they are working on exciting tasks most of the time, and that they are happy.

Don’t over-work them, give them the proper tools and equipment, treat them like they were kings (rather than slaves), and make sure they are happy working for you. While it does not guarantee that they won’t leave you, it will probably prevent most premature quitting or getting fired.

Make sure your developers are the people who ultimately dictate what is possible and what isn’t. At a previous workplace of mine, I was instructed to re-implement a PHP (and Flash 8) application in Perl. At first I thought it was some legacy code, but as it turned out it was done because the marketing department decided that our programs should run on either PHP, Perl or ASP. However, it is common knowledge that maintaining three different codebases in three different languages is close to impossible. (The only real solution is to have a compiler from one common language into the three languages, but I wasn’t instructed to do that.)

If the marketing department had understood what PHP, Perl and ASP were all about, then they would have known that writing it in PHP was enough. But there wasn’t a feedback from the developers back to the marketing department.

If your developer wants to work half-time - give it to him. If he wants to work from home, or have his own office instead of working from home - give it to him. Great developers are a scarce resource, and you can’t afford to lose them.