3 ms·

> These are two different modes of operation. I don't think this is universally true, and to some extent I think it's a practiced skill. I used to really stru

• KronisLV 5y ago
  > 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.
  • Closi 5y ago
    I think it's probably not a skill required for most software engineering, but it's probably useful if you have a more senior engineering position where part of your role is helping and coaching less experienced people. It's also useful to 'work a problem' with people sometimes which requires this sort of live communication, however the extent to which teams do this will vary by team. In my experience this is more common in teams that are physically located together in the same room. Also it's not inherently clear to me that "not used in the job" means it's also bad from an assessment perspective - take defensive driving certifications for example, which require drivers to 'verbalise' what they are noticing, doing, and their decisions while they drive. Do you verbalise when you are driving in reality? No - but it is an established technique for assessment and for learning. But each to their own. Different strokes for different folks, clearly this works for some people and not others.