程序员追求的是什么？

上周我收到三位Halmstad大学学生的电子邮件，他们正在做一个为期三月的项目，内容是关于程序员在工作中追求的是什么，以及企业如何吸引有才华的程序员。下面是我对他们问题的答案，按重要程度排序。显然人们会有不同的偏好，所以我很有兴趣听到你们赞同哪些，反对哪些，重要性的评判，以及你们认为遗漏了的要点。

1. 做软件产品。我希望我参与编写的程序成为公司的主要业务。这就排除了IT维护工作，因为这种工作只是间接地支持了真正的业务（不管它是什么）。我也希望参与系统核心部分的工作，越重要的越好。如果我做的东西出错了，它应该马上成为一个紧急问题。最后，我不愿意参与仅仅是配置、应用或整合其他公司的软件 — 我希望自己来实现关键性的功能。

2. 优秀的同事。和对软件开发充满激情的聪明程序员一起工作是催人奋进的。我一次又一次地看到和同事一起谈论一些问题或设计是如何产生比我们任何一个人自己闷头想出来更好的思路的。这种合作方式不光是产生更好的代码，过程本身就是非常令人享受的。

你怎么知道某人是不是一个优秀的程序员呢？一个特别好的特征就是看他们是否持续学习和提高他们的技能，例如通过读书、看博客、参加培训课程、以及参加技术大会。这倒也不是一个必要条件，我就曾经和很多不干这些事的很棒的开发者共事。最后，优秀的开发者会吸引其他的优秀开发者，因为以上原因。如果一个企业有很多优秀的开发者，它就更容易招到更多的优秀开发者。

3. 挑战难题。程序员通过代码解决问题。开发的产品起码在某些角度需要聪明的思路，比如低延迟、大量并发请求、或有限的硬件资源。不过，很多软件产品都是由常规代码组成，没有什么难做的部分。所以你也不能只是盼着做“困难问题”而避开其他的所有需求。而且，组织好那些看起来很无聊的代码，让它们容易理解和维护，这本身也是一个巨大的挑战。

4. 很酷的技术。这主要是关于使用有趣的编程语言（例如Clojure、 Erlang 或者 Go），但也包括框架和应用（例如Hadoop 或 Cassandra）。这可能是某些公司有问题的地方。如果它们的应用是用某个语言（比如C++）写的，它就不会改了。所以如果你想改用一些新的语言，你可能需要换个工作。例如，如果你在斯德哥尔摩想用Erlang，你可以给Klarna 或 Campanja公司投个简历试试。

5. 用户。编码的乐趣之一是做出一些对别人有用的东西。做了东西却没人用就无聊了。要让用户（越多越好）关注你开发的努力并且给予有价值的反馈。唯一例外的可能是创业的时候，但是之后就要把吸引尽可能多的用户作为最优先的事情。

6. 不错的薪水。拥有大量优秀开发者的公司懂得优秀人才的价值。因为优秀和一般程序员之间的差别是巨大的，所以报酬向优秀开发者倾斜在经济上是有道理的 — 其实在生产效率上的差别远大于薪酬上的差别。反过来说，那些不舍得给程序员较好薪水的公司往往把程序员看作是可以随意更换的“资源”。那么这些公司在其他方面的表现恐怕也是你看不上的，不仅仅是低薪水。

7. 很好的工具。这个因素的重要性几乎是不言自明的。一台快速的计算机和几个显示器可以加快开发过程 — 谁会反对这一点呢？（好吧，那些光看成本不看效率的秃头老板可能会反对）

8. 一周工作40小时。如果你总是要加班完成任务，肯定是你工作的单位有一些问题。而且，长时间工作也不等于有效率。

9. 最少的官僚主义。对于开发过程来说，或多或少会有敏捷开发方法的影子，看起来大家都采用了这种思路。根据我的体会，在大公司里日常管理的那些琐事基本上都是躲不开的问题。

10. 在家工作。 有时候能在家工作是有效的，不过我不常这么做。我喜欢在办公室里，和同事交流。我曾经通过视频会议、聊天工具和电子邮件在一个远程办公室工作，但这样的工作效率还是不如现场合作的高。

11. 离家近。显然这不容易强求，但是能不用每天花几个小时在路上多好啊。

 

评论

如果你是咨询顾问（而不是程序员），这个列表上某些项可能会不一样。我总是愿意在产品公司工作，主要因为我喜欢深入了解系统，看着它随时间如何演变。所以我没有作为咨询顾问的第一手工作经验，不过我觉得是这样的：作为一个咨询顾问，你更容易接触到很酷的新技术，因为你有机会和很多不同的客户一起工作。但是，即使你有很棒的同事，你可能也不会每天和他们在一起工作，因为你们会被派到不同的客户那里去。

这就是我在单位里最看重的几个因素，按重要程度排序。在现实生活中总会打一些折扣，但越是列在前面的因素，我就越不愿意给它们打折扣。你看重的因素有哪些呢？

What Do Programmers Want?

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?