Probably because unlike apprenticeships a senior developer isn’t an owner. This creates a situation where imparting knowledge means you have less time to do your own packed work stack.

Irrespective of the linked post, let me say why I (being sort-of-a senior developer) fail to communicate my expertise. In no particular order:

1. I am discouraged or forbidden from devoting time to communicating my expertise; they would rather use it. Well, often, they'd rather I did the grunt work to facilitate the use of my expertise.

2. Same, but devoting time to preparing materials which communicate my expertise.

3. A lot of my expertise is a bunch of hunches and intuitions, a "sense of smell" for things. And that's difficult to communicate.

4. My junior colleagues don't get time off their other duties to listen to "expertise sharing", when it does not immediately promote the project they're working on.

5. Many of my junior colleagues lack enough fundamentals (IMNSHO) for me to share all sorts of expertise with them. That is, to share B with them I would need to first teach them A, and knowing A is not much of an expertise; but they're inexperienced, maybe fresh out of university.

6. My expertise may only be partially or very-partially relevant to many of my colleagues; but I can't just divide the expertise up.

7. For good reasons or bad, I have trouble separating my expertise from various ethical/world-view principles, which fundamentally disagree with the way things are done where I'm at. So, such sharing is to some extent a subversive diatribe against the status quo.

8. My expertise on some matters is very partial - and what I know just underlines for me how much I _don't_ know. So, I am apprehensive to talk about what I feel I actually don't know enough about - which may just result in my appearing presumptuous and not knowledgeable enough.

9. My expertise on some matters is very partial - and what I know just underlines for me how much I _don't_ know. So, I try to polish and complete my expertise before sharing it - and that's a path you can walk endlessly, never reaching a point where you feel ready to share.

10. Tried sharing some expertise in the past, few people attended the session, I got demotivated.

11. Tried sharing some expertise in the past, few people were engaged enough to follow what I was saying, I got demotivated.

12. Shared some expertise in the past, got a positive feedback, but then those people who seemed to appreciate what I said did not implement/apply any of it, even though they could have and really should have.

> I don’t like this kind of senior developer [...] not my wavelength.

Bro & I would not get along well =)))) But the article IS good stuff.

I'm a "senior" developer.

Want me to communicate my expertise? Give me some time to actually do it.

If you're a senior Go player and you think robots can play I'm suspicious of your expertise.

Literally what people thought after Fan Hui (2-dan) was beaten. For humans software requires ingenuity and creativity. Computers can cheat that, infact computers ALWAYS cheat that to beat humans. NTP as a method of cheating is slightly more general than say board evaluation, so it's less efficient for the same problem, but scaling laws show that with enough compute NTP can beat humans at chess (or any most other arbitrary games, in real time).

The second part of the system that author proposes, will not work for most of the medium and small companies. From what I saw people that ran those companies, the owners for example were looking at those devs like, hacks that try to extort them for money. They were angrily grinding their teeth but put up with that because they need them to do their software to actually make money.

Now, with so-called AI they will mostly slap something kinda working in few days and then maybe get hacked or double invoice some customer from time to time... They will learn of those problems the hard way. Or maybe they will not because it will be mostly working emailing system and nobody will care if it will loose 2% of the emails because of some bug.

Nevertheless, either the Stable version, Scale version of the software will never happen or will be looked like not necessary or it will became a thing after catastrophic failure.

Anyway I do not think it will be like that, everybody cares about speed and money and making money quickly without an effort is the ultimate unicorn entire world is after.

Those complaining developers just stand in a way.

Here's a mental exercise - do you immediately think you know what this command does?

    PING

Junior developer: PING is used to check if a host is reachable by a network

Middle developer: PING constructs and sends ICMP packets to an address

Senior developer: what machine, what OS?

Junior manager: Don't care, ask a techie if you need to do something technical

Middle manager: Ask <techies name> about it, I know he has great experience with it

Senior manager: PING is used to check if a host is reachable by a network

Senior developers fail to communicate their expertise, because that expertise is developed and formed by asking more questions than answers, and managers fail to understand the capabilities of "their techies", because managers see question-asking techies as counter-productive, and attempt to route around them. Managers only want answers, developers know the value of asking deep questions.

Thus, AI.

(BTW, PING is a command that produces a distinct sound on the Oric-1/Atmos computers, and it is thus an Onomatopoeia.. I know this, because I am a Senior Oric-1/Atmos Developer who knows what lies at #FA9F, how it works, what the 14 bytes are for, and so on.. because I once asked the question, "how does PING go 'poooinnng' but ZAP go 'zap'?")

AI: <asks billions of questions in a second>PING is ..

Wow I'm only done with part one and the author pegged me to a t.

Interestingly the article put complexity management vs uncertainty reduction.

But reduction is narrower than management which is narrower than organization.

Also uncertainty is part of complexity. Being able to isolate what is deemed predictable under clearly identified premises is the best that can hoped on that matter. It means that then one strategy can be applied to protect the stable core, and other strategy can be tried on what is unknown (known and unknown unknowns).