Things I unlearned

Somebody asked me last month for something to read about naming conventions, and I went into my own archive to find the BEM post, and made the mistake of reading it.

Extremely sure of itself. I stand by roughly the technical content and I found the person writing it hard to be around, which I think is the actual return on keeping one of these for 11 years. You don’t get a record of what you knew. You get a record of how certain you were about things that were about to change.

So, six of them. Not the ones I got wrong on the facts, which are boring and mostly about browsers. The ones where I was sure, and the certainty itself was the mistake.

That a class name should describe what a thing is

I spent 2014 and 2015 telling anybody who’d sit still that a class name describes what an element is and never what it looks like. mb-3 was a moral failure. I could produce the argument on demand and it took about 90 seconds.

I wrote the post admitting otherwise in 2017, so this isn’t news, but it’s the cleanest example of the shape so I’m keeping it in the list. What actually moved me wasn’t the argument for utilities, which I’d heard and rejected several times. It was watching a client edit a page in a CMS and needing a bit more space under a heading, in one place, on one page, forever, and there being no honest semantic name for that because the thing genuinely was “a bit more space under this specific heading.”

The position hadn’t been wrong so much as it had been about me. It made my stylesheet coherent. Nobody else in the transaction had been consulted.

That progressive enhancement is a thing you believe

For years it sat in our proposal template as a bullet point, in a list of things we believe in, next to a couple of other bullet points of the same kind.

The thing I unlearned, and I wrote it up properly in 2021, is that a belief with no failure condition is not doing any work. If there is no test that could come back red, nobody can check whether you did it, including you. It got a lot more useful the week we rewrote it as claims: this form submits without JavaScript, this navigation opens without JavaScript, here is the browser list and here is what each one gets.

Less inspiring as a sentence. Considerably harder to quietly not do.

That tests should be written first

Held from about 2016, mostly on the grounds that everyone said so and I didn’t have a counterargument, and quietly failed to act on for nine years.

I wrote in August about deciding that writing tests after a bug is the correct policy rather than a discipline problem, and I’ll not repeat the argument. What I want to flag here is how long the gap was. I’d been working the new way since roughly 2018. I just hadn’t admitted it was a position, so I carried the guilt of not doing the other thing for the better part of a decade, for no reason, while doing something I’d now defend.

That’s the pattern more often than not. The practice changes years before the opinion does.

That estimating is a skill you get better at

I read books about this. I tracked my own accuracy for a while. I got measurably better at estimating and it improved absolutely nothing, because the problem was never my estimates.

The 2018 post has the technical version: you’re being asked to collapse a probability distribution into a single number, in a meeting, under mild social pressure, and the number is then treated as a commitment. No amount of personal calibration fixes that. Getting better at guessing while the guess is still being read as a promise just makes you more confidently wrong in a more specific way.

What helped was changing what I hand over, not how well I guess.

That shipping less is always better

This is the one I’m least finished with, so take it accordingly.

I spent about five years with a useful heuristic (fewer dependencies, less JavaScript, smaller pages) and gradually turned it into an identity, which is a different thing and much worse. The 2016 evening I spent putting a service worker on a five-page brochure site was the first time I noticed, because I couldn’t work out afterward whether it was worth doing or whether I’d just enjoyed it.

I still think most sites ship far too much. I no longer think “I removed a dependency” is automatically a report of an improvement, because half the time what I actually did was move the maintenance from a package I don’t own to a hundred lines I do, and I’d only counted one side of that.

That the technical answer is the answer

The last one, and it’s the one that took longest, which is embarrassing because I appear to have written it down correctly in 2014 and then not understood it.

There’s a post from September 2014 about IE8, and the argument in it is that browser support is a commercial decision that gets filed as a technical one. Which is right. It’s also a completely general claim and I treated it as a fact about IE8.

Nearly everything I’ve argued about since has that shape. Whether to rewrite. Whether to drop a browser. Whether the site can be edited on a Tuesday by a person who doesn’t work in software. What “done” means. In all of them the technical content is real and it is not the disagreement, and I have lost hours to arguing the technical half of a question whose actual content was about money, or risk, or somebody’s job.

The opinions I kept are the ones I could state as a claim about consequences. The ones I dropped are the ones I could only state as a claim about virtue.

The thing they’ve got in common

I laid these out expecting six unrelated corrections and got one, repeated.

Every position I dropped was one I could only defend as a claim about virtue. Good developers write semantic class names. Good developers write tests first. Good developers ship less. Each of those is unfalsifiable, flatters whoever is saying it, and quietly sorts everybody else into people who are doing it properly and people who aren’t.

The positions that survived 11 years all state a consequence instead, and you can go and check them. A support matrix says what happens in a named browser. A performance budget is a number somebody has to defend. A regression test goes red. None of those make me sound good and all of them can come back and tell me I was wrong, which appears to be the property that matters.

And none of it came from an argument

The uncomfortable observation, which I’ve sat with for a couple of weeks and can’t get around.

Not one of the six changed because somebody argued me out of it. I’ve read the good posts on all of these. I’ve been in the conference talks. I have had the utility classes conversation, in person, more times than I’d like to count, with people making the correct argument at me, and it bounced every time.

What changed my mind, in all six cases, was a specific project going a specific way while I watched. The client with the heading. The proposal nobody could act on. The bug that came back 18 months later with my own fix sitting next to it.

Which is a bleak thing to conclude about discourse, and I don’t fully believe it, because presumably the arguments were doing something in the background that made me able to notice the project when it happened. But if I’m honest about the mechanism, the arguments were never sufficient and the projects always were.

I’m not sure what to do with that. Write things down anyway, I suppose, and be somewhat less confident in the tone. My 2015 self would have known exactly what to do with it, which is rather the point 🙃