One of the most difficult things at work is understanding when you need to stop. When you're solving some problem, you want to solve it everywhere at once. When you're writing some new feature, you want to do it well right away. When you take on some refactoring, after some time you catch yourself thinking that you've already touched half the project. One thing hooked onto another, that onto a third, and so on. You want to fix it.
And all this is generally positive qualities. It's good when you're dissatisfied with something and want to improve it. This is what moves you and projects forward, what develops you as a specialist. This is your motivation.
But during formation, the average programmer in a vacuum has a fairly uncompromising position on many issues. In particular, it's obvious to them that cutting corners and doing something badly is wrong, because you can do it well. Doing something partially when you can do it completely is not true. Try to convince such a person.
And they don't even care that implementing the right solution most often requires disproportionately more investment. That it will add strong discomfort to the team's work. That their task is not the most important in principle. That the world won't collapse from us doing something imperfect now. The freed-up time, by the way, can be spent on something more priority.
To fully understand this, you need to go through years of experience and observe your mistakes several times over a long distance. I've probably already reached this moment, but at least I'm thinking about whether I should stop right now, or where the nearest stop is. I understand that otherwise I'll spend a lot of time, fall out of flow for my lead duties and won't have time for anything at all.
Stick to the original plan, don't make too sharp movements if the situation doesn't force it, commit/merge more often. Banal things, actually, but I remind myself of this every time.