For nearly two decades, I’ve been writing some form of code. But, the primary reason I code has changed over time.
In the beginning, I wrote code simply to make something real. It was empowering to finally run a program (after hours of debugging) and see it behave the way I had originally intended it to. It was thrilling to know that my code was there, forever, ready to run again on my whim. In some small way, it felt like playing the role of a deity.
Eventually, I got better at writing code. I finally learned how to debug strategically. I expected my code to behave the way I intended it to after a few attempts. The thrill of seeing something simply work had dampened.
It was at that point that I became the starving artist---I wrote code primarily for the beauty of it. I spent my hours reshaping things to be just right, discovering potential patterns in my code and to what degree I’d use them. Toward the end of writing a piece of software, I would inevitably learn a few new practices that made me regret the way I had started writing it. I’d write new code, with those new practices, and the cycle would repeat---I'd learn something new and regret my original approach again.
At this time, I began seeking my mentors---anyone from my colleagues at work to the ones that were famous for the ideas I was implementing (Martin Fowler and Joshua Kerievsky to name a few). I learned to appreciate the craft of programming during this period of my coding career.
But, it was also during this time where my programmer angst set in. If you’ve written code for anyone else before, you know the feeling. That tension you feel when a feature request bends your once-pristine code out of shape. The rush to make a deadline that jeopardizes the sanctity of your codebase. The stress of having to explain to your client why that “one simple tweak” actually breaks the foundation a feature sits upon.
In fact, my emotional journey as a programmer has been a bit like that of a growing child. At first, being able to make anything happen on my own captivated me. As I matured into that starving artist mentality, doing things the way I wanted to was paramount to my happiness as a programmer.
Almost twenty years in, my perspective on code writing has changed again. Don’t get me wrong. I still carry around the internal wiring of both the precocious child and of the world-is-against-me teenager. They were a part of my journey, have become a part of my psyche, and will always be there.
But, what keeps me primarily motivated to code today is something different.
These days, I don't write a lot of new code. In fact, I haven't actually started a new project in years. I primarily work on DoneDone, an application whose history can be traced all the way back to 2008. Our last rewrite was in 2011, so most of this code is still several years old.
DoneDone works, and, by and large, works well. The codebase is in very good shape. Does it have its crufty parts? Absolutely. Does it really impact its maintainability? For a development group of our size (two main developers), not usually. The younger me could easily spend weeks on pruning, purging, and reorganizing all the pieces that make it work. But, that no longer would fulfill the primary reason why I code now.
I continue to write code for DoneDone for a new primary reason---to help other people. To make people be a little more efficient and a bit more delighted. To help people get tedious things done faster with software so they can spend more time doing something else.
Because my primary motivation to code these days is to help other people, it clarifies for me what's important to do next. I can start picking off the coding tasks that will make the most people happier, faster. I can better gauge which task has more value to dive into (a small task that might help a number of customers could outweigh a larger task that only helps a few). And, it's easy to get customers and stakeholders to buy into it because you're ultimately helping them first.
This certainly doesn't mean that pristine code is no longer a priority for me. It absolutely is. But the reason is different. The reason used to be to satisfy my own futile quest for achieving perfect code. But, now it's to ensure that the people who will read my code (my colleagues, future inheritors of my work, or even my future self) reap the benefits of the care I put into it now.
Caring for our own code is one thing. Caring for the team's code is quite another. Teams help each other, and clean up after each other. -- Robert "Uncle Bob" Martin
Focusing on people first, instead of the craft, also makes me appreciate an aging codebase. Old codebases are old because they've survived. They've helped enough people through all these years to continue to be worth maintaining.
There was a time in my coding career where the art of software was more important than the purpose of software. I'm glad I went through that period because it helped me get better at my craft. But, my priorities have shifted. Today, I write code, first and foremost, to help people.
