> I don't think this is universally true, and to some extent I think it's a practiced skill.
But is it a skill that's even necessary and therefore developed while working as a software engineer?
In almost all cases that i can think of:
- real time communication might be important for discussing things before and after development, things such as architecture, concerns to pay attention to, or even choices made during development
- real time communication almost never plays a part during the actual development, unless doing pair programming live from 0 or even mob programming (absolutely unheard of in my current company)
- most of the time, what happens instead is dropping a detailed question in Slack and the other person responding to it when they have a minute, only escalating to calls if that's not helpful, which almost always only gives rough outlines of things to try next, not changesets to the code
- actually, most of the communication regarding code happens in merge requests asynchronously, which is better than synchronous communication which wouldn't be explicitly recorded and all of the arguments/outcomes of which would disappear
Thus, narrating the problem solving process live when you don't even have any idea how to solve the problem, haven't done research about that particular problem, have no idea what others in the industry have tried and how that worked out, is almost completely useless in my eyes. During this process, when you haven't done this discovery, about 80% of what you'd think of would be useless and would be tossed aside when you'd figure out what you actually need.
You can only feel confident in your ability to narrate these solutions when you know what they are or where to start, e.g. after a few hundreds of hours of grinding LeetCode, but at that point it's essentially following a flowchart of algorithms and in my eyes is basically "pretending" to be clever, even if there is something to be said about the ability to memorize solutions to problems (or even groups of solutions) and apply the correct one.
Perhaps it's a bit better in my eyes when you'll be applying these algorithms daily in your work, but so far it's about 90% CRUD development, struggling with the specifics of technologies and doing requirements engineering with clients who don't always know what they want or whether that what they want is technically feasible.
Disclaimer: there are probably cultural aspects to it as well, like how here in North/East Europe we don't really do much small talk with strangers. Or maybe it's just corporate culture, or the people working within the company happening to be more introverted and thus the idea of narrating things real time simply being uncomfortable to them.