Live data from Hacker News

How to communicate effectively as a developer

karlsutt.com

201–210 of 222 posts

Re: How to communicate effectively as a developer

#201
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:…

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

On the contrary I rarely meet engineers that want to collaborate all the time unless they don't fit the typical profile of an engineer (usually a transfer from another industry). Engineers, much like myself, like to work alone not because we are loners but because often times so-called "deep work" requires actual quiet time. I don't like meetings, I don't like to pair unless there is some mutual misunderstanding that needs to be resolved, and I like to control my small talk (because I have a tendency to talk a lot about CS). I'm not a shut in, I just have work to do. Pairing excessively, for example, is an antipattern. When I worked in an office I would regularly leave my headphones on even when I got coffee because if I didn't someone would inevitably find a way to pull me away when I needed to be doing thinking.

There is time and place for scuttlebutt and honestly the amount of work I have to do every day leaves very little time for it. I could also be an extreme case because being introverted generally, a large number of meetings physically exhausts me. I've estimated I can make it ~30 minutes in a meeting before I am checked out.

The more rules, people, and processes that are put in my way just reduce my effectiveness. This leads to more frustration than it solves. For example, all these company parties and get togethers, "fun" meetings, etc are annoying to me because I legitimately stress out when I can't complete my work on my own (internal) timetable.

Re: How to communicate effectively as a developer

#202

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…

You can have both of best worlds using BLUF: bottom line up front. I didn't read the code because it's too early to debug someone else's code, but here's an example:

These endpoints break REST conventions and will be harder to understand and maintain.

The convention is that GET /resources will list them, and POST /resources will create anew one. You can also use a path parameter to identify a resource you want to find with GET /resources/ or delete with DELETE /resources/.

I find it useful for two reasons:

- maybe you parse the first paragraph and you have enough context to act, so you skip the second

- or you parse the first paragraph and form the big picture in your mind, and that will make it easier to dive into the details

Re: How to communicate effectively as a developer

#204

Earlier quoted context omitted.

The parent comment said that non-autistic people often assumed that people knew what they knew and failed to communicate.

I think maybe you misread "People without that will just assume people know what they know..." to mean "without autism" but it actually meant "without a good theory of mind [as is often the case for autistic people]"

[deleted]

Re: How to communicate effectively as a developer

#205
post #193

Earlier quoted context omitted.

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

GP is using “theory of mind” as a technical term with a specific meaning: https://en.m.wikipedia.org/wiki/Theory_of_mind

Re: How to communicate effectively as a developer

#207

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.

> I'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities. People without that will just assume people know what they know, and proceed to fail at communicating with those who don't.

The OP overstated things, but it isn't completely wrong to conclude the basic idea from your above statement.

Also, the OP did not say you wrote it, so maybe being less pedantic would help the situation.

Re: How to communicate effectively as a developer

#208

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.

To create good code, developpers must have good "theory of mind" capabilities, because they must systematically consider what could go wrong, not only when the computer will execute their code, but also when other developpers will try to understand it. It helps them design more intuitive and safer APIs, choose better methods and variables names, etc.

Re: How to communicate effectively as a developer

#209

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…

Rather than poor theory of mind what about good understanding of economics. The cost of absolutely clear context is too high to bear in many situation, it is often better to get the message across in whatever way works for those who are also in the know.. that way collaboration can cheapen the cost of constructing context. Of course if there is an off-the-shelf context available that you can refer to then there is no communication problem in the first place.

Re: How to communicate effectively as a developer

#210

Earlier quoted context omitted.

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

If his goal was to be left alone entirely and never help anyone then it was certainly effective. I never went to him with problems that required deep expertise because they involved a recitation of how memory was allocated, or how linking works, or what an HTTP request is.. etc
Post reply on HN