As I start writing this, it's January 2nd, 2024. It will likely be published a few days later. The year has just turned over to a new number and tomorrow (January 3rd) will represent my 45th revolution around the sun. I've been blogging off and on for a little over two decades now with a more recent extended break (from Codepunk) that was so satisfying I wondered if I should even start writing again. But I spend enough time wallowing in nostalgia that I don't want to make this new re-excursion into writing a reflection on the past (at least, not a long one).

Beyond the decades blogging, I started programming seriously in 1998 and professionally in 2001. I'll be pushing three decades of coding soon… Behind me are a treasure trove of abandoned side projects and ideas. For example, I once wrote a chatbot framework based on actual conversational theory. I likely will never return to it. I own a cool .ai domain, but let's see if I ever use it.

Those are some of the things you come to terms with as you get older: books you'll never read, things you'll never learn, places you'll never go, projects you'll never finish. It reminds me a bit of something Massimo Pigliucci wrote a few years ago about how when you get older, you start to accumulate a number of "the last time I'll…" bullet points.

In all the time that I've worked in the industry, I've always tried to maintain a side hustle of projects with the hope that one of those projects would be good enough to launch. But while that was happening, I quietly built a career at an institution that I respect, surrounded by people that I enjoy being around, working on projects that make a sizeable difference not just for the institution, but for society. The salary and benefits aren't anything to complain about either. So while I haven't had the opportunity to be an Internet hero—and I gave up my Microsoft MVP status a few years ago—I've consistently excelled at the work I was doing in software and DevOps, planning and building important medical education applications, while establishing an enterprise level team process.

There's no reason to be disappointed about incomplete or abandoned projects. In one of his books, Mark Schwartz mentions that failed projects rarely have a net negative impact because although the project didn't launch, value was gained by those participating in the project through experience and education. Assuming the company actually cares about long-term investment in knowledge and enterprise assets, there are positives to gain. Think about how much failed side projects and abandoned hobby repositories have enriched your skills and critical thinking in other areas of your life, including your day job.

Programming culture is too focused on the start-up, which has a history of gambling high salaries for hustle culture and creating expections of 60-70 and even 80 hour work weeks while awaiting the vaunted IPO or other such cash in. As a result, even those working in established enterprises are guilted into buying shares of that hustle culture, and rather than taking pride in the work they're doing and enjoying time to themselves, they feel the need to fill those down hours with side projects and more work.

In the technology industry, we're always worried about the next big thing—whether that's crypto (remember that?), generative artificial intelligence (hot right now), or the next big framework. We forget about the things that matter now and long term to keep a society running. This is why programmers are still coming out of retirement in their 60's to maintain Cobalt programs for large insurance companies. We've become obsessed with novelty and growth, but not so much with the maintenance and stability we need to keep a long term perspective.

In announcing Stewart Brand's The Maintenance Race, Jacob Kuppermann writes:

[M]aintenance is a largely unheralded presence in our lives. We are fascinated with the people who begin great works — from ancient rulers who ordered the building of pyramids and other great monuments to tech founders who announced revolutionary devices. The maintainers downstream of those grand beginnings, the craft workers who made sure the rock-hewing tools remained sharp or the software engineers pushing patches to cover every new security vulnerability, get short shrift in our cultural memory.

This isn't just true for pyramid builders. I cringe at the thought of counting the number of times a project manager, CFO, or COO has asked when a project was going to be "done" because they are tracking the investment. When you live (and report) quarter to quarter, it's often the next project that is more exciting and subjectively valuable. But as we all know, a project is never "done" unless you're decommissioning it. Frederick Brooks noted years ago in The Mythical Man-Month that the cost and time spent maintaining a project far exceeds the initial start-up cost of the time-blocked project itself. Meanwhile, the aforementioned Schwartz points out that a deployed application in production immediately begins to acquire entropy if not maintained, as the technology around it continues to advance. Stasis equals degradation.

So here's to the maintainers… and as we look forward to future progress, let's take a measured approach that balances innovation with maintenance. And if you're a maintainer, cheers, your work has not gone unappreciated… and it holds far more value than any side hustle.