How to Learn From Your Programming Mistakes (in 5 Easy Steps)

Once upon a time, I made a very big mistake on a project at work. It was astonishingly stupid of me.

I’ll share that wonderful event with you tomorrow (see how I’m craftily tempting you to come back and visit me again?). In the meantime, here’s my take on how you can learn from those moments you’d rather forget…

1. Acknowledge what you did wrong

Even in this day and age of tools that record everything, automated comments, log files and digital history, there are still programmers out there who won’t admit when they have made a mistake. This varies from the vague ‘I don’t know how that happened,’ to the more outrageous ‘It wasn’t me!’.

Programmers, more than any other professionals I know, are very protective of their work and hate to look like they don’t know what they are doing. Compounding this is the culture of schadenfreude in finding fault with peers, and the retelling of major errors over and over again, especially on team events and nights out: “hey dude, at least I’ve never checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”

These stories, that provide so much amusement to everyone listening (except the protagonist), are popular because they make us all feel that we aren’t the only ones that make mistakes. And you know what? That’s actually a good thing.

No one gets it right all the time, so why try and hide your errors? As embarrassing as they are, covering them up and trying to forget about them is counter-productive. Not only are you trying to fool others that you never get it wrong, you are also fooling yourself that you don’t need to improve, or take more care, or understand a tool better, or learn something new.

So next time you check in a source file and find you’ve accidentally left memory leaking all over the show, stand up and be proud to admit it. In fact, get in first and tell people what you’ve done. Throw your hands in the air and shout about it. Apologise to your manager for causing 15 crashes in the overnight test suite.

Be human and accept that the only errors computers make are the ones we tell them to make.

2. Understand why it was wrong

In some cases this is easy, but in others you need to really look at why you made the mistake in the first place. If you don’t really, truly understand exactly what the error is that you made, and why you made it, you can’t be sure that you won’t ever do it again.

Was it a lack of understanding in a particular area? Maybe you don’t fully appreciate the workings of the library you are using, or your knowledge of pointers is less than perfect, or you’ve never really worked with this particular language/algorithm/operating system.

Whatever it is, understand why. It could be as simple as the fact that you were rushing and trying to do too many things at once (focus, people – attention to detail is one of your biggest assets). Or it could be that you were making modifications to code using intuition rather than knowledge. (Oops. Guilty.)

Once you know exactly why you made a mistake, you are a very, very long way ahead of the person next to you that just sweeps it under the carpet and tries to forget about it.

3. Commit to improving

Here’s the hard bit. This is the step that won’t happen instantly and that won’t happen by itself either. You HAVE to make the effort to improve in the area in which you made the mistake.

Created a mind-boggling memory leak? Read up on malloc and free (or new and delete; pick your weapon and don’t get them mixed up). Got your iterators all over the place? Go back to basics with STL and learn what you were trying to do.¬†Deleted an afternoon’s worth of code by accident? Get the manual out, google a tutorial, or read the help files and understand the tool you are working with.

Make the commitment to NEVER make that mistake again. But if you do, go back to step 1 ūüėČ

4. Look back and laugh (eventually)

It is very important to maintain a sense of humour about your mistakes. Going over things you have done wrong can destroy your confidence and leave you sitting in a corner, unwilling to contribute, failing to suggest ideas, refusing to raise your hand, and staying out of the debate.

Never let a big programming mistake, especially a publicly humiliating one (my story tomorrow!), take away your confidence or your desire for learning. Don’t give up.

If you admit your mistake, understand it, and improve your knowledge, then you will be able to forgive yourself.

And you might even end up as the one saying, “Hey dude, do you remember that time I¬†checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”.

5. Be gracious when someone else makes a mistake (very important)

I’m not saying you can’t laugh at someone else’s coding misfortunes, or that you have to cuddle your colleagues and tell them it’s OK to mess up the overnight test suite.

What I am saying is don’t go overboard on the humiliation. We left a voodoo doll on the desk of a colleague that messed up a release build one evening (OK, that’s actually quite horrible). BUT we were nice about it. We rallied around and talked about the disasters we had caused, we supported his mistake by talking about our own.

Remember that you’re all in it together. Your team, however diverse and intelligent/incompetent they are, will ALL benefit if everyone approaches mistakes with the right mindset.

Admit.

Understand.

Learn.

Laugh.

Join in.

Easy, eh?

10 signs the C++ will make your life hell

You think it’s going to be great. There are subtle signs it isn’t…

There’s an exciting new task on the horizon. You’re really looking forward to getting your teeth into something new.¬†The morning finally arrives when you get to sit down and take a look at your new charge. Oceans of lovely C++ code, untouched by anyone for months, maybe years, and now it’s all yours. You dream of the efficiency improvements you will make, of the features¬†you’ll be able to add that will make you look like the department coding superstar.

Yes – this project is going to be the making of you.

Two days later, you’re pounding the desk in frustration as yet another attempt to improve a class or function doesn’t work quite¬†as you expected. What small changes you have managed to make leave you with a feeling of uncertainty since the program is¬†crashing intermittently and you have a suspicion that your code might be the reason.

There’s no documentation, you can’t understand the endless layers of complexity, and the whole thing seems to have been written¬†by someone who wanted to deliberately obfuscate everything they were doing.

Your manager is asking questions about timescales and suddenly you realise your predicament for what it is:

LEGACY CODE HELL!

Here are 10 signs to help you see it before it hits you:

1. There are more than fifteen class header includes at the top of each .h file, and an additional five that are commented out.

2. Some classes contain methods that are thousands of lines long.

3. All the variables have tiny names, like “i”, “n” and “_kl”.

4. The ghosts of programmers past have written unanswered questions instead of comments in the code:¬†¬†“//Is this a call for registering??”

5. A base class has overloaded the ++ operator, so it does more than just ++.
(It takes you three days to work this out, as the effect is so subtle you start to think you are actually going mad before you stumble upon the root of the problem)

6. Coupling and dependence is so high, every time you change anything the program segfaults when you run it.

7. Code is obviously copied and pasted between lots of different cpp files that all do a similar, but not-quite-the-same, thing.

8. Everything is mutexed to within an inch of its life.

9. The code is compiled without -Wall.

10. You turn on -Wall and get 532,764 warnings.