Jim Dabrowski

Follow @jimdab on Micro.blog.

Knowing When Not to Fix Something

As professional software engineers working on large code bases, there are always things that are wrong, small bugs to fix, code that can be improved, etc. When working on some issue or bug fix, it's tempting to just fix these other little things to clean up the code. This may be the right thing to do, or it may not. As software engineers we sometimes have to be disciplined and focused in our work. Keep our work contained to the specific issue we're addressing, get that fixed and get it out the door. Then, once that's done, come back and fix that other issue you found. Depending on the work environment you're in, that work might need to be documented and accounted for. It may need to be prioritized and scheduled by a product team or by a project manager. Your fingers might be itching to "just fix it since I'm right here" but it's possible that little fix could introduce other, unforeseen side-effects. I'll never advocate for ignoring or not helping fix things in your software that are broken, but it can be a sign of a more mature software engineer to know when to not fix something that's broken.