What to do if programming gets boring

Has it happened to you, working for a long time in the same company on the same project, you begin to think about changing the situation, the technologies used and the project itself. Previously, I was sure that one way out of this situation was to find a new job. This article, the translation of which we publish, has changed my mind. It describes the approach by which you can make the work of the programmer boring and helping him grow and develop. We, the service for organizing the acceptance of PayOnline payments, suggest that you familiarize yourself with this methodology and share it with your employer in case you experience similar problems described by the author. The following is, directly, the translation.

When I was a developer, I never stayed at the same job for more than two years. In my case, each new job was a good move for me in terms of career growth. And even despite the fact that high “routine” is a common thing in our professional sphere, I can’t say that my previous employers were calm about my leaving. Some of them persistently tried to make me stay, but the work became so boring for me that I could not remain. Immediately I will explain: I was lucky enough to live in places where there was more work for programmers than the programmers themselves. I understand that the option of changing jobs is not available to everyone.

Now, being one of the founders and technical director of Enki , I am responsible for engineering culture, and therefore my responsibility is to ensure that our developers never lose interest in their work, as it happened to me before. Together with our team, we invented a strategy to combat this problem. We use this strategy every day, and since it has worked well for all this time, I want to share it here.

We at Enki are very lucky because we are working on difficult, but interesting problems. We have to code a lot and get involved in solving exciting problems, so the question of losing interest in our team is not worth it. However, at the beginning of work on the project it is quite natural, but over time, everything changes, because boredom has a habit of stealing up unnoticed and attacking at the most inconvenient moment. That is why we try to create in advance a culture that we hope will help us to always be passionate about our work.
')

We are changing quickly, we learn something new

The most characteristic and obvious reason why developers are starting to get bored is a long-running project.
I was convinced of this personally at my first job. My team worked to create a convenient API for preparing and presenting financial data. At first, because of their complexity and scale of the project, the work was fascinating. I learned a lot about high-performance data analysis techniques and API design. However, a year later, we still worked on the same data set and used the same technologies as at the beginning. I began to gradually turn into a too narrow specialist. There is nothing new that I could learn.

I could not change the team or project, because it would be too unreasonable from the point of view of the goals of my company. She needed me in the same place. It was impossible to replace me, because I was too well versed in data and technology. At the same time, I could not change the technology “for myself” because of the mere desire to learn something new. I told the employer what a hopeless situation I was in and how tired I was, but he didn’t take any measures, so it was time for me to move on.

How to protect yourself from such situations?

Our team tries to make sure that no one has to work on the same product, data set for more than three months. Of course, this time period is chosen based on our own preferences and may be too short for larger companies, however, in general, we believe in quick replacements.

For all this to succeed, we cultivate an integrated approach. Each of our developers is able to work on any part of the source code base or can quickly learn it.

Another important part of prevention is the ongoing dialogue with all team members. Every week we have individual sessions with the opportunity to frankly discuss all that worries a particular developer. If he begins to feel too comfortable or is too deep into some part of the project, then it is time for him to change the situation.

How code support makes work boring.

You can always easily determine that the project, officially or not, is in support mode, because in this case, developers spend 90% of their time correcting bugs, instead of developing new features. Perhaps someone will argue that improvements and updates are inevitable, and the old code needs to be maintained. Creating software is similar to building houses: you need to keep old houses in good condition and update them from time to time. Or is this the wrong logic?

Yes and no. The problem lies in your way of thinking.

One of my mentors, for example, was very cynical about the situation with the support of the code. For him, it was a matter of course, they say, nothing can be done, this is how the world of software development works, life is complicated, you have to get used to it.

How can you simplify this situation?

Sometimes a code maintenance jam occurs as a result of poor technical solutions coupled with a lack of courage. A large monolithic database of source code with complex dependencies requires additional work from the point of view of maintenance. In contrast, a well-designed infrastructure based on micro-services turns out to be more flexible. Defective microservice can be easily replaced. It can be rewritten from scratch using another language or technology. Thus, instead of patching the inherited code, you have the opportunity to learn something new. And if your architecture still does not allow the use of micro-services, you can improve it step by step, at the same time raising your level of knowledge in DevOps.

The strategy of using microservices is only one of the approaches to solving the problem of “boring” code maintenance. Some companies even create smart tools in order to make the maintenance process more efficient and fun. A good example is Facebook and its approach to optimizing the huge base of PHP source. The company's developers have created their own compiler and language Hack, using static typing and running on top of PHP. This helped them streamline the maintenance process and streamline their workflow. I suspect that this measure did not solve all the problems with the inherited code, but thanks to it, developers have probably become happier to live.

How regular copy-paste makes work boring.

There is coding, but there is coding .

If you look at my earlier activities, it becomes clear that I have created a lot of unwanted code. For example, once I wrote scripts in Groovy and Python for data integration. The structure was complex, containing dozens of non-permanent schemes that did not allow for any meaningful automation. So I had to write a lot of code. My colleagues who worked on this task with me, then believed that I received a lot of new and useful information in the process.

But in fact it is not, and I will explain why.

The thing is that 50% of my code was direct copy-paste from Stack Overflow, the other 40% was copy-paste from other scripts, which were written either by colleagues or by myself. The process turned out to be very monotonous and there was little creativity or learning in it.

How to treat this problem our team?

Being one team, we carefully analyze the types of code that each of us writes. We do this together during joint parsing of code and retrospectives, and if someone spent a week working on completely useless code, we try to understand why this happened.



Sometimes the problem is technical. We can spend too much time on scripting or configuring. This means that we need to achieve greater automation. If we have real reasons for using copy-paste, we try to divide its embedding in the project equally among all participants.

Internal tools usually make work boring.

We, as developers, like to create our own internal tools for solving specific problems, because for us creating something new is an exciting process. In addition, the creation of tailored solutions often means a cleaner approach than trying to adapt existing tools to these needs. However, the study of other people's closed solutions seems to us 10 times less exciting than the study of popular technologies with open source.

Why?

Because you can not discuss proprietary tools with friends. You can not boast that you know them. They will not be written on blogs, and besides, they cannot be used on hackathons or to work on their secret third-party project.

Nevertheless, many companies fall into the trap of creating something that later only adds to despondency and is therefore not worth the effort. I’m talking about development that saves you from short-term anxiety only to bring even more anxiety later.

I learned it from my previous experience at a previous job where I had to use an object-oriented language developed internally for large-scale data integration. What I actually had to study, it is possible, albeit with a little exaggeration, to be called the next SQL jargon. With a much greater desire, I would prefer to study and use some low-level open technology like Spark, because in this case I would be 10 times more involved, and even if my code were 2 times more redundant, it would be would make me 5 times more productive.

What should be the culture in the company to prevent such situations?

We try to maintain a strong bias towards open source technologies. If we have the opportunity to use something interesting, directly related to the problem and invented earlier, we do so. We do not avoid the newest solutions, and replace our own code with similar open technologies as soon as they become mature enough to replace it. We also open our source code as soon as they lose their uniqueness.

Errors happen from time to time. For example, for some time we used the agenda.js library for scheduling tasks on the server side, because we considered it modern and interesting. However, in our case, it turned out that it complicates everything, so it was decided to return to the old, but more reliable technology - the good old cron. Nevertheless, we do not regret this experiment, because for us it was a valuable experience.

How monkey-coding makes you boring

Another common cause of loss of interest in work is poor management of people. I mean the top-down management structure, which is used in the developer environment and often leads to higher dictatorships.

Sometimes the leaders, without even realizing it, use just such an approach, making it out of good intentions. This happens especially often when things are not going very well in the project, or when the deadline is approaching. This is a natural reaction of a person under pressure - try to interrupt discussions, minimize brainstorms, instead giving the subordinates direct instructions about what needs to be done, without any arguments or explanations. Of course, all this is done to save time and get the necessary result.

Not necessarily a subordinate, who understands the situation with understanding, will be dissatisfied with what is happening. In fact, some will even be happy from time to time to receive specific instructions on what to do, because it simplifies the workflow. All this, of course, provided that such instructions are given in an appropriate manner.

Nevertheless, this approach has its hidden costs. Knowing exactly which code to write, even before the work itself begins, makes programming from an intellectual and creative process into a purely mechanical one. In other words, the “developer” is transformed into “decoder decoys”.

At the same time, an active developer involved in the process, on the contrary, tries to grasp the essence of why it should be done this way and not otherwise, if, of course, this is not about such obvious things as a temporary patch or hack to bypass the borderline case. . But if he begins to understand that he is indifferent to certain important decisions and the reasons behind them, then it is time for him to change his work.

How to prevent such a situation?

The main thing for this is a culture that encourages open discussion. Create a platform for regular discussions, where you will work together as a team to develop strategies and make plans. Ensuring that this culture is preserved is the business of each team member. It is in the most difficult times that the wards should speak louder, and their heads should listen carefully.

Daily routine always gets boring

And last but not least. There is no better way to kill interest and enthusiasm than to put yourself in a closed space and do some routine activity.

This problem is encountered not only in software development or in the technical field: it is characteristic of any office work. Every day you are in the same room, with the same people, performing the same job duties, and all this in an environment that almost does not change ... And even if the work space expands quickly, and its internal stability is objectively useful, people anyway, they start to take all the good things for granted and get annoyed because they don’t like it.

How are we fighting this?

A key component of prevention is diversity. We hire people with different backgrounds and backgrounds. Our current team consists of 6 people, among whom there are representatives of Britain, France, Russia and Greece. Seeing the same people every day is definitely much more interesting if each of them can bring something new to the common culture.

We also try to diversify our daily activities and go beyond the usual working pattern.

For example, we go to public meetings and hakatons together. We have third-party projects and, in addition, we are contributing to the development of our favorite open-source tools. From time to time we even help the rest of the non-core work team, such as hiring, marketing, distributing products. Of course, one cannot say that we understand all this, but we do it just for a change.

In addition, we go somewhere with the whole team (in Secret Cinema, for example), and also conduct a weekly “Enkiton” (Enki + hackaton) without any previously agreed program. Sometimes during such meetings we sort out something together, or “storm” a new idea. Sometimes we just play League of Legends or go to the pub. The beauty is that we do not know until the very last moment what we will do until we decide together.

A little chaos - the last ingredient in our recipe against boredom. And like any other recipe, it can be improved infinitely. If something is not so easy to change the ingredients, or their proportions and try again.

As you can see, the recipe for “fun coding” is open and simple. Whether you are the leader of your team or an ordinary employee, you have the power to make your work more efficient and interesting. Develop, strive for new goals, do not dwell on one task, especially if the work on it does not bring the proper result. From time to time, switch attention to other projects. Analyze your work, it is better collectively, so you will quickly find "problem areas". Do not be afraid to express new ideas, be creative, otherwise programming will turn into a mechanical process, and this is simply boring. And of course it’s difficult to be a cohesive team without having other points of contact, except that you work in the same company. Change the situation, get out with your colleagues to rest, explore new horizons together, and you will hardly want to leave.

Material for publication prepared by PayOnline, an international system for receiving electronic payments. If you need to organize the reception of payments on the site, feel free to contact . Also subscribe to our corporate blog , there are still many interesting posts ahead.