This post was inspired by my cofounder Justin’s post on 20 Things I’ve Learned in my 20 Years as a Software Engineer. I don’t have much to add to that list, but reading through those items, I found myself thinking of all the things I still love about software engineering, even after doing it for 20 years. I’ve included 10 items below that still bring me joy.
In recent years, my daily work is focused on leadership and management, more about creating contexts for others to succeed, but for this list, I’m mostly focusing on aspects of being an individual developer who’s slinging code and working on production systems. I hope some of these resonate with you, regardless of your experience programming. Enjoy!
1. Wait, how did this ever work?
There’s a specific experience all developers have had, and I’ve never had it outside of programming.
You’re troubleshooting some issue, and as you dig into the logic… it doesn’t match expectations. In fact, the more you look, the more confused you become… how did this system ever produce the right results?
I’ve come to absolutely love this moment, because it means you’re about to have a breakthrough and learn something very important about your codebase.
It’s similar to the old quote about research: “The most exciting phrase to hear in science, the one that heralds new discoveries, is not, ‘Eureka! I’ve found it,’ but, ‘That’s funny…’“
2. A thoughtful, well-maintained Readme
Have you ever walked into a friend’s kitchen and everything just made sense? The utensils are in logical places; everything you need is within reach and easily discoverable. That’s similar to the joy I get from coming into a repo and finding a good Readme.
What makes a good Readme depends on the project, but it includes clear instructions on prerequisites with commands to install dependencies, maybe some common troubleshooting tips, simple commands to get the data seeded, run tests, etc. Few things garner my appreciation and instant respect as much as a good Readme that takes me from code to a functional dev environment with no problems.
3. A passing test suite 🟢🟢🟢🟢🟢
One of the cool things about software is that we can get instant feedback on the logic we write, and that testing process is inherently automatable. Of course you can’t automate everything, e.g., UX feedback often requires user interaction, and it may not be worth it to have robust tests for every line of code.
Nonetheless, you can write a line of code and then immediately write a test to verify that it behaves as you desire, under expected conditions. Not only is it instant; you can save the test and give other people instructions to use it. That’s amazing!
For most of my hobbies, the feedback cycle is so long, e.g., baking or gardening. It might be days or even months to get feedback, and even then, it often requires some level of expertise to interpret the results and guess what went wrong. I will never tire of running a test suite and seeing all the tests pass.
4. `rails new`
Is there anything like that energy at the start of a project? I love that feeling of starting from scratch, the limitless possibilities, the lack of legacy tech debt. It’s one of the reasons I enjoy advising young entrepreneurs through Darden’s i.Lab – and one of the reasons I still enjoy consulting after 20 years.
You can get this feeling from many endeavors, but software’s a little different with our emphasis on frameworks and automation. A few commands and boom, you have the scaffold for an application, a skeleton to start hanging your ideas on. Nice! I often wish I had something similar for writing, when I’m staring at the blank page.
Briefly, that means you can toggle the editor between two “modes”, one for inserting and one for manipulating text. In manipulation mode (AKA normal mode), you can do things like delete all text until the next comma by simply typing 3 characters. Once you get used to it, you can’t imagine ever going back.
6. Building Our Tools
Speaking of Vim… On lazy Sunday afternoons, I like to watch those woodworking shows like The Woodright’s Shop, where the host discusses old-timey tools and the history of carpentry. They’ll often start with just a basic set of tools, like some hand saws and chisels, and show you how to create your own workbench – or even sometimes a rudimentary setup for a lathe or mill.
It’s fascinating and often reminds me of software development. The tools we use to write code and build software are themselves software written in code. Our tools are typically created by other programmers, but besides the limitations of busy schedules, there’s absolutely nothing stopping us from building our own tools or taking something like Vim and customizing it to suit our needs.
That’s amazingly satisfying on a personal level – and amazingly powerful on a community level. It creates this automation feedback loop that has helped accelerate the rise of software.
7. Open Source
In a way, the previous point is just a more specific version of my general love of Open Source Software (OSS). Others have written about the incredible value of OSS, to individuals, to companies, to civilization as a whole. I won’t repeat their points. I just want to say how freakin’ cool open source is!
With the exception of Wikipedia and… I literally can’t think of anything else close…, open source software is the largest collaborative intellectual project humanity has ever attempted. And we programmers are here at the very beginning!
If human civilization still exists in some recognizable form in 100 years or 1000 years or even 10000 years, I expect we’ll still have some form of collaborative digital instruction sets, AKA open source software. I know it can feel like OSS is established and mature, but we’re only a few decades into this civilization-changing endeavor. That is literally awe-some.
8. Performance Optimization
Alright, let’s bring this back down to earth a little bit. Even after 20+ years, I still absolutely love working on performance problems. So much of what I work on these days is subjective and nuanced, e.g., organizational change that can take months to see the results of your efforts.
But troubleshooting performance is concrete and objective. This page loads too slowly. Fix it.
Often it’s a simple fix, like a database index or some caching, but occasionally, you get to really dig in and flex all of the knowledge you’ve accumulated over the years, maybe even get an excuse to push further into some esoteric bit of how disk swap works or something super nerdy and fun.
Then occasionally, it’s literally an impossible problem to solve directly with simple engineering effort. Instead you have to step back and re-envision the UX or the fundamental architecture, e.g., maybe you can just make it feel faster.
And at the end of the day, you typically have a clear measure of success. The page used to take 6 seconds with the largest payload scenario. Now it takes 300ms. Victory! Release the dopamine!
9. Removing Toil
These points have been pretty self-oriented so far. That’s fair. It is my list after all, but the thing that really got me hooked on programming as a career – not just a hobby – is how it can impact the world around me. At some point, I realized that I can use software development as a means to improve the lives of my fellow humans. That’s what made me decide this is a worthwhile pursuit for my limited time on this earth.
The rise of software has had profound effects on society, many good, some bad, but one thing I feel (almost) entirely good about is the removal of toil. Toil is that repetitive, manual work devoid of enduring value – the type of work that just has to get done but provides no avenue for expression, creativity, fulfillment, etc.
Imagine a task like reconciling an inventory list with system SKU codes and highlighting gaps. This is the type of tedious task that once required a human to spend hours every day mindlessly matching text – and it’s the type of task that computers are great at. Now that same human can spend their time reviewing the output of the software and making judgment calls, coordinating fixes with other departments, determining priorities, etc.
Automation can have obvious negative effects. But in general, I fundamentally believe that society is best when people from all backgrounds can engage in professional endeavors that let them bring their unique perspectives and talents. Having people waste their lives performing toil is not how civilization progresses. Writing software gives me a way to help with this.
10. Creating Something Just For Me
I’ll close with my first love. I originally got serious about programming as a hobby, because I had problems I wanted to solve. I was trying to figure out how to automate some BBS interactions. I got tired of waiting for a download to finish (or fail) and then manually issuing the command to start the next one (or retry). I remember thinking, “there’s got to be a better way.”
There was, in the form of a script… I think perl? I’ve forgotten the details, but it turns out that feeling is the core of what I love about programming. You get that feeling… there’s got to be a better way, and because you have the ability to program, there usually is a better way – if you have the will to create it.
I don’t fill my days writing code as often as I used to, but I do still write code for myself quite often. Just last week, I wrote a script to pull the price of an obscure piece of weightlifting equipment and log it to a daily CSV file. I wanted to get a sense of price trends, but the manufacturer website is too small to be covered by the big trackers. That’s okay. I’m a programmer. I can solve that.
These aren’t necessarily my top 10 favorite things ever about programming. They’re the first 10 ideas that came to mind, and as I wrote these, I thought of a dozen more. If you’re a programmer, I’m sure I missed some of your favorites.
The software development community is slowly becoming more diverse and welcoming to people from broader backgrounds. One of the things that’s so cool about that is seeing what parts of programming resonate with different folks, what new perspectives they bring. Please let me know if you dislike any of my favorites or have any big ones I should include in a follow up. Thank you for reading!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.