Where I work now, it's a shitshow. To a (technical) outsider who wasn't with the company when they built everything, the original requirements and constraints are not obvious. The solution was lazily built in an ad-hoc fashion, so requirements continuously emerged out of the need to work around the failings of some other foundational system that was badly implemented. Suddenly you're being asked for a zero latency relational database with 100% uptime and infinite storage, and you ask "why?". Somebody points to the fractal-like complexity of the existing system and says, "It's the only way to make it work properly". You ask for diagrams, design docs or operational docs. Someone hand-waves at the fractal monolith and says "Documentation as code, man".
Importantly, learn to modulate the level of technical detail at which you describe things and establish trust with your intended audience that your level of technical detail matches the nature of the problem. This gives your audience a clue that when you throw around jargon, it's because there's a subtlety in the implementation detail that breaks the abstraction and they need to care about it.<p>There's a difference between "This is a problem with our search indexing and we need to..." and "This a problem with Lucerne which is a search indexer. The tricky thing is, Lucerne implements search differently and because of that, ... and so we need to ... instead of ...".
I learned a lot from my early career, first when selling computers, then when making websites for small businesses (with a side of IT). I also taught Office to senior women for a few weeks. It was a delightful experience.<p>When you deal with laymen, you get to see how complicated our world is to them. I like to see myself as their honest broker with this confusing world. This has proven a viable business strategy.<p>If this is not abundantly clear to you, consider how clarity shapes your interaction with lawyers, doctors and mechanics.
All very deeply true.<p>Many moons ago I worked in a briefly-successful UK "dot com" integrator, and then took a break from work for personal reasons.<p>When I came back, I rejoined in the design department, rather than return to a role in engineering, where I had been mostly front-end. (I described myself whimsically as a "pet engineer".)<p>What we realised then is that the design team needed an engineer on their side of the divide to act as a go-between with implementation, but also to translate requirements in both directions, explaining what each side thinks (as well as urging some respect for the designers' craft).<p>Nowadays this is reasonably commonplace but at that time it was pretty radical.<p>Technical teams often make the mistake of thinking that their knowledge, their language, and their problems are supersets of or at least the essence of the problems of the business. They are quite wrong.
I have a phone call with my stepmom most weekdays. Part of the call always involves discussing what we plan to do for the day. She’s very impressively technical about the things she’s interested in, but our areas of expertise have very little overlap. I find it rewarding for both of us, and a really good mental exercise to “explain it to my stepmom” and find we both share some understanding at the end of the conversation, and I know she does too when I’m hearing her goals and ideas.<p>Learning how to communicate with anyone is hard. But it’s very worthwhile if we can.
Thought train:<p><pre><code> - What are the first principles of communication.
- Of what you want to say, what can they hear.
- The more refined (technical) your knowledge, the fewer people there are who can understand it.
- "Language is the interface for describing problems." This phrase makes me rather happy for some reason.
- Do you want to sound clever, or be clever. (It's easier to sound clever.)
- What are all the functions of using more technical language than necessary.
- Understanding what's relevant to another person is an advanced skill. In any context.
- Filtering technical knowledge into a relevant format for a listener to comprehend in real time is a skill that can be learnt.
- More people think they understand than actually do.
- There are infinite layers to understanding even the simplest thing.
- At what point do you tend to decide you've understood.
- Where does the feeling of 'understanding' come from.</code></pre>
I often try to explain something probing on what will be the appropriate level for the listener.<p>So you start at the level you expect the person to understand but you often have to go few levels lower (simplier).<p>I understand its needed for laymen, as in this saying “if you cannot explain something simple enough - you dont understand it well enough”.<p>Tho I often find myself explaining stuff the same way to experts in the field :)<p>Which makes me realize -> real experts are extremely rare.
Well-put. I participated in a protracted comment thread several weeks ago about the use of 'number' in HTML input field 'type' attributes. The problem was inexperienced HTML writers using 'type=number' for phone numbers, order numbers, social security numbers, account numbers, etc. The resulting interface elements— e.g. increment/decrement— are designed for elements like quantities and are more harmful than helpful with those more common uses.<p>I argued that in general, people are perfectly correct in calling telephone numbers, order numbers, account numbers, social security numbers, etc. "numbers" regardless of how a computer handles them. I also argued that the purpose of HTML was to describe data rather than how it should be handled, and that argument is to describe formatting rather than a data type. I asserted that a general-use term like "number" was wrong for a field with such specific use cases obvious only to developers.<p>Personally, I think the shakiest part of my argument was asserting the purpose of that label. To my surprise, others only argued that labelling those other things 'numbers' was not accurate <i>in general</i> because computers didn't treat them like numbers, and supported the current label 'text.'<p>OED definition 3a for number:
<i>> An arithmetical value assigned to something or someone, esp. to indicate position in a series, or for purposes of reference, identification, etc.</i><p><i>There is no definition for 'text' in the unabridged OED that describes anything other than words.</i><p>English is a descriptive language and software doesn't override that. Most people see a collection of numerals with punctuation and think "that's a number" and that's clearly how we use the term in regular language. "Order Number" and "Telephone Number" (3b for 'number' in the OED) are not colloquialisms. The most common uses for fields those developers would consider 'real numbers' — e.g. quantity— don't even have the word 'number' in the name.<p>I don't even expect most developers to intuitively recognize how these ingrained shorthands differ from the rest of the world, but we MUST NOT instinctively dismiss indicators that our perspective isn't representative. We're making the tools modern folks use to solve many of their problems and we stand to make their lives a lot worse by assuming our use cases, language, challenges, and perspectives are the same <i>or more</i> worth considering.
I always have trouble parsing the Seemingly Wrong Thing That I’m Redefining writing style, so I’m not sure my comment is germane.<p>It <i>seems</i> like OP is saying to communicate about technical matters in a way that is not obscured by jargon and distracting minutia. That is generally good advice, and has an ancillary benefit that explaining deeply technical matters in plain language usually deepens the explainer’s understanding.<p>There is a less charitable interpretation where this is just “I talk to the customers so the engineers don’t have to!” dreck, in which case, Be Less Click Thirsty.
> Though not a perfectly applicable example, we can see that the English language, due to its rules and formalization, does not have a single word that describes the complexity behind the feeling of “Schadenfreude”. This is an inherent constraint in the English language as it pertains to its translation to German.<p>Except English does have such a word and the author literally linked to its dictionary entry in an <i>English</i> dictionary.
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.<p>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.<p>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.
Very true. This is why I think 'Thing Explainer: Complicated Stuff in Simple Words' (Randall Munroe) is so brilliant. I think being able to communicate at the level your audience is an under-appreciated skill.
Cause: The Curse of Expertise - <a href="https://en.m.wikipedia.org/wiki/Curse_of_knowledge" rel="nofollow">https://en.m.wikipedia.org/wiki/Curse_of_knowledge</a>
My advice: Practice explaining what you do to your grandma. Not all the time, mind you (she probably has other things to attend to), but it is incredibly effective at showing you how "zoomed in" you are in your work and where there is still a "translation mismatch".<p>I still regularly catch myself using words that I think are common or high-level enough, just to realize that they don't invoke nearly the same picture in a non-technical person as they do for me.
The gist is, be as technical as you like, but don't lose your grip on reality.<p>Talking with people is your interface to the rest of the world. If they don't understand you, then you're lost.
Talking technical stuff to non technical is an enormous pain.<p>The levels of dumbing down is near endless.<p>Not everyone has to be able to explain their product to the masses, let someone else have that job.