Hacker News new | past | comments | ask | show | jobs | submit login

I have a rule of thumb to assist with this. If i feel like I have to maintain some state in my mind to understand a particular piece of code then I opt to clean it up since it'll potentially save future developers that time.

The thing is, especially with juniors, cleaning up code leads to a few things:

- poorly executed cleanup (aka regressions)

- misunderstanding of requirements (new bugs)

- "standardization" of naming (now you have two standards https://xkcd.com/927/)

- restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around)

Left unchecked this can all happen, at the expense of feature work, and an unmerged PR resulting in missed deadlines and a frustrated junior. Alas we usually learn best by making mistakes though and I find this one hard to teach for some juniors.

I would argue that a measured tolerance of ugly code (and sometimes bad code) is more important until you learn how to spot and write code that doesn't look wrong.

Two articles I found helpful:



I read once someone's estimate that the probability of introducing a bug when fixing a bug is somewhere between 20 and 50 percent. That probably also applies if it's not a bug - if you're just cleaning up something. That should make you think twice.

In particular, it might make you think about game theory. Is the expectation value of this change more bugs, or less? Will making this change have at least a 50% chance of preventing a future bug?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact