Many of them are Software Bureocrats - their job is to keep organisational processes running with the goal of avoiding expensive mistakes. They are a lot like corporate lawyers. They don't create new stuff, but they save your organisation from descending into chaos.

Actual engineering still happens at the heart of the organisation, that heart is just shielded by the gigantic army of software bureaucrats.

More of them are akin to social workers enduring the morale never gets to expectant of rewards and the corporate sociopathy never disrupts too much

22 is less than 2% of the engineering effort. I agree that code part of the engineering effort, but if your business is software driven, you would think it is more than 2% of the effort. A lot of the adjacent roles to an engineer, i.e. documentation, devops, sre, all have code involved, too.

I get the sentiment here. But I can understand why someone would want to optimize towards writing more code than dealing with organizational politics. I guess the tradeoff would be to go to a smaller company.

Everywhere I've worked (including for MAANG companies), software engineering was best done by a combination of three things, listed in priority order:

A) thinking

B) programming

...

Z) meetings

The meetings contained something useful maybe 1/10th of the time, lasted maybe 4x longer than they should have, and involved maybe 20x more people than they should have. Those numbers skew higher the larger the organization.

Maybe that's a bit of an exaggeration, but not by much.

May we all be so fortunate to have tasks defined so specifically and selected so precisely that one can accomplish them only by thinking and programming, and find satisfaction in doing so.

Heh. I knew I’d get downvoted.

I’ve generally been on the most productive teams in my segment of the business. The biggest differentiator seems to be that my teams had devs that knew when to ask questions and what questions to ask. This is probably the most important skill a dev can learn.

The solution to ambiguous requirements is not meetings. At least, not in the usual sense. It’s knowing who and what to ask, and occasionally meeting with customers or knowledgeable stakeholders.