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. 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.
5. Vim
Need I say more? IYKYK, as the kids say. But really, my love isn’t necessarily Vim; it’s mostly about modal editing.
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.
On personal machines, I even set my shell to vi mode; so I can use (some) Vim key chords to manipulate command line args. Super confusing if you’re not expecting it. Super powerful if you are.
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.
11. Learning a new tool
Software engineering is still an immature field in many ways. That means our tools are constantly evolving. People are constantly creating new ways to solve old problems. Couple that with programmers’ penchant for laziness-driven innovation, and you have a wide array of utilities and open source solutions for nearly any problem.
I’ve had similar experiences in DIY trades. For example, you can free-hand angles in woodworking using a jigsaw and with enough grit and finesse, you can make it work. But then your serious carpenter friend brings over their miter saw, and oh man, those angles are so easy to cut, so smooth. Everything just lines up so nicely.
If you’re anything like me, that is an extremely satisfying experience, and if you’re being thoughtful, programming can also give you many opportunities to find tools that are perfectly fit to the task at hand.
12. Helping people
I’ve written previously about getting into engineering through an interest in video games and that drive to understand what’s happening behind the scenes. And while that’s true, part of what kept me interested in technology was the feeling of empowerment. Oh, this is something most people around me don’t understand, and I can help them understand it.
Yes, that means being IT support for friends and family sometimes. And yes, that can get tiresome when people have misaligned expectations, but that applies to most skilled professions. I know it’s true for doctors, mechanics, architects, lawyers, and so on. Everybody has to set boundaries.
At the end of the day, I love having a skill that gives me a way to help people, even if I do have to occasionally just throw my hands up and say, “I’m sorry. I have no idea what’s wrong with your printer. Did you try turning it off and back on again?”
13. Practicing magic
I used to read a lot of fantasy books when I was younger. I guess I still do, but I used to daydream about being a wizard, what it would actually feel like to have the power to say the right incantation or perform the right steps and change the world around you. I suppose great writing can do that, but I’ve never written anything I’d call magical. 😉
The closest I’ve ever come to feeling like I’ve performed magic is building software, especially in the DevOps side of things. You craft the right Ansible script or Terraform plan, and suddenly a whole fleet of coordinated servers is doing your bidding. It’d probably lose the thrill if you did DevOps all day everyday, but for me it’s infrequent enough that I still get a joyful, intoxicating feeling watching everything fall into place, like magic.
14. Turning ideas into reality
One of the coolest things about consulting is that we get to help so many people build products they never could have built alone – products that far exceed their original vision.
They might have an idea for a product, or they might only have a thorough understanding of the problem and the confidence that there’s got to be a better way. Either way, we have the ability to make it happen, to turn that abstract idea into something humans in the real world can interact with and benefit from.
I will never, ever tire of shepherding clients through that process of discovering what they’re actually trying to achieve and then helping them turn those ideas into a real, functioning system.
15. Diagnosing ridiculous Heisenbugs
A Heisenbug was originally a term for bugs that disappear when you try to look for them or recreate them. But it’s also a general shorthand for bugs that seem to happen randomly, appearing and disappearing for no apparent reason.
Most bugs in software are straightforward, a case you didn’t think of, a downstream effect you hadn’t considered, etc. But every once in a while, you start looking into the problem… and keep looking… and the behavior being reported is just not possible. But then just as you’re about to give up, you reproduce it accidentally. What?!?
That’s when you know you’re about to learn something good. It may not be pleasant. It may be a murder mystery where you are in fact the killer, whoopsie. But you’re about to fill a gap in your knowledge and level up your expertise.
For example, normally you can write a file to a drive if there’s space on the drive and the process has permission. Unless it’s an old FAT32 drive, and you’re writing to a folder with 65k files because a cleanup process failed sporadically. Yeesh, that was a particularly painful lesson for me personally.
16. Solving impossible problems
It often feels like anything is possible in software engineering, given enough time and effort. That is simultaneously exhilarating and exhausting.
Sometimes people ask you to do the impossible. And sometimes the answer is just no, the technology doesn’t exist yet. But more often the answer is well, it depends.
You brainstorm and research and have some whiteboarding sessions with colleagues. And often you can figure out a solution that previously felt impossible.
Protip: Impossible solutions are typically discovered by figuring out how to redefine the problem to be something solvable. Then you solve that problem instead. As a common example, if it’s impossible to actually make an operation faster, maybe we can just make it feel faster to the user.
I’ve dabbled in some other fields, but nothing has come close to programming, in terms of regularly facing problems that feel impossible only to eventually find a solution.
17. SQL
I’m so glad the NoSQL movement fizzled out a bit and became another version of the right tool for the job. I explored a lot of those alternate databases. They have their merits in the right circumstances, e.g., I love Redis and Elasticsearch. But I still think relational databases are fantastic general purpose datastores – they’re sharks not dinosaurs.
And a large part of why I love PostgreSQL and the rest of ‘em is the SQL language. Yes, it has some weird inconsistencies, and it’s not perfect. But once you grok the basics, SQL is a beautiful, intuitive way to query and manipulate sets of data.
Imagine joining multiple data sets on various keys, doing projections and aggregations, grouping, deduping, providing defaults for missing values, etc. Sure you can do all of that in Ruby, Python, C#, etc., and it works okay. But it’s so much cleaner in SQL. Or updating attributes of one set based on values in another correlated set? Yeah, no, I’ll be keeping my SQL skills sharp, thank you very much.
18. Psychic debugging
Oh, you’re having a weird problem with the system? Is it DNS? No? Are you sure? Okay, is it a character encoding problem? Are you sure you don’t have some smart quotes pasted in from Word? Maybe it’s cache not getting invalidated correctly?
One of the fun things about having some years in this field is that certain problems keep coming up. I’ve lost count of how many times a colleague has described a problem and without knowing anything about the code, I could accurately diagnose the bug. It can definitely feel like some mystical, psychic power, but it’s really just that I’ve made a lot of mistakes and seen a lot of weird stuff.
And for the record, the problem is always DNS. Even when you’ve absolutely ruled out DNS. Especially then.
19. Refactoring
Refactoring specifically refers to improving the internal structure of software while preserving its observable behavior, but more generally, it’s about cleaning up code without changing the functionality.
Some devs can find it tedious and a waste of time. But their opinion is wrong. Sorry. I think refactoring is one of the greatest joys of programming, especially when working on the same system for a long time.
How often in life do you get a chance to go back and fix mistakes of the past? How often do you get to revisit past decisions and update them to match changing circumstances?
For me, it’s not that often, and it is incredibly satisfying to stride into a messy section of code, envision how it could be structured more cleanly, and then methodically go about disentangling and deobfuscating. When you’re done, the tests still pass; everything works the same as before, but it’s no longer a part of the codebase where people fear making changes.
20. Being cool under pressure
This last one is not unique to programming, but it’s the context where I’ve gotten to experience it most often. Early in my career, I worked with some senior devs who just exuded calm under pressure.
You’d get a bizarre production bug report from an important client. Data is disappearing? What in the world? You’d start looking into the problem and get that sinking feeling in your stomach… oh no, something is very wrong. Adrenaline starts pumping. Oh crap, this is really bad. Time to escalate.
You pull in the lead dev and start excitedly racing through everything you’ve done. They let you finish and calmly go back to the beginning, maybe walk up to the whiteboard. “Okay, let’s start by listing what we know. Then we can list… ” And so on.
You go from freaking out to feeling like everything will be okay. It’s such a relief to have that person on your team.
And somehow, against all odds, I think I’ve managed to become that person in a lot of software engineering contexts. I can soak up the stress of people on the team and emit back a sense of calm. It’s not that I have some special ability; I’ve just seen enough software problems and managed to find reasonable solutions to them that I’m confident we’ll get through whatever this new crisis is also. Being able to provide this source of calm to people on my teams is highly satisfying.