Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

61–70 of 222 posts

Re: How to communicate effectively as a developer

#61

> 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 breathing before I respond. It's just so disrespectful to the people you're trying to get to help you. There's also the common issue of someone dropping a meaningless "left-side type message" and then when you later see it and respond for clarification they're in the bathroom or at lunch.

There's a 20% chance I'll respond with something sarcastic like:

"Why are you referring to yourself as 'the worker' instead of your real name? And why are you having a bad time?"

If I'm in a less sarcastic mood I still have to ask:

"what is the worker? What do you mean by a bad time? What environment (local/dev/prod?) How can you tell it's having a bad time? What is an example of having a good time?"

If you want to keep the first message as a brief overview, that's fine, but you can send a 2nd message with more info, in slack you can comment on your own message as a subthread. I will say sometimes inexperienced people have the opposite problem of a massive info dump it takes you forever to parse through. That's not great either. But there is a middle ground.

Re: How to communicate effectively as a developer

#63
> It's not about you, though.. It's about them.

Ironically (given the context), he buried the lede.

That aside, if you're interested in raising your comms flag, I recently finished "Smart Brevity". As a solution, it's not a panacea for all use cases. Still, it's a quick and useful read. Simple but effective.

https://www.thriftbooks.com/w/smart-brevity-write-less-say-m...

I'd also recommend "Words That Work" by Frank Luntz. Chapter 1 is all you need. The rest is simply the lessons from Chapter 1 in practice.

https://www.thriftbooks.com/w/words-that-work-its-not-what-y...

Re: How to communicate effectively as a developer

#64

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…

[deleted]

Re: How to communicate effectively as a developer

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

For context: I never really cared about yearly reviews or raises at my job before my current job. I knew they were going to be mostly shit anyway and that I was better off job hopping every couple of years to get a “raise”. Which I did six times between 2008 and 2020 after staying at my second job 9 years and getting 3% raises and seeing the bonus drop.

That being said, the only formal raise/promotion process i know about are at tech companies. Promotions are based on “scope” and “impact” and not how well you code. The only time “coding well” comes into play is going from junior or mid.

Even the interviews that determine your leveling is based on behavioral interviews and system design.

I couldn’t interview for my next job and all I could put on my resume is “I wrote a lot of code”

Re: How to communicate effectively as a developer

#66

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 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/Curse_of_knowledge

Re: How to communicate effectively as a developer

#67

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.

Yes, that's often it. But it's also not exclusive to devs. As the receiver I've learned to say / ask, "I don't follow. Can you clarify?"

Re: How to communicate effectively as a developer

#68

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…

> I have experience that suggests the contrary of his suggestions Yep, this is the "internet blog" phenomenon. The author asserts, without any evidence, that _X_ ought to be true, therefore _X_ is true.

On the contrary I think treating DMs in an internal chat tool as blogging is quite harmful.

As elaborated in another comment, I do trust my peers to point out errors in my assumptions.

Re: How to communicate effectively as a developer

#69
post #66

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

This is something I wrestle with at work all the time. I try to break things down to make them comprehensible but I wind up forgetting to frame the discussion to give the context needed to get input even from fellow developers.

Re: How to communicate effectively as a developer

#70

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

[deleted]
Post reply on HN