Be Less Technical

I'm flattered that the OP took an interest in my comment, and when I said "less" click-thirsty I hope I didn't come off too judgemental: whether we admit it or not we're all pretty well wired-up for the engagement dopamine hit at this point, including me and my comment.

Given that you've clarified the point you were making was the one I hoped: I am interested in hearing more from you and I would gently discourage that particular writing style. Your post could have been called, just for the sake of argument, "Work Technical, Speak in Plain Language" or something to that effect.

There is this, I'll say it, dysfunction, where certain folks in the software business are trying to create a (high-paying) career track that is adjacent to deeply technical stuff but not really touching it. That needs to be drowned in a bathtub.

Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one.

> Lawyers, accountants, architects, and doctors, for instance, are expected to be able to speak with people from outside their profession. (I see wfme already mentioned doctors.)

Those are frontline positions working directly with laymen though. So while doctors needs to be able to talk to laymen, the chemists working in medicine factories don't. The problem here is that we have the same title for frontline and backline developers, frontline developers are doctors, they know a bit about chemistry and can prescribe and implement treatments. However there is no reason for a developer optimizing database engine queries to be able to communicate their work to laymen, as the entirety of their work are technical details no layman would care about, they are akin to the chemists working in medicine plants.

People will continue to talk past each other as long as we have the same word for those two jobs. Developers who double as product managers and work directly with clients says that technical skills hardly matters and you should be a product manager first and foremost, which is fine but they shouldn't tell pure developers that it is wrong to focus on the technical part since they don't do the same job.

Contrived example does not serve the argument well, if someone is starting with "our users are complaining that our system is slow!", they could already do some legwork and check for themselves or check with users before dropping it directly on the engineer.

If someone goes to a surgeon he does not start with "I don't feel well, do something about it please", that what general practitioner is for.

I understand there are small companies where engineer is basically support as well, but for any bigger operation follow up question on "what part of system is slow" should be worked out on support level and provided with question to the engineer.

> 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.

> So while doctors needs to be able to talk to laymen, the chemists working in medicine factories don't.

But they for sure need to talk to lawyers, accountants and doctors occasionally. All of those (especially the doctors /s) are laymen when it comes to chemistry.