I want to come clean about a bad habit of mine: I am a habitual tinkerer. Some of my tinkering causes no harm, like when I resealed and adjusted a carburetor with little to no mechanical knowledge and it worked afterward. Or the times when I use recipes as guidelines instead of step-by-step instructions and ended up with a wonderful meal. Then there are times when my tinkering does more harm than good. I once challenged myself to take apart a perfectly good wind-up alarm clock and rebuild it. The clock never worked again. There are also many times when my experimental meals result in inedible food.

This tinkering also spreads to wanting to fix things around me that break or need updating, like, most recently, the time I tried to update an HTML template used to create our eNewsletters.

From time to time, we update/maintain our HTML templates. To implement change in the template, our Web development team must step in to update the code. Work time is allotted for such requests on an as-needed basis. Last time an update was requested, I thought I could handle the job. It seemed simple enough. I have a good understanding of HTML, I thought to myself, so why not save our Web team some time and resources by doing the job myself?

After updating the code, I checked the template to see if it still worked. Everything seemed to be functioning properly, but then two weeks later the template became corrupt. Of course, I didn't find out that the template was corrupt until there was an eNewsletter to publish. I worked feverishly trying to figure out what went wrong, but my untrained eye couldn't find the errors. I fessed up to the tinkering and call in the professionals. It took a member of our Web development team and I about an hour or two to fix my mistakes. The updates that took me thirty minutes to complete and our Web team one to two hours to fix would've taken our Web development team minutes to complete the first time around. Instead, I created more work for our already-busy Web development team. I also fell behind on a time-sensitive project.

The time I spent sifting through code with a properly trained person looking for my mistake taught me a valuable lesson: Let the professionals handle the maintenance. My "help" caused so much extra work that when all was said and done, it wasn't worth the effort in the first place. But you live and learn—hopefully.

If you're a tinkerer like me, let me offer you this bit of advice: Take a moment to consider the consequences of your tinkering before you touch anything. Carefully analyze the risks associated with your tinkering, especially if it deals with a work-related item. What are the risks—time- and cost-wise—associated with your efforts? Are you knowledgeable enough to do the job right the first time? My good friend does risk analysis and research before reacting. Because he thinks before he acts, he's excellent at knowing when to tinker and when to leave it to the professionals.

I've been following his example, but it's taken a lot more patience to adopt this methodology than I first expected. Fighting the urge to tinker without first analyzing and researching the solution is a tough battle for me, but knowing that this important first step could save me a lot of trouble in the end helps me quell those urges.

Are you a tinkerer? If so, how do you safely approach tinkering? If you're good at risk mitigation and you're a tinkerer, are there specific steps you follow before fiddling with an item?

Until next time, live well, learn from other's mistakes, and build better software.    

Francesca Matteu
fmatteu@sqe.com