Time and mental energy are limited resources - use them wisely

Anyone working in a legacy app will notice, pretty quickly, that there are so many places to improve on things. Everything you touch and see could potentially benefit from a slightly different approach, or an upgrade to some newer .NET feature, or maybe just replacing a 10-line code block with a single-line LINQ statement.

Of course, my definition of "improve" will be slightly different than yours, and ours will both differ from the next dev that comes along. You can find plenty of evidence of that in a legacy app - multiple architectures implemented and abandoned after a few years, one commit that was 90% indentation and whitespace changes and another that removes all the curly braces from around single-line if statements in a couple classes. We've all got pet-peeves and different experiences and levels of knowledge that we bring to our work, which is generally a good thing, but only when we apply it prudently.

One of the older pieces of our codebase is a simple "busy" window that runs a piece of code in the background, and displays a modal "working..." box with a little animation, which goes away when the code finishes running. It uses some outdated constructs like Thread/ThreadStart instead of Task, and the UI could benefit from something in the Telerik suite like WaitingBar, but it's worked reliably in production for years - and that's not something to be taken lightly.

When I was asked by our BA recently to see whether we could reuse that control, or something like it, for a new process that could block the UI, I felt that oh-so-familiar twinge. The heart-skips-a-beat, should-I-shouldn't-I feeling of, oh I could create something cool and sleek here. It might take longer, but it'd be worth it, and then we could use it ALL OVER THE PLACE wherever there's long-running processes! buahahaha....

Then I took a cold (mental) shower and calmed down. That feeling is a familiar one, and probably not just for me. The feeling that what's old is worse, and new is better, and here's a chance to leave my fingerprint on something. I've learned the hard way that sometimes, best-case scenario, if all goes absolutely perfectly, that new improvement no one asked for will be noticed by no one too. Not to mention, the company already paid someone (or multiple someones) thousands of dollars over the years to write that code and occasionally maintain it and fix bugs in it.

I think for me, that's something I didn't necessarily consider in the past. I saw an opportunity for improvement - my definition anyway - and I'd be damned if I wasn't going to follow it through. Maybe I was trying to impress others, but I think it was just myself. Just another way to prove that I could see it through, whatever it was. The problem is, what's best for my ego isn't usually the best for anyone else.

It's not the best for the company that's paying me to get a feature out to a customer. It's not the best for the team that has to shoulder a bit more work while I'm off experimenting. It's not the best for me, spending my limited time and mental resources on a problem I invented, when there are any number of issues that could be made better. Isn't that the thing that makes this field so intriguing, and daunting, and at times overwhelming? We have a thousand opportunities to improve things, but only so much time and energy to work with, so we have to choose wisely.

It becomes a question, I think, of deciding which problems are worth your time and energy. Maybe the biggest problem of the day is a busy indicator screen. But maybe a bigger, better problem to solve is automating some manual process to support the team, or clearing up an issue with the BA, or just asking your teammates how they're doing and whether they need help debugging something or be a soundboard. Or even taking a 15 minute walk to clear your mind, so you can tackle the rest of the day's challenges.

So what'd I do? I took the road less-traveled (by me, lol) and just used what was already there. I discovered that, once I understood what the old screen was doing and how it did it, it made sense. Go figure. It's almost as if someone was paid to write this stuff and, since it's used in production every day, it's got a proven track record. /sarcasm

I figured out how to reuse it for our new code without even having to touch it. That's something the old me would've really struggled with. I spent a few hours figuring it out, then a few more hours implementing it, and by the end of the day it was working.

When I started in this field, I didn't know what to change. Later, I wanted to change everything. Now I've finally gotten to a place where I can honestly discern whether a thing even needs to change, then change only what's necessary... and let the rest just be.