Skip to main content

The Ego Roller Coaster

In my varied life experiences, I have never encountered a vocation or activity that could build up one's confidence before snatching it away in such quick succession as in software development. There is magic in bending a computer to your will and having it execute your commands faithfully. However, as with all good tales of magic, there are many pitfalls, which can rapidly deflate your ego.

Little Oversights Can Bite

I once wrote database upgrade code that repaired some broken references in a database. This fixed several known defects. I was really proud of myself because the code came together quickly, it looked good and it worked well. It passed all tests and review, it was merged with the product and all was well. That is, until someone discovered that some databases were triggering crashes on upgrade. Fortunately, it took little time to find the source of the problem, but all of my pride vaporized, as I had to explain to my manager that I forgot to account for the possibility of null entries within the database.

Obvious is a Matter of Perspective

I was working on a side project developing an iOS prototype app for some clients. After many meetings hashing out the requirements and several months of development, I was ready to demonstrate my work for the first time. The clients were really excited to see their ideas presented back to them in a more concrete form. There were many technical challenges for me, as I had to implement several features I had never implemented before, but I thought I had done a good job, all things considered.

Of course, one of the first things the client did after starting to play with the app was press the Back Button. I stared, horrified in that moment, realizing that in all of my testing, I had never thought to press that Back Button myself. Of course, everything after that point was completely broken. I reset the app, and we tried again, but even after informing the client that the Back Button would break the app and needed to be fixed, she kept pressing it because it was just a very natural thing to do. This served as a wonderfully repetitive reminder of how incompetent I was.

Don't Leave Anything Out

Toward the beginning of my career, I worked on an issue that had been plaguing the product for a while and very much needed to be fixed before the next release. I spent several 12-hour days trying to find a workable solution, with each iteration becoming more complex than the last, as every path I went down failed for one reason or another. Finally, I stumbled upon something that worked. I coded it up and tested it during a couple more long days and late nights, and all looked good. After merging the code, the bug in the product disappeared, so the release went out.

I felt great. My manager had demonstrated a lot of trust in me to have relied upon me to fix the issue. He had restrained from reassigning the problem to our lead developer even when I was struggling, and I had solved the problem for him, reinforcing his trust in me.

Perhaps a month or so later, during a team meeting, we started discussing a peculiar bug that had cropped up. The behavior didn't make any sense in the context of the fix I had implemented before, so I was tasked with investigating further. After doing some significant research, I realized that I had missed checking in a particular file when I "fixed" the bug. This file was the one that invoked the logic that I had written to fix this issue, which meant my code had never actually executed inside the product.

This raised a lot of questions in my mind. How did the test I had written work if the code was never executed. Well, on my machine, of course, it worked just fine, as I had the missing file in my local repository. However, I had submitted the test; how did it pass on other machines? After closer examination, I realized my test was inadequate. It passed even in the presence of the bug. This was an important lesson for me. I learned it's always a good idea when possible to execute regression tests both in the context of the buggy code, to verify the test actually triggers the bad behavior, and in the context of the fixed code, to verify the issue is really fixed.

After discovering my test was flawed, one important question remained, why did the bug disappear in the product after I merged my fix? It turned out that someone else had simultaneously made some changes that happened to resolve the issue. Unfortunately, these other changes left open the possibility of future problems, which is how we ended up discovering that my fix was never really implemented.

I am sure you can imagine how embarrassed and ashamed I was that a key bug fix that I had worked so hard on had never really even made it into the product. The good news is that it gave me an opportunity to come up with a really clever fix for the subsequent problem that did actually get into the product and worked quite well.

From Hilltop to Facedown

Such is the ego roller coaster of software development. You're the king on top of the hill one moment, and the next you're lying face-down on the floor in a pool of your own vomit. Despite the bumpy ride though, it's always a great thrill and an adventure.

Comments

Popular posts from this blog

When All Else Fails, Use the GUI

In this blog post, I show you how I automated entering credit card transactions in QuickBooks using the PyAutoGUI package for Python. Automating routine tasks is a great way to save yourself a lot of time. Whenever I spend a significant amount of time doing a partiuclar task on a computer, I ask myself if there is a way to automate it. Generally, as long as the input to the task is located on the computer, the answer is yes. The kinds of tasks that evade automation are those that have some kind of physical medium as an imput. While there are technologies that could help automate those tasks, it is much more complicated and difficult to do so. For tasks that can be automated, my favorite language for doing so is Python. Python has a wonderfully readable, expressive syntax, and there are an astoundingly large number of libraries and packages available that make the job of automating jobs much easier. One of my favorite simple examples of how Python saved me a lot of time is when I

Yet Another Post About Text Editors

Here's a debate that will never end as long as people are writing code: which text editor is superior? While there is one that I regularly use, I really think the answer to this question is none of them. They all have their strengths and limitations. It often comes personal preference, convenience and the nature of the tasks you typically need to accomplish. What is less often discussed is why we should even bother with using a text editor at all. What is a Text Editor? I'm going to back up a bit though. Let's first ask: what is a text editor? A text editor is a program with the primary function of editing and manipulating characters on a screen and writing them to and reading them from files. While text editors are very commonly used in software development, they are not restricted to that purpose. Anyone who has any textual content to write or edit can potentially benefit from using a text editor. Text editors generally don't provide much in the way of visual form

Books That Have Influenced Me and Why

A mantra that I often repeat to myself is, "Don't abandon the behaviors and habits that made you successful." I believe this trap is actually much easier to fall into than most people realize. You can sometimes observe it in the context of a professional sporting event such as American football. One team might dominate the game, playing exceptionally well for the first three quarters. Then, as they sit with a comfortable lead, you see a shift in their strategy. They start to play more conservatively, running the ball more often than they had. Their defense shifts to a "prevent" formation, designed to emphasize stopping any big plays by the other team while putting less pressure on the short game. The leading team often looks awkward in this mode. They have switched their perspective from that of pursuing victory to that of avoiding defeat. They have stopped executing in the way that gained them the lead in the first place. I have seen more than one game ult