Managing a team of programmers: how and what motivates them correctly? Part one
Epigraph:
A husband, looking at dirty children, says to his wife: well, what, shall we wash these or new ones?
Under the cut is the discussion of our team leader, as well as RAS Product Development Director - Igor Marnat about the features of programmer motivation.
The secret of success in creating cool software products is known - take a team of cool programmers, give the team a cool idea and do not interfere with the team to work. Cool developers - guys are rare and popular. Some recruiters even say that they have the impression that it is easier to give birth to a tough programmer than to hire him from the market. In addition to difficulties in hiring, as such, the experience of each particular developer, his knowledge of the existing product and the history of its development are often irreplaceable or replenished hard and long. Therefore, if you are lucky and you already have a cool team of programmers, it is important to work on their motivation. Hiring, training new developers, making a team of them is almost as difficult and long as giving birth and raising children.
Consider the main factors of programmer motivation (team of programmers), using Maslow's pyramid for clarity and structuring the presentation. If suddenly you have not heard of Maslow's pyramid, this is not the indisputable, but very popular and visual theory of the American psychologist Abraham Harold Maslow, who proposed a theory of personality motivation based on a hierarchy of human needs (see picture below).
')
Maslow arranged the needs of the individual in a hierarchical order, from physiological needs to the need for disclosure of potential and self-actualization. A key assumption in Maslow’s theory is: “a person cannot experience the needs of a higher level until his needs of a lower level are satisfied”. For example, a person cannot be driven by a need for knowledge or aesthetic needs, if this person has not slept or eaten for three days.
Before we delve into the details, let us dwell on the obvious fact - the team consists of people, all people are different, each has its own motivation structure. In addition, each person is driven by different interests, each person is also in different living conditions. Someone is at the beginning of a career and is thinking about how to build it, someone is going to get married, and someone wants to master a new subject area. What is important for one is completely unimportant for the other, but tomorrow everything will change again. In order to properly understand this context, there is a simple means - you need to think about it and need to work with it. The most important is communication.
Be sure to talk with your team about something other than work, build informal relationships.
So now let's go through Maslow's pyramid and consider its levels as applied to managing a team of programmers.
I: Physiological, biological needs:
Speaking of motivation, many, in the first place, often think about salary. Under salary in this case, I understand the permanent part of the compensation package, which does not depend on the results. This does not apply to bonuses, bonuses and company shares. I would refer the salary to the level of “physiological needs” in our case. Bonuses, awards for performance, options and company shares - all of this I would have attributed to other levels.
In my opinion, however strange it may sound, salary can be a demotivating factor rather than a motivating factor. The peculiarity of working with programmers is that they are all people, firstly, they are very clever (profession feature), secondly, they are deeply and / or widely educated. Usually, in addition to their profession, programmers have a deep understanding of one or more subject areas for which they create products. In addition, good programmers are interested and well know the history of the development of programming, algorithms, standards, etc. The same applies to their subject area. For people of this level, salary is usually not the main motivating factor.
At the same time, the absence of a programmer's salary fair in their understanding demotivates, and demotivates strongly. Having a fair salary is the norm. Salary is much higher than the norm (market) - also, oddly enough, the factor is rather demotivating. One colleague once told me about a team of programmers in one of the large animated American companies, which, due to a number of circumstances, received salaries at the level of two to three times the market. As he said, he had never seen more bored, lazy and demotivated programmers in his life. The fact of a salary increase can be motivated in the short term, but after a few months the new salary becomes the norm and stops motivating. In general, I would say, for programmers at the beginning of a career, the salary factor is more important, as they grow and develop - its importance decreases, and other factors begin to prevail.
The second important point is the presence of a fair balance in the level of salaries in a team. If the team feels that the contribution of one of the participants is noticeably lower, but the level of compensation is not different, it will demotivate the whole team. Sometimes managers are tempted to pour fire with money - to keep a burned-out or demotivated person, raising his salary above the norm. This usually only creates problems in the long run - the motivation of the person does not particularly grow, or grows up for a couple of months, but the motivation of the rest of the team will fall. In such situations, it is worth looking for other approaches, if, of course, it is not a unique specialist who needs to be retained at any cost, even for a short time.
Ii. The need for security, comfort, consistency of living conditions:
70 years ago, the presence of a stove in a car could be a motivating factor when choosing a car, then it was above the norm, it was a sign of luxury. Now, even the absence of an air conditioner is nonsense, and its presence, of course, will not be a motivating factor when choosing a car. So 10-15 years ago, a comfortable office, good iron, delicious coffee, fitness, flexible hours, etc. Could be good motivating factors, now it’s probably the norm for a good programmer’s work. At the same time, their absence, again, will demotivate.
An important demotivating factor is the lack of concentration, a noisy working environment. The work of a programmer requires silence and concentration. If office space does not provide an opportunity to provide developers with a lonely workplace, it is necessary to at least ensure a comfortable joint work of colleagues who do not interfere with each other. Energetic and vociferous comrades better to combine with each other, giving an opportunity to focus those who need it.
The cost of a programmer’s time is now noticeably higher than the cost of the hardware on which he works. Two or three monitors, powerful computers, a convenient workplace for each developer should be the norm in any company. This topic is well covered in one of Joel Spolsky’s “ The Joel Test: 12 steps to better code” articles .
The physical component of comfort is the most basic and simple, now let's talk about the rest.
In many companies, flexible working hours and lack of dress code are the norm for programmers. This is good and correct if the peculiarities of the team's work allow (for example, there are no meetings with customers, politicians or bankers).
The important point is the presence of a certain window of time when the whole team works together locally, so that people can communicate and resolve issues in personal communication. The programmer, in essence, does not leave work even after work. Usually working moments scroll in his mind, regardless of the presence in the office, and good decisions often come out of it. Taking into account the need to be good (which we will dwell on below), petty control is harmful. Not only does he demotivate, he also reduces productivity. As practice shows, in the absence of control, a motivated team is more likely to work longer than necessary. With control, developers can sit at the keyboard from nine to six, but I think the result will be worse. As they say, one person can bring a horse to a watering place, but even a hundred will not make him drink if he does not want.
The description of this level of needs also mentions freedom from anxiety and fear, the absence of chaos, the need for structure and order. These are also extremely important points that strongly influence the atmosphere in the team.
First, the absence of chaos, structure and order - the team must understand who is responsible for what, how roles are distributed, what to do, to whom, when, what requirements underlie the product, what are the expectations of the authorities and the customer ... Most of this should be formally described, everything should be periodically discussed. Without discussion and periodic use descriptions do not work. It is good practice to periodically discuss and update them on the results of postmortem analysis after release.
Secondly, the calm and friendly atmosphere. We all spend at work most of the time, and we want to do it without stress, conflict, fear. The development team usually works under pressure from schedules and customers. Additional stress from colleagues and bosses is not needed by anyone. The atmosphere in a team, in general, the very fact that a group of developers can be called and be a “team” is the direct and important responsibility of a manager, one of the most important mid-term and long-term tasks. Therefore, it is important for the manager to work, in particular, with conflicts in the team, not to let their development take its course. Conflict management is a separate topic that deserves a separate study.
There are two main ways to influence the emotional state of the team, the behavior of colleagues (if someone adds in the comments - it will be fine). The first is your own behavior. A personal example is super important for a manager and a team. As the saying goes, what a pop, so is the parish. Behave as you expect your colleagues to behave. The second is the promotion of correct behavior, and, so to speak, de-promotion of the wrong. Communicate with people, give them feedback, there are many ways to do it. Generally, feedback is a topic for a separate conversation, it is a big and important part of working with motivation.
Another remark about the atmosphere, which may seem unusual, but in practice it is important. More often than not, there are fewer girls in the development team than men. Often the teams are completely male. Under such conditions, even under load, sometimes obscene vocabulary begins to be used in a team. Practice shows that this affects the atmosphere negatively, communication gradually becomes rude. You should avoid using it yourself and not encouraging its use in a team.
Development teams are often called R & D (research and development), and research is a significant part of the work. This is the part that is usually difficult to program and plan, otherwise it would not be research. It is important that the team had the right to make a mistake, to take the initiative, to test various options that may or may not end in success. Mistakes are a normal part of work, they cannot be avoided, but you can study, analyze, learn from them for the future and move on. Principle 5 why's, which originated in Toyota, well helps to get to the original cause of the problem. Punishing mistakes is a great way to create an atmosphere of fear and uncertainty. The only exception is when according to the results of the analysis it turns out that the error is caused by an unprofessional attitude to work, in that case, it may be necessary to make personnel decisions.
The atmosphere in the team is greatly influenced by your expectations, emotional state before the start of the conversation. Before the start of a difficult discussion, some sort of debriefing or just an emotional conversation, your attitude and attitude towards the person with whom you are going to speak is important. I always think by default and act on the basis of what a person sincerely tried to do as best. If from your position it seems that this is not so - you need to calmly and thoroughly find out the context and understand what he did right, why he thought it was right, and where our expectations diverge. It usually turns out that they don’t really differ, just his vision of the context is more complete or fresh, and you didn’t know something. Or, on the contrary, he did not know something. This is especially important in a distributed team, when people rarely communicate in person, use mail and instant messengers. Even more, this is critical in a team of programmers from different countries and distributed between different time zones. Here, cultural differences are beginning to play a big role.
In a difficult situation it is easy to drive on the move, very simple, but then it is hard to drive back then, and the sediment remains for a long time. I will give a simple example from recent experience. One of the managers of the team urgently needed comments about a problem for a customer from a manager from an adjacent team from another country. He pinged a colleague in the messenger, waited 15 minutes, pinged again, then 15 minutes later he went to a large chat room in which there were other managers, and slightly hit a colleague, with a wording like: “since you don’t deign to answer me, and the question is not so urgent? ”. As a result, it turned out that our corporate messenger was slightly blunted, and my colleague did not see the question at all. I had to apologize. In general, it is better to proceed from the good. To make a mistake in the bad direction and always succeed in driving later, there are no problems with this (although it is not worth doing this). In general, for more than 20 years of work in our industry, I have met a really malicious colleague just one (!) Time. Fortunately, we broke up pretty quickly. To proceed from the fact that colleagues want the best, to the best of their vision of the context, is correct in the vast majority of cases.
As a manager, your task is to ensure synchronization of contexts, a common understanding of expectations, requirements, deadlines, standards adopted by the team. This may seem trifles, but the atmosphere in the team is built from such trifles. From the point of view of a distributed team, one of the important tasks is to provide periodic personal communication between team members. I have often heard from programmers that after, for example, the engineers of the support team came to them and worked together personally, they gladly stayed at work to help Pasha, who had recently visited them, in a difficult case, although earlier Pasha was just an icon in the messenger, and no one would have to linger for the sake of the icon.
By the way, I started talking about the support team and remembered the canonical example for me. Somehow, one of the customers in America had a problem with the product, one of the engineers of the support team who worked on his implementation (sent from Russia) remained after work to help, but the problem was not solved and was not solved. In general, he lingered and sat there almost until the morning. At this time, the managers of the customer escalated the problem, identified its criticality for them and left work in the evening. The escalation process was gaining momentum in another time zone, support managers in Russia began to try to help, due to certain difficulties in communicating with the customer’s office (VPN, communication problems, difficulties with calls between countries, ...) they did not know that the guy was already sitting in the office and decides the question, and tried to find him. Found only in the morning (American), when the question was already practically solved by him, and the product earned. From the quarry they began to run down, what the hell, such an escalation of the customer, nothing works, where you are carried, we cannot find you, etc. Needless to say, as a result of this behavior, the guy was very demotivated. The organization of a distributed team is a separate big topic, but it is important to keep two things in mind. First of all, communication, atmosphere - this is very important, the success of the work depends on it. Secondly, it does not work by itself, it must be dealt with separately and in depth.
Another important point relating to this level of needs is again a salary. Not the size of the salary, as such, but the presence of a certain order of its change. The company should have an approach to determining the requirements for positions at different levels. Each developer should be able to discuss expectations for his work with the company, to understand how he and when his efforts can affect his salary. Periodic meetings with the manager, semi-annual or annual appraisals serve this purpose. This, again, is one of those moments whose presence does not motivate explicitly, but their absence demotivates strongly.
From the need for order and the presence of rules, there is a need to follow these rules, follow the standards adopted in the team, both formal and informal. In summary, I would call it the need to be good. The presence of this need confirms that micromanagement is not needed, rather is harmful. It is enough to provide a person with everything necessary for work, to give him knowledge of the context, priorities, and provide freedom of action and decision-making at his level. , , .
, — , . . . , , . , , . — , , , . “ Google — Site Reliability Engineering ”, , , , , .
To be continued...
A husband, looking at dirty children, says to his wife: well, what, shall we wash these or new ones?
Under the cut is the discussion of our team leader, as well as RAS Product Development Director - Igor Marnat about the features of programmer motivation.
The secret of success in creating cool software products is known - take a team of cool programmers, give the team a cool idea and do not interfere with the team to work. Cool developers - guys are rare and popular. Some recruiters even say that they have the impression that it is easier to give birth to a tough programmer than to hire him from the market. In addition to difficulties in hiring, as such, the experience of each particular developer, his knowledge of the existing product and the history of its development are often irreplaceable or replenished hard and long. Therefore, if you are lucky and you already have a cool team of programmers, it is important to work on their motivation. Hiring, training new developers, making a team of them is almost as difficult and long as giving birth and raising children.
Consider the main factors of programmer motivation (team of programmers), using Maslow's pyramid for clarity and structuring the presentation. If suddenly you have not heard of Maslow's pyramid, this is not the indisputable, but very popular and visual theory of the American psychologist Abraham Harold Maslow, who proposed a theory of personality motivation based on a hierarchy of human needs (see picture below).
')
Maslow arranged the needs of the individual in a hierarchical order, from physiological needs to the need for disclosure of potential and self-actualization. A key assumption in Maslow’s theory is: “a person cannot experience the needs of a higher level until his needs of a lower level are satisfied”. For example, a person cannot be driven by a need for knowledge or aesthetic needs, if this person has not slept or eaten for three days.
Before we delve into the details, let us dwell on the obvious fact - the team consists of people, all people are different, each has its own motivation structure. In addition, each person is driven by different interests, each person is also in different living conditions. Someone is at the beginning of a career and is thinking about how to build it, someone is going to get married, and someone wants to master a new subject area. What is important for one is completely unimportant for the other, but tomorrow everything will change again. In order to properly understand this context, there is a simple means - you need to think about it and need to work with it. The most important is communication.
Be sure to talk with your team about something other than work, build informal relationships.
So now let's go through Maslow's pyramid and consider its levels as applied to managing a team of programmers.
I: Physiological, biological needs:
Speaking of motivation, many, in the first place, often think about salary. Under salary in this case, I understand the permanent part of the compensation package, which does not depend on the results. This does not apply to bonuses, bonuses and company shares. I would refer the salary to the level of “physiological needs” in our case. Bonuses, awards for performance, options and company shares - all of this I would have attributed to other levels.
In my opinion, however strange it may sound, salary can be a demotivating factor rather than a motivating factor. The peculiarity of working with programmers is that they are all people, firstly, they are very clever (profession feature), secondly, they are deeply and / or widely educated. Usually, in addition to their profession, programmers have a deep understanding of one or more subject areas for which they create products. In addition, good programmers are interested and well know the history of the development of programming, algorithms, standards, etc. The same applies to their subject area. For people of this level, salary is usually not the main motivating factor.
At the same time, the absence of a programmer's salary fair in their understanding demotivates, and demotivates strongly. Having a fair salary is the norm. Salary is much higher than the norm (market) - also, oddly enough, the factor is rather demotivating. One colleague once told me about a team of programmers in one of the large animated American companies, which, due to a number of circumstances, received salaries at the level of two to three times the market. As he said, he had never seen more bored, lazy and demotivated programmers in his life. The fact of a salary increase can be motivated in the short term, but after a few months the new salary becomes the norm and stops motivating. In general, I would say, for programmers at the beginning of a career, the salary factor is more important, as they grow and develop - its importance decreases, and other factors begin to prevail.
The second important point is the presence of a fair balance in the level of salaries in a team. If the team feels that the contribution of one of the participants is noticeably lower, but the level of compensation is not different, it will demotivate the whole team. Sometimes managers are tempted to pour fire with money - to keep a burned-out or demotivated person, raising his salary above the norm. This usually only creates problems in the long run - the motivation of the person does not particularly grow, or grows up for a couple of months, but the motivation of the rest of the team will fall. In such situations, it is worth looking for other approaches, if, of course, it is not a unique specialist who needs to be retained at any cost, even for a short time.
Ii. The need for security, comfort, consistency of living conditions:
70 years ago, the presence of a stove in a car could be a motivating factor when choosing a car, then it was above the norm, it was a sign of luxury. Now, even the absence of an air conditioner is nonsense, and its presence, of course, will not be a motivating factor when choosing a car. So 10-15 years ago, a comfortable office, good iron, delicious coffee, fitness, flexible hours, etc. Could be good motivating factors, now it’s probably the norm for a good programmer’s work. At the same time, their absence, again, will demotivate.
An important demotivating factor is the lack of concentration, a noisy working environment. The work of a programmer requires silence and concentration. If office space does not provide an opportunity to provide developers with a lonely workplace, it is necessary to at least ensure a comfortable joint work of colleagues who do not interfere with each other. Energetic and vociferous comrades better to combine with each other, giving an opportunity to focus those who need it.
The cost of a programmer’s time is now noticeably higher than the cost of the hardware on which he works. Two or three monitors, powerful computers, a convenient workplace for each developer should be the norm in any company. This topic is well covered in one of Joel Spolsky’s “ The Joel Test: 12 steps to better code” articles .
The physical component of comfort is the most basic and simple, now let's talk about the rest.
In many companies, flexible working hours and lack of dress code are the norm for programmers. This is good and correct if the peculiarities of the team's work allow (for example, there are no meetings with customers, politicians or bankers).
The important point is the presence of a certain window of time when the whole team works together locally, so that people can communicate and resolve issues in personal communication. The programmer, in essence, does not leave work even after work. Usually working moments scroll in his mind, regardless of the presence in the office, and good decisions often come out of it. Taking into account the need to be good (which we will dwell on below), petty control is harmful. Not only does he demotivate, he also reduces productivity. As practice shows, in the absence of control, a motivated team is more likely to work longer than necessary. With control, developers can sit at the keyboard from nine to six, but I think the result will be worse. As they say, one person can bring a horse to a watering place, but even a hundred will not make him drink if he does not want.
The description of this level of needs also mentions freedom from anxiety and fear, the absence of chaos, the need for structure and order. These are also extremely important points that strongly influence the atmosphere in the team.
First, the absence of chaos, structure and order - the team must understand who is responsible for what, how roles are distributed, what to do, to whom, when, what requirements underlie the product, what are the expectations of the authorities and the customer ... Most of this should be formally described, everything should be periodically discussed. Without discussion and periodic use descriptions do not work. It is good practice to periodically discuss and update them on the results of postmortem analysis after release.
Secondly, the calm and friendly atmosphere. We all spend at work most of the time, and we want to do it without stress, conflict, fear. The development team usually works under pressure from schedules and customers. Additional stress from colleagues and bosses is not needed by anyone. The atmosphere in a team, in general, the very fact that a group of developers can be called and be a “team” is the direct and important responsibility of a manager, one of the most important mid-term and long-term tasks. Therefore, it is important for the manager to work, in particular, with conflicts in the team, not to let their development take its course. Conflict management is a separate topic that deserves a separate study.
There are two main ways to influence the emotional state of the team, the behavior of colleagues (if someone adds in the comments - it will be fine). The first is your own behavior. A personal example is super important for a manager and a team. As the saying goes, what a pop, so is the parish. Behave as you expect your colleagues to behave. The second is the promotion of correct behavior, and, so to speak, de-promotion of the wrong. Communicate with people, give them feedback, there are many ways to do it. Generally, feedback is a topic for a separate conversation, it is a big and important part of working with motivation.
Another remark about the atmosphere, which may seem unusual, but in practice it is important. More often than not, there are fewer girls in the development team than men. Often the teams are completely male. Under such conditions, even under load, sometimes obscene vocabulary begins to be used in a team. Practice shows that this affects the atmosphere negatively, communication gradually becomes rude. You should avoid using it yourself and not encouraging its use in a team.
Development teams are often called R & D (research and development), and research is a significant part of the work. This is the part that is usually difficult to program and plan, otherwise it would not be research. It is important that the team had the right to make a mistake, to take the initiative, to test various options that may or may not end in success. Mistakes are a normal part of work, they cannot be avoided, but you can study, analyze, learn from them for the future and move on. Principle 5 why's, which originated in Toyota, well helps to get to the original cause of the problem. Punishing mistakes is a great way to create an atmosphere of fear and uncertainty. The only exception is when according to the results of the analysis it turns out that the error is caused by an unprofessional attitude to work, in that case, it may be necessary to make personnel decisions.
The atmosphere in the team is greatly influenced by your expectations, emotional state before the start of the conversation. Before the start of a difficult discussion, some sort of debriefing or just an emotional conversation, your attitude and attitude towards the person with whom you are going to speak is important. I always think by default and act on the basis of what a person sincerely tried to do as best. If from your position it seems that this is not so - you need to calmly and thoroughly find out the context and understand what he did right, why he thought it was right, and where our expectations diverge. It usually turns out that they don’t really differ, just his vision of the context is more complete or fresh, and you didn’t know something. Or, on the contrary, he did not know something. This is especially important in a distributed team, when people rarely communicate in person, use mail and instant messengers. Even more, this is critical in a team of programmers from different countries and distributed between different time zones. Here, cultural differences are beginning to play a big role.
In a difficult situation it is easy to drive on the move, very simple, but then it is hard to drive back then, and the sediment remains for a long time. I will give a simple example from recent experience. One of the managers of the team urgently needed comments about a problem for a customer from a manager from an adjacent team from another country. He pinged a colleague in the messenger, waited 15 minutes, pinged again, then 15 minutes later he went to a large chat room in which there were other managers, and slightly hit a colleague, with a wording like: “since you don’t deign to answer me, and the question is not so urgent? ”. As a result, it turned out that our corporate messenger was slightly blunted, and my colleague did not see the question at all. I had to apologize. In general, it is better to proceed from the good. To make a mistake in the bad direction and always succeed in driving later, there are no problems with this (although it is not worth doing this). In general, for more than 20 years of work in our industry, I have met a really malicious colleague just one (!) Time. Fortunately, we broke up pretty quickly. To proceed from the fact that colleagues want the best, to the best of their vision of the context, is correct in the vast majority of cases.
As a manager, your task is to ensure synchronization of contexts, a common understanding of expectations, requirements, deadlines, standards adopted by the team. This may seem trifles, but the atmosphere in the team is built from such trifles. From the point of view of a distributed team, one of the important tasks is to provide periodic personal communication between team members. I have often heard from programmers that after, for example, the engineers of the support team came to them and worked together personally, they gladly stayed at work to help Pasha, who had recently visited them, in a difficult case, although earlier Pasha was just an icon in the messenger, and no one would have to linger for the sake of the icon.
By the way, I started talking about the support team and remembered the canonical example for me. Somehow, one of the customers in America had a problem with the product, one of the engineers of the support team who worked on his implementation (sent from Russia) remained after work to help, but the problem was not solved and was not solved. In general, he lingered and sat there almost until the morning. At this time, the managers of the customer escalated the problem, identified its criticality for them and left work in the evening. The escalation process was gaining momentum in another time zone, support managers in Russia began to try to help, due to certain difficulties in communicating with the customer’s office (VPN, communication problems, difficulties with calls between countries, ...) they did not know that the guy was already sitting in the office and decides the question, and tried to find him. Found only in the morning (American), when the question was already practically solved by him, and the product earned. From the quarry they began to run down, what the hell, such an escalation of the customer, nothing works, where you are carried, we cannot find you, etc. Needless to say, as a result of this behavior, the guy was very demotivated. The organization of a distributed team is a separate big topic, but it is important to keep two things in mind. First of all, communication, atmosphere - this is very important, the success of the work depends on it. Secondly, it does not work by itself, it must be dealt with separately and in depth.
Another important point relating to this level of needs is again a salary. Not the size of the salary, as such, but the presence of a certain order of its change. The company should have an approach to determining the requirements for positions at different levels. Each developer should be able to discuss expectations for his work with the company, to understand how he and when his efforts can affect his salary. Periodic meetings with the manager, semi-annual or annual appraisals serve this purpose. This, again, is one of those moments whose presence does not motivate explicitly, but their absence demotivates strongly.
From the need for order and the presence of rules, there is a need to follow these rules, follow the standards adopted in the team, both formal and informal. In summary, I would call it the need to be good. The presence of this need confirms that micromanagement is not needed, rather is harmful. It is enough to provide a person with everything necessary for work, to give him knowledge of the context, priorities, and provide freedom of action and decision-making at his level. , , .
, — , . . . , , . , , . — , , , . “ Google — Site Reliability Engineering ”, , , , , .
To be continued...
Source: https://habr.com/ru/post/452598/
All Articles