I got an e-mail last week from three students at Halmstad University doing a three month project on what programmers want in a job, and how companies can attract talented programmers. Here are my answers to their questions, in order of importance. Obviously people have different preferences, so it would be interesting to hear what items you agree and disagree with, how you would rank them, and what you think is missing.

The product is software. I like the programs I work on to be the main business of the company. This rules out working in an IT-department, since their job only supports the real business (whatever it is) indirectly. I also like to work on the central parts of the system – the more important it is, the better. If my parts stop working, it should immediately become an emergency issue. Finally, I don’t want to merely configure, adapt and glue together software from other companies – I want to write significant chunks of functionality myself.

Great colleagues. It is very stimulating to work with smart programmers who are passionate about software development. Time and again I see how discussing a problem or a design with a colleague leads to a solution that is better than either of us would have come up with by ourselves. Not only does it lead to better code, the process itself is also very enjoyable.

How do you know if someone is a good programmer? A very good sign is if they keep learning and improving their skills, for example by reading books and blogs, taking courses, and going to conferences. It is not a necessary condition though; I’ve worked with plenty of really great developers that don’t. Finally, good developers tend to attract other good developers, because of the reasons above. The fact that a company has many great developers makes it easier to recruit more.

Challenging problems. Programmers like solving problems with code. There should be at least  some aspect of the product that requires clever solutions, be it requirements on low latency, many concurrent requests, or limited hardware resources. However, a lot of productions software consists of regular code without any particularly difficult parts. So you should not expect to only work on “hard problems” and shun everything else. Besides, it is a big challenge to organize even the boring code in a way that makes it easy to understand and maintain.

Cool technology. This is mainly about using interesting programming languages (for example Clojure, Erlang or Go), but also includes frameworks and applications (for example Hadoop or Cassandra). This is one area where a company may have a problem. If their application is written in a certain language (say C++), it won’t change. So if you want to change to using some new language, you pretty much have to change jobs. For example, if you want to work with Erlang in Stockholm, you could try Klarna or Campanja.

Users. One of the joys of coding is making something that is useful to others. Making something that nobody uses is boring. Having users (the more the better) focuses the development effort and gives valuable feedback. The only exception would be a start-up, but then the overriding priority must be to get users as soon as possible.

Good salary. Companies that have a lot of good developers know the value of great people. Since the variation between great and average programmers is big, it makes economic sense to pay for quality developers – the variation in productivity is much greater than the variation in salary. On the flip side, companies that don’t pay their programmers well tend to be the companies that view programmers as interchangeable “resources”. Those are the companies you want to avoid for other reasons as well, not just for the low salary.

Good tools. This is almost self-evident. Having a fast computer and several monitors speeds up development – who’s against that? (OK, pointy-haired bosses that only see the cost, not the benefit, would be against).

40 hours a week. If you constantly have to work overtime to ship, something is wrong in the organization. Besides, working long hours don’t equate with being productive.

Minimal bureaucracy. For the development process, this is more or less fixed with agile development methodologies, which seem almost universally adopted. General administrative overload is mostly a problem at larger companies in my experience.

Working from home. It’s handy to be able to work from home sometimes, but it is not high on my list. I like being at the office and interacting with people. I’ve worked with a remote office using video conferencing, chat and e-mail, but it didn’t come close to the kind of productivity you get from being co-located.

Short commute. Obviously hard to influence, but not spending hours each day in traffic is really great.

Comments

If you are a consultant, some things on the list change. I’ve always liked working for product companies, mostly because I prefer to really get to know a system deeply and seeing it evolve over time. So I don’t have any first-hand knowledge of working as a consultant, but my take is this. As a consultant, it is much easier to get exposed to cool new technology, since you have a chance to work with many different clients. However, even if you have great colleagues, you probably won’t work with them day to day, since you may be with different customers.

So this is the list, in order of importance, of what I look for in a company. In real life there are always some compromises, but the higher up something is on the list, the less willing I am to compromise on it. What are your priorities?