I've seen another headline today suggesting the UK might drop to a 3-day workweek to conserve fuel.

Like damn, between reduced work-weeks and the prospect of wrecking our government-entwined spyvertising parasites, maybe the war was a good idea...

I never use them to replace a comma, certainly, and only rarely a colon.

I find parenthesis often awkward or too heavy, so may use the m-dash to replace those. Especially if what might have been a parenthetical is going to terminate a sentence, an m-dash is much cleaner, as it doesn't need a closing mark, and a terminating paren right before a period looks awful. For long potential-parentheticals that do terminate before the end of the sentence, the m-dash takes up more visual space and marks the beginning and end more-visibly, making for easier scanning. One ought probably re-write to avoid parenthetical statements most of the time in the first place, when there's time, but sometimes they're desirable for stylistic reasons, or just because one lacks the time to improve a draft.

I also use it as a "classier" version of the ellipsis. It doesn't replace every use, but it replaces very-casual, colloquial use of that mark as a kind of harder-comma. Looks much better, I think, and serves the same purpose.

As for the semicolon, I'd never shy away from the semicolon when I can get away with it, but use them rarely nonetheless. I don't think I ever replace them with the m-dash, though. As inline list separators they're great and an m-dash would be an awful replacement, while as soft-periods, they're fine, though most of the time I just use a full period—but not an m-dash, not if a semicolon could have worked.

I do think they're more at-home in, say, fiction than technical writing, but I like having them in my toolbox in any case.

Mine's tracking it complete with a leaderboard (LOL) and it's been suggested to me that it'd be in my best interest not to be too low on that list, so I suspect in the back half of the year some sterner conversations and/or pink-slips are going to be coming the way of those who've not caught on that they need to at least be sending some make-work crap to their LLMs every day, even if they immediately throw the output in the metaphorical garbage bin.

It's basically an even-more-ridiculous version of ranking programmers by lines-of-code/week.

What's especially comical is I've seen enormous gains in my (longish, at this point) career from learning other tools (e.g. expanding my familiarity with Unix or otherwise fairly common command line tools) and never, ever has anyone measured how much I'm using them, and never, ever has management become in any way involved in pushing them on me. It's like the CEO coming down to tell everyone they'll be making sure all the programmers are using regular expressions enough, and tracking time spent engaging with regular expressions, or they'll be counting how many breakpoints they're setting in their debuggers per week. WTF? That kind of thing should be leads' and seniors' business, to spread and encourage knowledge and appropriate tool use among themselves and with juniors, to the degree it should be anyone's business. Seems like yet another smell indicating that this whole LLM boom is built on shaky ground.

A related Dirty Secret that's going to become clear from all this is that a very large proportion of code in the wild (yes, even in 2026—maybe not in FAANG and friends, IDK, but across all code that is written for pay in the entire economy) has limited or no automated test coverage, and is often being written with only a limited recorded spec that's usually fleshed out only to the degree needed (very partial) as a given feature is being worked on.

What do the relatively hands-off "it can do whole features at a time" coding systems need to function without taking up a shitload of time in reviews? Great automated test coverage, and extensive specs.

I think we're going to find there's very little time-savings to be had for most real-world software projects from heavy application of LLMs, because the time will just go into tests that wouldn't otherwise have been written, and much more detailed specs that otherwise never would have been generated. I guess the bright-side take of this is that we may end up with better-tested and better-specified software? Though so very much of the industry is used to skipping those parts, and especially the less-capable (so far as software goes) orgs that really need the help and the relative amateurs and non-software-professionals that some hope will be able to become extremely productive with these tools, that I'm not sure we'll manage to drag processes & practices to where they need to be to get the most out of LLM coding tools anyway. Especially if the benefit to companies is "you will have better tests for... about the same amount of software as you'd have written without LLMs".

We may end up stuck at "it's very-aggressive autocomplete" as far as LLMs' useful role in them, for most projects, indefinitely.

On the plus side for "AI" companies, low-code solutions are still big business even though they usually fail to deliver the benefits the buyer hopes for, so there's likely a good deal of money to be made selling companies LLM solutions that end up not really being all that great.

> senior engineer would hate their jobs reviewing more code from their teammates

Jesus, yes. Maybe I'm an oddball but there's a limit to how much PR reviewing I could do per week and stay sane. It's not terribly high, either. I'd say like 5 hours per week max, and no more than one hour per half-workday, before my eyes glaze over and my reviews become useless.

Reviewing code is important and is part of the job but if you're asking me to spend far more of my time on it, and across (presumably) a wider set of projects or sections of projects so I've got more context-switching to figure out WTF I'm even looking at, yes, I would hate my job by the end of day 1 of that.