Programmers are optimists.

Programmers are notoriously bad at estimates. (Programmers are optimists.)

No program survives first contact with end users. (Programmers are optimists.)

No matter how much we try to predict the future or how many edge cases we can imagine, there's no substitute for the cold, hard crash of reality against our carefully constructed edifices. Two examples come to mind.

If you've written Perl before, spot the bug without running this program:

my %extensions_to_names = ( 001 => 'Rodney', 004 => 'Lucky', 020 => 'Daisy', 080 => 'Petunia', 108 => 'Tuxie', );

(Why do the animals have phone extensions? In a world of software telephony through Asterisk, the question becomes why not?)

Sure, the code aligns prettily and uses three-digit phone extensions where it makes sense, but four of those numbers are octal numbers. One is invalid. One isn't what you expect. The presence of the autoquoting fat comma doesn't fix this. Oops.

This is the kind of mistake you make without thinking about it because it never comes up. Then it comes up again. (Yes, the righter approach is to require an explicit base when writing literals in anything other than base 10, like 0b or 0x .)

We make these mistakes because of the assumptions we bring to our data, and we bring those assumptions from our experiences. As Tom Christiansen says, "You don't come from somewhere whose zipcode begins with a 0."

One of the reasons I use a single-word nom de plume and never capitalize it is to see what breaks. (Answer: lots of stuff.)

What happens if you're Icelandic and your surname depends on the first name of your father and not his surname? (Happened to a friend of mine.)

What happens if you don't have a middle name?

What happens if you're from a culture with a different order of names? What do you put in the little boxes in some startup's web form?

It's not just names. It's not just Unicode. It's not just the one true way to express street addresses or telephone numbers. It's every expectation we make.

How do you calculate the growth rate of free cash of a company when it's negative for the first few years, then turns positive halfway through? (What percentage is positive one million dollars greater than negative seven million dollars?)

As I see it, we have three overlapping pieces of solutions.

First, experience helps. As we do things wrong, find out why they're wrong, and fix them, we have the opportunity to learn things and do them less wrong in the future. Better yet it doesn't even have to be your own experience.

Second, knowledge of the world outside of programming helps, if you pay attention. The more you know about the world and its complexities, the more opportunities you have to learn about what can go right and what can go wrong, or at least the kind of information you will eventually have to scrub and munge and mangle into correctness.

Third, the sooner you deliver software to real users to break things, the sooner you can revise and fix your faulty assumptions. Keep a notebook. (I deployed software to friends and family over the past couple of weeks. Even though I thought I made it easy to use, they're full of suggestions to make it easier. Also they have a knack for finding weird bugs.)

If nothing else, move somewhere with a weird postal code and change the representation of your name for a while. I suggest Unicode symbols with weird casing and at least one punctuation character. If nothing else, you'll get your text editor settings right.