Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

191–200 of 222 posts

Re: How to communicate effectively as a developer

#191
post #148

Earlier quoted context omitted.

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

> there is nothing more annoying than someone assuming context I don't have I worked with a senior developer when I was a junior who would answer any question by starting from first principles. I understand sometimes a question can betray a misunderstanding of foundational principles but this was decidedly not the case, at least in most of the incidents. I eventually learned to just not ask him questions unless I was…

> I think he just liked to hear himself orate.

I think his strategy had exactly the intended effect. If you had a real problem that required deep expertise, you knew to come to him.

If you didn't, you figured it out yourself, and thus grew your skills rather than having him feed you the answer.

Re: How to communicate effectively as a developer

#192

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?

In general I don't, but usually when meeting someone new we introduce each other right? Otherwise if the person is someone you know already there's a better chance that you know what is their line of work.

Also It's more of a analogy thing Explain stuff to them in their language.

But while writing stuff we don't know who's going to read it, so a general analogy, a bit tech stuff and few visual stuff all of these can be used.

Re: How to communicate effectively as a developer

#193

Earlier quoted context omitted.

I am a Staff Engineer leading a large engineering organization. I am also “on the spectrum” and openly autistic. My co-workers know that I am autistic. I have found that communicating to business folks and leaders is a skill like anything else and can be taught. Your assumption that being autistic somehow completely disqualifies one to speak competently to others is ableist and harmful. While it is true that people w…

> Your assumption that being autistic somehow completely disqualifies one to speak competently to others... As anyone can see, I did not write that.

The word completely does over-assert that quote, but it's disingenuous to pretend that the quote does not follow from your overall point. People with good "theory of mind" would supposedly read between the lines, but I guess it was never that simple. Spoiler alert: there's no such thing as one true generalized theory of mind.

Re: How to communicate effectively as a developer

#194

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'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities.

FWIW this idea has been losing some ground to the double empathy problem. People who aren't on the spectrum have corresponding poor theory of mind and empathy towards those who are. The problem is at least partially symmetric.

I've noticed a form of cultural cringe in developer communities where we assume that developers tend to be on the spectrum, have uniquely poor communication and social skills and cause social problems more than other working professionals. It's contrary to what I have seen in real life which is that dev teams socialize effectively and form cohesive and healthy cultures as much as any other field. That developers are usually the ones promoting better written norms and more thoughtful and thorough written communication.

The "assumed context" problem is common everywhere. Poor communication, anti-social and toxic behavior are common everywhere in most organizations. Developers are self-conscious of our poor social skills to an extent that is not matched elsewhere.

Re: How to communicate effectively as a developer

#195
post #109

Earlier quoted context omitted.

I think there are ways to learn how much context the other party needs - like asking them in the beginning of the conversation.

If you ask people if they know something and they already do, they can sometimes be insulted. I'm never insulted when people do that, I think it's considerate, but I have seen people get all "of course I know that, what do you think I am, an idiot" on me. I still ask if I'm not sure of someone's level of expertise - I think any reasonable person would react positively.

I've found it super helpful to frame conversations establishing shared context with "I have no idea what you do or don't know about X" It helps re-center the conversation so that I'm the one who's ignorant, and the other person potentially has an opportunity to show off.

Re: How to communicate effectively as a developer

#196

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

[deleted]

Re: How to communicate effectively as a developer

#197

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

[deleted]

Re: How to communicate effectively as a developer

#198

Earlier quoted context omitted.

It's a black box but the CEO has communicated dev performance is dependent on amount of code shipped. I suspect they're using sloc or pr counts behind the scenes. I've done everything you're recommending. CEO doesn't care about any of that. Only metric they care about is money made and code shipped. They do say they care about communication and apparently track it but I havnt seen it reflected in comp reviews so my c…

Yowza. In that case… time to look elsewhere. I can tell you many companies do not do this sort of thing.

I am. Only issue is that it isn't the worst place I've worked and it's hard to find better than what I have where I'm at.

Re: How to communicate effectively as a developer

#199
I think we overlook wordiness too often! In fact, each "good" example in TFA can be shortened without losing context:

Good:

"I checked the foobar.py script and told Sarah that there was a bug related to updating the users table in SQL — the script does not seem to update the last name column."

Better:

"I found a bug in foobar.py and told Sarah it's not updating the last name column in the users table."

Good:

"Hi team, the email sending worker keeps crashing with the following exception. I've tried re-running, clearing the cache, re-installing dependencies. Can I get a hand?"

Better:

"The email sending worker keeps crashing with the exception below. I reran it, cleared the cache, and reinstalled dependencies. Can I get a hand?"

Good:

"The resource defines two routes, but the GET handler can only handle one of those — the one without any path params. I can technically make a request GET /api/foobar/123/456 and have the app crash with a 500 because there is a route but the handler doesn't take any params.

Roughly speaking, there are two "types" of resource endpoints — list and singular.

List type resource endpoints handle - getting a list of resources: GET /things - creating a new resource: POST /things

Singular type resource endpoints handle - getting a single resource: GET /things/123 - updating a single resource: PATCH /things/123 - deleting a single resource: DELETE /things/123

To handle all cases properly, you need two resources:

... "

Better:

"The resource defines two routes but the GET handler can't take path params, so a request to GET /api/foobar/123/456 crashes the app with a 500.

There are two "types" of resource endpoints:

List: - get a list of resources: GET /things - create a resource: POST /things

Singular: - get one resource: GET /things/123 - update one resource: PATCH /things/123 - delete one resource: DELETE /things/123

So you need two resources:

... "

Re: How to communicate effectively as a developer

#200

Earlier quoted context omitted.

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.

Maybe so. Maybe it's also being led aware of/naive about how much one knows? I would guess there's less trust/faith in authorities than before?

(but I lack facts, so maybe I'm equally wrong)

Post reply on HN