Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

51–60 of 222 posts

Re: How to communicate effectively as a developer

#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 mind" capabilities. People without that will just assume people know what they know, and proceed to fail at communicating with those who don't.

It also makes it easy to think of those who don't know what is obvious to you as idiots.

The workaround, if you want to communicate with the idiots surrounding you, is to start conversations by fact finding. The question "so how much do you know about the flurbigator system?" can help.

Re: How to communicate effectively as a developer

#52
post #8
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…

Personal opinion or anecdata: Is it possible that communication is "detested" because it's not valued within the developer group? Many times, when someone speaks of a 10x software engineer, the gut feeling is of someone that provides the output (measurable in code) of 10 developers, not that he's able to have an impact in the organization through communication as 10 developers (breaking silo-s, syncing teams, etc), a…

> Many times, when someone speaks of a 10x software engineer, the gut feeling is of someone that provides the output (measurable in code) of 10 developers, not that he's able to have an impact in the organization through communication as 10 developers (breaking silo-s, syncing teams, etc), although this might be closer to the truth and what the duties of some staff and principal level developers includes.

Both are 10x developers. One by 10x impact at the code level, the other by 10x impact at the "delivering the right thing the first time" level.

Though, in reality, it's really hard to be a 10x developer without doing both of those things ... a profilic coder who is solving the right problem because they took the time to communicate and understand the real issues.

Re: How to communicate effectively as a developer

#53

Earlier quoted context omitted.

Yep, that's exactly how human communication ought to work, and the world would be infinitely better if it did. But it doesn't, actually.

I have often been frustrated that my attempts to communicate clearly have failed, but I choose to believe that it’s my fault as a writer, not their fault as a reader. The alternative is being a jaded, negative person who is unpleasant to work with. It’s too easy, too lazy, to fall into that trap.

Are you disagreeing with their conclusion or just the vibe? You can do both: believe things would be better with some global change, and also accept that won’t happen and do your best with how things are.

Re: How to communicate effectively as a developer

#54
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…

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 reviewer and walk them through the parts that are hard to understand.

Designing a big piece of architecture? Instead of writing a thorough design doc that nobody will read, build a rough diagram and share it with the team immediately, preferably on a call.

Writing documentation? Ask your team members what they want to see in it.

Yeah, it sucks to do all of that when you're an introvert. But it gets easier with time. And hopefully you can find joy in the fact that you are delivering value X times faster.

Re: How to communicate effectively as a developer

#56

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 generally agree with this - the first part of any effective communication is to see where you and the other person/people are starting from.

Only then can you decide how to try to communicate the rest.

Re: How to communicate effectively as a developer

#57
> Writing messages on Slack isn’t what engineers get paid for, though. Writing code to solve problems is. Instant messaging tools are seen more as a necessary evil to get work done in a team than anything else. Because of this dynamic, there is a tendency to elide details or cut messages short, sometimes at the expense of legibility.

The article is long on tips for individual media without explaining why you'd use one over the other. Digital communication encompasses a wide spectrum of media, each with its best use:

- realtime/recorded text (Slack, GitHub issue, README, Comment, etc.);

- recorded graphics/text (PowerPoint)

- realtime/recorded voice (voicemail, phone);

- realtime/recorded video (Zoom, YouTube).

The most important question before you use any one of them is: why this medium and not one of the others?

Even the right message created well will flop if sent across the wrong medium.

Re: How to communicate effectively as a developer

#58

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…

Alternatively, why is someone who doesn't know the product directing its design without asking appropriate questions on their end?

Re: How to communicate effectively as a developer

#59
In my own brain I've created 3 different categories :- Others, Developers, Management.

I find it easier to explain stuff to other people by giving context from their field

For example to someone in food industry I'd say, frontend is like how you present your food at the table and back-end is like the kitchen where food is prepared.

To people in development what I've learnt is that you've got to find the right balance, can't dumb it down a lot or can't switch it up, always in the middle.

Management will understand 3 things : Excel, PowerPoint, Money.

That takes care of 90% of my conversation.

Re: How to communicate effectively as a developer

#60
post #30

I have experience that suggests the contrary of his suggestions. Working in a remote culture, often we can spend too much time writing things out and in turn reading things that are irrelevant. I would propose a more progressive framework: Start with the short message without any context. If needed, make a new message with all the context. As an example I have a couple of times asked for help where a response would l…

The problem with opening with " > X is hard to do in Elixir, any ideas? " is that it shuts down any conversation about X. You've decided it's hard, but what if you're wrong? What if you could avoid X entirely by doing Y? What if the context around X makes it also hard to do in Next? Adding a little bit of context really helps open conversations.

Two people pointed this out with this commentary.

This is the exact point. I trust my colleagues in asking the right questions. Unless I shut them down with a wall of chatter.

> X is hard to do in Elixir, any ideas?

> Thanks!

Post reply on HN