Picking Up Pennies

Author’s Note: This article was written in April 2020, but not published until September 2020. The world, and my life along with it, has change significantly since then; please bear this in mind while reading.

According to the step-tracker built into my phone, thus far in 2020 I have walked, on average, 7.16 miles per day. This is, of course, just a rough estimate, but it seems reasonable to me: I walk about 2 miles every morning to catch a train to the office and about a mile and a half at night to return to my apartment, I take a walking break at lunch to clear my head and get some fresh air; factoring in the rest of my daily steps around the office, errands, and general activity I can accept 7.16 miles as a ballpark estimate. Given the distance, this clearly means I spend a good chunk of my day on my feet - I fill this time by consuming a lot of audio entertainment: music, podcasts, and audiobooks are staples in my media diet.

A Few Top-of-Mind Audio Entertainment Recommendations

As much as I enjoy all of the above content (and that’s just a small sample!), I find that I sometimes prefer to simply walk in silence: observing the world around me, those that I pass on the street, and listening to the sounds of the city. There’s never a dull moment living in the San Francisco Bay Area, just stepping out the door and wandering can yield adventures. It is on these walks that I find a great deal of mental clarity, frequently coming up with solutions to longstanding problems, making progress towards my self-reflection goals, and taking general inventory of my life. I encourage any and everyone who is experiencing stress or feeling overwhelmed to try going for a walk, especially if it’s not a regular part of your life: you may find the practice helpful and restorative, allowing you to return to tackle the tasks of the day with renewed energy and focus.

While the mental benefits remain the primary driver that gets me to lace up my walking shoes every day, I have also found that it saves me a good deal of money: I don’t own a car, meaning that I have no car loan to pay nor the associated parking, fuel, and repair bills. I also avoid spending as much on rideshares as I once did (though they’re still quite convenient in the right circumstances). In fact, I’ve probably made money by walking: the amount of loose change that I find on the sidewalk is astounding. In the past week alone I’ve picked up a coin on every walk I’ve been on. These coins are mostly pennies, so their overall value is small in the grand scheme of my financial life but nonetheless I enjoy picking them up. On a recent outing, after spotting a dime ahead, I was bending down to claim my bounty when a thought came over me: “What can be learned from picking up this change? There’s got to to be a lesson here somewhere!”. Being a lover of metaphor and analogy, and always seeking blog post ideas, I quickly connected the idea of picking up change to how I think of making small changes “along the way” to an unrelated goal, especially in the context of programming and feature implementation.

I never set out on a walk with the intention of finding money, it is just a positive side-effect of something that I’m already committed to doing. I find this same principal surfaces in my day-to-day engineering work. Let’s say, for example, that I am working on implementing a new feature into an app. In the course of accomplishing the tasks that will add up to the feature being released to our users I’ll occasionally happen across a small change to an unrelated system that I can make easily, thereby improving the health of the project as a whole. I’ll make the micro-improvement and include the change as a part of the implementation effort towards the feature work that is my ultimate goal. These small auxiliary changes are miniscule in size compared to the feature that I’m focused on but over time they do add up, much like picking up change on the sidewalk will eventually result in a full piggy-bank!

Unfortunately on a few occasions after submitting work for review containing changes in this vein I’ve received surprisingly negative feedback on my penny-sized advancements. Reviewers complain that the inclusion of these changes contributes to clutter, that all changes ought to be associated with tickets in task-tracking software, and that such modifications are “out of scope” from the items of work primarily targeted by my patch. In response I’d say that while I didn’t set out to correct spelling errors in comments, I didn’t intend on happening across unused import statements, and I wasn’t hunting for mis-formatted braces I’m only taking advantage of being in the right place at the right time! The effort that it takes to fix these little nits in the code is so small when you’re already making changes nearby that it would feel irresponsible to just pass them by. Much like neglecting to put in the effort to pick up a penny on the sidewalk because “it’s only a penny” feels elitist and entitled I’d feel like a poor steward of quality were I to simply ignore an obviously positive change I could make to code just because it’s not directly related to the feature that I’m currently targeting.

These tiny, nearly imperceptible improvements add up over time to a codebase that is, at the end of the day, more pleasant and efficient to work on. Fixing spelling errors leads to better search results. Improving compliance with our styleguides makes our continuous integration system less likely to fail. Removing unused import statements increases the isolation of individual product areas and can create opportunities to deprecate dependencies entirely over time. The benefits of making these tiny improvements are hard to observe in the short term, just like we may struggle to see the spare-change jar getting any more full every time we deposit the day’s spoils, but that shouldn’t deter us from doing it anyway with the knowledge that we’ll thank ourselves the day that we finally get to take the contents of that jar to the bank to be counted. In my opinion we shouldn’t let task-trackers, processes, and “feature scope” get in the way of us individually doing what we know is best. Just like that rewarding trip to the bank we’ll thank ourselves the next time we grep our code in search of a specific method, the next time our CI builds pass under style-violation thresholds, and reap the architectural benefits of separation of concerns.

In closing, I’d recommend that the next time you face a challenging problem you take a walk, and if you find a bit of spare change along the way be sure to pick it up: the penny in your pocket may feel insignificant now, but remember that it’ll add up to something big over time.