Programming is the worst profession, except for all the others
Software engineering is an exceptionally rewarding career, except for the majority of the time when it’s the worst of all professions. After all, why would someone suffer though long periods of time trying to figure out why something that clearly should work is instead spitting out incomprehensible results.
You stare at the screen in disbelief, and decide its time for more coffee. There literally is no way the result you observe should be happening. This is not what you told the computer to do.
And yet there it is. Deadlines looming. Your code is not working, and you have no idea why.
Your mind wanders to the last sprint close-out meeting when the business folks ask why things are taking so long. Alas, if you could only describe the current state of affairs in a way that would resonate with them.
Many hours later, you finally realize the cause of the problem. It happens a few moments before you are about to completely give up, close your laptop, and peruse job boards to find your next position after you get sacked for this debacle.
The Tyranny of a Single Character
Of course, it’s all due to a single character located within many thousands of lines of code. A single equals sign sits there where you thought you had typed two. In software, this is the difference between an assignment and a comparison.
Computers have the benefit of interpreting your assignment expression as saying, yes, that is true. Despite your intentions, this condition is true, therefore go do the thing that you thought only happens some of the time.
This reminds me of the best kind of problem, one of the intermittent variety. Sometimes your software works just fine. Except when it doesn’t. Those are the best ones to figure out, because there are even more variables (pun intended) involved in figuring out what is going on.
The one reason to suffer the slings and arrows of outrageous programs
So why do software engineers go through all of this? Sure, we need to earn a living like everyone else. But there are other ways to do it. Yes, software engineers are compensated fairly well, but there are other professions that pay even more.
For me, it boils down to one reason. Solving customer problems using technology is a nice feeling, but it’s not the main driver. I have interviewed hundreds of candidates throughout my career, and I estimate about half say they want to work in a role where they can solve tough problems. This is something they enjoy, like a puzzle waiting to be untangled or decoded.
Problem solving is certainly rewarding, but it’s a side-effect of what got me into this racket. The magic of software is that there is simply no easier way to build something of value.
The Intrinsic Reward of Creating Something
The maker culture permeates the software world. The DIY mentality to go out and create something potentially meaningful. I would not be so presumptuous as to say it puts your stamp or mark on the world, but its something like that. Who doesn’t want to create something that will be valued by others?
I don’t think its even around anymore, but I was no good back in wood shop class. I once built a horse shoe pit in my backward, but even then I needed help from my neighbor. However with software, I can sit down at my desk and in no time create games, utilities, or applications that analyze Bitcoin price action.
Some of these programs I create are things that real, live human beings, even those outside of my family, might acknowledge to be actually useful or enjoyable.
This is why open-source software is so prevalent. Contributors don’t get paid (at least not directly) for their contributions. Rather, the engineer’s true desire is recognition for what they have constructed. To see others use, enjoy, and value your creation is the ultimate reward. This is the true reason in my mind to pursue this profession.
Science, Engineering, or Just Coding?
Its becoming slightly less common or considered a prerequisite, but many programmers obtain degrees in Computer Science. We fill job positions titled Software Engineer. These terms “Science”, “Engineer” … these are somewhat fancy words to describe who we are and what we do.
Ironically, it seems to me you rarely get the opportunity to use true Computer Science skills, unless you work in hardcore areas such as operating systems or hardware. I worked at Amazon Web Services for 4.5 years, and I did actually get to exercise CS skills there. Mostly, this was in regards to scaling services up to the ever increasing demand and number of users that AWS has.
Beyond that, I find that coding gets “scientific” when I am creating user interfaces. Not web pages, of course, but actual graphics where you need to calculate x and y coordinates. It’s actually probably more mathematics at the end of the day and not computer science, but at least its STEM.
Meetings, sprint planning, and documenting requirements don’t usually feel like science, but they are necessary elements. Most agile-based methodologies at their core seek to minimize process and planning, and maximize software development time. Just don’t ask when things are going to be done.
Besides, what is the definition of “done” anyway?
Beautiful code is the dream
Our dream of building something of value is often encumbered by the fact that the vast majority of time, we are modifying existing code rather than creating something new. The existing code we are forced to work with, or “enhance” as they say, typically has almost no explanatory comments but it does feature nine layers of indirection when one would have sufficed. It was written by a well-intentioned, but clearly misguided engineer on the team before you.
Almost by definition then, every engineer wants to “refactor” the code on the project to a style that they prefer, i.e. readable and elegant. But delivery schedules rarely offer time for this, so we are confined to adding a few lines of code nested within one of the indirection layers that abstract every conceivable thing the software would ever want to do. The overall goals of your team will probably change five times this year, but you won’t ever need most of the flexibility that was so thoughtfully coded in by your predecessor. I’m sure it made for a nice class diagram though.
Maybe I am just getting old and my view of things is different now than when I first started. One of the joys of being over the age of 40 is that your eyesight inevitably deteriorates leading you to sometimes mistake an equals sign for a minus sign, or vice versa. These are my favorite bugs to discover. After two hours I finally realize my mistake, either though dumb luck, squinting my eyes, or leaning in towards the screen. Any of the above might lead me to catch a glimpse of this ridiculous error. Solving tough problems, that’s what I do.
Your mental model does not equal reality
As in life and relationships, the primary challenge is discerning the difference between your mental model of the world and the reality of what is actually there. In my mind, I wrote the algorithm exactly as I designed it, and any output except for 100% accurate results is implausible.
In reality, what occurred was I translated that mental model into a logical algorithm, wrote code that implemented the algorithm, typed the corresponding characters and instructions into the computer, and then asked the machine to kindly interpret those instructions. At any one of these steps, there are plenty of opportunities for things to get lost in translation.
Life has the same problem. We have thoughts in our head, and we form a mental model of the topic at hand. The challenge lies in that our job is not done. We need to transform that model into words so that we can communicate the ideas to others. Then it is the responsibility of the recipient to perform the inverse transformation and convert the words into ideas in their own mind. When you think about it, its a miracle we are able to communicate anything effectively at all.
Likewise, it sometimes appears to be a miracle software engineers are able to get a program working according to specification. Fortunately, we are usually allowed to get it wrong many times first. This is what we call development and testing. We only need to get it right once at the end, and that is the version of software that gets shipped.
Relationships are often not this forgiving. If we say something stupid, you can’t take the words back. If we do something impolite, we can apologize, but we can’t undo it. The person on the other end of the conversation or the recipient of our actions might not be so pleased.
This often-wrong-but-right-once property of software is indeed an appealing characteristic. It gives us freedom to explore and try things. Software engineering does have some redeeming qualities after all.
Combine that with the fact we get to create something where there was once nothing. All from the comfort of our own home. Or Starbucks.
Green Fields and Tee Boxes
Each time you sit down to write software, its like the first tee in a round of golf. You may never have broken 90 before, but at that point, anything is possible. You could shoot par today if everything falls into place.
Likewise in software, you could also create the next social media platform, game that sweeps the nation, or decentralized finance application that revolutionizes the world.
That is the power of software, and its a fantastic reason to pursue this profession.
Ok, that’s it for me. I’ve got to go work on a pinball game I am creating. Why do that, you ask? There are a number of similar games you can play online or purchase. Don’t worry, mine will be better. Or at least it will be something I created.
Follow me on Twitter or kindly clap if you enjoyed this and would like to hear more on simplifying your code (and life).
