Many many years ago, I did a 3-week backpacking trip through the Beartooth Mountains in Montana, in the wilderness area north of Yellowstone National Park. I learned a lot on that trip, but my most enduring memory is of the importance of craft when traveling in the backcountry. This was partly stuff like knowing how to pitch a tent so it wouldn’t blow away in a storm, and knowing how to get from point A to point B without following a trail. But the thing that struck me about knowing how to do these things — the way I learned on that trip — was built on an ethical foundation, not solely a practical one.
And that ethical foundation was the idea of stewardship; the idea that when you’re traveling through a wilderness area, it’s your obligation to leave it better than you found it.
This isn’t predicated on the idea that if enough people go to a wilderness area, it’ll be better than if nobody went there at all. It’s more based on the idea that if a certain number of people go there, and strive to leave it better than they found it, it won’t be significantly worse. The way to minimize your negative impact isn’t solely to intentionally do the least amount of damage, it’s to intentionally counter the negative impact of others. Pack out some trash, clean up some fire rings. No matter how diligent you are, you’ll unintentionally leave stuff behind too; you’re just evening the balance.
And doing this isn’t something separate from knowing how to pitch a tent or find your way with a map and compass or treat a blister. It pervades all those things. It’s not like you’d plan a backpacking trip and say, well, if we want to leave things better than we found them, it’ll take us 6 days to get from point A to point B, but if we just skip that part and leave things a little worse, it’ll only take us 5.
I mean maybe you could do that, but you’d be ~an asshole~ a jerk.
I’m sure you can see where I’m going with this.
Most of us spend most of our time in a legacy codebase, and most of the code most of us write is going to be someone else’s problem, too, soon enough.
If we don’t think about leaving things a little better, we’ll (unintentionally) leave things a little worse.
And leaving things a little better isn’t something extra to do if you have time and get permission. It’s literally your job. Do it. Make that code testable. Add some instrumentation. Comment the parts that confused you.
And here’s the most magical part, that I discovered on that trip many many years ago, and that I frequently rediscover in my job:
Doing this work makes us happy. There’s a very real and very human satisfaction in making things better for others. Packing out some rando’s beer cans isn’t only onerous, it’s also immensely satisfying, because nobody else will have to do it. Commenting some old code feels good because someone else’s life will be easier. And, for me anyway, that good feeling fills my well of creativity and motivation — it makes the hard parts of my job easier.
So, take the time to leave it better than you found it. You’ll feel great. The next person to change that code will be happier. And, ultimately, it’ll lead to better software for our customers, and they’ll be happier.