Something that can go red

Somebody in the team channel asked for something to read about naming conventions last month. So I went and dug out my own BEM post, sent the link, and then made the mistake of reading the thing I’d just recommended.

The technical content mostly holds up, which isn’t the problem. The problem is the person writing it, who is extremely sure of herself and who I would not want to be stuck next to at a party.

Which might be the actual return on keeping one of these for 10 years. I don’t end up with a record of what I knew. I end up with a record of how certain I was about things that were about to change. The certainty is easy to see from out here in a way it never was while I was standing in it.

So I went looking for the rest of them. Not the ones where I was wrong on the facts, which are mostly about browsers and aren’t interesting. The ones where I was sure, and the being sure was the mistake. There are about six I’d defend as genuine reversals. I went in expecting six unrelated corrections. I think I came out with one thing, six times.

Pleased with itself

The position in the BEM post is that a class name describes what a thing is and never what it looks like. mb-3 was a moral failure. I could produce the argument on demand, it took about 90 seconds, and I did produce it, at people, for two years.

I recanted in 2017, so none of this is news. It’s just the cleanest specimen I have.

The position isn’t what bothers me now. It’s defensible, and I still hold about half of it. It’s that every benefit in the post is a benefit to me. My stylesheet is coherent. I can find things. I can delete things. Nobody else in the transaction gets a mention, not the developer who inherits it, not the client editing a page in a CMS, and definitely not the person who needs one heading on one page to have a bit more space under it forever, which is a real requirement with no honest semantic name.

Good developers write semantic class names

Once I noticed the shape I had a hard time unseeing it. Every position I dropped was one I’d been defending as a claim about virtue.

Good developers write semantic class names. Good developers write their tests first. Good developers build less. Good developers believe in progressive enhancement.

I don’t think any of those is wrong. Plenty of people hold them and do good work. I still half-hold most of them myself. But the way I was carrying them around, nothing could ever have come back and told me I hadn’t done it. No build, no test, no meeting. They flattered me for holding them. They quietly sorted everybody else into people who were doing it properly and people who weren’t, and the sorting was being done by me.

I wrote that up properly in 2021 about one of them. It took me another 4 years to notice it wasn’t really a fact about progressive enhancement.

I might be being unfair to 2015 me. It’s easy to be generous about a position after you’ve already dropped it, and even easier to be insufferable about it, tbh. I’m grading my own homework here and I know it.

A number somebody has to defend

The ones that survived 10 years all say what happens in a named situation, which means I can go and check them. That’s the only thing I can find that they have in common, anyway.

A support matrix says what happens in a named browser at a named grade, and week six is when everyone finds out whether it was true. A performance budget is a number somebody has to defend, and the year I set one the site went to more than twice it and the number is what told me. The progressive enhancement claims take about a minute each to check with the JavaScript switched off. A regression test goes red or it doesn’t.

Estimating went the same way, sort of. I read the books, tracked my own accuracy, got measurably better at guessing. It helped almost nothing, because the problem was never the guess. It helped to change what I hand over, so instead of a number it’s a range with the conditions attached to each end. Which is once again a thing somebody can hold me to later.

None of those makes me sound like a good developer. All of them can come back and tell me I was wrong. I suspect that’s the difference. Or it’s the only difference I can see from where I’m standing, which isn’t quite the same claim.

Seven years of feeling bad about it

The tests one has a detail in it I keep chewing on.

I held the tests-first position from about 2016, on the excellent grounds that everybody said so and I didn’t have a counterargument. I wrote in August that writing tests after a bug is the correct policy instead of a discipline problem, so I won’t do the argument again.

It’s the gap I keep coming back to. I’d been working the new way since roughly 2018. I’d been making a version of the counterargument out loud since that winter and still didn’t file it as a change of mind. So I spent seven years feeling bad about not doing the other thing while doing the thing I’d now defend in a review.

I think that’s how it usually goes for me. The practice changes years before the opinion does, and the gap in between is where I do all the feeling bad.

I’ve been to the conference talk

Then there’s the part I can’t get around. I’ve been sitting with it for a couple of weeks.

Not one of these changed because somebody argued me out of it.

I’ve read the good posts on all of them. I’ve been to the conference talk. I’ve had the utility classes conversation in person more times than I’d like to count, with people making the correct argument directly at me. I nodded, said it was a fair point, went home and changed nothing. I know, I know. A woman announcing that arguments don’t work on her is, at this exact moment, making an argument.

One project going one specific way while I watched did it, every time I can point to.

400 lines in a stylesheet from a 2015 project whose entire job was adjusting the margins of an existing component in one particular context. I’d written most of them 🙃

The same bug arriving twice, 18 months apart, on the same store, with my own fix from the first time sitting in the history and nothing next to it that could have caught the repeat.

An evening I spent putting a service worker on a five-page brochure site, after which I could not honestly tell whether it had been worth doing or whether I’d just enjoyed it. That’s the one that took the shine off building less, because “I removed a dependency” stopped being automatically a report of an improvement. Half the time what I’d done was move the maintenance off a package I don’t own and onto 100 lines I do. I’d only ever counted one side of that.

And a client asking, not adversarially, what progressive enhancement meant in practice, and 4 competent people producing 90 seconds of gesturing. I was one of the four.

So why read anything?

The bleak version of this is that discourse does nothing, we’re all just waiting to get hit by a project, and I’ve written 1300 words to no purpose.

I don’t fully believe it. Without the utilities argument already sitting in my head, 400 lines of margin modifiers is just the job. You don’t see it. It’s a normal stylesheet, everybody’s looks like that, go close your ticket. The reading is what builds the pattern and the project is what fires it, so the argument was never sufficient and it was probably never nothing either.

I also can’t rule out the unflattering explanation, which is that I’m stubborn, that plenty of people do update on the argument alone, and that I’ve taken a personal defect and dressed it up as an epistemology. If that’s how it works for somebody else, sincerely, more power to them.

I’d genuinely like to know which way it goes for other people. Has anyone actually changed their mind about a technical position because of a post, before anything went wrong on a real project? I want to believe it happens and I can’t produce an example from my own life.

Show me the 400 lines

The one thing that’s changed is that I stop making the argument at around the second attempt now, mostly because I’ve watched it not work so many times.

Instead I go looking for their version of the 400 lines. In their repo, on their project, with their name on it. I count the modifiers that exist only to adjust a margin. I open the two commits where the same bug got fixed twice. I pull the analytics for the browser we’re arguing about, which is the IE8 post all over again and is still the only thing I’ve watched end that particular argument in one move.

Then I try to shut up about it, which I am not naturally good at.

The useful part is when I go looking and it isn’t there. 3 modifiers, not 400. 2 different bugs in 18 months instead of the same one twice. And then the honest conclusion is that I might be right in general and I’m wrong about this project, which is not something I’d ever have found out by making my argument better.

The 2015 post is still up

I haven’t deleted it and I haven’t touched a word of it. It’s still what I send when somebody asks about naming, because the convention works and the technical content is fine.

It’s also the only instrument I’ve got. I can’t feel my own certainty from the inside now any better than I could then, and the archive is the closest thing I have to a measurement, on a delay of about a decade.

So I’ve started marking the drafts where I can’t state a failure condition. There are more of them than I’d like. They’re the ones I’d have told you I was most confident about. I’d much rather find that out from a note in my own file than from somebody asking me for a link in 2035.