Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

41–50 of 222 posts

Re: How to communicate effectively as a developer

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

It is the opposite, being wrong is a really great way to start a conversation, people are really eager to correct mistakes.

Re: How to communicate effectively as a developer

#42
post #33

> Communicating effectively as an engineer means empathically increasing the resolution of your writing. What does that even mean?...

To communicate technical concepts effectively, think harder about what may be unclear or misunderstood by the recipient(s) and take the time to address those ambiguities preemptively.

Re: How to communicate effectively as a developer

#43

Judging the right amount of information is what I struggle with. It's easier to judge whether someone wants more details when you're talking to them. It's harder when you're responding to a comment or in a chat. When it's too little, you go back and forth. When it's too much nobody reads your novel. I tend to go into too much detail, so I'm learning go where I feel is adequate and then take a few steps back.

I think it helps if you can preface your paragraph with a short summary.

The reader then knows generally the scope of what you are trying to communicate, and the details become more approachable. That said, I’m pretty horrible at this balance as well, and often lean towards long form “walls of text” that eat office hours, then work OT to compensate.

Re: How to communicate effectively as a developer

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

It's interesting, because I've heard a lot of stories about environments like that, but I've never personally seen one. In every job I've had, the most respected (and highest paid) developers have always been the ones who struggle to find time to write code because they're too busy communicating. It was actually a hurdle for me at the start, and I remember being shocked the first time a manager told me writing lots of good code wasn't enough to get promoted.

Re: How to communicate effectively as a developer

#45
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 noticed this in the author's review example. The first paragraph gets a reasonably high resolution description of the problem, then the detail follows in the next paragraphs.

Re: How to communicate effectively as a developer

#46

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

The ones at the top of the blog post? The ones on the right are better for nearly every case I can think of. "what is 'it'?", "who is 'her'?", and "'not working properly' how?" are not the type of detail questions that people generally want to have to ask ever. (maybe the third is sometimes OK)

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.

Re: How to communicate effectively as a developer

#48

Judging the right amount of information is what I struggle with. It's easier to judge whether someone wants more details when you're talking to them. It's harder when you're responding to a comment or in a chat. When it's too little, you go back and forth. When it's too much nobody reads your novel. I tend to go into too much detail, so I'm learning go where I feel is adequate and then take a few steps back.

Every IM I send has an immense emotional toll for some reason. Everyone is overworked and you’re another distraction, you feel like a giant asshole and then project that they’re a giant asshole too until you enter the emotional doom spiral.

In person or on video flows so much more nicely because you can see the effect of interaction and be cordial to each other without the paranoia and dread setting in.

Re: How to communicate effectively as a developer

#49
post #19

This has little to do w/ being a developer vs. being human. People joke about the programmer in a dark corner plugging away and never talking to others, but that's actually pretty rare. In 20 years I've only worked with a handful of developers who don't want to socialize, collaborate, or solve problems together. The truth is that people - regardless of discipline - generally all want the same things from their work:…

There are developers who have no choice but to work alone, but they socialize and collaborate otherwise. No matter what they do, a person talking over them is enough to make it impossible to focus on the task at hand, to think, even.

Re: How to communicate effectively as a developer

#50

Earlier quoted context omitted.

The ones at the top of the blog post? The ones on the right are better for nearly every case I can think of. "what is 'it'?", "who is 'her'?", and "'not working properly' how?" are not the type of detail questions that people generally want to have to ask ever. (maybe the third is sometimes OK)

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.

Post reply on HN