On the culture of development in groups of programmers
“Why is everything so bad?” - every time I ask myself this question when I have to deal with another code, product or API created for internal needs in a non-core organization.
In profile, things are better, but far from always: in boxed replicated solutions are often better than in design development. In products of one customer, usually, the worst of all.
And money does not solve anything: terrible code and terrible products are written by both small poor universities, which have enough money only for the slave labor of graduate students, and large and rich companies, including IT companies, including foreign ones: several times they encountered the code that they wrote foreign contractors and every time he wanted to sob and beat his head against the wall.
')
An organization can declare strict standards, hire costly developers, impose regulations and methodologies, puff up cheeks at meetings, and publicly denounce the “wrong decision” in someone else's product. And continue to make terrible products with terrible code, contrary to the high qualifications of their developers and very correct and necessary regulations and standards.
I have been developing software in several organizations and for various reasons, I rebuilt the team several times from scratch. As a result, I came to the conclusion that the quality of the product depends only on the culture of development. Everything else, including methodologies and standards, are tools: they are necessary, but they are not enough.
The culture of the development can be compared with the ecosystem: as a garden or aquarium. A strong, healthy culture has a margin of safety to heal the inhabitants of the ecosystem, get rid of pests, forgive small errors of care, smooth out stress, and still get excellent results at the output. A sick culture negates all efforts, infects and destroys even the healthiest and strongest seedlings.
When a new engineer comes to a team with an established development culture, he either accepts the culture, or the team rejects it. It is almost impossible to settle down and parasitize on a team with a healthy development culture - it instantly calculates untrained, lazy and indifferent developers. At first they will try to instruct, explain, teach, and then your staff will be pulled to you one by one “to talk about a new colleague”. Conversely, those who are passionate about their work, ready to develop and cooperate, such a team welcomes them and now they already go out together for lunch, socialize outside of work, get to know their families, invite each other to their home events and help with household chores.
Culture can not be bought or stolen, lured by the developer. As it is impossible to take a fruit-bearing tree from the garden: if it survives the transplant, you will not wait for the previous harvests.
Culture can not enter the order. This is a daily work, creating a microclimate, tracking parameters, training, mentoring. As soon as a running aquarium requires constant monitoring of water parameters, gradual but timely settlement, flexible adjustment of lighting, aeration, fertilizer and microorganism parameters. But then, when the culture gets stronger and stabilizes, it will start working for you.
If culture is not engaged, it will form itself and most likely it will be a destructive, unhealthy culture.
The larger the ecosystem, the more stable its culture. If you have 1-2 developers, the development culture degrades very quickly despite all the efforts. The minimum number of team developers to form a stable positive culture in it is 3-5 people.
I have repeatedly observed how the development culture is rapidly degrading, with less than three programmers remaining. Yesterday, great developers are starting to write such a terrible code that after restoring the team and culture, it has to be completely rewritten.
Even in large and stable teams, an established culture can be easily destroyed, provoking its degradation, with wrong organizational decisions: incorrectly built motivation, connivance, demands mindlessly submitting to the decision without explaining and convincing of its expediency, constant burning tasks that need to be “done yesterday and no matter how ", decisions like" to do something urgently, and then redo it in the normal way. "
Large groups with a developed destructive culture will violently resist change. Reject or sabotage standards and regulations, or abide by with poor quality results.
I came across the following signs of a destructive culture:
- Indifference: “I do as I was told,” “they don’t pay me for it”, “the main thing is that it works at the delivery-acceptance”.
- Angry sarcasm and harassment in the team.
- Hatred of the customer and the user: “the letters are filled with the hoof,” “misuse the product”, “miser”, “they themselves do not know what they want”.
- Hatred of leadership: "Incompetent exploiters."
- Hatred of colleagues: "Krivoruky fools."
- Sabotage through diligence: “Give me a clear task and give instructions on how to execute it”, “This procedure is not spelled out in the regulations”, etc.
- A thoughtless fulfillment of wishes by the customer: “I was told - I did. There is no time for documenting, commenting, designing and other nonsense. The customer wants everything to work exactly as he requested, in the cheapest and fastest way. The customer did not say anything about the development, maintainability and upgradeability. ”
- Excessive concentration on external functionality: "The main thing is to work."
- Excessive concentration on architecture, to the detriment of functionality: "From the point of view of architecture, entering all this data in one window cannot be done."
All these signs, like weeds, constantly appear even in a healthy team. It is necessary to control their growth, to conduct explanations, to discuss the motivation and emotions of other project participants, in order to develop understanding and empathy. Explain or provide an opportunity to face the consequences of ill-considered decisions, so that the importance of certain rules is reinforced by personal experience.
From my experience, the easiest way to grow a culture is to start with 3 developers with whom you need to communicate daily and continuously, watch the code together, discuss all architectural solutions. Then, when the developers start to make the right decisions themselves, it is necessary to weaken the control - this cannot be delayed, otherwise you will grow up “mindless robots” and will constantly engage in petty care.
After that, you need to add at least two more and see how they adapt. Adjust this process: talk with the developers so that they do not take newcomers to bayonets, treat them kindly, but also don't upset them.
New people are better to add one by one. So they will not have the opportunity to withdraw from each other and organize a mini-party inside the team. Mini-party trainees are dangerous because they oppose themselves to the team. They are constantly looking for what they have been cheated of, as in the joke about the greedy blind girl, whom her parents welded a whole bowl of dumplings (“I can imagine how much they nafigachili”).
It is more convenient for me to hire juniors: their training takes longer, but they are easier to adapt to the culture, less likely to begin to resist and try to destroy it. The main thing is to track the moment when the junior grew up and raise his salary, otherwise you will lose it: to raise the salary, when the person came with a statement, more often than not, he had already made a decision, made a job offer. Even if he stays, the “mobility charge” will fire again in the coming months. Trying to save on salary, delaying the increase after the growth of competence and market value - a bad tactic, besides, it has a bad effect on the culture of development.
To form a healthy culture of development is troublesome and slow. But efforts pay off a hundredfold and the quality of the code, and loyalty, and simplifying the adaptation of new employees. Therefore, it is definitely worth it.
In profile, things are better, but far from always: in boxed replicated solutions are often better than in design development. In products of one customer, usually, the worst of all.
And money does not solve anything: terrible code and terrible products are written by both small poor universities, which have enough money only for the slave labor of graduate students, and large and rich companies, including IT companies, including foreign ones: several times they encountered the code that they wrote foreign contractors and every time he wanted to sob and beat his head against the wall.
')
An organization can declare strict standards, hire costly developers, impose regulations and methodologies, puff up cheeks at meetings, and publicly denounce the “wrong decision” in someone else's product. And continue to make terrible products with terrible code, contrary to the high qualifications of their developers and very correct and necessary regulations and standards.
I have been developing software in several organizations and for various reasons, I rebuilt the team several times from scratch. As a result, I came to the conclusion that the quality of the product depends only on the culture of development. Everything else, including methodologies and standards, are tools: they are necessary, but they are not enough.
The culture of the development can be compared with the ecosystem: as a garden or aquarium. A strong, healthy culture has a margin of safety to heal the inhabitants of the ecosystem, get rid of pests, forgive small errors of care, smooth out stress, and still get excellent results at the output. A sick culture negates all efforts, infects and destroys even the healthiest and strongest seedlings.
When a new engineer comes to a team with an established development culture, he either accepts the culture, or the team rejects it. It is almost impossible to settle down and parasitize on a team with a healthy development culture - it instantly calculates untrained, lazy and indifferent developers. At first they will try to instruct, explain, teach, and then your staff will be pulled to you one by one “to talk about a new colleague”. Conversely, those who are passionate about their work, ready to develop and cooperate, such a team welcomes them and now they already go out together for lunch, socialize outside of work, get to know their families, invite each other to their home events and help with household chores.
Culture can not be bought or stolen, lured by the developer. As it is impossible to take a fruit-bearing tree from the garden: if it survives the transplant, you will not wait for the previous harvests.
Culture can not enter the order. This is a daily work, creating a microclimate, tracking parameters, training, mentoring. As soon as a running aquarium requires constant monitoring of water parameters, gradual but timely settlement, flexible adjustment of lighting, aeration, fertilizer and microorganism parameters. But then, when the culture gets stronger and stabilizes, it will start working for you.
If culture is not engaged, it will form itself and most likely it will be a destructive, unhealthy culture.
The larger the ecosystem, the more stable its culture. If you have 1-2 developers, the development culture degrades very quickly despite all the efforts. The minimum number of team developers to form a stable positive culture in it is 3-5 people.
I have repeatedly observed how the development culture is rapidly degrading, with less than three programmers remaining. Yesterday, great developers are starting to write such a terrible code that after restoring the team and culture, it has to be completely rewritten.
Even in large and stable teams, an established culture can be easily destroyed, provoking its degradation, with wrong organizational decisions: incorrectly built motivation, connivance, demands mindlessly submitting to the decision without explaining and convincing of its expediency, constant burning tasks that need to be “done yesterday and no matter how ", decisions like" to do something urgently, and then redo it in the normal way. "
Large groups with a developed destructive culture will violently resist change. Reject or sabotage standards and regulations, or abide by with poor quality results.
I came across the following signs of a destructive culture:
- Indifference: “I do as I was told,” “they don’t pay me for it”, “the main thing is that it works at the delivery-acceptance”.
- Angry sarcasm and harassment in the team.
- Hatred of the customer and the user: “the letters are filled with the hoof,” “misuse the product”, “miser”, “they themselves do not know what they want”.
- Hatred of leadership: "Incompetent exploiters."
- Hatred of colleagues: "Krivoruky fools."
- Sabotage through diligence: “Give me a clear task and give instructions on how to execute it”, “This procedure is not spelled out in the regulations”, etc.
- A thoughtless fulfillment of wishes by the customer: “I was told - I did. There is no time for documenting, commenting, designing and other nonsense. The customer wants everything to work exactly as he requested, in the cheapest and fastest way. The customer did not say anything about the development, maintainability and upgradeability. ”
- Excessive concentration on external functionality: "The main thing is to work."
- Excessive concentration on architecture, to the detriment of functionality: "From the point of view of architecture, entering all this data in one window cannot be done."
All these signs, like weeds, constantly appear even in a healthy team. It is necessary to control their growth, to conduct explanations, to discuss the motivation and emotions of other project participants, in order to develop understanding and empathy. Explain or provide an opportunity to face the consequences of ill-considered decisions, so that the importance of certain rules is reinforced by personal experience.
From my experience, the easiest way to grow a culture is to start with 3 developers with whom you need to communicate daily and continuously, watch the code together, discuss all architectural solutions. Then, when the developers start to make the right decisions themselves, it is necessary to weaken the control - this cannot be delayed, otherwise you will grow up “mindless robots” and will constantly engage in petty care.
After that, you need to add at least two more and see how they adapt. Adjust this process: talk with the developers so that they do not take newcomers to bayonets, treat them kindly, but also don't upset them.
New people are better to add one by one. So they will not have the opportunity to withdraw from each other and organize a mini-party inside the team. Mini-party trainees are dangerous because they oppose themselves to the team. They are constantly looking for what they have been cheated of, as in the joke about the greedy blind girl, whom her parents welded a whole bowl of dumplings (“I can imagine how much they nafigachili”).
It is more convenient for me to hire juniors: their training takes longer, but they are easier to adapt to the culture, less likely to begin to resist and try to destroy it. The main thing is to track the moment when the junior grew up and raise his salary, otherwise you will lose it: to raise the salary, when the person came with a statement, more often than not, he had already made a decision, made a job offer. Even if he stays, the “mobility charge” will fire again in the coming months. Trying to save on salary, delaying the increase after the growth of competence and market value - a bad tactic, besides, it has a bad effect on the culture of development.
To form a healthy culture of development is troublesome and slow. But efforts pay off a hundredfold and the quality of the code, and loyalty, and simplifying the adaptation of new employees. Therefore, it is definitely worth it.
Source: https://habr.com/ru/post/337490/
All Articles