Hacker News Reader

Comment by ramesh31 | Hacker News Reader

>The idea being that if you're working in an area, you should refactor and tidy it up and clean up "tech debt" while there.

This is horrible practice, and very typical junior behavior that needs to be corrected against. Unless you wrote it, Chesterton's Fence applies; you need to think deeply for a long time about why that code exists as it does, and that's not part of your current task. Nothing worse than dealing with a 1000 line PR opened for a small UI fix because the code needed to be "cleaned up".

View on HN

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...

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.

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?

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.

> 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.

Just do it in a follow up PR to keep them atomic. But do clean up; it's so easy now.

Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.

Reply on news.ycombinator.com