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

141–150 of 222 posts

Re: How to communicate effectively as a developer

#141

Post by karmelapple »

xbfjvusb6 wrote: post #15
ngrost24 wrote: post #8

Earlier quoted context omitted.

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…

This. I can tell HR, my lead and skip about how good my communication, soft skills and team work have been this year but come comp review they don't give a crapola about any of that. All they look at is how many sloc I've shipped.

I'm fascinated: does your company/manager truly track SLOC and promote based on that?

Or is SLOC here more of a proxy for "features shipped"?

Because if this is what's happening, I'd encourage two changes:

1. Communicate differently to HR, lead, and skip - either use different approaches of documentation, or point out different aspects of your contributions 2. If trying various different approaches don't work... leave.

For communicating differently - I used to work at a large company, and our yearly reviews had places to capture accomplishments. That was a broad topic: it wasn't just features built, bugs fixed or identified, etc. It would also be totally appropriate to put ways you saved money or time on various initiatives, and I would frequently put down items like this.

How do you communicate "how good" your "communication, soft skills, and team work have been this year"?

Re: How to communicate effectively as a developer

#142

Post by nuclearnice1 »

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 like your opening question. A casual way to establish some context and rapport.

I’m not sure this is a competing take vs the article. More like complementary.

The article mainly says “add more details.” Eg. Don’t write “the system is broken” be specific about what’s broken, what you did, and if you need help.

Basically, don’t assume context.

The author takes himself to be some kind of writer, so he said it in too many words.

Re: How to communicate effectively as a developer

#143

Post by mjw1007 »

slillibri wrote: post #139
mjw1007 wrote: post #89

Earlier quoted context omitted.

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.

My view is that, whatever is causing developers to often be bad at filling in context, it isn't a deficiency in their theory of mind.

(Similarly, someone elsethread is talking about how their non-developer colleagues neglected to tell them about an upcoming release. One possible explanation is that their colleagues were bad at "theory of mind", and believed that as they knew about the release, so did everybody else. But I think it's more likely that they were too disorganised to make sure that it was somebody's job to tell everyone who needed to know.)

Re: How to communicate effectively as a developer

#144

Post by karmelapple »

> Writing messages on Slack isn’t what engineers get paid for, though. Writing code to solve problems is.

Perhaps I'm being picky, but... that's also not what engineers get paid for, either.

I think engineers get paid to do things that solve problems. Sometimes that involves writing code, but sometimes it absolutely involves writing a Slack message, having a call, or just thinking a little more.

A Slack message might be, "Got a minute to chat?" to start a voice call that will clarify some requirement that's been bogged down in a quagmire of too much writing or conflicting ideas. Requirements are clarified, maybe not a single line of code is needed to be written, thanks to a better understanding of the customer's desires.

A Slack message might ask, "Does this change work instead?" with an image attached of a simpler approach.

I wouldn't typically respond to one line from a blog post, but since this was up so high in the post, I felt I needed to gently encourage a little rewrite of this sentence :)

Re: How to communicate effectively as a developer

#145

Post by wcedmisten »

tristor wrote: post #140

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

I recently watched Kelsey Hightower's Strange Loop talk on "The Secure Software Supply Chain", which incorporates a humorous narrative about deploying code found on a flash drive in a coffee shop. I think the talk was especially captivating because of that.

I'm trying to incorporate that narrative aspect into my own demos and presentations now.

https://m.youtube.com/watch?v=JC-xCXcyNXI

Re: How to communicate effectively as a developer

#146

Post by cratermoon »

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 work with a developer* who draws labelled boxes and arrows for diagrams and posts screenshots of code in response to questions I put to him. I can't say I've been able to find more than a handful of places where he's put words together into sentences and paragraphs. Getting useful information out of him is like pulling teeth. Even when he could link to code on the git server, e.g., he doesn't.

His screenshots are the worst-case scenario of lack of context – just a couple of dozen lines of code, no information about where, in what file, in which repo, he's given.

* We both work remotely and live in different states, nowhere near each other.

Re: How to communicate effectively as a developer

#147

Post by nescioquid »

cjblomqvist wrote: post #134
A4ET8a8uTh0 wrote: post #128

Earlier quoted context omitted.

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

Re: How to communicate effectively as a developer

#148

Post by jonahx »

_greim_ wrote: post #74
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 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 right)

While both of those are real phenomena, they are pretty dysfunctional. Many people (most people?) enjoy genuine cooperation within a context of mutual trust, learning things from others, and teaching others who want to learn. In that context, checking for knowledge is not a slight, and assuming things "are obvious" and failing to explain them is not a flex.

Re: How to communicate effectively as a developer

#150

Post by leepowers »

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…

But ... the examples on the right are short, concise, and effectively communicate the problem. The left examples contain no actionable information, wasting the time and attention of everyone in the channel/thread.

Maybe working in an adversarial or dysfunctional work environment is what leads to misinterpreting a detailed message as hostile.

Or the team needs to learn to use communication tools effectively. Slack messages should be concise. But a bug report doesn't always fit neatly into a few lines of text. Use an issue tracker for detailed reporting and Slack/email for informal conversations.

Either way the point of the blog post stands - everyone needs to communicate clearly and avoid ambiguous language. If I send an ambiguous message to 10 people, I've just increased their mental overhead and frustration, ultimately distracting the team and slowing them down. Instead, I should take a moment and try to look at it from their point of view and try to communicate what they need to hear and not what I want to say.

Post reply on HN