Be Less Technical
sequential.dev
Be Less Technical
1–10 of 73 posts
Re: Be Less Technical
#2Importantly, 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 ...".
Re: Be Less Technical
#3Talking 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.
Re: Be Less Technical
#4Talking 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.
>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.
Re: Be Less Technical
#5I 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.
Re: Be Less Technical
#6Talking 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.
>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.
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.
Re: Be Less Technical
#7Talking 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.
I don't really think of dumbing it down, more like distilling it to its true essence. To be able to do so requires even more skill and understanding than just enumerating the details. I always think of the Feynman anecdote where he talks about skipping chalk on a chalkboard.
Re: Be Less Technical
#8Importantly, 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 be…
My mind immediately jumped to cows and Switzerland reading this.
Re: Be Less Technical
#9> 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.
Re: Be Less Technical
#10Where 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".