What to do if the team is shit-coded?

Question

JavaScript

What should I do if the team writes shitty code, and I can't influence it in any way? Put up with it for a while and hope that everything will come to its senses, or not fool around and try to find another job? I will say that I am not a team leader guru, but I see when people write a comparison ==or manage to create 4 identical methods with different names in an object, something is clearly wrong here.
If someone has a similar experience, tell me what to do.
UPD:
Thank you colleagues for responding and accepting a heated discussion of the issue. I discussed this issue with the team on the assumptions indicated in my opinion and not only. Now I want to actually tell the position of the team (in particular, the team leader) on these issues.
As it turned out, everything was written for a reason, and in the opinion of the team leader, the code is not shit.
Comparison with the help of the sign ==, which was so vigorously discussed to be and whether not, turned out to be quite normal, in the opinion of the team leader, of course. The explanation for this feint is that data from the backend comes only in the form of null or the necessary data, and this is a normal situation for it. By the way, I can’t be sure that only the data that came from the back is checked in this way. On this issue, our opinions naturally differ.
At the expense of 4 identical methods, as it turned out, they are not the same. Maybe they do the same thing inside, but they are used for different purposes.
They also wrote about linting and code review. They told me clearly about linting: we will not introduce Eslint. As I was told, the team already knows how to write code and place semicolons. They gave instructions on how to set the indent in the editor to 4 spaces, so that everyone had it. Actually, for some reason, I didn’t even argue here. Apparently the answer was given clearly and understandably. I don't have time for code review right now. Maybe later, but now you have to cut.

anecdote on the topic

Мужик тупой пилой пилит дерево пилит. Его спрашивают: Мужик чего пилу не наточишь? Мне некогда, пилить надо!

In general, there was a lot of other interesting things in the conversation. My subjective opinion is that people seem to have gathered for the first time to write a new project. I understand that you always need to do something quickly and show or launch it to someone. But it seems to me that some banal things can be done right away without wasting time. If no one is doing it now, where is the guarantee that they will do it later, and not abandon it all? For myself, I drew conclusions.
Thanks again to everyone who contributed to the discussion. I hope all the answers and comments help someone else.

Answer 1

We try not to trigger this problem through code review, trying to distribute the review load among the most experienced contributors. If there are problems in the code, the ticket is returned for revision with comments. Even if it doesn’t corny merge with the main branch. Try to improve this process.
Also, we are all going to set up Continuous Integration. Jenkins can run code checks for standards compliance and test coverage, and then display the results in a pretty way. If someone's commit shows more than N errors per unit of code, you can return it for correction.
We seem to have almost no frank copy-paste and noodles. We try to avoid it, come up with declarative abstractions in all cases where there is a lot of stupid imperative code, write in a functional style. I think that constant purposeful efforts are needed in this direction in order to prevent the dominance of entropy.
A couple more ideas.
I think that the purity and beauty of the code should be points of culture in the development team, values, if you will. It is necessary not only to scold for mistakes, but also not to forget to praise a friend for a beautiful solution, for good code, for attentiveness.
Well, it is important that the developers themselves have an attitude towards good code, professional pride. It happens that freelancers don’t have it, but there is an attitude “tap-blunder, if only it works and if only the hours are paid, and there is at least a flood.” Considering that their customers do code reviews infrequently, the development of such an attitude is natural. But still I want to write beautiful programs. Such a desire must be.
Of course, I'm not a magician myself, I'm just learning, and working with a team is such a thing that you need to constantly learn. Apparently, you are also learning; success in this.

Answer 2

It is necessary to allocate time for refactoring : https://refactoring.guru/ru all programmers with whom I was familiar liked to refactor the code. As for “something you can write normally right away” - no, you can’t, you still need to learn this, and in order to learn this you need to first write shit code, and then refactor it and may write a little less shit code in the future.

Answer 3

Another sad story of a runaway from problems.
"There will always be a perfect place for me" - no, it won't.
If you see yourself as a beacon of clean code, then share it with your colleagues, maybe your view of life will change, similar to the story of the best project while you have it in your head.

Answer 4

What to do if the team is shit-coded?

Change team lead? Well, why do we need a team leader who does not know about linters?

Answer 5

Just do your bit :)
Well, apart from jokes about this, I spoke out: " Comprehend the kung fu of legacy code refactoring - multi-pass careful improvement of the application architecture, without interruptions in the application and in parallel with the development of new functionality ... (C) I 2017 " Completely here: How to argue to the authorities for the creation of an existing project from scratch?

Answer 6

I would not work for such an office. Working with shitheads, you yourself will gradually slide down to their level. Most of the time, they don't even know what the problem is.

Answer 7

Ask yourself the question: "If I switch to another company, will it be better there?" If the answer is yes, go ahead, if not, solve the issues in your team. I think fines for shitcode and bonuses for a week without shitcode can solve the problem. For those who are on the armored train, there is always a letter of resignation.

Answer 8

Contact management.
It will tell you
. Perhaps it's just the management's policy - to hire as cheaply as possible.
Better yet, tell the management that there are programs for automatic style checking and automatic error detection (all kinds of linters and code style checkers).
In our case, in particular, they are configured to automatically start with each commit.
And the developer immediately sees his jambs.
Until the commit goes through linters, its code is not sent for consideration for implementation in production
. If you need the current team for training and improving your skills, run away from there.
It won't change by itself.