I have heard many endings to this quote over the years. “If you aren’t making mistakes, you aren’t going to learn anything.” “If you aren’t making mistakes, you aren’t living.” “If you aren’t making mistakes, you aren’t taking enough risk.” There may be others. Take your pick. Choose the most appropriate quote for the situation and the individual you are consoling. Or go ahead and make up your your own. How’s about, “If you aren’t making mistakes, the problems aren’t hard enough.” It’s kind of catchy.
I have actually taken a liking to “If you aren’t making mistakes, you aren’t doing anything.” It works for nearly any occasion and it is 100% true. In software development, everyone makes mistakes. So, armed with this knowledge, what do we do about it?
First, we need to learn from your mistakes. No surprise here! Well, the problem is we don’t. We tend to get so focused on fixing our mistakes (and then we get so sidetracked by the praise which follows the amazing fix) that we neglect to put any time or thought into preventing the problem from occurring again. Here’s what I mean:
Web Service X is failing on all servers and it is negatively impacting all users. This is a code red. Fix this or update your resume. After 30 minutes, you identify the issue. Web Service X shares a database with Web Application Y which recently modified and deployed a few stored procedures. The stored procedure changes are causing the web service to continuously fail so you roll back the code and the problem is solved. The fire is out. Everyone is happy, but really, your job isn’t done. It’s time to document the dependency and share the mistake with fellow developers. Perhaps you could discuss in a post mortem meeting. If nothing else, post a note on your monitor which reads, “Web Service X must be updated and deployed with Web Application Y or else…” Or else three months down Web Application Y is going to be deployed and break Web Service X again. Round and round we go.
[ On a cynical tangent: You know you were the one who caused the problem in the first place, right? Want to be hero for a day? Try this experiment. Take down a server, wait for company-wide panic and then bring the server back up. Finally, listen for the whispers which will soon circulate through the halls. "Was the problem solved? Great. Who solved it? Great. They are so great! I don't know what we would do without them!" It's funny, but this type of thing happens all the time. I mean, who can solve a problem faster than the person who causes it? And doesn't everyone forget about the problem's cause once it is solved? Though it may sound silly, the quickest way to save the day is to be the one to ruin it in the first place. ]
Okay. Now we’re learning from our mistakes. (At the very least, we’re writing never-do-this-again warnings to ourselves.) The second thing to do is accept your mistakes. You must truly understand that mistakes come with the a coder’s territory and know that you are going to botch things up every once and a while. The underlying message is don’t be afraid of failure and try to spread this viewpoint to all team members. I know it is especially difficult if you have witnessed (or have been the brunt of) the fingerpointing when it is late in the project lifecycle and things are looking grim, but this is extremely important. You are going to do your best work if you aren’t worried about your next blunder. I’m not saying to throw caution to the wind and start coding with reckless abandon. To the contrary, you must continue to code with a lot of heart and consideration knowing that you are going to live to tell about your next mistake. The best way to become comfortable with your mistakes is to share them with others. Everyone likes a person who can admit their mistakes and poke a little fun at themselves. Here’s a fine example on how to put this to practice:
We hosted a small post-release party for the members of our development team recently. About halfway through the party, we went around the room and openly shared the mistakes which were made along the way. It was comfortable and safe and everyone had a story to share. My favorite story went something like this:
The QA department submitted a defect that our entire user base appeared to be male. Not a single female could be found in the database and the testers correctly deemed this an issue. We looked at the XML posted to us from our vendor. We found that each user’s gender was included in plain text as either “male” or “female.” From this, we knew there should be instances of female users. We then turned to the XML parsing algorithm. The mistake was easy to find since the code read “If the gender value contains M-A-L-E, the user is a male. Otherwise the user is a female.”
It was undisputedly a stupid, yet amusing, mistake.
Coincidentally, the defect was introduced by one of our better coders. This guy single-handedly coded a service which was the project’s foundation. He worked many nights and weekends and did everything in his power to ensure the project would be successful. Without him, we never would have met our deadline and no one could accuse him of “not doing anything.” The best thing is he was still contributing, even at the victory party, by demonstrating what to do about mistakes. You learn from them and you accept them. Eventually you may be fortunate enough to even laugh about them.