I love a good failure

Forcing myself to remain calm, I stamped up the stairs to the second floor of the building that the company I work for sublets. If ever there was a day to have a case of the Mondays, this was going to be that day. There are only five parking spots available to us, but all were taken. Visitors were in town, so I rolled into an adjacent unmarked spot in the morning, mistaking it as visitor parking. I was wrong. How did I find out? My car was towed — a gift from the gentlemen upstairs.

I had unknowingly slid into one of their spaces, and it was apparent from their reaction that they were not happy. Neither was I. I let them know. They let me know. Some unpleasant words were exchanged. Did I mention it was unpleasant? You might say we had a failure to communicate. My boss was very amicable regarding the whole situation. He picked up the fine on the company card. This will never happen again. I have learned my lesson. The experience will stick, like a pin in my side.

Adrift in a sea of routine

Every morning I pull into one of the same parking spots, get out my car, walk into the building, perform the tasks assigned to me, and return back to the safety of my vehicle for the drive home. Hundreds of thousands of programmers do the same, and it takes a monkey wrench tossed into the machine to upset this balance. Those are the experiences we tend to remember most. Those are the failures that grab our attention and shake up the routine.

Only a month after I started at my current job I was met with my first software engineering failure. Deployments are a rather tedious process, but I had documented the entire ordeal with extreme detail so that I could run through the procedures with a brainless enthusiasm. Believing firmly that I could multitask while copying and distributing .WARs across servers, I mistakenly unpacked files onto our production environment that were instead meant for an internal staging box.

It took only fifteen minutes and a call from customer service to our Systems Architect to realize what I had done. Customers could not complete orders. Thankfully it was a short lived ordeal, and rectified without financial recompense. The issue was identified quickly by viewing a single configuration file, but it was a failure nonetheless, and a good one at that. Whenever I deploy now I keep my mind on the task at hand. I shove aside distractions and focus supremely on a single job. Get it done… right.

Failure can be rewarding

That uncomfortable knot that twists up inside your stomach — you remember that. It can be like getting caught with your hand in the cookie jar. It forces you to question motives, process, communication, and even work ethic. Have you ever been red faced, afraid that a mammoth mistake will define your entire career? Did you ever want to crawl underneath your desk, and maybe just sleep the rest of the week through? You never forget something as insidious as a scathing review from your peers. Moments like these can breed more failure, or spawn an incredibly conscientious employee.

It happens to us all, and it can be rewarding. That is, if you decide to learn from it. You do not only know what you did wrong, or simply feel apologetic enough to avoid punishment for poor performance. Instead, the sort of lesson you learn from a good failure should speak volumes about your attitude and future outlook. Contemplating the failure should bring about resilience, and the fortitude to avoid failing again. This meditation should build up initiative, so that you can devise a correct solution when the next opportunity presents itself.

Scrutinizing oneself can be difficult, and this is the reason project postmortem examinations are uncomfortable, but personally profitable. Before I left my previous position the name postmortem was changed to EOPA (End of Project Assessment). Interestingly enough the focus changed as well, from drudging through the poisonous failures in a project’s life cycle to kindly debates about timelines and client eccentricities. I understand that a certain amount of hospitality must accompany sensitive meetings like these, but an inability to get right down to the business of addressing failures is a colossal waste of time.

A little encouragement

Wallowing in the muddied waters of failure might also seem like an enticing idea, but this self-deprecation will not improve your track record. Find encouragement and advice from other engineers who fail just as you do, and you will gain valuable insight. Ask for feedback, and if you have a mentor or friends in the field, ask them to share not only the failures, but any introspection they harbor. This exercise will improve your mood, especially if you are in the midst of a good failure.

Encouragement can also be found by sharing the tribulations faced daily. Although not always a quantifiable failure, spending hours, or an entire week fixing code can certainly appear to others to be a failure. Only other programmers will understand the frustration that you face every time you pop open your favorite IDE. I recently spent 4 hours to get Ruby to read a simple XML file. It was not that complicated. I know XPath. I know XML. Any project manager would take one look at those 8 lines of code and probably question my profitability.

I shared that with a coworker who has been struggling with some JavaScript. I was there once. Someone was where I was once as well. When we both see other more experienced engineers struggling with the same concepts, a sigh of relief is almost always let loose. We do not revel in their misfortunes, but we simply find comfort in the fact that everyone in some point in their career will fail. It is the same reason we love to read entertaining narratives that are even considered Worse Than Failure. They are indeed curious perversions that hold our attention.

I blame you

Although you may find hope in celebrating your successes, be sure to consider these good failures that result in growth and maturity. Stop patting yourself on the back, remember the difficulties you face, and the trials you have overcome. As many programmers will tell you — your code is crap. So is mine, and so is theirs. Occasionally, we are all failures. Realize this, and in time you will come to love a good failure, too.

The only other alternative is to push the blame on your fellow programmers. For this act of treason there is no hope, no escape, and no excuse. Even if you do not learn to “celebrate” your failures, above all else, avoid casting shadows over coworkers. Tame your tongue, and own up to your responsibilities. If the fault is not your own, how you handle the situation will be your own defense.

• Posted by Brian
• October 10th, 2007