How to keep your programmers from getting bored with their work?

As a programmer, I never worked for the same company for more than two years. Each new job was a good career move, and job hopping is common in this industry. But my former employers were not happy about my departure, and some of them tried hard to keep me, but I was tired of the same job and really didn't want to stay in the same company anymore.

[[158532]]

(Disclaimer: I'm lucky enough to live in an area where there's a glut of programmer jobs, so there's always more than one option for me when it comes to changing jobs.)

Today I am a partner and CTO at Enki, and I am responsible for building an engineering culture within the company. Part of my job is to make sure our programmers don’t get bored with their work, like I did in the past.

With the help of our team, we developed a set of strategies to help programmers fight boredom at work, and we implemented them in our company. It’s been working well so far, so I wanted to share it with you.

At Enki we programmers are lucky enough to have challenging work. We have a lot of interesting things to code and a lot of interesting problems to solve. So solving boredom is not a very urgent thing for us. But all work will not make you feel bored at the beginning, boredom is a feeling that spreads over time and will break out at the worst time.

That’s why we’ve been working to prevent these kinds of problems since the beginning of the company, relying on building a culture that helps our programmers overcome boredom at work (fingers crossed it works).

Let’s summarize why programmers feel bored at work and how to avoid these situations.

[[158533]]

1. The project lasted too long and I didn’t learn anything new.

The most common and obvious cause of programmer boredom is a development project that takes too long.

I experienced the boredom of long projects in my first job. My team was tasked with processing financial data through a common API. The work was exciting at first because the data was complex and large, which was challenging. I learned how to analyze data efficiently and design API interfaces from this work. But after a year, we were still working on the same database and using the same technology. I had become an expert in this highly targeted field, and there was nothing new for me to learn in this job.

I couldn't move to another team or project because the company felt that keeping me in this project was the best choice. I knew that the existing data and technology in this project were so easy to use that they couldn't be replaced. I couldn't convince the company to change the original technology just to let the project team members learn new knowledge. I expressed my boredom and frustration to the company, but it didn't help, so I had to find a new job with a bright future.

How to prevent boredom?

In our team, we try not to let any programmer touch the same code, product, or database for more than three months. Setting a time limit of three months may be arbitrary, and it may be too short for a large company. But we believe that it is right to let programmers rotate quickly between different projects.

To achieve this design, we promote a full-stack culture in the company, where every programmer in the team can take on any part of the coding work (or can quickly learn to operate it).

Another way to prevent boredom from setting in is to discuss it openly. We have direct, open one-on-one conversations every week. If a programmer feels too comfortable and unchallenged in their work, or has become too specialized in one area, then it's time to rotate them to another project.

2. Maintaining legacy code is boring

[[158534]]

You can clearly tell when a project has entered maintenance mode, whether through formal channels or otherwise, as long as your programmers spend 90% of their time fixing bugs instead of developing new features, it means that they have entered the code maintenance period. Some people would say that maintaining code is an inevitable task, and old code needs to be supported continuously. Developing software is like building a house, you always need to maintain and renovate the house, right?

Yes and no. Someone does need to do the job, but the problem usually lies in the attitude towards the work.

One of my former colleagues had a strong aversion to maintaining code. He took it for granted that there was no point in maintaining code and that the software should just run after it was developed. Life was terrible and you had to get used to it.

How to alleviate this resistance?

Project development efforts sometimes enter boring maintenance mode due to a combination of poor technical decisions and lack of courage.

Unlike a monolithic codebase with complex dependencies that takes extra time to maintain, a well-architected microservice infrastructure offers greater flexibility. When a microservice architecture breaks down, you can take immediate steps to fix it. You can rewrite the code, using a different programming language or technology. This way, you’ll learn new things instead of just patching up legacy code. If your architecture doesn’t allow you to start over, you can take other steps to improve it and learn some DevOps techniques in the process.

There are many ways to solve the boredom of programmers in maintaining code, and companies adopting a microservice strategy is just one of them. Other companies will build smart tools to make code maintenance more efficient and more interesting. An extreme example is what Facebook did with their massive PHP code base. Facebook developed their own compiler and Facebook-style language (Hack) to make their PHP code base not only easier to maintain, but also improve the programmer's work experience. I guess this approach does not completely solve the legacy of code maintenance, but it does make the job sound more interesting.

3. The only work left is copying and pasting

All a programmer does is write code.

I've written a lot of code in my previous jobs that didn't make sense. For example, I wrote Groovy and Python scripts for data integration. The data was quite complex, with many inconsistent sets of database objects, and therefore couldn't be automated. Given that I had to write a lot of code, my colleagues assumed that I must have learned a lot from it.

But it didn’t. Why is this happening?

Because 50% of the code (and that’s an exaggeration!) I copied and pasted directly from Stack Overflow. Another 40% was copied from other scripts, some from my colleagues, and some I had written before. The work became a repetitive labor with no creativity or learning.

How can we avoid this?

As a team, we all take the time to understand what kind of code other team members write. We do this during code reviews, syncs, and work reviews. If someone spends a week writing code that is not creative, we try to understand what happened to them.

[[158535]]

Sometimes the root of the problem is the technology you use. We may be using too many scripts, or doing more configuration than we should be doing. If that's the case, we'll add more automation. Sometimes we copy and paste code for a reason, in which case everyone will share the boring work that has to be done.

4. It’s too boring to only use internal tools

As programmers, we love to build a custom in-house tool to solve a specific problem because it’s exciting to create something, and it’s often better to build a custom solution than to find an existing one and reuse it.

Yet, compared to learning a popular open source technology, learning an in-house proprietary tool is only one-tenth as interesting as learning a popular open source technology. Why is that?

Because it’s not something you can talk about with your friends, you can’t brag about it, you won’t read about it on Hacker News, you can’t use it in hackathons, and you certainly can’t use it in your secret side project.

Many companies fall into the trap of building internal tools because it leads to more boredom for programmers. In other words: the internal tool you build to solve a short-term problem creates more long-term problems.

I experienced this firsthand in my last job. I was restricted to using the company’s own DSL for large-scale data integration, and I had been learning a completely different language, SQL. I would have preferred to use even a less open language like Spark. If I didn’t use internal tools, I would have worked 10 times harder, written 2 times better code than I already had, and would have been 5 times more productive (don’t worry about whether the multiples make mathematical sense, just feel my way!).

What kind of corporate culture can avoid this dilemma?

We don't have a bias against open source in our company. If we can reuse open source technology, we're happy to do it. We don't shy away from cutting-edge technology. Once open source technology becomes mature enough to replace our current proprietary languages, we will immediately abandon the original custom code and embrace open source technology. When the custom code we developed ourselves becomes general enough, we will open source it.

We sometimes make mistakes. For example, we used agenda.js to schedule our backend work for a while because it felt like a new and exciting technology. But it soon became too complex and we had to go back to the older but more reliable technology. Even so, we still don't regret trying it because it was a valuable learning experience.

5. If you don’t know why you write code, you will get bored with your work

Poor human resource management is also a common reason why programmers are bored with their work. More specifically, programmers become resentful of top-down, authoritarian management.

Well-intentioned managers often use this authoritarian approach without even realizing it. This is especially common when a development project is not going well or when a deadline is approaching. Under great project pressure, it is natural for managers to shorten team discussions, reduce brainstorming, and directly order programmers to write code without explaining why or accepting any arguments. The starting point for managers to do this is usually to save time and get the work done as soon as possible.

If this management method can be understood, it will not always cause annoyance; in fact, some people can accept you telling them what to do simply and directly. Of course, this is also based on the premise that your tone of voice is acceptable to the other party.

There are also hidden costs to using this authoritarian management approach. Usually, programmers need an inherent thinking process that converts intelligence and creativity before they know exactly what code to write. In other words, if you don't let him figure out the key points and just blindly order him to code, he will become an ape that can write code but can't think.

[[158536]]

More importantly, you should encourage programmers to ask "why" so that they can be more engaged in the work they do. Unless what you are doing is an extreme thing or a temporary patch, you should explain it clearly to the programmer. If a programmer no longer cares about important decisions related to the project and no longer thinks about the logic behind these decisions, then he is probably ready to change jobs.

How to prevent this problem?

The most important thing to solve this problem is to establish a mechanism for open discussion in the corporate culture. Set aside a fixed discussion time and let the whole team participate in discussing what to do next and how to plan. To maintain this corporate culture of open discussion, everyone must be vigilant against autocratic management style.

Especially when the team is facing difficult moments (or when a deadline is approaching), team members need to express their opinions more loudly, and managers need to listen more carefully.

6. Day-to-day work will inevitably lead to boredom

One more thing I have to mention is that working long hours in a closed work environment will definitely kill the joy of life. This is not just for tech workers or programmers, but also for other industries. This applies to almost any back-end operation position. Every day in the same office, seeing the same group of people, doing the same work, and there is no collision of different cultures. Even in a fast-growing corporate environment, even if everything is running "well" from an objective point of view, people will feel entitled to find some fun and will be frustrated by things that are not so good.

How do you combat boredom that creeps into your daily work?

The key to solving this problem is to create diversity as much as possible: recruit employees with different backgrounds and from different countries (for example, our team currently has 6 members from the UK, France, Russia and Greece). If the same group of people you see every day can bring you a different cultural shock, then work will definitely be more interesting.

At the same time, we actively create opportunities to step out of the regular working environment.

For example, we go to industry meetups and hackathons together. We also build side projects together and work on our favorite open source tools together. In addition, we also help other teams with less technical tasks (including recruiting, marketing, and distribution) from time to time. We do this not because we are good at these tasks, but just to seek changes in our daily work.

[[158537]]

We also organize some team activities (such as watching a secret movie together), and we also have a fixed team activity time every week without a preset theme. During this independent activity time, sometimes we will work on technology together, sometimes we will brainstorm a new idea, sometimes we will just get together to play LOL, or make an appointment to go clubbing together. The beauty of this free activity is that when we sit down to discuss what to play, we don’t know what to do in less than *** minutes.

Adding this little unknown to our lives becomes our first line of defense against boredom. Like any other way to fight boredom, it's not a perfect solution. What we need to do is to keep tweaking the old ones, find some new ones, and keep using them in the battle against boredom.