It is a skill issue. Such developers have to take a problem, isolate it and explain it to someone/something else with enough context to be able to work with it.

It is perplexing how many developers lack this basic skill, some of them borderline lack theory of mind and are incapable to understand that other people can't see the unspoken part in their heads.

It has been a good long while, but in my undergrad the engineering dept did not put a lot of emphasis on being a well rounded individual. It was more about passing physics and getting through all of the math.

One of my first jobs out of undergrad was technical writing on EDA tools for Mentor Graphics Calibre product. For many years, I did not appreciate that experience--it seemed orthogonal to what I'd gone to school.

Once I did become a professional SWE, something that took me too long to realize was that writing documentation and tutorials for people and looking after the quality of onboarding materials was almost never rewarded.

I came to see it more of a liability with ~all emphasis being on human code gen.

I listened to an interview with Steve Yegge earlier this year, one of his concerns was that many people just don't type very fast or read very quickly. IIRC, he expressed concern this would continue to be a big barrier to successful use of AI.

I previously commented on annotation for coding agents that an important skill was knowing the beat of a conversation.

I think that extends into critical reading. For example, it is not that unusual for a Washington Post article to put some ~explosive detail deep in the article--this is called "burying the lede."

I see this regularly reading AI output. That is: the AI will lead with the strongest claim it can state cleanly, but not the most explosive implication.

With Claude Code and Codex, you're looking essentially neverending walls of text dense with technical information.

So now you have to have high domain expertise, a good understanding of written communication, a sense for the beat of a conversation (which assists in identifying understatements or overstatements), and the ability to dense text outputs quickly and then highlight critical statements for further exploration.

I'd almost describe part of this work as that of a skilled interviewer.

I wonder how much this overlaps with the seeming inability of so many developers to ask good questions. They want to jump right into screen sharing and talking about the issue. They cannot sit down and summarize the problem accurately and describe the things they have tried already. It's always "let's hop on a call real quick and walk through it". Just tell me what the damn problem is!