September 8, 2017 at 16:36About 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 the next code, product or API, created for internal needs in a non-core organization.
In specialized matters, things are better, but not always: in boxed replicated solutions it is often better than in design development. In the products of one customer, usually the worst.
And money doesn’t solve anything: horrible code and terrible products are written both by 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 I came across a code that they wrote foreign contractors and every time I felt like sobbing and banging my head against the wall.
The organization can declare strict standards, hire expensive developers, introduce regulations and methodologies, puff out cheeks at meetings and loudly 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 the very correct and necessary regulations and standards.
I was involved in software development in several organizations and, for various reasons, several times recruited the team from scratch. As a result, I came to the conclusion that the quality of the product depends only on the development culture. Everything else, including methodologies and standards, are tools: they are necessary, but they alone are not enough.
The development culture can be compared to an ecosystem: like a garden or an aquarium. A strong, healthy culture has a margin of safety to heal the inhabitants of the ecosystem, get rid of pests, forgive small mistakes of care, alleviate stresses and, at the end, get an excellent result. A sick culture nullifies all efforts, infects and destroys even the most healthy and strong seedlings.
When a new engineer enters a team with an established development culture, he either accepts the culture or the team rejects it. Attracting and parasitizing in a team with a healthy development culture is almost impossible - it instantly calculates untrained, lazy and indifferent developers. First they will try to instruct, explain, teach, and then your employees will be drawn to you one by one to "talk about a new colleague." And vice versa, such a team is enthusiastic about those who are keen on their business, willing to develop and collaborate, and now they already go to dinner together, communicate outside work, get to know families, invite each other to home events and help with household chores.
You cannot buy or steal a culture by luring a developer. It is impossible to pick up a fruit-bearing tree from the garden: if it survives the transplant, you will not wait for the previous harvests.
Culture cannot be introduced by order. This is daily work, creating a microclimate, tracking parameters, training, mentoring. As soon as an aquarium has just been launched, it requires constant monitoring of water parameters, gradual but timely settlement, flexible adjustment of lighting parameters, aeration, fertilizing and microorganisms. But then, when the culture gets stronger and stabilizes, it will start working for you.
If you don’t engage in culture, 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 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 when there are fewer than three programmers. Yesterday, great developers started to write such terrible code that after restoring the team and culture, it had to be completely rewritten.
Even in large and stable collectives, an existing culture can be easily destroyed by provoking its degradation by incorrect organizational decisions: improperly built motivation, connivance, demands mindlessly submit to a solution without explanation and conviction in its expediency, constant burning tasks that need to be “done yesterday and it doesn’t matter how, "decisions like" to do something urgently, and then we will remake it in the normal way. "
Large groups with an established destructive culture will violently resist change. To reject or sabotage standards and regulations, or to comply with maintaining a poor-quality result.
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 on the acceptance test.”
- Angry sarcasm and bullying in the team.
- Hatred of the customer and the user: “they stuff letters with a hoof”, “they use the product incorrectly”, “presses”, “they don’t know what they want.”
- Hatred of leadership: "Incompetent exploiters."
- Hatred of colleagues: "Crippling fools."
- Sabotage through diligence: “Set me a clear task and give instructions on how to carry it out”, “This procedure is not prescribed in the regulations”, etc.
- Mindless fulfillment of the wishes of the customer: “They told me - I did. There is no time for documenting, commenting, designing and other nonsense. The customer wants everything to work exactly as he asked, in the cheapest and fastest way. The customer did not say anything about developability, serviceability and renewability. ”
- 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, conduct explanations, discuss the motivation and emotions of other project participants, so that understanding and empathy develop. Explain or give the opportunity to face the consequences of ill-conceived decisions, so that the importance of certain rules is reinforced by their own experience.
From my experience, the easiest way to grow a culture is by starting with 3 developers who need to communicate daily and continuously, watch code together, and discuss all architectural decisions. Then, when the developers begin to make the right decisions themselves, it is necessary to loosen control - you cannot delay this, otherwise grow up “mindless robots” and will constantly engage in petty wardship.
After that, you need to add at least two more and trace how they adapt. To correct this process: to talk with developers so that they do not take novices with hostility, treat them kindly, but also do not nurse them.
It is better to add new people one by one. So they will not have the opportunity to close each other and organize a mini-party inside the team. Mini-lots of trainees are dangerous in that they oppose themselves to the team. They are constantly looking for what they were deprived of, as in a joke about a greedy blind girl, whom her parents had cooked a whole basin of dumplings ("I imagine how much they got for themselves").
It’s more convenient for me to hire juniors: their training takes longer, but they adapt more easily to the culture, are less likely to start resisting it and trying to destroy it. The main thing is to track the moment when the junior has grown and raise his salary, otherwise you will lose it: raise the salary when a person came with a statement, most often too late - he already made a decision, accepted a job offer. Even if he remains, the “charge of mobility” will shoot again in the coming months. Trying to save on salary by delaying the increase following the growth of competence and market value is a bad tactic; moreover, it has a bad effect on the development culture.
To form a healthy development culture is a troublesome and slow-moving affair. But the effort pays off handsomely and the quality of the code, and loyalty, and simplifying the adaptation of new employees. Therefore, it is definitely worth it.
In specialized matters, things are better, but not always: in boxed replicated solutions it is often better than in design development. In the products of one customer, usually the worst.
And money doesn’t solve anything: horrible code and terrible products are written both by 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 I came across a code that they wrote foreign contractors and every time I felt like sobbing and banging my head against the wall.
The organization can declare strict standards, hire expensive developers, introduce regulations and methodologies, puff out cheeks at meetings and loudly 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 the very correct and necessary regulations and standards.
I was involved in software development in several organizations and, for various reasons, several times recruited the team from scratch. As a result, I came to the conclusion that the quality of the product depends only on the development culture. Everything else, including methodologies and standards, are tools: they are necessary, but they alone are not enough.
The development culture can be compared to an ecosystem: like a garden or an aquarium. A strong, healthy culture has a margin of safety to heal the inhabitants of the ecosystem, get rid of pests, forgive small mistakes of care, alleviate stresses and, at the end, get an excellent result. A sick culture nullifies all efforts, infects and destroys even the most healthy and strong seedlings.
When a new engineer enters a team with an established development culture, he either accepts the culture or the team rejects it. Attracting and parasitizing in a team with a healthy development culture is almost impossible - it instantly calculates untrained, lazy and indifferent developers. First they will try to instruct, explain, teach, and then your employees will be drawn to you one by one to "talk about a new colleague." And vice versa, such a team is enthusiastic about those who are keen on their business, willing to develop and collaborate, and now they already go to dinner together, communicate outside work, get to know families, invite each other to home events and help with household chores.
You cannot buy or steal a culture by luring a developer. It is impossible to pick up a fruit-bearing tree from the garden: if it survives the transplant, you will not wait for the previous harvests.
Culture cannot be introduced by order. This is daily work, creating a microclimate, tracking parameters, training, mentoring. As soon as an aquarium has just been launched, it requires constant monitoring of water parameters, gradual but timely settlement, flexible adjustment of lighting parameters, aeration, fertilizing and microorganisms. But then, when the culture gets stronger and stabilizes, it will start working for you.
If you don’t engage in culture, 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 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 when there are fewer than three programmers. Yesterday, great developers started to write such terrible code that after restoring the team and culture, it had to be completely rewritten.
Even in large and stable collectives, an existing culture can be easily destroyed by provoking its degradation by incorrect organizational decisions: improperly built motivation, connivance, demands mindlessly submit to a solution without explanation and conviction in its expediency, constant burning tasks that need to be “done yesterday and it doesn’t matter how, "decisions like" to do something urgently, and then we will remake it in the normal way. "
Large groups with an established destructive culture will violently resist change. To reject or sabotage standards and regulations, or to comply with maintaining a poor-quality result.
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 on the acceptance test.”
- Angry sarcasm and bullying in the team.
- Hatred of the customer and the user: “they stuff letters with a hoof”, “they use the product incorrectly”, “presses”, “they don’t know what they want.”
- Hatred of leadership: "Incompetent exploiters."
- Hatred of colleagues: "Crippling fools."
- Sabotage through diligence: “Set me a clear task and give instructions on how to carry it out”, “This procedure is not prescribed in the regulations”, etc.
- Mindless fulfillment of the wishes of the customer: “They told me - I did. There is no time for documenting, commenting, designing and other nonsense. The customer wants everything to work exactly as he asked, in the cheapest and fastest way. The customer did not say anything about developability, serviceability and renewability. ”
- 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, conduct explanations, discuss the motivation and emotions of other project participants, so that understanding and empathy develop. Explain or give the opportunity to face the consequences of ill-conceived decisions, so that the importance of certain rules is reinforced by their own experience.
From my experience, the easiest way to grow a culture is by starting with 3 developers who need to communicate daily and continuously, watch code together, and discuss all architectural decisions. Then, when the developers begin to make the right decisions themselves, it is necessary to loosen control - you cannot delay this, otherwise grow up “mindless robots” and will constantly engage in petty wardship.
After that, you need to add at least two more and trace how they adapt. To correct this process: to talk with developers so that they do not take novices with hostility, treat them kindly, but also do not nurse them.
It is better to add new people one by one. So they will not have the opportunity to close each other and organize a mini-party inside the team. Mini-lots of trainees are dangerous in that they oppose themselves to the team. They are constantly looking for what they were deprived of, as in a joke about a greedy blind girl, whom her parents had cooked a whole basin of dumplings ("I imagine how much they got for themselves").
It’s more convenient for me to hire juniors: their training takes longer, but they adapt more easily to the culture, are less likely to start resisting it and trying to destroy it. The main thing is to track the moment when the junior has grown and raise his salary, otherwise you will lose it: raise the salary when a person came with a statement, most often too late - he already made a decision, accepted a job offer. Even if he remains, the “charge of mobility” will shoot again in the coming months. Trying to save on salary by delaying the increase following the growth of competence and market value is a bad tactic; moreover, it has a bad effect on the development culture.
To form a healthy development culture is a troublesome and slow-moving affair. But the effort pays off handsomely and the quality of the code, and loyalty, and simplifying the adaptation of new employees. Therefore, it is definitely worth it.