In praise of mistakes
I’ve been talking to a lot of developers lately in order to make people work better together and get things done faster. One thing that keeps fascinating me is the length people go to not to communicate mistakes and problems.
We are very much happy to celebrate successes and point out the obvious benefits of what we produce and do, but there is an innate tendency not to own up to mistakes or to welcome people telling you what is wrong.
I once heard the quote “a good friend tells you they like your shirt, a great friend tells you that you have dirt on your nose before you go on a date” (I think it was on Sherman’s Lagoon).
Mistakes are a great thing. They hurt, they make us think, they make us angry and they make us learn. The one wrong thing we do with them is to take these negative gut reactions and vent them in the wrong direction in most of the cases.
This is how we are wired, the first cave-man finding a burning branch after a lightning storm will have put his hand in the fire and quickly found out that it is a bad plan. He then most probably told others (the ones he liked) not to do that. He probably also pondered to use that fire against the ones he doesn’t like – sadly enough something we seem to excel at as humans.
Making mistakes makes us fell inadequate and uneasy – we failed as the crown of evolution and should be better than that. They also makes us feel protective – we don’t want to own up that we make mistakes as that would make us look weak or stupid in the eyes of others. This is a mistake in itself as we all are fallible and do stupid things all the time.
Case in point: I was chuffed when my first A List Apart article was posted – having been a fan of the site for ages. The article JavaScript image replacement sparked a very strong counter-post by Peter-Paul Koch, aptly named Why ALA’s ‘JavaScript Image Replacement’ Sucks.
I was shattered. PPK was someone I looked up to and his post accused me of stealing his idea and code (we solved that riddle on a mailing list proving with time stamps that I did indeed neither) and his critique was partly very right but in other parts just over-zealous.
I was hurt, I was confused and – well – pissed off. Instead of grumpingly packing in or shooting back I actually looked at my code and fixed the issues PPK talked about. I also started communicating more closely with him and this started a long, great discussion and sharing of information and contacts.
I grew a lot by my mistake, and there are no hard feelings between PPK and me – I will be one of the experts talking at the conference he organizes later this year.
In short – making a mistake, being called upon it and fixing it made me a much better developer. It humbled me and made me realize that working with others (even if it is only for a quick sanity check) makes me a lot more effective than I could ever be on my own.
This can be applied to products: instead of celebrating the successes, we should be celebrating issues that have been brought to our attention. A bug is a chance to analyze what lead to it to fix it.
This is the real opportunity – we have to learn not to do stupid things. Instead of huffing and puffing and – worst case – putting in a “stop gap solution” or a “quick fix” we should spend time to see where the bug came from, what lead to it, what impact it has and document the way to fixing it. There are millions of “best practice” tutorials and examples but not many “here’s how we fixed a nasty bug that caused this and that” articles.
The reason is guilt and fear of appearing weak and fallible. Well, I personally think that owing up to the fact that you do make mistakes actually makes you strong. The same way that appreciating good work of competitors makes you more believable than just banging on about what you do and act as if others don’t do great things, too.
I am quite sure that if we managed to turn the development culture around to see mistakes as a positive, we’ll make a massive step forward. A person pointing out an obvious flaw is not a whistle-blower and “not on message” but someone you have to thank for providing a chance to really improve our work and learn not to do things wrong the next time around.
Mistakes are OK – they do happen.
May 15th, 2008 at 7:22 pm
I couldn’t agree more. It’s scary to put yourself out there, especially when you look up to the people critiquing you. So when I make mistakes, as I do on a regular basis, I take comfort in the fact that even if I’m wrong, I’m still ahead of the people who avoided risk by not even trying.
On the flip side, there’s no excuse for contempt when giving feedback; it doesn’t make you look stronger and can create an enemy when you could have had a friend.
May 15th, 2008 at 7:30 pm
We all know “fail quickly, fail often” but failing visibly is also incredibly important. At so many conferences speakers only talk about the great stuff they did; how awesome their clients are and how happy they are to be on stage. I want to hear about what went wrong, how the client was a arse and how you fixed it.
By placing the metaphorical ‘head on a spear’ and making it visible on the cross-roads of a decision helps other people who’re facing the same decision learn from your mistakes.
May 15th, 2008 at 9:41 pm
I’m a big fan of being one’s own harshest critic. A few years ago, after a similar (though much less public) experience, I decided that I’d try to get as much criticism as possible, and try to always be the first to pwn my own mistakes, but be genuinely grateful when it comes from someone else, and try to let them know that I appreciate it.
I’ve found 2 effects since then, which have convinced me that this is the right course of action.
1. It has a huge social ripple effect. Teammates are much more likely to point out my errors. They see me do it to myself, so they tend to not be uncomfortable about how I’ll respond. This means that my errors are more likely to be exposed. It also creates an atmosphere where others tend to be more receptive to criticism, and we can all stop tiptoeing around our code.
2. When mistakes don’t hide, there’s a lot less tendency to green-shift. (”Green shift” is what happens to a project’s status as it is reported up the management chain. The CTO thinks everything’s green, but the devs involved know it’s in trouble.)
Software demands honesty, and we should all still be friends afterwards.
May 16th, 2008 at 7:47 am
hey dude,
Thank you very much for this writing. Its rtrue that we must admit our mistakes in order that prevent others from repeating it.
The ego that we have has to go in order to attain better team performance.
May 16th, 2008 at 1:04 pm
For the record, PPK’s addEvent() recoding contest in September 2005 is another example of javascripters looking at each other’s work and derive something great from that. When Dean Edwards — a member of the contest jury — released his addEvent() solution a month later, it beared some striking similarities with the DOM0-based solution (entry #21) I had submitted but it improved things significantly enough that I didn’t raise the hue and cry.