RE: https://mastodon.social/@nixCraft/116087634363842093

This is a great take.

Anecdote time.

I worked at a company where the engineering team was a mess. An absolute mess. The company as a whole consistently found that the engineering team would just fail to deliver anything. Releases took literally months and required massive investment, they were error prone, and features would get rolled back.

Over time we fixed it. We got it down to a 6 week release cycle that still had a lot of manual steps, but was no longer being compiled on Ye Random Senior Engineer's laptop. There was unit testing and integration testing. Engineering ran on a kanban-like system and features could be delivered at all and, while they still sometimes took a while still (six week release cycles are still painful), they very very rarely would ever see a rollback.

There was still a lot of room for improvement, but we were improving.

Then something happened.

Engineering no longer was the bottleneck.

Why? Because the company was completely unwilling to let go of customers or features and the squirrels in upper management couldn't stay focused for even a single month, let alone for the three months a full feature release would take.

Engineering, even with all of its flaws, had become increasingly reliable, but the rest of the org still held the company back.

Even when we were at our worst our bottleneck was _never_ the actual generation of code. That was always straightforward. The bottleneck was all of the _other_ stuff that went into it. Resources being undersized or hard to bring up, production toil pulling away senior engineers (in particular), customers whose idea of a modern browser was IE6 and who refused to test releases early, etc.

The company persisted in a delusion that the problem was "if we could just write code faster." That was the motto of upper management.

But the problems were never how quickly the code got generated. The problems were deeply systemic. Most ideas were terrible and even when they weren't terrible we couldn't focus on them, and engineers were constantly stressed by shifting directions, "productiontyped" code that might as well have been hallucinated given its lack of quality controls, and fundamental lack of discipline.

AI wouldn't have changed anything.

As I've said before. If people think this is so easy then "men" should (or women should get their favorite man to help them):

1. Undergo HRT for two years.
2. Undergo the other additional steps required to compete at this level, which for most orgs at this level requires one or more surgeries, some of which have longer than two year leadups.
3. See how well the get along wth jars by that point, let alone competing at elite levels.

"the studies weren't big enough!"

Because there were only a handful of trans athletes operating at the levels required to study it among elite athletes. Especially trans women.

If trans women had any substantive advantage we'd have like… more examples to choose from. Not a small handful who haven't medaled.

"Trans women have no advantage in women's sports, studies confirm this result"

A bunch of weird people: "nuh uh, science says otherwise!"

What do these tools think a "study" is and what do they think "science" is.

Types of replies you can expect when talking about #ActivityPub:

Well actually…

* …that isn't _activitypub_ that is _mastodon_.

* …that is solved in _mastodon_ therefore it is solved in _activitypub_ (bonus points if it is on the same point that got the previous response).

* …I wrote some code that solves it, it's easy! <code does not, in fact, solve the problem>

* <Insert rant about corporate social media>

* <insert rant about Jack Dorsey>

* <insert rant about threads>

1/