Original: Bruno Marnette: Coding is boring, unless ...

I did not manage, as a developer, to linger on one job for more than two years.

Each new job is an excellent career step, and the high turnover of workers is inherent in our field. But my former employers were not particularly happy that I was leaving. Some of them tried to keep me, but I felt so bored that I had no choice.

(Disclaimer: I was lucky that I lived in places where there was more work for programmers than programmers! I understand that the opportunity to change jobs is not available to everyone).

Now I am the co-founder and technical director of Enki. So I am responsible for engineering culture. Part of my job is to be sure that our developers are not going crazy with boredom, as has happened to me in the past.

The team and I developed a strategy against boredom and applied it to our company. And since this strategy still works well, I would like to share it here.

At Enki, we are fortunate to work on a difficult and interesting task. We have a lot of interesting pieces to translate them into code and many amusing problems that need to be solved. Therefore, it would seem, what kind of boredom can there be? But in the beginning it never happens. Boredom, as a rule, is intensified over time, and hits you at the most inopportune moment.

That is why we propose a solution in advance, creating a culture that will save us (knock on wood!) And make sure that it never gets boring.

TLDR: Too Long; Didnt learn

The most common and obvious reason for developer boredom is a project that lasts too long.

I experienced it personally at my first job. My team worked on the preparation and maintenance of financial data through a convenient API. At first everything was interesting because of the complexity and volume of data. I learned about effective data mining and API design. But a year later we were still working on the same data set, with the same technologies. I was becoming a specialist in a narrow area. I did not learn anything new.

I could not change the team or project, because it was very important for the company to keep me where I was. I understood data and technology too well to be replaced. I could not justify before them the replacement of technology with the mere need to learn something new. I said that I was bored and I didn’t have the strength, but they didn’t hear me, so I had to move on.

How to prevent such a feeling?

In our team, we try not to let any employee work on the same code, product or data set for more than three months. This period varies slightly and is probably too small for large companies. But we generally believe in frequent rotations.

To implement such schemes, we provide a comprehensive environment. Each of our developers can work on any part of the main code (or can quickly learn how to do it).

Another factor for prevention is the ongoing discussion of such problems. We have direct, open discussions every week. If the developer begins to feel too specialized or feels excessive comfort, then it's time to change the place.

Keeping the old code is boring

You can understand that your project is in support mode - officially or not - when developers spend 90% of their time fixing bugs instead of developing new components.

Some will say that service is inevitable. Old code needs support. Creating software is like building a house. Old houses need to be serviced and restored from time to time. Right?

Yes and no. A typical problem is established installations.

I once had a mentor who was cynical about this issue. He took it for granted that nothing could be done. This is how software development works, he said. Life sucks - get used to it.

How to deal with such a problem?

Support mode is sometimes the result of low-quality technical solutions combined with a lack of firmness of conviction.

A large, monolithic code base with complex dependencies requires additional maintenance. A well-designed micro-services infrastructure, on the contrary, is a bit more flexible. When the micro service stops working, you can replace it. You can rewrite it from scratch using another language or technology. This way you will learn something new, instead of fixing the inherited code. And if your architecture still does not allow it, then you can take some steps to improve it and get the skills of DevOps in the process.

The micro-services strategy is only one of the possible ways to tackle the problem of “boring” maintenance. Some create advanced tools to make support more effective and fun. A great example is what Facebook did with its massive PHP code base. They built their own compiler and wrote their own typed language (Hack) on top of PHP to simultaneously ease maintenance and improve developer experience. I suspect that this did not “solve” the legacy code problems, but it certainly made the work more interesting.

Copying bored

There is programming, and there is programming .

In some of my former posts, I wrote kilometers of code that was not too worthwhile. For example, I once wrote Groovy and Python scripts for data integration. The data were complex, with dozens of conflicting schemes that did not provide enough room for automation. So I had to write a lot of code, and my colleagues thought that I learned a lot of new things.

But this was not the case. Why?

Because 50% of my code (especially exaggerating!) Was direct copying from Stack Overflow. And the other 40% were copying from other scripts. Either my colleagues, or my own. The work has become monotonous. There was little creativity or knowledge.

How are we trying to handle this?

As a team, we pay attention to the type of code written by others. We do this during code review, call and meeting. If someone spent a week on not too creative code, we try to understand why.

Sometimes the root of the problem is technical. Perhaps we are working on scripts or settings more than required. In this case, we add more automation. In some cases, we do copy-paste specifically. Then we try to distribute the load of boring work in order to get rid of it as soon as possible.

Internal tools are usually boring.

We, developers, like to create our own internal tools to solve specific problems, because creating new things is great. And yet, the design of special solutions is felt "cleaner" than the adaptation and reuse of existing ones. But the study of a proprietary tool is about 10 times less interesting than the study of popular open source technologies.

Why?

Because you cannot talk about him with friends, brag about him, cannot read about him on Hacker News, use it during hackathons or in a closed third-party project.

But many companies fall into the trap: they create solutions that are not worth the boredom. In other words: coping with short-term hopelessness, they create hopelessness for the long term.

I saw it myself at a previous job. I was forced to use internal DSL for large-scale data integration. All that I have learned is new, another SQL such a jargon (I specially exaggerate). It would be better if I used and studied open low-level technology, like Spark. I would be 10 times more involved, and even if my code were twice as verbose, it would still make me 5 times more productive. (not exactly mathematically justified, but you understand).

What culture and environment can prevent this?

We try to make the most of open technology. If we can reuse something relevant and exciting, we do it. We do not avoid the most modern technologies. We throw away the code we created as soon as the open technology becomes mature enough to replace it. And when our own code becomes quite universal, we publish it under an open source license.

Sometimes we make mistakes. For example, for some time we used the library agenda.js to plan the backend task, because it seemed modern and tempting. But it turned out that this complicates everything, so we switched to the old, more reliable technology (good old cron !). We do not regret experimenting because it was a valuable experience.

Being a decoder is boring

Another common cause of boredom is unprofessional personnel management. More precisely: dictatorial management of developers, on a "top down" principle.

Leaders with noble intentions sometimes use this management style without realizing it. Especially when the project is not progressing well, or when the deadline is approaching. Under pressure, a natural reflex is triggered: to try to reduce discussions, minimize brainstorming and give people specific instructions on what to do - without discussion and explanation. Just to save time and results.

Understanding the ward is not necessarily upset; in fact, some people (sometimes) appreciate simple tasks that need to be performed exactly as said. It is assumed, of course, that this was asked for in a way that seems appropriate.

But there are some hidden costs.

Exact knowledge of how to write code before starting work turns the intellectual and creative process into a mechanical one. In other words, it turns developers into monkey coders.

More importantly, the involved developers want to understand why they are doing something in this way, and not others. If, of course, this is not a trivial job of circumventing the problem in the boundary case or writing a temporary patch. But a developer who stops taking care of important decisions and their validity is the developer who is ready for a job change.

How to prevent this?

The main thing that is needed is an environment that encourages open discussion. With a regular forum for discussion, strategy development and planning of what should be done in a team. And in order to maintain this atmosphere, everyone in the team must be vigilant.

It is in difficult times (or when the deadline is close) that the clients need to speak louder and mentors to listen carefully.

Routine always gets boring

Last but not least, a routine in a closed atmosphere is an absolute killer of pleasure.

And this concerns not only developers and the IT industry. This can be applied to almost any employee who does not work directly with clients. Every day the same room, the same people, the same atmosphere, the same position ... Even in a fast-growing team, and even when all these things are objectively “good,” people start taking everything good for granted, and bad things frustrating.

How do we fight this?

The key ingredient here is diversity: to hire people with different types of experience and different backgrounds (for example, our team consists of 6 people from Britain, France, Russia and Greece). It’s certainly more interesting to meet the same people every day if each of them can bring something special to the culture.

In addition, we try to more often have the opportunity to get out of the daily routine.

For example, we go together to public meetings and hackathons. We have third-party projects, and we are promoting the development of our favorite open source tools. We even occasionally help colleagues with non-technical issues (for example, hiring new people, marketing, distributing ...). Not because we are all specialists in this, but for a change.

We also organize third-party raids for the team (for example, Secret Cinema) and we have a weekly campaign without a clear goal and plan. During it, we sometimes write together useless programs. Sometimes we ponder a new idea. Sometimes we just play League of Legends. Or go to the pub. Pleasant here is that we do not know what we will do until the last minute, until we decide together.

A drop of chaos is the last ingredient of our recipe against boredom. And, like any recipe, it can never be brought to the ideal. Change the quantity, replace the ingredients and repeat.

Original: Bruno Marnette: Coding is boring, unless ...

(Translation by Natalia Bass )