Coding is boring, unless…

As a developer, I never managed to stick to the same job for more than two years.

Each new job was a good career move, and a high turnover is common in our industry. But my previous employers were not particularly happy that I left. Some of them tried hard to keep me, but I was so bored that I couldn’t stick around.

(Disclaimer: I was lucky enough to live in places where there are more programming jobs than programmers! I realize that changing jobs is not always an option.)

I am now co-founder and CTO of Enki. As such, I’m responsible for the engineering culture. Part of my job is to make sure that our developers never get as bored as I have sometimes been in the past.

With the help of my team, we have devised a strategy against boredom and applied it to our company. And because this strategy has worked well so far, I wanted to share it here.

At Enki, we‘re lucky to be working on a challenging problem. We have plenty of interesting things to code and plenty of fun puzzles to solve. Therefore “boredom” doesn’t feel like an urgent concern. But it never does at the start. Instead, boredom tends to creep in with time, and hit you at the worst possible moment.

This is why we’re addressing this early, by building a culture which will save us (fingers crossed!) from ever getting bored.

Too Long; Didn’t Learn

The most common and obvious cause of boredom for developers is a project that lasts too long.

I’ve experienced this first-hand in my first job. My team was working on preparing and serving financial data through a convenient API. It was exciting at first because of the complexity and the scale of the data. I learned about high-performance data analysis and API design. But after one year, we were still working on the exact same dataset, with the exact same technologies. I was becoming a specialist of something too specific. There was nothing new for me to learn.

I could not change team or project because it made too much sense for the company to keep me where I was. I knew the data and the technology too well to be replaced. I couldn’t justify to change the technology just for learning something new. I expressed my boredom and frustration, but it wasn’t addressed, so I had to move on.

How to prevent that sort of feeling?

In our team, we try and prevent anyone from working on the same code, product or dataset for more than three months. This period is a bit arbitrary and perhaps too short for larger companies. But we generally believe in fast rotations.

To make this possible, we promote a full-stack culture. Each of our developers are able to work on any part of our code base (or could quickly learn how).

Another factor of prevention is to discuss these things constantly. We have direct, open, one-to-one discussions each week. If a developer starts feeling too comfortable or too specialized, it’s time to rotate.

Maintaining legacy code is boring

You can tell when a project is in maintenance mode — officially or not — when developers spend 90% of their time fixing bugs instead of developing new features.

Some will say that maintenance is inevitable. Old code needs to be supported. Building software is like building a house. You need to maintain old houses and refurbish them from time to time. Right?

Yes and no. The common problem here is a problem of attitude.

I once had a mentor who was cynical about this. He was taking for granted that nothing could be done. It’s how software development works, he would say. Life sucks, get used to it.

How to mitigate this?

Maintenance mode is sometimes the result of poor technical decisions combined with a lack of courage.

A large, monolithic code base with complex dependencies requires extra maintenance work. In contrast, a well architected micro-service infrastructure is a bit more flexible. When a micro-service becomes faulty, you can replace it. You can rewrite it from scratch, using a different language or technology. This way, you learn something new rather than patching legacy code. And if your architecture doesn’t allow this yet, you can take steps to improve it, and learn some devops skills in the process.

A microservice strategy is only one among other possible ways to approach a problem of “boring” maintenance. What some places do is to build smart tools to make the maintenance more efficient and fun. An extreme example of that is what Facebook did with their massive PHP code base. They build their own compiler and their own typed language (Hack) on top of PHP to both facilitate maintenance and improve the developer experience. I suspect it didn’t “solve” the legacy problems entirely, but it certainly make the work sound more interesting.

Copy/pasting is boring

There is coding, and then there is coding.

In some of my previous roles, I produced a lot of not-so-rewarding code. For instance, I was once writing Groovy and Python scripts for data integration. The data was complex, with dozens of inconsistent schemas, which didn’t allow for much automation. I therefore had to write a lot of code, and my peers assumed that I was learning a lot.

But I was not. Why?

Because 50% of my code (hyperbole intended!) was a direct copy/paste of Stack Overflow. And another 40% was a copy/paste from other scripts. Either my colleagues’ scripts or my own. It became repetitive. And there was little creativity or learning involved.

How are we trying to mitigate this?

As a team, we pay attention to the type of code written by others. We do that during code reviews, syncs and retrospectives. If someone spent a week writing not-so-creative code, we try to understand why.

Sometimes, the root of the problem is technical. We may be doing more scripting or configuration work than we should. In this case, we add more automation. Other times, we did the copy/paste for a reason. In this case, we try to share the load of boring work to get done with it.

Internal tools are usually boring

As developers, we like to create custom internal tools to solve specific problems, because creating new things is exciting. Also, building tailored solutions often feels cleaner than repurposing existing ones. But learning a proprietary tool is about 10x less interesting than learning a popular open-source technology.

Why?

Because you can’t talk to your friends about it; you can’t brag about knowing it; you can’t read about it on Hacker News; you can’t use it during hackathons.; you can’t use it in your secret side project.

But a lot of companies fall into the trap of creating things that are not worth the boredom they create. In other words: they solve a short-term frustration only to cause more frustration in the long-term.

I have seen this first-hand in a previous job. I was constrained to use a company-made DSL for large-scale data integration. All I was learning was yet another SQL-like-ish jargon (hyperbole intended). I would have much preferred using and learning a low-level open technology like Spark. I would have been 10x more engaged, and even if my code was 2x more verbose, that would still make me 5x more productive. (Not exactly how the math works, but you see my point!).

What kind of culture can prevent this?

We try to keep a strong bias for open source technologies. If we can reuse something relevant and exciting, we do it. We don’t shy away from the cutting edge. We throw away our custom code as soon as an open source technology becomes mature enough to replace it. And when our own custom code becomes generic enough, we open source it.

We occasionally make mistakes. For example, we were using the agenda.js library for a while to schedule our backend jobs, because it felt modern and exciting. But it turned out to complicate things, so we switched back to an older, more reliable technology (good old cron!). Still, we don’t regret experimenting with it, because it was a valuable learning experience.

Being a code-monkey is boring

Another common cause of developer’s boredom is poor people management. More specifically: top-down, dictatorial management of developers.

Supervisors with noble intentions can sometimes use this management style without realising it. Especially when a project is not going so well, or when a deadline is approaching. Under pressure, it is a natural reflex to try and cut discussions short, minimize brainstorming, and tell people exactly what to do without debate or explanation. Just for the sake of saving time and getting things done.

An understanding supervisee would not necessarily get upset by this; in fact, some people would (occasionally) appreciate the simplicity of being told exactly what to do. Assuming of course that it is asked in a way that feels appropriate.

There is however a hidden cost.

Knowing exactly what to code before coding transforms an intellectual and creative process into a mechanical process; in other words, it turns developers into code monkeys.

More importantly, engaged developers like to understand “why” they are doing things one way rather than another. Unless, of course, it’s a just a hack to work around an edge case, or a temporary patch. But a developer who stops caring about the important decisions and the reasoning behind them is a developer ready to change their job.

How to prevent this?

The main thing needed is a culture that encourages open discussions. With a regular forum to debate, strategize and plan as a team what needs to be done. And to preserve such a culture, everyone in the team must be vigilant.

It is when times are tough (or deadlines are approaching) that mentees need to speak louder and mentors need to listen carefully.

The day-to-day always gets boring

Last but not least: the routine of a closed environment is the absolute killer of fun.

This is not specific to the developer role or the tech industry. It applies pretty much to any back-office job. Every day the same room, the same people, the same culture, the same role… Even in a fast-growing environment, and even when all these things are objectively “good”, people start feeling entitled to the good parts and frustrated by the not-so-good parts.

How do we fight this?

A key ingredient here is diversity: hiring people with different backgrounds and origins (e.g. our team of 6 is currently British, French, Russian and Greek). Seeing the same people every day is definitely more interesting if each of these people can brings something different to the culture.

Also, we try to create frequent opportunities to step outside of the day-to-day.

For instance, we go to public meetups and hackathons together. We also have side projects and contribute to our favorite open source tools. We even help the rest of the team with less-technical work from time to time (e.g. hiring, marketing, distribution…). Not because we’re all good at this, but for a change.

We also organize team off-sites (e.g. Secret Cinema) and we have a weekly “enkithon” with no predefined agenda. During these, sometimes we hack something together. Sometimes we brainstorm a new idea. Sometimes we just play League of Legends. Or we go to the pub. The beauty of it comes from the fact that we don’t know what we’re going do until the last minute, when we decide together.

This little bit of chaos is the final ingredient in our recipe against boredom. And like every recipe, it can never really be perfected. Tweak the doses, replace the ingredients and repeat.