This month’s T-SQL Tuesday invite comes from Pat Wright, who asks us to reflect on how our code has aged. Has it aged gracefully? Poorly? I’ll go with an example from early in my career that lands somewhere in the middle.
To read the full T-SQL Tuesday invite, click the T-SQL logo to the right.
Old Timer
With the thought of “aged” code, my mind goes to some of the first code I wrote and had implemented in a real job. Without going into too many details, let’s just say there was a particular solution with a fragile process that left it vulnerable to going offline and taking down multiple systems along with it. If someone opened a particular file to modify it and had a minor typo, it was going to be a bad time.
There had been talks of a newer version of the process for months, but I suspected it may not happen anytime soon. Based on my role, I was far from being a developer of any kind. But I saw it as an opportunity (and I may have also feared making typos).
If I came to that team with a solution that would help until the new version was available, great. If I brought it to the team and got laughed out of the room, how much would it really matter? It wasn’t my area of expertise to begin with. I viewed it as low risk, high reward.
I put together a solution and brought it to the team. I vividly remember sitting in the conference room, demoing how it worked, and then the silence that followed. Then the quiet response of “Yeah, that should work. Nice job!”
Too Many Candles For The Cake
It was far from perfect, but it got the job done enough to save some outages and add some logging to help track activity. For better or worse, it seems to still be aging. Amazingly, the last I heard, that little tool is still in use today.
How did it age from a coding standpoint? While it works, it still makes me cringe to look at it now. For something 10 years old, 20 years old, etc. I think cringing is a healthy response. If I looked at it and thought, “It was flawless, and I wouldn’t make a change,” then that would reflect pretty poorly on my development.
Never Too Young to Try
Age restrictions are in place for a reason. You shouldn’t hand over the car keys to a child. You shouldn’t give a teenager open access to alcohol. But you don’t have to have X amount of years of experience to propose a solution to a problem.
My code from years ago was never an Olympian in its younger days. Today, it’s more like a 100-year-old running a 100m dash. Not as fast as the young whippersnappers, but still finishing the race.
Thanks for reading!
Chad Callihan 