The Inquisitive Coder – Davy Brion's Blog

Just read an interesting post from Leo Babuata about how important making mistakes can be. I quote:

Yet without mistakes, we could not learn or grow.

If you think about it that way, mistakes should be cherished and celebrated for being one of the most amazing things in the world: they make learning possible, they make growth and improvement possible.

I could not agree more. There are two mistakes in particular that have had a huge impact on my career, and that i’m actually very grateful for.

The first was when i once accidentally truncated 4 tables in a production database losing millions of records in the process. I actually learned a few important things from this. Checking your connection string to make sure you’re connected to the right database obviously being one of them. Not doing any important work before 8am is another one. The most important thing i learned from this? Being honest about your screw-ups. This happened in an organization where nobody ever makes a mistake (wink wink), yet things go wrong all the time. Whenever someone screwed up, they would call up the people from Operations, blame it on some kind of faulty process or whatever, never taking personal responsibility for it. The result was that the Operations guys made you jump through hoops to get the problem resolved. After my accidental truncation of those production tables, i called the Operations guys who were responsible for our Oracle server, and i said “Umm… i made a stupid mistake, and i accidentally truncated 4 production tables”. The silence on the other end of the line was deafening. It was like the guy from Operations was waiting for me to come up with an excuse, so i just asked “how can we get this fixed as soon as possible?”. And they just started working on the restoration process (which for some reason takes a couple of hours) immediately, not even requiring me to fill out a support ticket (which meant having to navigate in an application with about 16 tabs, some of them containing between 5 and 10 sub tabs, with each tab having about 20 fields on it).

Lesson learned? If you screw up, be honest about it, don’t blame someone else, don’t come up with an excuse, just tell them you screwed up. You’d be amazed at how well people react to that, and problems usually get fixed much quicker because of it.

The second huge mistake was about the 4th or 5th project in my career. It was a pretty interesting project, and was a lot of fun to do. It was an application that had to keep a lot of statistics on the usage of an intranet site of a large enterprise. One part of it was a nightly process which would parse the logfiles and store all of the data. The other part was a client tool to consult the data in variety of ways. The first version was great. Performance was pretty good (at first), and the application did what it was supposed to do. The users were happy. I was too.

Then some of the requirements changed. And i changed both tools. Then the requirements changed again, and again, and again. The code was quickly turning into such a nightmare, that i often feared making changes, knowing very well that each change was very likely to introduce new problems. The project turned into a maintenance nightmare (luckily, the only one i ever produced) and after about 2 years i was the biggest proponent of killing it and just buying some tool to do the same thing.

My biggest mistakes in that project were that i hadn’t designed my code to enable change in an easy manner, and that i had no tests whatsoever. When i had to make changes, it usually resorted in adding if and/or switch statements here and there, and lots and lots of debugging. I just didn’t know any better at the time. It actually took me a few more years before i actually started writing tests, but it did have an immediate impact into how i started designing and writing code.

Ever since that project, i’ve been gradually moving towards keeping code loosely coupled and making sure that, when necessary, i could easily change parts of it with confidence, or even replace parts altogether without affecting other parts of code. It took me a while to get there, but these days i’m pretty sure that i can deal with a lot of changes, in pretty much every layer, without causing new problems or decreasing the overall quality of the system. I may have gotten to this point without having first created a maintenance nightmare, but it probably would’ve taken me a lot longer to realize the benefits to all these hippie patterns and practices that we now subscribe to.

So yeah… learn from your mistakes, and be thankful that you made them.