How to communicate effectively as a developer • Hacker News Board

Re: How to communicate effectively as a developer

#151

Post by _greim_ » Fri, Oct 28, 2022, 8:45 PM UTC

johnchristopher wrote: post #121

_greim_ wrote: post #113

Earlier quoted context omitted.

It's definitely a coping mechanism. When you've been burned repeatedly by people nodding vigorously in understanding, then turning around and revealing a complete lack of comprehension, forcing you to either intervene or allow the error to propagate, it's tempting to fall into a habit of pre-emptively explaining everything.

> revealing a complete lack of comprehension, forcing you to either intervene or allow the error to propagate, it's tempting to fall into a habit of pre-emptively explaining everything. Or maybe the explanation was bad to begin with. Over communicating won't turn a bad explanation into a good one. Understanding something doesn't mean you know how to explain it to someone else.

> Understanding something doesn't mean you know how to explain it to someone else.

Too true. Explaining things is hard. My gripe is mainly people's tendency to pretend they understand in perpetuity, instead of expressing a modicum of curiosity about it. "What does 'TPS' stand for actually?" As mentioned, explaining things is hard, and I think I'm not alone in needing help identifying gaps in my explanations.

That said, I also understand that there are huge social barriers to admitting a lack of understanding in the tech industry, especially for juniors.

Re: How to communicate effectively as a developer

#152

Post by hbrn » Fri, Oct 28, 2022, 9:06 PM UTC

skydhash wrote: post #104

hbrn wrote: post #54

Earlier quoted context omitted.

Spot on. But it's not even about writing. Developers hate communication , in any form. Going remote made it much worse, there's even more ways to avoid communication or turning it async. The only remedy I found is actively forcing people to talk to each other, starting with yourself. Doing a code review? Grab the reviewee in a Slack huddle for 15 minutes, it'll save time for both of you. Need a code review? Grab the…

> The only remedy I found is actively forcing people to talk to each other, starting with yourself. That's not communication. That is forced socialization. There are things that are expressed more efficiently in spoken form, but the truth is that spoken words are ephemeral and the mechanism for storing and retrieving them are cumbersome. I like written communication, it forces you to be more structured in your thinki…

> I like written communication, it forces you to be more structured in your thinking

It sure does, but I don't care if comms are unstructured if same job gets done much faster. You're not going to frame your structured communication and put it on the wall. You could argue that someone might find your past PR communication useful in the future, but that's what code comments are for.

> a review that can be done in a slack hurdle in 15 minutes can be done async in less

Strongly disagree, some code reviews have lots of back and forth. A branch that could be merged within an hour may take several days because reviewers and branch owner each going at their own pace. The more async you are, the more WIP you're going to have, and it is always a bad thing.

> every one of these hurdles will actually be surrounded by a period of non-productive time

I consider time spent getting on the same page with my team members to be one of the most productive things I can do. Even more productive than writing code.

Re: How to communicate effectively as a developer

#153

Post by roenxi » Fri, Oct 28, 2022, 9:06 PM UTC

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…

> I'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities.

As an alternate theory, maybe they've spent a lot of time staring at the code in question and internalised the context to a point where they no longer think about it. Happens to everyone.

Re: How to communicate effectively as a developer

#154

Post by frenchman99 » Fri, Oct 28, 2022, 9:07 PM UTC

devonkim wrote: post #87

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…

The issues I have are that developers tend to be bad at communicating even with each other. Communication as a discipline is a lot about meeting people where they are and this is difficult for basically everyone. The antagonistic attitude that developers seem to develop happen across almost every technical discipline whether it’s engineering or even trades. It may be even worse in trades given so much contact with th…

> If developers had to do customer support for their products as a rule you bet they’d get grumpy.

Do you have data to support this?

I would love to do customer support from time to time to better understand the users of the product I work on as a developer. But that request has been denied to me many times, in multiple jobs.

To get people to communicate better, inspire them to do so and have faith in them.

Re: How to communicate effectively as a developer

#155

Post by mfuzzey » Fri, Oct 28, 2022, 9:07 PM UTC

D13Fd wrote: post #133

phinullfermata wrote: post #45

Earlier quoted context omitted.

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…

I think it's far better give the reader as much information as reasonable and let him decicde how much he wants / needs to read. That can avoid multiple round trips and makes sure the whole picture is available to anyone who may need it.

Particularly as often the same message will be sent to multiple recieients that have different needs.

Of course you should try to structure the message so that people don't necessarilly have to read all of it.

For instance I recently sent a message about an analysis of the feasibility of changing a piece of hardware to a group that contained

* Managers * Hardware developers (in charge of implementing the hardware modification) * Software developers (in charge of adapting the software to the new hardware)

So it started with a brief summary of the idea and conclusion "yes it will work" (for the managers).

Continued with a some comments, questions addressed to the hardware team "the aproach is fine but we still need to sort out X,Y,Z"

And finished with a detailed description for the software team of how we should integrate the new hardware whilst remaining compatible with the existing.

Re: How to communicate effectively as a developer

#156

Post by raydiatian » Fri, Oct 28, 2022, 9:10 PM UTC

> empathically increasing the resolution of your writing

I find this to be obnoxious and nonsensical, which, in an article about communicating effectively, is ironic.

Re: How to communicate effectively as a developer

#157

Post by kitanata » Fri, Oct 28, 2022, 9:13 PM UTC

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…

I am a Staff Engineer leading a large engineering organization. I am also “on the spectrum” and openly autistic. My co-workers know that I am autistic.

I have found that communicating to business folks and leaders is a skill like anything else and can be taught. Your assumption that being autistic somehow completely disqualifies one to speak competently to others is ableist and harmful.

While it is true that people who are autistic struggle to communicate with non-autistic people I would argue it is also difficult for non-autistic people to communicate with autistic people.

It is also ableist to assume that just because someone lacks communication skills that they are “on the spectrum”.

What is true is that communication as a skill is not often taught to developers.

Re: How to communicate effectively as a developer

#158

Post by _greim_ » Fri, Oct 28, 2022, 9:16 PM UTC

jonahx wrote: post #148

_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.…

Bottom right should be "points lost" imo. For me, the most points lost, as there is nothing more annoying than someone assuming context I don't have. It seems that this chart assumes: 1. Everyone is a baby that gets their feelings hurt when you imply they might not know something they do in fact know (top right). 2. Everyone loves being alpha nerd and making people feel dumb for not knowing things they know (bottom r…

Yes, I'm for sure describing a perverse incentive structure, but one that's easy to fall into, almost a default state. If you get enough well-intentioned people together they can break the cycle, and then you have a healthy team.

> Bottom right should be "points lost" imo.

There's a certain breed of hot-shot dev who truly believes they're gaining status by making cryptic, in-the-know references, and there's another breed who falls for it. When it comes to social status games, if enough people believe it, it becomes true.

Re: How to communicate effectively as a developer

#159

Post by cjblomqvist » Fri, Oct 28, 2022, 9:25 PM UTC

nescioquid wrote: post #147

cjblomqvist wrote: post #134

Earlier quoted context omitted.

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

> One big problem I see nowadays is that more people do not care about the details... I think people today care about the details just as much as people used to. It's just that there are so many more details to care about today. The exhaustive CYA-flagging of risks (and similar behaviors) denotes more a problem of how incentive are aligned in that workplace rather than any lack of skill with words.

CYA?

Re: How to communicate effectively as a developer

#160

Post by _greim_ » Fri, Oct 28, 2022, 9:28 PM UTC

californical wrote: post #122

_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 think your chart is incomplete, because in the bottom-right quadrant, there’s the caveat that they never ask for clarification and blindly do the wrong thing. Then when you have to go back and tell them the basic assumptions that they are wrong about, and that they have to redo tons of work, you lose a giant sum of hypothetical points

My theory is that devs often trade pretense-now for research-later. This habit allows them to gain ~0.002 status points here and there. But now combine that with unknown-unknowns. The thing they're hearing—if they actually understood it—ought to cause them to abandon or completely rethink a change they're currently working on. But because their takeaway isn't new knowledge, but a placeholder for potential new knowledge, they end up losing 15 status points when it blows up, in a way that was utterly unforeseeable.