Look for the code that everybody avoids, the code they’re afraid to touch or that they don’t want to deal with. Watch for the code that you avoid. Maybe you can make that code less fear-inducing, or less difficult to deal with.
You’re probably afraid to touch it because it’s been painful before. Maybe it’s hard to get your head around. Maybe every time you need to touch it you have to spend a while just figuring out what the heck it’s doing. Maybe it’s hard to change. Maybe every time you change it, other stuff breaks unexpectedly.
Those are smells! Those are signs this code could probably use some design attention. Good design means maintainable code. When you have to touch it, it should be easy to understand what’s going on. Responsibilities should be isolated so changes will be isolated. That means less breakage of unexpected stuff. Tests can help with that, too. Blah blah. There are whole books on good design. The point is: Bad design shows its face in the form of code that’s painful to maintain. So when you feel that pain, you need to fix the design.
Sometimes you need to make substantial changes in order to do that, and of course changing stuff might break other stuff. Especially in code like this. That’s okay! Sometimes we should accept some short-term pain in the name of longer-term stability.
And sometimes the effort won’t be worth it. Don’t pour a ton of effort into fixing up code if the pain isn’t there. Bad code you have to fight with regularly begs for some love. Bad code that gets the job done can be left alone. If you only feel pain from it once a year, maybe you have higher priorities.
There’s a balance to be struck: balancing magnitude of pain, frequency of pain, magnitude of effort required to make things better, and just how much better they’ll be after going through that effort.
