Hacker News new | ask | show | jobs
by BurningFrog 1337 days ago
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 mind" capabilities. People without that will just assume people know what they know, and proceed to fail at communicating with those who don't.

It also makes it easy to think of those who don't know what is obvious to you as idiots.

The workaround, if you want to communicate with the idiots surrounding you, is to start conversations by fact finding. The question "so how much do you know about the flurbigator system?" can help.

22 comments

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 "next Wednesday", it isn't when I'm talking to programmers that I feel the need to follow up with "Is that when you want me to give them to you, or when you're going to be making the presentation that includes them?".

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.
I suppose, but as someone in infrastructure I have had developers ask very, very specific questions without ever actually providing the context or what they were actually trying to solve. Seems to me to be a variation on the same problem. Just because a question is specific doesn't mean it's the right question.
My view is that, whatever is causing developers to often be bad at filling in context, it isn't a deficiency in their theory of mind.

(Similarly, someone elsethread is talking about how their non-developer colleagues neglected to tell them about an upcoming release. One possible explanation is that their colleagues were bad at "theory of mind", and believed that as they knew about the release, so did everybody else. But I think it's more likely that they were too disorganised to make sure that it was somebody's job to tell everyone who needed to know.)

> My view is that, whatever is causing developers to often be bad at filling in context, it isn't a deficiency in their theory of mind.

The "theory of mind" explanation is that those developers don't understand what context other people are probably missing.

I agree that there are of course other possible reasons.

I've had the same experience. It was kinda jarring as I expected devs to not fall into the same trap they complain about with questions/requests from their users.
> The ones with subjects like "query for account ACME-37" were from technical staff.

if you get an email from me, and when you want to follow up you're thinking "what was that phone number I should call?", don't worry, I have already put it in the subject line along with the person's name and the deadline

It's above-and-beyond of you to follow up at all in that situation, IMHO.

Taking "I need X next Wednesday" at face value to mean "as long as I have X by 5pm Wednesday I'm happy" is completely reasonable.

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 who are autistic struggle to communicate with non-autistic people I would argue it is also difficult for non-autistic people to communicate with autistic people.

It is also ableist to assume that just because someone lacks communication skills that they are “on the spectrum”.

What is true is that communication as a skill is not often taught to developers.

> Your assumption that being autistic somehow completely disqualifies one to speak competently to others...

As anyone can see, I did not write that.

It was such a perfect illustrative response because your post said nothing of the sort and in fact explained how anyone can pick up the skill
I'm not sure about that. Communication is hard when words associated with specific emotional valence get involved. For the responder, I'd suspect that on the spectrum is one of those phrases.

I think what makes this stuff difficult is that the same word can trigger wildly different responses.

As an example, I've been working from Ireland for US multinationals for a while now. In Ireland, the word stupid means bad or crap but doesn't have a massive emotional valence.

In the US based tech side however, it was literally the worst thing one could say, I suspect because people were identifying with their ideas.

Same word, multiple different meanings lead to communication problems.

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
Reading between the lines is a whole different thing.

"Theory of mind" means, among other things, having a good mental model of what other people know and don't know.

Obviously, without understanding what piece of information the other person is missing, it's very hard to explain it to them.

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

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]"
> 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. Draw a 2x2 grid. On the top axis is the correctness versus incorrectness of your assumption. On the side axis is whether you assume ignorance or knowledge. The social calculus always favors assuming a prior understanding:

                       correct      incorrect
                  +--------------+--------------+
                  |              |              |
                  |              |     lose     |
        ignorance |   neutral    |    status    |
                  |              |    points    |
                  |              |              |
                  +--------------+--------------+
                  |              |              |
                  |              |              |
    understanding |    points    |    points    |
                  |    gained    |    gained    |
                  |              |              |
                  |              |              |
                  +--------------+--------------+
IME, this is exactly the difficulty that "ELI5" addresses. By asking people to dramatically underestimate understanding, they are comfortable undershooting without implying disrespect.
<<I somewhat take issue with this, as people on the spectrum are more likely to over-communicate, all other things being equal.

I don't think I am on the spectrum ( I mean, I guess technically everyone is, which is why its a spectrum ), but I do know that I was ..what is a good word.. chastised.. no.. maybe gently admonished for putting up very long detailed summaries with some discussion of potential risks involved in an assumed approach, potential tradeoffs and pitfalls.

It really depends on your boss, but I come from compliance world, where you do want to CYA pretty extensively.

Anyway, back to the story. I was effectively asked to keep writing executive summaries. I hate to say it, but things seldom are that simple. I can simplify it for you, but you will lose a lot of context with that. And this how we get to the situation, where only one guy in the entire company knows how X actually works with all the constraints that it brings.

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 you learn Newton. Then you eventually realize Einstein adds nuance to the formula. Start with Einstein and it becomes much more complex, hard to grasp and less likely you'll understand anything. And, equally important. If the receiver doesn't want to know Einstein, then no point in talking about him.

One big problem I see nowadays is that more people do not care about the details, meaning it's less useful as a communicator to communicate then - but also that people do not fully grasp as much the nuances and believe (and search for) simple answers - and come to dangerous conclusions about them. From my POV this is the danger with the attention economy, leading to Trumpism and similar phenomena.

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

CYA?
Cover your ass.
Right it's as if the low-information people are saying (and believing) "I have just as much the right to be correct as anybody else. It's my right. Don't tell me I'm wrong because it is my right to be the one who tells what is the truth".
> > 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,

Low theory of mind is definitely not incompatible with over-communication.

If anything over-communication sounds like a coping mechanism!
It's definitely a coping mechanism. When you've been burned repeatedly by people nodding vigorously in understanding, then turning around and revealing a complete lack of comprehension, forcing you to either intervene or allow the error to propagate, it's tempting to fall into a habit of pre-emptively explaining everything.
> revealing a complete lack of comprehension, forcing you to either intervene or allow the error to propagate, it's tempting to fall into a habit of pre-emptively explaining everything.

Or maybe the explanation was bad to begin with. Over communicating won't turn a bad explanation into a good one. Understanding something doesn't mean you know how to explain it to someone else.

> Understanding something doesn't mean you know how to explain it to someone else.

Too true. Explaining things is hard. My gripe is mainly people's tendency to pretend they understand in perpetuity, instead of expressing a modicum of curiosity about it. "What does 'TPS' stand for actually?" As mentioned, explaining things is hard, and I think I'm not alone in needing help identifying gaps in my explanations.

That said, I also understand that there are huge social barriers to admitting a lack of understanding in the tech industry, especially for juniors.

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 right)

While both of those are real phenomena, they are pretty dysfunctional. Many people (most people?) enjoy genuine cooperation within a context of mutual trust, learning things from others, and teaching others who want to learn. In that context, checking for knowledge is not a slight, and assuming things "are obvious" and failing to explain them is not a flex.

> 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 absolutely desperate, because it would take him 5-10 minutes to work up to the critical piece of information I was actually missing. I think he just liked to hear himself orate.

> 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
It’s hard to solve. I’ve read blogs where people find it condescending but the opposite can be harrowing, especially if it is clear the other party is annoyed.

Empathy tends to drive my own novelistic explanations, not conceit. It might help to mention something if you haven’t yet. Everyone is different though.

Yes, I'm for sure describing a perverse incentive structure, but one that's easy to fall into, almost a default state. If you get enough well-intentioned people together they can break the cycle, and then you have a healthy team.

> Bottom right should be "points lost" imo.

There's a certain breed of hot-shot dev who truly believes they're gaining status by making cryptic, in-the-know references, and there's another breed who falls for it. When it comes to social status games, if enough people believe it, it becomes true.

> There's a certain breed of hot-shot dev who truly believes they're gaining status by making cryptic, in-the-know references, and there's another breed who falls for it. When it comes to social status games, if enough people believe it, it becomes true.

Yes, this is what I described in point 2. Again, I'm not saying it isn't a real thing. At the same time, I wouldn't call it the norm either.

I think your chart is incomplete, because in the bottom-right quadrant, there’s the caveat that they never ask for clarification and blindly do the wrong thing.

Then when you have to go back and tell them the basic assumptions that they are wrong about, and that they have to redo tons of work, you lose a giant sum of hypothetical points

My theory is that devs often trade pretense-now for research-later. This habit allows them to gain ~0.002 status points here and there. But now combine that with unknown-unknowns. The thing they're hearing—if they actually understood it—ought to cause them to abandon or completely rethink a change they're currently working on. But because their takeaway isn't new knowledge, but a placeholder for potential new knowledge, they end up losing 15 status points when it blows up, in a way that was utterly unforeseeable.
I agree, it's really not worth exposing yourself to the risk. Ignorance-Correct can even be interpreted as a micro aggression.
I think this is a big one as well, and would go one step further and say that anyone no matter their place on the spectrum may fail at communication in this way. I bet most junior developers know what I mean, if they've sat in meetings with senior guys talking about something esoteric.

One simple trick, I think, is to avoid extensive use of pronouns. A sentence like "Because of that, it doesn't find it there" might be clear enough when you know the context, but is meaningless if you don't. Filling in "that", "it", "it", and "there" would help tremendously. It will make sentences awkward if you avoid them completely, of course, but I think sentences that contain nothing but pronouns are a red flag.

As a math teacher, I try to instill a similar idea in my students, and am glad to hear that the idea is useful in a broader range of situations!

In overstated form, my version of the idea is: “never use ‘it’”—because a student just learning mathematical language will have many different ‘it’s in mind, or, even worse, no clear idea of what ‘it’ is. (For example, I'll often see an application of the derivative summarized as “since it is negative, it is decreasing”, which is correct only if you change ‘it’s midstream—but students often don’t realize that they are, or should be, doing so.)

> One simple trick, I think, is to avoid extensive use of pronouns.

I was taught this is a project management for engineers course I took when I was younger: never use language that is open to interpretation. In addition to your examples, I also see this happening in meetings when engineers say a non-sprint task will be "quick." How quick? A few minutes? A few weeks? A few quarters? As soon as we started clarifying these ambiguities we eliminated a lot of misunderstandings.

I have a tendency to info-dump to establish shared context, and people find that insulting as well. So it can turn into a dilemma of:

Info-dump: "I know that already! What do you think I am, an idiot?"

Assume context: "In English, please! I didn't get my MBA to be made to look like an idiot."

Excuse me for failing to read your mind and know exactly what you know and what you don't before I begin.

Those of us on the spectrum are set up to fail by NT-centric culture. You think we're mind-blind? It goes both ways, look up "double empathy problem". It's just that most people are NT, so by default we have to accommodate your neural quirks but the vice is not versa.

When you say “NT-centric culture” I think you’re talking about this, right?

https://www.myersbriggs.org/my-mbti-personality-type/underst...

I assume it means "neurotypical" here.
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.

Yup, absolutely; this is yet another angle on empathetic communication. When in the listener's seat, it's important to be mindful of the fact that the presenter is trying their best at the difficult task of conveying this information to you.
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.
Yea, that’s simple in a one on one. But how do you simultaneously provide the right level of jargon and context in a standup with a mixed crowd of MBAs and developers? Either the PM is frustrated that they have to listen to you go in the weeds, or they don’t understand why is this is important, or the fellow dev isn’t getting enough technical detail to understand precisely the crux if you’ve oversimplified.
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

I can speak to what it's like with autism brain.

In conversations people often say things that I have unusual associations about. My mind will start spiraling about the unusual association and I will begin an internal narrative about the new, unrelated topic without verbalizing any of it. I will continue with the original conversation with the convo partner. Then, out of the blue, I will verbalize something about the second topic and the convo partner has no idea what I'm talking about. The topics can be as unrelated as databases and the mating habits of penguins. I have forgotten that the convo partner did not take the journey into the second narrative with me.

Countdown to database of mating habits of penguins comment.

> Countdown to database of mating habits of penguins comment.

19 minutes.

That's very clearly stated - I recognize it so much from my son (who has autism)! Thanks for putting it out there!
Is this specifically an autistic trait and not something allistic minds do? Asking, uh, for a friend.
FWIW I think everyone does this on occasion.
Dang, this describes many interactions I've had over my life.
This sounds eerily familiar. Thank you for posting, I have some reading to do.
Curse of knowledge is a different thing. The "assumed context" problem isn't a teacher-pupil or expert-novice dynamic. It's just someone not providing enough context to an audience that would otherwise be able to understand and help them.
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.
I just got out of a conversation where surprise was expressed that I didn't know, and prepare, for an upcoming release that was obviously coming.

Well the answer is that no one told me that they were even thinking about releasing. The last I heard we were waiting on the vendor.

Apparently I should have known it was coming and had prepared production servers for it so the roughly week and a half given magically became enough.

What's worse is that technically speaking it can be easily done in that time, it's a people problem. They could technically put pressure where it needs to be, but will they? All signs point to no.

---

So while I understand putting responsibility for communication onto the developer, there's a responsibility for the others as well and at some point it's just flat not the developers problem.

> I'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities.

As an alternate theory, maybe they've spent a lot of time staring at the code in question and internalised the context to a point where they no longer think about it. Happens to everyone.

> 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?"

I generally agree with this - the first part of any effective communication is to see where you and the other person/people are starting from.

Only then can you decide how to try to communicate the rest.

> It also makes it easy to think of those who don't know what is obvious to you as idiots.

Honestly, if someone does this to me, I often think they are the incompetent one/idiot. Teaching and ensuring understandability is a core skill (which can absolutely be learned) necessary for a functioning team.

At least the two folks I know with autism on my team have worked incredibly hard at ensuring they practice this skill, and they are some of the best developers I know, partially for that.

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

Alternatively, people who have to explain everything problem from the creation of the universe are even worse. They waste everyone's time and come across like they think you're an idiot. There is a middle ground, but I much prefer if you are direct and get to the point and allow me to ask questions over the alternative where you spend a lifetime bc you're not sure what I know already.
How is that a competing take?

From the article:

> In both cases, the example on the left is what I call “low-resolution writing”. There is very little context, too much reliance on pronouns and unclear references. The writing is not emphatic —the reader has to spend extra energy to work out what is being said

Your comment here is the main point of the article, which is a point made multiple times within it.

I work with a developer* who draws labelled boxes and arrows for diagrams and posts screenshots of code in response to questions I put to him. I can't say I've been able to find more than a handful of places where he's put words together into sentences and paragraphs. Getting useful information out of him is like pulling teeth. Even when he could link to code on the git server, e.g., he doesn't.

His screenshots are the worst-case scenario of lack of context – just a couple of dozen lines of code, no information about where, in what file, in which repo, he's given.

* We both work remotely and live in different states, nowhere near each other.

Ivwould feel a bit offended if somebody would send me screenshots withoutva word of context. Often times the explanation of the context is a big part of a solution to a problem, or even shows the problem to be non existing.
I've only been working with the person about 6 weeks. I didn't think too much about it at first, though it did seem odd and unhelpful. It's only in the past couple of weeks that I've started to find it irritating, and yes, offensive. I will probably bring it up to the lead at some point.

By the way, I double-checked my assertion that he doesn't use words, in case there were some documents I forgot or had missed. Nope. At best, his diagrams or screenshots will have captions. Those captions remind me of the sort of useless comments we've all become conditioned to ignore.

    x = y + z; // set x to the sum of y and z
>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.

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.
I generally agree with your post, but that question is really bad, as it can be seen as mansplaining. The fact finding is fine, but requires a gentler approach.
I don't assume that someone knows the context, I assume that they could understand the context if they looked at it - that it can be explained to them to a useful extent.

Because if you don't understand that, then your understanding of the problem space is not going to be sufficient for any useful purpose.

And if you're a manager, then the company fucked up by putting something technically complex within your purview.

I like your opening question. A casual way to establish some context and rapport.

I’m not sure this is a competing take vs the article. More like complementary.

The article mainly says “add more details.” Eg. Don’t write “the system is broken” be specific about what’s broken, what you did, and if you need help.

Basically, don’t assume context.

The author takes himself to be some kind of writer, so he said it in too many words.

All good, but what makes you call this a competing take? What view of the article does this compete with? It seems to agree with it, more or less.
Alternatively, why is someone who doesn't know the product directing its design without asking appropriate questions on their end?