8 ms·

Be Less Technical

141 points by 7237139812 4y ago

shalmanese 4y ago
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. 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 ...".
- rzzzt 4y ago
  My mind immediately jumped to cows and Switzerland reading this.
- greggsy 4y ago
  as a security professional, there is nothing more frustrating than reading a report that completely misses the mark in terms of audience, and the overuse of industry jargon.
- unfocussed_mike 4y ago
  Right. You can't hide the detail with a wave of the hand, you can definitely overcommunicate detail that is unnecessary, but the art of it is finding a way to explain the bit that matters in a way that makes it clear to the users that you're eliding detail that isn't important, without misleading them. There is a very fine example of this in cinema -- the senior partners meeting in Margin Call, where Zachary Quinto's character has to explain why the firm needs to sell all of a particular asset class: https://www.youtube.com/watch?v=Hhy7JUinlu0 https://www.youtube.com/watch?v=Hhy7JUinlu0 One day I will use the line Jeremy Irons uses in this clip. I don't want to spoil it by quoting it.
  - nthj 4y ago
    That’s a great scene. For anyone who hasn’t seen the movie, I might recommend skipping the clip and watching the full film! If you’re on HN, odds are you would enjoy it, and it has an impressive cast.
    - unfocussed_mike 4y ago
      It is an outstanding movie. But I think this particular scene is one of the finest scenes in any movie ever made. It could stand alone as a short.
  - ColinWright 4y ago
    Outstanding film, outstanding cast, outstanding performances. I initially watched it because Stanley Tucci is in it ... I stayed for the drama, and then Jeremy Irons stole it.
langsoul-com 4y ago
Talking technical stuff to non technical is an enormous pain. The levels of dumbing down is near endless. Not everyone has to be able to explain their product to the masses, let someone else have that job.
- PradeetPatel 4y ago
  >The levels of dumbing down is near endless This is the kind of patronising attitude that will further the gap between engineers and product people. Being able to articulate technical details with the right level of abstraction, and without "dumbing it down" is an essential skill when engaging with stakeholders of varying levels.
  - wfme 4y ago
    Agreed. When talking to a doctor, you expect to communicate in terms you understand, or at least have essential terms explained in a non-condescending manner. It doesn't matter if they know a technically correct term for something if it means nothing to you - you expect to be communicated with, not communicated to. The same expectations carry across to most jobs in tech. It is rare that you work in isolation, so being able to communicate details without going over the head of the other person is an invaluable skill to master.
    - majkinetor 4y ago
      In what universe doctors communicate in terms you understand? They even write freeking diagnosis on Latin that nobody knows. Coming out of doctor that explained things to you is once-in-life event.
      - nulbyte 4y ago
        Not sure where you are located, but I've lived in many places in the Midwest and Florida, and almost every doctor I have interacted with is fully capable of explaining things and does it well. This is not a once-in-a-lifetime thing, but a basic requirement. If your doctor isn't doing this, maybe you should ask more questions. If your doctor can't do this, find another one.
eyelidlessness 4y ago
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. Learning how to communicate with anyone is hard. But it’s very worthwhile if we can.
- greggsy 4y ago
  Back in my service desk days, we were encouraged to write and revisit SOPs in our downtime as it is and excellent way to pick up how things work, and how to write in a style that everyone is on board with. The most effective part of that system was to get the older lady in accounts to run through some of the processes that required detail and rigor to see where things weren’t clear enough.
- unfocussed_mike 4y ago
  This was my telephone life with my Dad for thirty years, all of his later life and almost two thirds of my life, even well into his dementia (because his memories of his professional career were really untouched by it). After only one month I already miss it enormously. I am very glad you find these calls rewarding and I am certain she does too. I am going to have to find someone to fill this role in my own life again.
  - O_H_E 4y ago
    I'm sorry for your loss, and I am glad that you had a fulfilling relationship with your dad. It sounds like you are steadily strolling the road of healthy grieving, I'm sure he would be proud. Keep your head above the water my friend.
    - unfocussed_mike 4y ago
      Thank you. And yes -- navigating the line between the endings/beginnings bit, the loss (which it is), and tragedy (which it isn't) is difficult but this time around I am finding it easier. One of the things I have already realised is that explaining-stuff-to-my-Dad is portable. I can do it in my head. And when I can do that without tears, I'll be able to add my Dad to any audience in the future, and hear his questions as well as theirs.
Tainnor 4y ago
> 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. Except English does have such a word and the author literally linked to its dictionary entry in an English dictionary.
- 7237139812 4y ago
  OP here. I think it serves as a loanword, but I concede that linking to an _English_ dictionary can blur the point I was trying to make. Edited for clarity, thanks!
raffraffraff 4y ago
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".
- Multicomp 4y ago
  > Documentation as code, man In my list of mean things I'm going to insist on should I ever go crazy and start my own company, documentation will be just as if not more incentivized than the actual code. I want design diagrams, users lists, documented decisions on how backups are expected to happen, how this is expected to scale, why we went with X pattern instead of Y, who asked for a given feature, then as a last measure start doing the brittle document bits like API reference n such. The code has its own inertia and desirability, but if you don't push docs, they are looked down on even though they have proven value. What are we, scientists building and designing a new system or children slapping mud into a play dough concrete mixer and moving on to our next mud pie? Write it down Mr supposed professional!
  - nicklarsennz 4y ago
    I've found Lightweight Architecture Decision Records (as markdown docs in a repo with the code, or wherever makes sense) to explain the current landscape, options, decision, and foreseeable consequences. Keeping it really light makes it tolerable for people who don't like to write docs, though does need the team to insist on the doc for anything non trivial. I also like using the Draw.io vscode extension to draw diagrams without having to export into a separate file or copy into the repo.
    - 4y ago
known 4y ago
benreesman 4y ago
I always have trouble parsing the Seemingly Wrong Thing That I’m Redefining writing style, so I’m not sure my comment is germane. It seems 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. 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.
- yakshaving_jgt 4y ago
  My interpretation was that it was more of an encouragement to think about things at a higher level of abstraction rather thinking of implementation details, as is a common reflex for so many programmers. Being able to communicate at that higher level of abstraction is a consequence of first having trained yourself to think at that level.
  - Enginerrrd 4y ago
    Yeah it's an important skill. I knew an engineer that was about as smart as me in school. If there was a real stumper of a question on the exam, we'd be the only two to get it right. He was a hard worker. But that guy was incapable of discussing things at the 64,000 ft view, let alone the 30,000 ft or 10,000 ft. As a result, he had a really tough time working with anyone else, and the entire program was deeply focused on teams. You became like family with the other students by the end of the 2nd year. Your reputation in groups was incredibly important. This guy, he could be completely correct, and yet somehow get other smart engineering students to turn against him, including myself. No one could work with him. One instance of that still haunts me... It's really unusual that I don't listen to someone else and consider what they had to say, and yet I did exactly that on a really important project with that guy. He was completely correct about a very important and fundamental thing, and yet I just couldn't see it until it was too late. 10 years later, that still bothers me. That lack of skill haunted him in his later career. The last I'd heard, he had gotten fired from a job with a company that didn't fire anybody. It was bizarre to watch someone that could think about such technical and difficult things effortlessly, yet be unable to reason about them (or at least communicate) with nearly any level of higher abstraction.
nicbou 4y ago
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. 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. If this is not abundantly clear to you, consider how clarity shapes your interaction with lawyers, doctors and mechanics.
- dgb23 4y ago
  > 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.
  - Jensson 4y ago
    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.
unfocussed_mike 4y ago
All very deeply true. Many moons ago I worked in a briefly-successful UK "dot com" integrator, and then took a break from work for personal reasons. 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".) 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). Nowadays this is reasonably commonplace but at that time it was pretty radical. 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.
ozim 4y ago
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.
MauranKilom 4y ago
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". 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.
redbar0n 4y ago
Cause: The Curse of Expertise - https://en.m.wikipedia.org/wiki/Curse_of_knowledge https://en.m.wikipedia.org/wiki/Curse_of_knowledge
k__ 4y ago
The gist is, be as technical as you like, but don't lose your grip on reality. Talking with people is your interface to the rest of the world. If they don't understand you, then you're lost.
bright_light 4y ago
Thought train: - 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.
- adhesive_wombat 4y ago
  > Filtering technical knowledge into a relevant format for a listener to comprehend in real time is a skill that can be learnt. Sadly, not a skill most "scientific journalists" appear to have learned. There's a difference between "make understandable" and "dumb down to complete context-free drivel"[1]. And that's before the aforementioned "journalist" takes a single press release from a university PR department at face value rather than doing, well, journalism. [1]: or maybe this is just https://xkcd.com/2501 https://xkcd.com/2501 on my behalf
  - SamoyedFurFluff 4y ago
    My understanding of what might be going on here is broken telephone with intent. A reporter gleans only a subset of information from a given body of research, then ends up reporting only on what portions they consider to be essential. The end result loses nuance and context. I don’t think reporters want to be doing this, but society doesn’t incentivize serious reporting in of itself.
a_square_peg 4y ago
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.
pojzon 4y ago
I often try to explain something probing on what will be the appropriate level for the listener. So you start at the level you expect the person to understand but you often have to go few levels lower (simplier). I understand its needed for laymen, as in this saying “if you cannot explain something simple enough - you dont understand it well enough”. Tho I often find myself explaining stuff the same way to experts in the field :) Which makes me realize -> real experts are extremely rare.
- russellendicott 4y ago
  I find this to be true. I find that while I work with people who are perfectly capable of becoming experts in a given category, they protect their brains from having to hold unnecessary information that isn't relevant to their current course. This is a very important survival tactic in our field as one can get easily distracted. I can count on one hand the number of people I could walk up to in a hallway with a random article and geek out for 3hrs--like a mental foodie. A rare profile indeed.
deleted 4y ago
[deleted]
chefandy 4y ago
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. 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. 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 in general because computers didn't treat them like numbers, and supported the current label 'text.' OED definition 3a for number: > An arithmetical value assigned to something or someone, esp. to indicate position in a series, or for purposes of reference, identification, etc. There is no definition for 'text' in the unabridged OED that describes anything other than words. 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. 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 or more worth considering.
- asddubs 4y ago
  yeah, i suppose it should have been called type=amount
  - 4y ago

141 points by 7237139812 4y ago

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

rzzzt 4y ago
My mind immediately jumped to cows and Switzerland reading this.
greggsy 4y ago
as a security professional, there is nothing more frustrating than reading a report that completely misses the mark in terms of audience, and the overuse of industry jargon.
unfocussed_mike 4y ago
Right. You can't hide the detail with a wave of the hand, you can definitely overcommunicate detail that is unnecessary, but the art of it is finding a way to explain the bit that matters in a way that makes it clear to the users that you're eliding detail that isn't important, without misleading them. There is a very fine example of this in cinema -- the senior partners meeting in Margin Call, where Zachary Quinto's character has to explain why the firm needs to sell all of a particular asset class: https://www.youtube.com/watch?v=Hhy7JUinlu0 https://www.youtube.com/watch?v=Hhy7JUinlu0 One day I will use the line Jeremy Irons uses in this clip. I don't want to spoil it by quoting it.
- nthj 4y ago
  That’s a great scene. For anyone who hasn’t seen the movie, I might recommend skipping the clip and watching the full film! If you’re on HN, odds are you would enjoy it, and it has an impressive cast.
  - unfocussed_mike 4y ago
    It is an outstanding movie. But I think this particular scene is one of the finest scenes in any movie ever made. It could stand alone as a short.
- ColinWright 4y ago
  Outstanding film, outstanding cast, outstanding performances. I initially watched it because Stanley Tucci is in it ... I stayed for the drama, and then Jeremy Irons stole it.

langsoul-com 4y ago

Talking technical stuff to non technical is an enormous pain. The levels of dumbing down is near endless. Not everyone has to be able to explain their product to the masses, let someone else have that job.

PradeetPatel 4y ago
>The levels of dumbing down is near endless This is the kind of patronising attitude that will further the gap between engineers and product people. Being able to articulate technical details with the right level of abstraction, and without "dumbing it down" is an essential skill when engaging with stakeholders of varying levels.
- wfme 4y ago
  Agreed. When talking to a doctor, you expect to communicate in terms you understand, or at least have essential terms explained in a non-condescending manner. It doesn't matter if they know a technically correct term for something if it means nothing to you - you expect to be communicated with, not communicated to. The same expectations carry across to most jobs in tech. It is rare that you work in isolation, so being able to communicate details without going over the head of the other person is an invaluable skill to master.
  - majkinetor 4y ago
    In what universe doctors communicate in terms you understand? They even write freeking diagnosis on Latin that nobody knows. Coming out of doctor that explained things to you is once-in-life event.
    - nulbyte 4y ago
      Not sure where you are located, but I've lived in many places in the Midwest and Florida, and almost every doctor I have interacted with is fully capable of explaining things and does it well. This is not a once-in-a-lifetime thing, but a basic requirement. If your doctor isn't doing this, maybe you should ask more questions. If your doctor can't do this, find another one.

eyelidlessness 4y ago

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. Learning how to communicate with anyone is hard. But it’s very worthwhile if we can.

greggsy 4y ago
Back in my service desk days, we were encouraged to write and revisit SOPs in our downtime as it is and excellent way to pick up how things work, and how to write in a style that everyone is on board with. The most effective part of that system was to get the older lady in accounts to run through some of the processes that required detail and rigor to see where things weren’t clear enough.
unfocussed_mike 4y ago
This was my telephone life with my Dad for thirty years, all of his later life and almost two thirds of my life, even well into his dementia (because his memories of his professional career were really untouched by it). After only one month I already miss it enormously. I am very glad you find these calls rewarding and I am certain she does too. I am going to have to find someone to fill this role in my own life again.
- O_H_E 4y ago
  I'm sorry for your loss, and I am glad that you had a fulfilling relationship with your dad. It sounds like you are steadily strolling the road of healthy grieving, I'm sure he would be proud. Keep your head above the water my friend.
  - unfocussed_mike 4y ago
    Thank you. And yes -- navigating the line between the endings/beginnings bit, the loss (which it is), and tragedy (which it isn't) is difficult but this time around I am finding it easier. One of the things I have already realised is that explaining-stuff-to-my-Dad is portable. I can do it in my head. And when I can do that without tears, I'll be able to add my Dad to any audience in the future, and hear his questions as well as theirs.

Tainnor 4y ago

> 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. Except English does have such a word and the author literally linked to its dictionary entry in an English dictionary.

7237139812 4y ago
OP here. I think it serves as a loanword, but I concede that linking to an _English_ dictionary can blur the point I was trying to make. Edited for clarity, thanks!

raffraffraff 4y ago

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

Multicomp 4y ago
> Documentation as code, man In my list of mean things I'm going to insist on should I ever go crazy and start my own company, documentation will be just as if not more incentivized than the actual code. I want design diagrams, users lists, documented decisions on how backups are expected to happen, how this is expected to scale, why we went with X pattern instead of Y, who asked for a given feature, then as a last measure start doing the brittle document bits like API reference n such. The code has its own inertia and desirability, but if you don't push docs, they are looked down on even though they have proven value. What are we, scientists building and designing a new system or children slapping mud into a play dough concrete mixer and moving on to our next mud pie? Write it down Mr supposed professional!
- nicklarsennz 4y ago
  I've found Lightweight Architecture Decision Records (as markdown docs in a repo with the code, or wherever makes sense) to explain the current landscape, options, decision, and foreseeable consequences. Keeping it really light makes it tolerable for people who don't like to write docs, though does need the team to insist on the doc for anything non trivial. I also like using the Draw.io vscode extension to draw diagrams without having to export into a separate file or copy into the repo.
  - 4y ago

known 4y ago

benreesman 4y ago

I always have trouble parsing the Seemingly Wrong Thing That I’m Redefining writing style, so I’m not sure my comment is germane. It seems 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. 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.

yakshaving_jgt 4y ago
My interpretation was that it was more of an encouragement to think about things at a higher level of abstraction rather thinking of implementation details, as is a common reflex for so many programmers. Being able to communicate at that higher level of abstraction is a consequence of first having trained yourself to think at that level.
- Enginerrrd 4y ago
  Yeah it's an important skill. I knew an engineer that was about as smart as me in school. If there was a real stumper of a question on the exam, we'd be the only two to get it right. He was a hard worker. But that guy was incapable of discussing things at the 64,000 ft view, let alone the 30,000 ft or 10,000 ft. As a result, he had a really tough time working with anyone else, and the entire program was deeply focused on teams. You became like family with the other students by the end of the 2nd year. Your reputation in groups was incredibly important. This guy, he could be completely correct, and yet somehow get other smart engineering students to turn against him, including myself. No one could work with him. One instance of that still haunts me... It's really unusual that I don't listen to someone else and consider what they had to say, and yet I did exactly that on a really important project with that guy. He was completely correct about a very important and fundamental thing, and yet I just couldn't see it until it was too late. 10 years later, that still bothers me. That lack of skill haunted him in his later career. The last I'd heard, he had gotten fired from a job with a company that didn't fire anybody. It was bizarre to watch someone that could think about such technical and difficult things effortlessly, yet be unable to reason about them (or at least communicate) with nearly any level of higher abstraction.

nicbou 4y ago

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. 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. If this is not abundantly clear to you, consider how clarity shapes your interaction with lawyers, doctors and mechanics.

dgb23 4y ago
> 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.
- Jensson 4y ago
  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.

unfocussed_mike 4y ago

All very deeply true. Many moons ago I worked in a briefly-successful UK "dot com" integrator, and then took a break from work for personal reasons. 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".) 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). Nowadays this is reasonably commonplace but at that time it was pretty radical. 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.

ozim 4y ago

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.

MauranKilom 4y ago

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

redbar0n 4y ago

Cause: The Curse of Expertise - https://en.m.wikipedia.org/wiki/Curse_of_knowledge https://en.m.wikipedia.org/wiki/Curse_of_knowledge

k__ 4y ago

The gist is, be as technical as you like, but don't lose your grip on reality. Talking with people is your interface to the rest of the world. If they don't understand you, then you're lost.

bright_light 4y ago

Thought train: - 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.

adhesive_wombat 4y ago
> Filtering technical knowledge into a relevant format for a listener to comprehend in real time is a skill that can be learnt. Sadly, not a skill most "scientific journalists" appear to have learned. There's a difference between "make understandable" and "dumb down to complete context-free drivel"[1]. And that's before the aforementioned "journalist" takes a single press release from a university PR department at face value rather than doing, well, journalism. [1]: or maybe this is just https://xkcd.com/2501 https://xkcd.com/2501 on my behalf
- SamoyedFurFluff 4y ago
  My understanding of what might be going on here is broken telephone with intent. A reporter gleans only a subset of information from a given body of research, then ends up reporting only on what portions they consider to be essential. The end result loses nuance and context. I don’t think reporters want to be doing this, but society doesn’t incentivize serious reporting in of itself.

a_square_peg 4y ago

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.

pojzon 4y ago

I often try to explain something probing on what will be the appropriate level for the listener. So you start at the level you expect the person to understand but you often have to go few levels lower (simplier). I understand its needed for laymen, as in this saying “if you cannot explain something simple enough - you dont understand it well enough”. Tho I often find myself explaining stuff the same way to experts in the field :) Which makes me realize -> real experts are extremely rare.

russellendicott 4y ago
I find this to be true. I find that while I work with people who are perfectly capable of becoming experts in a given category, they protect their brains from having to hold unnecessary information that isn't relevant to their current course. This is a very important survival tactic in our field as one can get easily distracted. I can count on one hand the number of people I could walk up to in a hallway with a random article and geek out for 3hrs--like a mental foodie. A rare profile indeed.

deleted 4y ago

[deleted]

chefandy 4y ago

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. 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. 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 in general because computers didn't treat them like numbers, and supported the current label 'text.' OED definition 3a for number: > An arithmetical value assigned to something or someone, esp. to indicate position in a series, or for purposes of reference, identification, etc. There is no definition for 'text' in the unabridged OED that describes anything other than words. 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. 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 or more worth considering.

asddubs 4y ago
yeah, i suppose it should have been called type=amount
- 4y ago