[cassianoleal]

That is the flip side of what you're arguing against, and is also very typical junior behaviour that needs to be corrected against.

Tech debt needs to be dealt with when it makes sense. Many times it will be right there and then as you're approaching the code to do something else. Other times it should be tackled later with more thought. The latter case is frequently a symptom of the absence of the former.

In Extreme Programming, that's called the Boy Scouting Rule.

https://furqanramzan.github.io/clean-code-guidelines/princip...

[traderj0e]

The Boy Scout "leave it better than you found it" is a good rule to follow. All code has its breaking points, so when you're adding a new feature and find that the existing code doesn't support it without hacks, it probably needs a refactor.

[yamajun93]

This is a real pain, I notice over-editing a lot when using AI coding tools locally and also re-inventing the wheel (e.g not using external libraries or reimplementing something over and over again). The Boy Scouting Rule is a good framing, but the tricky part is deciding when we apply it and what's actually a 'minimal' change. Maybe smt like 10% of the PR should be refactor max, and if is more open a new PR?

[ramesh31]

Indeed there's a distinction that needs to be made here between "not refactoring this code means I'll need to add hacks" and "Oh I'll just clean that up while I'm in here." The former can be necessary, but the latter is something you learn with experience to avoid.

[cassianoleal]

> the latter is something you learn with experience to avoid.

The latter is something you learn to judge the right time to tackle. Sometimes a small improvement that's not required will mean you're not pressed to make the refactor to avoid hacks. The earliest you can tackle problems, the cheaper they are to solve.