The Petty Tyranny of Good Habits

| 1 Comment

The most useful general purpose tool I've ever owned is a Leatherman. It has pliers, a knife, wire cutters, two screwdriver heads, a bottle opener, a file, and a punch tool. It's great to keep at arm's reach for those occasions when I need one of those tools for a moment. It's quick and easy, even if it's not always the rightest tool.

If I wanted to make coleslaw, I could cut cabbage with it (but cutting cabbage is easier with a mandolin slicer).

If I wanted to tighten the handle of a drawer, I could use one of the screwdriver blades (though a dedicated screwdriver of the appropriate size offers more leverage).

If I had to open a paint can, I could use one of the other small blades (though that takes more work than using a real pryer).

I'm sure I could even break through rotten sheet rock with the tool if I didn't have a sledgehammer handy.

Go to a restaurant and you won't see the prep chefs shredding cabbage with a Leatherman. Go to a cabinetry shop and you won't see carpenters driving screws with a Leatherman. Go to an paint shop and you won't see the mixers opening cans with a Leatherman. It's a great tool for quick and dirty things, but it doesn't scale to professional uses.

If only programmers could exhibit the same degree of professionalism.

Consider the debate over Ugly Old Perl:

  • "Why should I change working code?"
  • "Isn't there more than one way to do it? Stop being so rigid!"
  • "The old way works just fine!"
  • "This has never failed for me before."
  • "You're just a follower of fashion!"
  • "You're a petty tyrant who loves to tell other people what to do."

Here's the thing. If all you have is a Leatherman and you have a really quick job you can get done in ten seconds, that's one thing. (It still helps if you know what you're doing; opening a paint can with the knife is a great way to break the tool and lose a lot of blood.) If you need to do something else, bad habits don't scale.

If you're writing a tiny program that no one but the five-minutes-in-the-future-you will ever have to read and you know all of the characteristics of user input and output and the security considerations, go ahead and use global variables. Go ahead and leave your code unfactored. Go ahead and ignore the error codes of system calls. If the sole determinant of how well you've programmed is how quickly you can get from having no program to having a program and no one never, ever, ever needs to maintain it, make as much of a mess as you want.

With that said, I know very few programs which don't need to scale for maintainability. Sure, that function you've written just now gets away with clobbering a global filehandle without any ill effect you can detect, but can you guarantee it will continue to do so while other people write other code in other parts of the program? Can you guarantee that all code called from that function will respect the global filehandle you've created?

Good habits like lexical encapsulation, checking for error codes, and avoiding all unnecessary interpolation of variables you are (at least for now) confident are always completely safe help you enforce those guarantees and keep confidence in a system as it grows and changes under the hands of other people (including future you).

That's why it's important to teach novices the safest way to program first, and then show them how to manage working with quick and dirty code. Set their habits appropriately so that their code will help, not hinder, their ability to write correct and maintainable code.

1 Comment

If you never make mistakes then you never learn anything. Playing around with knives and making coleslaw with your leatherman are two of those things that we sometimes have to do so we can learn better ways to approach a problem.

With raising kids it's time to have the talk about knives when they can reach the knife drawer. And with learning programming it's time to learn about encapsulation and abstraction when you have enough details for the techniques to be of use.

This is why it's important to let programmers mess around and make mistakes before they're ready to learn better habits. A good teacher sets up the student to make the desired mistake so the lesson obvious.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on November 18, 2010 1:13 PM.

The Book is Out! was the previous entry in this blog.

Unnecessary and Insecure Interpolation is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?