Given enough cautionary tales, can we become better developers?

A recent tweet by Smashing Magazine about mistakes got me thinking about all the times either myself or a colleague had made a significant mistake. I’m not talking about a white-space error here. I mean the sort of mistake that gives instant, sinking nausea. Your heart sinks and your stomach knots up as the realisation comes crashing down; I did this, and the only way out is through.

You see, I’m a great believer  that “mistakes maketh the developer”. I’m pretty sure that @phpcodemonkey is tired of hearing me say it at every opportunity. I appreciate that there are many facets to a developer, but a key one for me is dealing with disasters or better yet, avoiding them totally. So even though you can recite a good Fowler book off by heart, it’s no good to me if you become some trembling wreck in the corner because a MyISAM table crashed. Don’t get me wrong, I don’t want to work with Inspector Clouseau, constantly wrecking things as he makes his way around a system, but let’s say I’m skeptical of a developer who can’t provide a juicy anecdote to “what’s the worst mistake you’ve ever made?”

Story Time

A friend of mine (no really, it wasn’t me) issued an UPDATE statement on a table with 6.5 million rows … without a WHERE clause. Perhaps the worst casualty of this episode was his pride; in that particular instance, it was the communal “dev box” so impact was minimal. In the next few years I worked with him, he never made the same mistake again and I bet he’s never done it since. I know I haven’t and I certainly don’t intend to any time soon  (touch wood).

And so what happens now?

Every seasoned developer starts with a SELECT, works their way to a satisfactory set of criteria, then changes the SELECT to an UPDATE. That, to me, is the sign of someone who has been stung by a run-away UPDATE statement. Stitch in time saves nine an’ all that jazz. There are lots of other work patterns which may seem inefficient at first but once you have the back-story from a developer, it would make sense.

What’s your point?

Isn’t there some sort of stack overflow-esque repository of cautionary tales, categorised by technology which can be used when training junior developers I’d like to combine the conciseness of Clients From Hell, the anecdotal tech focus of The DailyWTF, and the tagging/categorisation of your average WordPress blog. If the repository got large enough, imagine the huge collective wisdom stored within. You could have a Friday afternoon activity where your team finds good stories and presents the set up, the point of failure and the preventative cure. Suddenly, all developers are benefiting from others’ mistakes.

 

Posted in Development, Ramblings
3 comments on “Given enough cautionary tales, can we become better developers?
  1. Paul M says:

    Brilliant! I once worked at a (fairly well-known) B2B teleco. There was no proper dev server, and no backup server. I had continually badgered the boss for proper backups (rather than a MySQL dump of a night that downloaded – over several hours – via SCP). His response? “I pay you enough not to make mistakes”. Heh, so no pressure!

    Needless to say, working late one night, I managed to erase the entire day’s call logs for all of our customers, and – worse than that – settings for any lines we’d set up that day, customer preferences, etc.

    Thankfully the customer service staff managed it well and we lost no customers…

    … I however apologised but stood up to the boss – and got fired!

    Lesson learnt.

    • adrian says:

      That’s a rough deal. I guess I’ve been lucky because I’ve never had a typical “boss from hell”.

      I’m sure you wished him all the best :)

  2. Russell says:

    Great post, I love the idea of there being a repository of cautionary tales! An example from myself of a lessen learned from refactorings gone wrong.

    I don’t use the “plip” operator, for example I’d write “if (variable == false)” over “if (!variable)”. It may save those keystrokes, it may even read more naturally, but it’s such an easy little symbol to miss when refactoring code. That one’s burned me too many times!

    Russ

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">