This post is a continuation of an earlier 10 Things I (Still) Love About Software Engineering, even after doing it for 20 years.
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!
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.
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.
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.
This post probably concludes the series of posts on things I still love about programming, but it’s funny, as I described these, I thought of several 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.