What to do when colleagues are lower level?

Question

Work organization

There is a project where 4 programmers work. I am on the team for this project.
Each developer has his own area of ​​responsibility, each is responsible for his own component of the system.
The problem arises when one of the developers goes on vacation, gets sick, or urgently needs to close his tasks.
At these moments, you have to work closely with the code and solutions of a colleague, which causes not the most pleasant sensations. Attempts to influence, to teach are often perceived with aggression and lack of understanding. There were also attempts to rewrite important parts of the system by me and show how to solve this problem better, but over time everything returns to its previous state. There is a review code where I try to somehow reduce the number of possible problems in the future.
How would you try to get out of this situation?
It seems to me that the simplest solution is to find another place of work and leave the project to be torn to pieces, but this is an avoidance of the problem, not a solution to it. In addition, the situation may be the same at a new job.
I would love to hear your experience and advice.

Answer 1

Who said that they are below the level?
The Dunning-Kruger Effect It is
always difficult for a programmer to delve into someone else's code - this does not depend on the qualifications of the one who coded.
It is possible that even they are more qualified - they just gave up on perfectionism a long time ago, and it still rushes out of you because of youthful maximalism.
And maybe you're right.
It's not about qualifications, but about motivation and organization of the process.
Let's say I've worked on a team where git only missed 200 lines of changes at a time. And these lines had to go through standardized formatting and linters (static analyzers) - otherwise git would spit them out. This forced programmers to write more or less acceptable code - code was less annoying to colleagues.

Answer 2

What to do when colleagues are lower level?
1. Do not be arrogant. For every smart person there is a smarter one.
2. If crooked programmers set you up and interfere with your work, talk to the management, like I can’t deal with them and allocate an independent work area.
3. If you want to fix something with the programmer, discuss with him, explain why it would be better. Perhaps you are just ruling and a colleague regards this as an invasion and humiliation of his professionalism.
\\\
It seems to me that the problem is not in the level of knowledge, but in the organization of work.

Answer 3

Faced this 2 times. Both times I tried to explain, convey, brought books, read lectures. In response - the same as yours - aggression, lack of understanding, indifference. Both times for a long time in such a company did not linger.
My conclusions are these. Firstly, accept the fact that in any profession, IMHO, 1% of geniuses, 5-10% of professionals (those who are really passionate, improve their skills, read tons of books, study new technologies), for the rest - this is nothing more than Job.
Accordingly, if there is a situation that the level is different, then people need to be used in different ways. For example, an experienced programmer designs an architecture, a subject area, can describe interfaces and indicate how to do what, where, what tools and patterns to use, and less experienced ones implement all this. It is possible and vice versa, for example, I don’t understand much about layout. Therefore, when necessary, I stupidly figure out on a clean bootstrap, and then our layout designer creates his magic and makes everything beautiful.
As for attempts to correct the situation: It is necessary to introduce generally accepted practices - introducing coding standards, writing those documentation, outputting some common components to either, forcing employees to speak in front of a group with lectures on various aspects of programming (which they figured out on their own), code review , CI and more. It is necessary that they come across good code, and see that their work can be done much easier.
But the main thing is that the initiative should come from the team leader (although this is not a guarantee of success). If you want - try to convince him of the need for change. But if he himself does not realize this, it’s a pipe, especially if you are new to the team.
We must not forget that projects have karma (or staff skill levels) that come from management (you can read about this in the book "The Human Factor in Successful Project Teams"). If you are less professional than this level, you will not get into the company (you will not pass the interview corny). If you are much more professional - leave yourself, because the work will be uninteresting and nervous. You need to understand that your situation is not some kind of exceptional case, it is an absolutely standard life situation, and judging by the statistics, sooner or later people leave the company where the skill level is below their own standards.
Here it is really worth talking about qualifications as such: each programmer considers his own approach to programming to be the most correct. Wise people sometimes doubt it, but still. You need to understand that your approach is not the ultimate truth. Sometimes you look at someone else's code, you think - what the hell is going on here. You start to understand, to delve into, to understand the logic of the developer, perhaps different from yours, but sometimes no less slender and beautiful, sometimes you understand that it couldn’t be done in any other way. You need to be more tolerant of other people's code. IMHO, it is important to communicate with the team, learn from each other, and most importantly - develop a unified approach for the project. But again - for this, the team must have a desire, at least - the team leader.
But the most important question in your situation - why do you need all this? In vain, there is a saying: a smart one will not go uphill - a smart one will bypass the mountain. Most likely, nothing will work out for you (especially if the team is successful). If you think that there is a chance to get some kind of profit (become a team lead, get an overdose for your salary) - you can. But most likely you will just be sent to hell, your loyalty to the company will disappear, and in the end you will quit. Wouldn't it be better to immediately leave for a company of your level? You write that this is not a solution to the problem, but a way out of it. But you need to understand that this is not your problem. And solving other people's problems often turns out to be more expensive for yourself.

Answer 4

What to do when colleagues are lower level?

Shine

Answer 5

If you are their leader and objectively more experienced than they are, what prevents you from replacing them with other people?

Answer 6

I can confidently say that this problem is reproduced not only in groups of people who are engaged in development. Very often I observe, for some reason I didn’t see this before, how colleagues working in the same department begin to try to teach others how to do it. In my opinion, there are two sides of the coin here, the first is when the one you are trying to reason with does not want to change anything, because your training takes him out of his comfort zone and he is trying in every possible way to return back, the second side is how you are trying to submit something new, if with positions - your level is lower and see how it should be done, then their reaction is understandable. In my opinion, if you do not occupy the level of the leader of this team, then you risk becoming a white crow, and in the end, if you do not find support, everything will remain at best, at worst, a conflict will be provoked and the team "

Answer 7

Work and not torment the soul with experiences. It's a job, not a hobby club.

Answer 8

Better get out of there, working with the weaker ones will make you weaker. It is necessary, on the contrary, to be the weakest player in the team

Answer 9

Get out of there. You can always learn something from strong colleagues, and it will never be superfluous.

Answer 10

depends on the working conditions: if the salary and other benefits suit you, then you can gradually take command of the parade, as a result, you will either establish yourself as a more qualified professional and get a promotion or gain useful experience in order to qualify for higher positions in other companies,
use them to practice their leadership qualities

Answer 11

If I understand correctly, then it's not so much about the external design of the code, but about how to name functions and variables and how to distribute the code from the point of view of OOP?
You need to make a code style guide and describe the rules for formatting the code as you see them, including examples of variable and function names (for example, I like under_score. and others like CamelCase) and examples of bad code from your project in your opinion.
Then offer your code style guide to your colleagues for criticism, let them make their edits, express their point of view on how to name variables, functions and how to distribute code among classes, etc. and examples of bad code from your project in their opinion, and in this way you can come to a compromise and develop a single code style guide that suits you all.
Code style guide is a fairly common practice, for example, here is a set of code style guides from google for different languages ​​https://github.com/google/styleguide

Answer 12

It seems to me that the simplest solution is to find another place of work and leave the project to be torn to pieces, but this is avoiding the problem, not solving it.

In the world and the Internet, there is always someone wrong. But this is not a reason not to sleep at all =)

Answer 13

The way out is to become the leader and dictate your conditions to them. But only here there is another problem, one of them can become the main one, then it will be "hello swamp" for you.
If you already have a boss, then it’s worth explaining to him why it’s bad here, and why it’s good for you.
Will not understand. Xs what to do.
What to do when colleagues are lower level?- I also wrote the same thing in my opinion.

Answer 14

Become the head of them, and send all your colleagues to improve their skills, for example, send them all to learn Pure C, this raises discipline

Answer 15

Well, it's inevitable, the world is what it is, it's not perfect and you have to work with what is, most of the developers available to your company are probably mediocre. It is important even with mediocre developers to create a worthwhile, competitive product.
Well, where do you think to go where this will not happen? This is everywhere, including top companies (those who have products that are too complex and large to be of high quality in all details).

Answer 16

There were also attempts to rewrite important parts of the system by me and show how to solve this problem better, but over time everything returns to its previous state.

I did the same, but I wrote my edits as comments. Over time, they began to be taken for granted (changes were made to the code). True, this led to "May I ask?".

Answer 17

Specifically, the problems you listed can be solved by hiring or designating a project leader from the current employees . This employee should be aware of all the intricacies of the project at all its levels and can assign the task to the most competent developer in the field or answer all questions on the task to the developer who does not have enough competence, while other developers were stupidly not at hand.
Moreover, one of the main properties of a project leader is the ability to make far-sighted decisions on controversial issues. For this, his objective view of the project is necessary. Accordingly, in order to maintain the objectivity of the project leader 's viewYou are not allowed to commit your own code to the project. After all, it's not a secret for anyone that any person/programmer/developer will consider his code more important than the code of other colleagues - which undoubtedly loses objectivity in decision-making in controversial situations. That is, the project leader should be, like a judge in court, blind to irrelevant factors, and his decisions should not be imposed by self-interested performers.

Answer 18

A clear example of how "owning the code" is evil. It will be even more fun when one or more of them quit, and the rest do not know "their" code.
Invite the rest to team up and decide together which of you will be the tech lead. If neither of you has sufficient authority, try to reach out with this to management. Let him appoint you or appoint a third party. If the management turns out to be deaf, then it is up to you to decide whether to gradually gain the trust and authority of colleagues or leave for another team.