Saturday morning, at around 1 a.m., I was woken up to an alarm informing me of a build failure, along with my partner texting me, freaking out because this recent branch — of a project we’re releasing in the fall — having to be complete by Monday for internal QA testers.

The Lie

“We have two days, it’s no big deal, we can probably knock this out in a few hours…so we’ll look into it when I wake up.” was my initial response.

How naive was I.

Due to what I will admit to be a misunderstanding of debugging in its entirety, more errors were introduced through the integration that was made.

Necessary integrations, mind you.

As we got to work and time began to dwindle, I could feel the anxiety coming in from my peers.

Something Was Definitely Not Right

“Yes, I know we have about 6 hours left, but if we can’t fix these errors, maybe there is something more to the situation…” I began to think.

In absence of thought, or a momentary lack of the necessary requirements to achieve a certain result, flaws or bugs are commonly produced in our software that can often drive us mad.

But should they drive us mad? 

Should we even be panicking right now?

Truth

Perhaps this bug was necessary…

Maybe it and all bugs are really meant to help us reach a better understanding of how we think about the software that we are writing, not to just fix them.

There are a lot of moving parts. 

I mean, this is a game and a multiplayer one at that. 

Maybe we are doing more than we should be doing. 

Perhaps that is the true message of this bug.

Making Progress

“I wasn’t certain, but I felt it was so.”

You see, most of us believe that debugging is about fixing a mistake or series of mistakes that were made. 

That the error messages we come across are meant to give us a walking pass to freedom — away from the endless stream of red appearing in our consoles.

But that is rarely the case.

Error messages are more or less meant to exist as a roadmap. 

Meant to make our systems stronger and also, meant to show us that there is no perfect system at the same time.

These error messages are meant to contain our panic, not encourage it. 

If anything, the only encouragement being for us to think even more about the various moving parts of the applications we write.

To remind us that there are always going to be problems, that there are always going to be mistakes which are introduced, but that there is always a remedy to the problems we face.

And our journey, in this circumstance, was to move towards doing less.

Through the course of decomposing a large integration into several minor integrations within our last 5 hours of development, we were thankfully able to one, focus on the important parts of this update and also, two, come to a better understanding of our project.

But it all began with what I like to call a false promise.