My example above is about application performance, but this questioning-method applies to everything a developer does, from project estimation to designing for end-user usability. And it applies to every field! Stained glass artists accept as superstition that "lead is stronger than copper," but has anyone tested this assertion? Is it true? Some early experiments imply copper is equally strong. Woodworkers nod along when someone else mentions-in-passing which type of joint "everyone knows" is strongest; it wasn't until a couple of years ago that one magazine actually tested different kinds of joints for strength (with surprising results).

Superstitions are strongest (and most dangerous) when these "everyone knows" data points are hard to confirm or deny (such as most discussions of search engine optimization, since Google ain't talkin') and where "proof" is possible only through data triangulation. It's worse for developers and people in IT, I think, because things that were true a few years ago no longer are. In addition to questioning our own assumptions (or, as politely as possible, challenging the assumptions of people we work with), we have to test our knowledge against a time-stream. Last week, I flipped through a book on search engine optimization which pointed out that the "right things" to do five years ago are now useless... or worse.

Asking "Is that true?" does tend to upset some people, because they don't easily distinguish between a sincere question and an assumption that the listener is wrong. They are apt to think you're accusing them, saying, "This isn't true!" when you're asking "Is this true?" However, by asking someone to back up their assertions--as Linus Torvalds does in Linux kernel development—you're asking them to revisit their assumptions, to identify their confidence in the data and to check whether the speaker is repeating something "everyone knows" but may not be true at all.

I'll warn you: when people don't know the answer, they're going to get pretty mad at you. "Other people do it that way" sure isn't a good answer to, "Is that true?"—but that's the first answer they'll trot out.

Don't wait for Mike. Turn the question on yourself and your teammates. Instead of accepting others' (alleged) wisdom, take the time to revisit the question. Sure, write the code. Then look at the assumptions you're making, and ask yourself, "Is that right? Is there a better way?"