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

How to communicate effectively as a developer

karlsutt.com

Post reply on HN
Print view View original

131–140 of 222 posts

Re: How to communicate effectively as a developer

#131

Post by MonkeyClub »

Consultant32452 wrote: post #125
taude wrote: post #66

Earlier quoted context omitted.

I think you're "assumed context" problem actually has another term called "Curse of Knowledge" [1] (which I believe it's much more known as). There's a ton of strategies that have been written about it. Just adding this term here for people who want to search for strategies on how to work around this. It comes into play in all forms of communication, written, verbal, Slack, etc... [1] https://en.wikipedia.org/wiki/Cu…

I can speak to what it's like with autism brain. In conversations people often say things that I have unusual associations about. My mind will start spiraling about the unusual association and I will begin an internal narrative about the new, unrelated topic without verbalizing any of it. I will continue with the original conversation with the convo partner. Then, out of the blue, I will verbalize something about the…

> Countdown to database of mating habits of penguins comment.

19 minutes.

Re: How to communicate effectively as a developer

#133

Post by D13Fd »

phinullfermata wrote: post #45
D13Fd wrote: post #29

This is a great article with nice examples, and I like the "high resolution" vs. "low resolution" concept. But it leaves off the other side of the equation: know your audience. If your audience wants to read a long, detailed communication, then that's great and you should write a "high resolution" message. If your audience has little time available and no real need to know the details, then the "low resolution" messa…

Someone who doesn't care about the detail can and will stop reading. It's important to get your main point across early because of this fact. The inclusion of detail is helpful but it needs to be in the right place. I think this is why traditional business writing evolved to have an order like summary, recommendation, then supporting evidence. If you've written things well you can get the best of both worlds. I notic…

I still disagree. Sure, you can get your main point across and then offer extra detail. But the extra detail is often detrimental in that your reader probably isn’t comfortable stopping before they read it.

To be clear, I’m talking about business communications here (as was the article), not other kinds of writing.

In my field, at least, this is a fundamental concept that differentiates some of the best communicators.

Re: How to communicate effectively as a developer

#134

Post by cjblomqvist »

A4ET8a8uTh0 wrote: post #128
_greim_ wrote: post #74

Earlier quoted context omitted.

> The biggest problem I see in developer communication is what I call the "assumed context" problem. Ah yes, the "shouting up from the rabbit-hole problem". > people "on the spectrum" often having low "theory of mind" capabilities. I somewhat take issue with this, as people on the spectrum are more likely to over-communicate, all other things being equal. Techies are rather caught in a web of social status pressures.…

I don't think I am on the spectrum ( I mean, I guess technically everyone is, which is why its a spectrum ), but I do know that I was ..what is a good word.. chastised.. no.. maybe gently admonished for putting up very long detailed summaries with some discussion of potential risks involved in an assumed approach, potential tradeoffs and pitfalls. It really depends on your boss, but I come from compliance world, wher…

I agree (I think). I think the point is that by talking about the details the receiver doesn't get it more - it's more that some details stick instead (and thus the big picture is lost).

Thus, the only way forward is to summerize, and then point out that there are details/nuances (but not getting into it). Only if the there's interest in those nuances, then it's relevant going into them.

Same as with physics. First you learn Newton. Then you eventually realize Einstein adds nuance to the formula. Start with Einstein and it becomes much more complex, hard to grasp and less likely you'll understand anything. And, equally important. If the receiver doesn't want to know Einstein, then no point in talking about him.

One big problem I see nowadays is that more people do not care about the details, meaning it's less useful as a communicator to communicate then - but also that people do not fully grasp as much the nuances and believe (and search for) simple answers - and come to dangerous conclusions about them. From my POV this is the danger with the attention economy, leading to Trumpism and similar phenomena.

Re: How to communicate effectively as a developer

#135

Post by cjblomqvist »

Consultant32452 wrote: post #125
taude wrote: post #66

Earlier quoted context omitted.

I think you're "assumed context" problem actually has another term called "Curse of Knowledge" [1] (which I believe it's much more known as). There's a ton of strategies that have been written about it. Just adding this term here for people who want to search for strategies on how to work around this. It comes into play in all forms of communication, written, verbal, Slack, etc... [1] https://en.wikipedia.org/wiki/Cu…

I can speak to what it's like with autism brain. In conversations people often say things that I have unusual associations about. My mind will start spiraling about the unusual association and I will begin an internal narrative about the new, unrelated topic without verbalizing any of it. I will continue with the original conversation with the convo partner. Then, out of the blue, I will verbalize something about the…

That's very clearly stated - I recognize it so much from my son (who has autism)! Thanks for putting it out there!

Re: How to communicate effectively as a developer

#136

Post by vsareto »

squeaky-clean wrote: post #61
commandlinefan wrote: post #32

> The examples on the right, on the other hand, try to make the reader do less work, even though it is more effort for the writer Ironically, these are perfect examples of the sort of thing that developers think is better but actually turn out to be worse. I thought the same thing as the author, early on - the more detail I can cram into each message the better. What I've found, though, is that most people actually i…

For taking with non-technical teammates I'd agree, but these examples look like developer-to-develeloper or support-to-developer, in which case I don't agree. Good communication is also about knowing who you're communicating with. If I get sent any messages like those examples on the left it actually upsets me. If someone sends me "the worker is having a bad time", first thing I'm doing is taking 10 seconds and breat…

>It's just so disrespectful

I think you're seeking that out. Someone more relaxed might just respond with "what's it doing?" and let them share the details. Some people chat over messengers like they talk in real life and you can learn to cope with both styles.

Re: How to communicate effectively as a developer

#137

Post by justin_oaks »

markrages wrote: post #91
ramilefu wrote: post #3

The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion. I think this is the origin for much of the friction we experience in collaboration and documen…

Sometimes I get the feeling that many developers are functionally illiterate. (In the https://quoteinvestigator.com/2012/12/11/cannot-read/ sense.) I can spend as much time as I like writing comments or design documentation or whitepapers or commit messages, but nobody reads it. Maybe they will set up a meeting for me to read it to them.

That's probably about right. But it's not isolated to developers. Most people skim or skip most instructions, documentation, warnings, etc.

When I write documentation I hope that people will never talk to me because the information they need is already written down. But more often it's so I can redirect them to the documentation and implicitly require that they read it before they continue to talk to me. In other words, documentation doesn't usually prevent an interruption as much as it minimizes the interruption.

Re: How to communicate effectively as a developer

#139

Post by slillibri »

mjw1007 wrote: post #89
BurningFrog wrote: post #51

Here is my competing take: The biggest problem I see in developer communication is what I call the "assumed context" problem. As in, you talk/write to people as if they know all about your code, except the detail being discussed. In reality, they usually have much less detailed understanding, and you're making no sense to them. I'm pretty sure this is related to people "on the spectrum" often having low "theory of mi…

The idea that programmers have a poor theory of mind doesn't stand up at all in my experience. I remember once seeing the inbox of someone working as a sales-ledger clerk. It was full of messages with the subject "accounts query", or a small variation of that. The ones with subjects like "query for account ACME-37" were from technical staff. Similarly if I ask "when do you need those figures?" and I get the answer "n…

I suppose, but as someone in infrastructure I have had developers ask very, very specific questions without ever actually providing the context or what they were actually trying to solve. Seems to me to be a variation on the same problem. Just because a question is specific doesn't mean it's the right question.

Re: How to communicate effectively as a developer

#140

Post by tristor »

As someone who went from engineering to product management, partly due to having developed a skill of communicating effectively in writing and in speech, I would suggest perhaps the most important part of communicating effectively is storytelling. If what you are sharing does not have a clear and obvious narrative arc, people are going to disengage quickly. This is not necessary for short bursts of information in a high-context environment, but any time you need to level set and share context before communicating the critical information, you should do so in story fashion.

If you want to level up your technical communication, I'd highly recommend taking classes in creative writing, participating in things like NaNoWriMo, or taking a class in improv comedy/theater. All of these things emphasize construction of narrative arcs and how to draw people through a story, which are essential communication skills. This gets more important the farther up the chain of command in a company you are communicating with.

Post reply on HN