If there’s one thing that’s made it possible for me to learn as much as I have, and create as much as I have, it’s that my default attitude about things, especially technical things, is that I’m probably wrong about them.

When I first took up CSS and it didn’t do what I expected from reading the spec, I started creating simple, focused tests of each property and its values, to figure out what I was getting wrong. Because I wanted to be sure, I built tests for all the properties, even the ones I was confident about understanding—and, in places, found out my confidence was misplaced. Eventually, those tests became the CSS1 Test Suite. Since I had discovered that, in a lot of cases, the browsers were actually wrong, I decided to document CSS support in browsers. That became the CSS Mastergrid (long since gone). On the strength of that resource, I started writing articles to explain how things worked, or didn’t, which led to writing my first book. And so on.

But it all started because I assumed I was wrong about how CSS should work, not that the browsers were fundamentally broken. Simple test cases seemed like the best way to find out. One thing led to another. In a lot of ways, you could say that my career was made possible by me assuming I was wrong, and setting out to determine exactly how wrong I was.

It’s not that I want to be wrong; in fact, I dislike being wrong. But I dislike continuing to be wrong much more, so I try to find out how I’m wrong, in hopes of becoming less wrong. It’s not even “strong opinions, weakly held”—it’s more “strong suspicion of error, strongly pursued”. In public, when necessary. (This is where it helps to be willing to look like a dork, or even a fool, as Kitt wrote about yesterday.)

When asking for help, this is the approach I take. When I post to mailing lists or forums, it usually comes out as, “Here’s what I think is so, but results don’t match that understanding. What am I missing? Please help me get it right.”