Great question. Of course unions in software aren't really a widespread thing, so speculating at what they would look like is fraught with all the problems of speculation, but this is what I think of:

Currently at work, I'm more of a "devops" guy but I get into things all over the stack sometimes too. In previous places I've been a "backend" guy that occasionally got into the frontend, etc. I view this as the optimal arrangement: blurry lines of responsibility (so people aren't pigeon-holed), but you can still develop depth and expertise in an area of specialty.

In a world of unions, if it were analogous to my past experience, there could be a "front end" union, a "back end" union, a "dev ops/operations" union, etc. These unions would then draw up lines, much like the "driver" and "mechanic" unions did in my past. Need to change a line of javascript? Talk to a "front end" guy. Tweak a deploy script? Not if the union agreement forbids it.

Those seem like ludicrous thoughts based on where we are now. But I'm sure at one time the idea that a driver can't effect any repairs to the truck, no matter how small, probably seemed ludicrous as well. Yet here we are.

I know I probably sound very anti-union, but to clarify my position, I'm only anti-forced unions. So long as I can opt out of the union if and when I please, I have no qualms. Sadly that is not the case in many places in the United States.

P.S. If I could edit and re-word this line, I would. I think the language is unclear and unnecessarily harsh:

> Acting like unions are this amazing shining solution with no downsides is pure ignorance.

I would change that to: "Thinking of unions as all upside with no downside (or vice versa) is an argument from ideology, not one from experience."

I can definitely agree with your rephrasing. Unions can be large organizations too, and are certainly not immune to bureaucracy and the pursuit of short-term wins over long-term gains for the people they represent.