> If this is not abundantly clear to you, consider how clarity shapes your interaction with lawyers, doctors and mechanics.
I have a bunch of friends who are or have been mechanics and technicians. They, and others I have interacted with are actually quite good at explaining things in layman's terms. Doctors are quite similar in that regard. It's an important part of their job to do so. With lawyers I had fewer interactions, they tend to produce terrible texts (contracts, licences, ToCs etc.) but they can explain things typically well enough for one to understand their advice.
And going back to the article I think the problem statement is important. But the solution is only half-way there.
If you can afford to be less technical when interacting with others, then yes, do so. But given a large enough project and people you are building up knowledge about the thing your building and that needs terms (a mini language) that foster shared understanding. Those terms are often used across the code, data, UI, email, version control, chat and most importantly a spec or any document that describes the most important terms and their functionality.
All involved sides should be learning form each other and build up a common language. It's a two way street and it should be deliberate. It can be a small thing and still be super useful.
Mechanics, technicians, doctors and lawyers are jobs bridging between technical and non-technical. Mechanics and doctors needs to be able to talk to laymen, but mechanical engineers and chemists who design the parts/medicine don't need to do it. Similarly you have pure developers focusing on developing core parts, and bridging developers who focusing on delivering those parts to customers/users. Pure developers are still extremely important and a viable career path that pays well, you can't say that it is wrong to focus on that part.
I submit that you will always interface with people who are not purely technical, no matter how technical your role. But it is in the most technical roles that it's hardest to learn how to match your language to a given audience (for lack of practice/opportunities), so I actually think these are the groups that need to consciously work on developing this skill the most.
> I submit that you will always interface with people who are not purely technical, no matter how technical your role.
This is provably false though, I've worked in jobs where entire large teams never talked to non-technical people.
What you maybe meant is that you always talk to people less technical than you, which is true, but that is a very different statement. For example, when I worked on developer tooling at Google the stakeholders were all developers, the director was a developer, the directors for the orgs we worked with were developers, the product managers were former developers etc. There was just no non-technical people in sight. But you still need to talk to people who are less technical than you, that is still true, but it isn't true that all jobs needs to be able to talk to non-technical people.
I think many misses all the people who work in the background because you don't see or talk to them, but they still exist.
That's fair. I concede that there are jobs that in no part rely on communicating with non-technical people. But I still believe you will find it beneficial to be able to explain your work to non-technical audiences. Your family, your lawyer, or a future hiring manager will all value it.
All I did was work on/design math/algorithm libraries. I can of course explain that I write code, and which parts of Google used it, but I can't explain anything I produced to non-technical people since there is nothing left when you removed the technical details.
I also worked on server message routing. I can explain that it is basically like the internet, ie explain why my job is important, but explaining any of my projects to a layperson wouldn't be possible without teaching the layperson a lot of technical skills.
I have a bunch of friends who are or have been mechanics and technicians. They, and others I have interacted with are actually quite good at explaining things in layman's terms. Doctors are quite similar in that regard. It's an important part of their job to do so. With lawyers I had fewer interactions, they tend to produce terrible texts (contracts, licences, ToCs etc.) but they can explain things typically well enough for one to understand their advice.
And going back to the article I think the problem statement is important. But the solution is only half-way there.
If you can afford to be less technical when interacting with others, then yes, do so. But given a large enough project and people you are building up knowledge about the thing your building and that needs terms (a mini language) that foster shared understanding. Those terms are often used across the code, data, UI, email, version control, chat and most importantly a spec or any document that describes the most important terms and their functionality.
All involved sides should be learning form each other and build up a common language. It's a two way street and it should be deliberate. It can be a small thing and still be super useful.