Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Less Technical

sequential.dev

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Be Less Technical

#51

Post by adhesive_wombat »

bright_light wrote: post #41

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…

> 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 on my behalf

Re: Be Less Technical

#52

Post by pojzon »

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.

Re: Be Less Technical

#53

Post by Multicomp »

raffraffraff wrote: post #10

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 re…

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

Re: Be Less Technical

#54

Post by nulbyte »

majkinetor wrote: post #15
wfme wrote: post #6

Earlier quoted context omitted.

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 bein…

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.

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.

Re: Be Less Technical

#55

Post by nulbyte »

unfocussed_mike wrote: post #29
langsoul-com wrote: post #3

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.

You are missing one of the great untold truths of engineering: non-technical people can be just as brilliantly intelligent. They just don't speak your language or have your experience. You do not particularly need to dumb it down. You do need to think about which things they actually need to know, and provide some backstory that helps them contextualise it. Get good at this and your life will be enormously better. Ke…

I agree wholeheartedly with this. I have lost count of the number of times I have found a solution to some problem after explaining some technical detail to a layman who then suggested something I wouldn't have thought of.

Re: Be Less Technical

#56

Post by ColinWright »

unfocussed_mike wrote: post #37
shalmanese wrote: post #2

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 be…

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…

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.

Re: Be Less Technical

#57

Post by Enginerrrd »

yakshaving_jgt wrote: post #18
benreesman wrote: post #14

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 understa…

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.

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.

Re: Be Less Technical

#58

Post by russellendicott »

pojzon wrote: post #52

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…

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.

Re: Be Less Technical

#59

Post by nicklarsennz »

Multicomp wrote: post #53
raffraffraff wrote: post #10

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 re…

> 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 m…

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.

Re: Be Less Technical

#60

Post by RSHEPP »

nicklarsennz wrote: post #59
Multicomp wrote: post #53

Earlier quoted context omitted.

> 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 m…

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 diag…

I push for plantuml sequence diagrams for almost any new feature. Keep the files in SCC and can review with the MR.

Most engineers find them useful and not too much of a headache to write.

Post reply on HN