How I Avoid Making Mistakes

No one likes to be wrong, except maybe the class clown; even then, I'm sure they don't like it if their incorrect answer does not get any laughs from the others. I especially hate when someone breaks the build, and the cause turns out to be a change that I made. I learned long ago not to try to chase perfection. However, I also learned there are many things that can be done to improve productivity and success.

It's Only a Mistake If You Do It Twice

That's not the actual definition of a mistake, it's simply a new frame of mind to help see a different picture. Here's the actual definition of a mistake:

mistake
noun
1. An action or judgment that is misguided or wrong.

verb
1. To be wrong about.

If you misjudge and action, but you know not to make that same action, you have just had a learning experience. You have learned something from the first time you made the mistake, and you don't let it happen again. To continue to make the same mistake over and over means that a person is not learning from your misjudgments. This could be for a variety of reasons, they are careless, ambivalent, distracted, or even they take away the wrong lesson from each time they recreate their learning experience (LE). But that's not you. You're here to learn how to reduce the number of mistakes that you make, or at least the number that others have to know about.

What Went Wrong?

This is important. If you have made a mistake, be sure to find the cause of the mistake. Not just a potential cause, but the actual cause. At least when that is possible. You will not be able to change your behavior, or improve your judgements unless you know where you were wrong.

Consider the Flight Recorder on commercial aircraft, also known as the Black Box (although we all know that it is really orange.) These devices record important information with respect to aircraft for the purpose of investigation of accidents. There are two data recording components, the Cockpit Voice Recorder(CVR) and the Flight Data Recorder (FDR). The CVR generally records the last 2 hours of audio from the cockpit. The FDR records at a minimum, 88 data parameters many times per second. The information from both of these devices are used to analyze and help identify the cause or contributing factors to the accident.

Chances are that you don't have a personal black box to analyze and reconstruct your mistake. Hopefully the mistake, I mean learning experience, occurred recently. The details will be clearer in your mind. Things like:

• What was I thinking?
• What caused me to believe that?
• Was I under time pressure?
• Was this a quick fix that I forgot to return to?

When you are programming, you make a quick change, recompile, run, and the change does not work, you know what you last changed. That information is fresh in your mind so you know exactly where to go to analyze, and attempt to correct the problem.

Whenever a colleague states that they had to fix some code that I wrote, I ask them where, and learn what the change was. Or if it is more convenient, I go silently perform a diff with the version control software to find out what I did wrong. Then I can start analyzing my mistake.

It's much more difficult to analyze your hopeful LE when you made the change two weeks ago, or six months ago. Your change completed the immediate task at hand, but at the expense of another part of the program that went undetected. It becomes more difficult to remember the details as time passes. At the very least, you need to understand the details that answer What to be able to avoid creating the same situation again. You don't always need to understand Why that is a problem; only that things like using the hair-dryer in the bathtub cause a problem.

A Personal Learning Experience

I remember when I was six (no I didn't use the hair-dryer in the bathtub.) I was making macaroni and cheese, although it could have been Kraft Cheese and Macaroni. I don't know for sure, but I do know that fact is not important. The noodles were cooked to perfection (probably), and I was going to drain the boiling water from the pan into a colander in the sink. Sitting underneath the colander was an ugly green 70's era glass pitcher. I poured out the water into the sink, draining over the pitcher, and the pitcher cracked and fell into a number of pieces.

I didn't understand then, the reason why the glass cracked. But I did surmise that it was not a good thing to pour boiling hot liquids over cold glass. Ever since then, I check the sink for glass items before I drain hot liquids into the sink. I am not sure, but I think it took another LE to discover that pouring ice-cold liquids over hot glass has the same affect. Also, I think it's likely that I didn't get in trouble for that LE because I was doing my mom a favor by breaking the pitcher. The point is, some times knowing What is enough to avoid making a mistake. Consider that half the battle.

The Value of Why?

If you can learn enough information to determine Why something went wrong, then you will be on path that can help you recognize similar situations that led up to your previous LEs. If I had a basic understanding of thermodynamics and the forces involved with the rapid expansion of molecules with the application of energy, I may have been able to deduce that something similar could happen in the opposite direction when energy is removed. However, I did not have that understanding, and simply gained another LE.

Let's imagine you are working with a developer that constantly makes mistakes, and these are their responses through progression of mistakes.

• So what if I don't delete my dynamic allocations? When the program exits, the system will do it for me.
• I did what you asked, other objects ask for this pointer, I am sure they call delete when they are done.
• Fine, dynamic memory is too much trouble, I'll just put everything on the stack.
• I can't put everything on the stack?! It's not large enough?! Fine, I'll make everything global.

Technically, this developer is not making the same mistake over and over, it just happens to be a different mistake in the same context. These mistakes haven't become LEs for him. It's as if he is using finger paints, and keeps rearranging the placement of colors. The colors slowly blend and pretty soon the only color on the paper is brown, and this developer is content to paint with brown.

Why does he continue to make this series of mistakes?

Clearly, this developer does not understand computer memory management.

Why is important to understand for you to be able to change the circumstances and decisions that led to the LE. You will also be able to recognize similar situations that result in the negative outcome. This could even be true for situations in completely different contexts. If you cannot understand why, you are most likely doomed to continue make mistakes, that will feel like Déjà vu.

How to Avoid Mistakes

I was about to summarize and end this post, then I realized I haven't told you how I avoid mistakes. Thinking about it, my tendency to fire off emails with an important attachment, but forgetting to add the attachment, just helped me avoid making this mistake. I sometimes still send off those emails too quickly. As for the "Reply to All" button, it's like brown paint to me, and I usually avoid using it as much as possible.

Learn From Other People's Mistakes

I think the best way to avoid mistakes, is to make other peoples LEs your own. Then you never have to experience the pain or embarrassment that you just witnessed. Unfortunately, it's not that simple. For some reason, we don't like to listen to our parents, mentors and colleagues, and make a mistake. It really is a mistake because they "Told us that would happen." It frustrates me to no end to watch my kids make the exact same mistakes that I did, even after I told them the story of how I made that mistake.

A Collection of Small Mistakes

If you seem to be making the same mistake over and over, hopefully you can at least mitigate it to small relatively harmless mistakes. Such as sending of an email without the attachment. You can usually recover by quickly sending a second email, be sure to add the attachment first, then add a little joke. If you fire off that second email without adding the attachment, you should step away from the keyboard and take a walk and reflect on what you just did. You're escalating the original small mistake. However, making that same mistake from time-to-time does happen. After I made that mistake many times, I avoid that mistake now by adding my attachment first, then I write my email. I haven't figured out how to mitigate the overuse of the "Reply to All" button.

Controlled Experiments

As I grew older, I am certain that I cautiously experimented with boiling hot water and different materials in the sink to see which ones can't handle the abrupt change in temperature. Thinking that was odd when I ran into Corningware and Pyrex. In this situation I wasn't ignorantly content with just avoiding glass. I'm not content with only using brown paint. I was curious. I was doing Science!

I still do experiments when I learn of some misguided action that I have taken. Is it a misunderstanding of the programming language I am working with? The way the product was designed? Something non-programming related? It doesn't matter. I experiment to understand. Then I avoid repeating the experiments with negative consequences.

Write It Down

I don't mean write it in your diary for you to review periodically and dwell on the mistakes you have made in your life. Most people have plenty of those already. I mean as another way to understand what happened. You write it down on a piece of paper, as if you were explaining it to someone. You want it to be more than simple notes to remind you what the mistake was, because that doesn't force you to think through all of the details. And that is what is important, those details that we tend to abstract away and over-simplify. Then throw the piece of paper away, because you found clarity in what you wrote. Alternatively, you could talk it through with a colleague or someone you trust. Clarity often appears, and you remember when you actively fill in the details.

Summary

The idea for this entry came to me when I helped a colleague get a test tool up and running. It turned out to be something simple like a missing semi-colon that I spotted after we had been looking for about 10 minutes. I think he was embarrassed, and I said "It's not a mistake, it's a Learning Experience... Just don't let it happen again."