The pursuit of the programmer

One weeks, three Halmstad university students emailed me and they were working on a March project to study what programmers are looking for at work and how businesses can attract talented programmers. Here are my answers to their questions, which are sorted to an important degree. There is no doubt that people will have different hobbies, so I am very interested in what you agree to, what you disagree with, and what you think is missing.

1. Make software products. I hope that the program I am involved in is the main business of the company. This excludes it maintenance because it only indirectly supports the real business (whatever it is). I also want to participate in the core part of the system, the more important the better. If I do something wrong, it should immediately become an urgent problem. Finally, I don't want to be involved in simply configuring, applying, or integrating software from other companies-I want to do the key functions myself.

2. Excellent colleagues. Working with intelligent programmers who are passionate about software development is inspiring. I see it again and again to talk with my colleagues about some problems or how design can produce better ideas than any one of us has ever thought of. This collaboration is not just about producing better code, but the process itself is very enjoyable.

How do you know if someone is a good programmer? A particularly good feature is to see if they continue to learn and improve their skills, such as reading books, reading blogs, attending training courses, and attending technical conferences. It's not a necessary condition, and I've worked with a lot of great developers who don't do it. Finally, good developers attract other good developers for the above reasons. If an enterprise has many good developers, it will be easier to recruit more excellent developers.

3. Challenge challenges. Programmers solve problems through code. Developed products at least at some point need smart ideas, such as low latency, a large number of concurrent requests, or limited hardware resources. However, many software products are made up of regular code, and there is no hard part. So you can't just look forward to "difficult problems" and avoid all the other needs. And it's a huge challenge in itself to organize the seemingly boring code that makes them easy to understand and maintain.

4. Cool technology. This is mostly about using interesting programming languages (such as Clojure, Erlang, or go), but also includes frameworks and applications (such as Hadoop or Cassandra). This may be a problem for some companies. If their application is written in a language such as C + +, it will not be changed. So if you want to switch to a new language, you may need to change your job. For example, if you want to use Erlang in Stockholm, you can give Klarna or Campanja company a resume to try.

5. Users. One of the pleasures of coding is to make something useful to others. It's boring to do something but nobody uses it. Let the user (the more the better) focus on your development efforts and give valuable feedback. The only exception may be the time to start a business, but the first thing to do is to attract as many users as possible.

6. Good salary. Companies with lots of good developers know the value of good people. Because the difference between good and average programmers is huge, it makes economic sense to tilt the rewards to good developers--in fact, the difference in productivity is much greater than the difference in pay. Conversely, companies that are not willing to pay programmers a better salary tend to think of programmers as "resources" that can be arbitrarily replaced. Then these companies in other aspects of performance I am afraid you do not see, not only low salary.

7. Good tools. The importance of this factor is almost self-evident. A fast computer and several monitors can speed up the development process-who would object to that? (well, those bald bosses who look at cost-less efficiency may disagree)

8. Work 40 hours a week. If you are always working overtime to complete a task, there must be some problems with the unit you work with. Moreover, working long hours is not equal to efficiency.

9. Minimum bureaucracy. For the development process, more or less there will be the shadow of agile development methods, it seems that everyone used this idea. According to my experience, the day-to-day management of the big companies in the trivial matters are basically not open.

10. Work from home. Sometimes it works at home, but I don't do it often. I like to communicate with my colleagues in the office. I used to work in a remote office with video conferencing, chat tools, and emails, but it's not as efficient as onsite collaboration.

11. Close to home. Obviously it's not easy to force, but it's nice not to spend a few hours a day on the road.

Comments

If you are a consultant (not a programmer), some items on this list may be different. I'm always willing to work in a product company, mostly because I like to get to know the system and see how it evolves over time. So I don't have first-hand experience as a consultant, but I think it's like this: As a consultant, you're more likely to have access to cool new technology because you have the opportunity to work with a lot of different customers. But even if you have great co-workers, you may not be working with them every day because you will be sent to different clients.

This is the number of factors I value most in my organization, sorted by importance. In real life there will always be some discounts, but the more they are listed in the front, the less willing I am to give them a discount. What factors do you value?