Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

91–100 of 222 posts

Re: How to communicate effectively as a developer

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

Sometimes I get the feeling that many developers are functionally illiterate. (In the https://quoteinvestigator.com/2012/12/11/cannot-read/ sense.)

I can spend as much time as I like writing comments or design documentation or whitepapers or commit messages, but nobody reads it. Maybe they will set up a meeting for me to read it to them.

Re: How to communicate effectively as a developer

#92
post #89

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

For any theory about a common pattern of behaviour, there will be many exceptions that don’t fit the theory. Without hard data, both sides are giving a subjective opinion based on their experience, and both sides are probably right in part.

Re: How to communicate effectively as a developer

#93
I think some epic SE failures, the DOJ LE should get involved.

So the engineers' habit of providing details in written materials is indisputable potential forensic self defense.

Like the egg Greg in succession, he has a filmsy shell, but it protects, serves when needed.

My first civil engineering trainings, our department head she repeatedly stated and gave examples that 'you may go to jail if you don't follow the design rules and it failed' like this.

There is nothing called communication in engineer's world. That means plane fell, bridge collapse -- they are negotiable.

This is a community talk of opinions.

Re: How to communicate effectively as a developer

#94
post #74

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

IME, this is exactly the difficulty that "ELI5" addresses. By asking people to dramatically underestimate understanding, they are comfortable undershooting without implying disrespect.

Re: How to communicate effectively as a developer

#95

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

I agree to an extent, I think it just has a lot to do with knowing your audience and meeting them where they are. Frankly nobody wants to read a book of a comment and don't always have the time anyway (so they just won't read it all), so while it's important to include relevant information and avoid ambiguous/unclear language, it's also important to keep it concise rather than just spitting out as much information as…

Yeah the REST example makes this painfully clear. Donwright assuming he doesn't know and writing an education explanation on REST to anybody except a junior developer can be downright offensive. And many times (especially when working remote!) you're interacting with devs you are not entirely sure who they are.

Re: How to communicate effectively as a developer

#96
post #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.

Yeah, that's a bonus level of complexity, especially when you're reporting directly to someone you know probably has way more important stuff to do but you need a decision from their level about how to approach a certain issue that is constrained mostly by business.

Re: How to communicate effectively as a developer

#97
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 writers among us are quite the minority. Tell me about it. I'm lucky enough to have a supportive manager when I try to define my teams fitness functions, but getting the rest of the team to engage is an exercise in patience testing on all sides. They don't see the value in writing useless essays, shouldn't self documenting code be enough? I don't see the value in skipping high resolution communication up front…

document decisions and move on, why are you asking your team to write essays?

Companies bitch about the performance of developers then ask them to do things like this.

What's worse is when companies give developers all the responsibility and none of the control.

Re: How to communicate effectively as a developer

#98

I tend to write diatribes that nobody will ever read, so I've switched to writing a quip first, with details below in inverted pyramid style so that the reader doesn't have to ask for more information. --- I usually start with a: # Solution: With links to any tickets/jobs/etc. For example, the inverted pyramid puts the most important info first: https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism) Then I'll pu…

This is how newspaper articles are written. Critical details up front followed by the extra info at the bottom.

Re: How to communicate effectively as a developer

#99
post #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.

The short preface is a good point. Maybe it could even get expanded in more dynamic elements. Basically a short recap with the ability to quickly dive in deeper if interested, so everyone can choose their level of detail, or glance over it, and only drill down if something stands out to them.

I'll need to see whether our systems supports it.

Re: How to communicate effectively as a developer

#100

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…

What makes you think you know anything about the food industry, or the context where people are coming from, in general?
Post reply on HN