Getting told to do x and y is theory. Experiencing that one really doesn't understand one's own code is practice. Can you pass the bug to the person who wrote that code, such as "hey something is not working as expected. I see you wrote that, surely you can find out what goes wrong here faster than me"? The more time has passed between writing code and now, the better is the chance that this will work.

"mainly care about delivering what was promised" Why is that not a priority for you too?

@TymoteuszPaul it is my priority... but that's not the point of the question...

@user8469759 so why are you doing this if it's not to improve the speed of delivery?

Well, it is, because if what you want is not aligned with the business reason, then it's furthering what you, personally, want instead of furthering the business.

I don't wanna start a massive debate.. but working with discipline is necessary to deliver the product the customer asked... no disciplines puts actually at risk project deliverable, I say this from experience. We had a employee who was the only one who knew his code and it was considered for commercial product. However it was so badly written we had to ditch the all code and start from scratch that feature. All I am doing in my question is separating the two points cause they're related but I am focusing on a specific one. This is not personal but just common sense...

How long have you been in this type of role? Is this first forey, 17th etc as team lead?

Around 1 year and a half.

"no disciplines puts actually at risk project deliverable, I say this from experience." Does your management agree with you that this is true for this specific project?

They do and I quote "In project X we had an incredible amount of technical debt".

Some of this seems subjective to me. What is "clean" code and who determines whether code is "clean" or not? Is there a universal or widely and generally accepted standard for "clean" code. Who determines how many nested lops are too many and how many are "just the right amount of nested loops". Who determines if the programming logic is faulty? All I'm seeing in this question are your opinions.

Just few basics --> That is not an universal concept.

This is engineering, not science. Yes, easier-to-read code is better. So is more performant code. So is getting something working quickly. And it does take experience to balance these and do any one of them well, If you're trying to teach, understand when to do so, and how to make it constructive criticism. If the code works and isn't unreasonable, consider approving it and opening a technical debt item to improve clarity/documentation, then prioritize that alongside other tasks. "Make it work, make it good, make it great. In that order."

@user8469759 Do you have a company wide coding standard, and if so do you enforce it?

@joeqwerty There is a definition of Clean Code, but I am also not sure if the OP knows it. I'd recommend Uncle Bob's series (available e.g. at YouTube). In short: Write code in a way you do not have to comment it.

@FlorianAlbrecht I'll disagree with "Write code in a way you do not have to comment it.". Code tells you what the computer will do. Comments tell you what you intended the computer to do. They are orthogonal concepts. (Note that the quality of the comments is a different subject. But I'll refer you to my answer here )

@PeterM Well, you may disagree, but to my understanding, this is what Robert C. Martin tries to achieve with his concept of Clean Code (very, very simplified). This is what I referred to, no more, no less.

@FlorianAlbrecht I am very aware of Uncle Bob. And I also have a copy of Code Complete (although it's being used as a monitor stand right now .. lol)

See also many of the questions listed as "Related" (If you're on a large enough screen, they display in a column to the right of the question.) This comes close to duplicating some of them.

"Quality, Service, Price. Pick any two." (Or more accurately, accept that they do need to be balanced against each other.)