Developers Don’t Understand Communication

Programming languages, APIs and protocols. Understanding how one system communicates with another is interesting for each and every person.

As software developers we learn how one system tells another system precisely what it wants and precisely what it expects back in return.

So why when we add a human being into the mix, does everything fall apart?

Talking Isn’t the Same as Communicating

I’ve worked in development teams where we’ve had stand-ups, refinement meetings, planning meetings, retrospectives, Slack channels, pull requests, documentation and enough Jira tickets to reconstruct human civilization after a nuclear war.

Yet somehow nobody knows what anybody else is doing.

Perhaps developers don’t understand communication, and it is a problem which goes to the heart of what it means to be a developer and what work means.

I’m on holiday right now. I didn’t even have a Slack group to say I’m off for a few days. Nobody cares, and I’m here to say that might just be a systemic problem and not just a The Secret Developer problem.

Stand-Up Theater

We never seem to share what actually matters in any particular stand-up.

Yesterday I worked on ticket 1234. Today I’m continuing with 1234. I’m waiting for 1235 to be finished.

Excellent. You managed to avoid telling anyone anything of value. You managed to avoid making anyone else’s life easier.

On the other hand, I’ve also been in meetings where someone has come off mute halfway through and asked what the question was.

The problem is that the software industry seems to have confused speaking with communication, which are not the same thing. 

In most stand-up meetings and actually most company businesses you’re essentially generating human-readable log output.

A reasonably substantial body of software-engineering research suggests communication isn’t some fluffy bonus skill either. A review of the soft skills demanded by the software industry found communication and teamwork among the skills most consistently identified across previous research.

We apparently know communication is important on some level. We just aren’t necessarily very good at doing it.

It’s such a shame that we learnt nothing from COVID, and failed to take the learnings forward from working from home. We simply added more meetings and forced developers to come back to the office. We still struggle to communicate.

Who could possibly have predicted this?

Read the Pull Request

Another surprisingly difficult form of communication is writing something down and having somebody read it.

This is just like the behavior I’ve experienced this in code review.

I’ve experienced so many times the folly of having a pull request sit around for most of a working week before somebody finally reviewed it. Fair enough. People are busy. You have to contact them directly to get something reviewed.

This is made worse by our code owners where a team of maybe 5 people are required to approve your work. They’re all offline, whatcha gonna do? Days go by, nothing changes. ⁠You Want to Be Liked? Review Your Colleagues’ Code, but nobody takes this seriously.

Documentation is written, has no value, is not updated. We all simultaneously complain constantly about missing documentation.

It all comes to the same thing. We aren’t listening to each other, and by definition we are not listening to each other. It all doesn’t really matter because we are becoming meat bags who sit behind AI systems anyway.

More Communication Can Make Things Worse

There’s another uncomfortable idea here.

Not every communication event is useful.

Developers need concentration.

A study of software developers examining task switching found that developers perceived significant cognitive costs associated with switching tasks and interruptions, including those related to daily stand-ups.

Another study using thousands of recorded developer tasks found that task switching disrupts concentration and that the context surrounding an interruption substantially affects how disruptive it becomes.

The answer to bad communication isn’t necessarily another meeting. The communication is the problem and the solution sometimes.

Nobody wants to be in another boring meeting to discuss your silly issues. 

All communication goals should be to transfer enough useful information to the right people at the right time, not just blasting the information to anyone who might listen.

It’s this piece which is missing. As software developers we simply don’t know how to optimize our communication at all.

Communication Is the Next Crucial Engineering Skill

Perhaps we should stop describing communication as a “soft skill”. By making it a soft skill we give developers a way out, a way to make something else their priority.

Yet there’s nothing soft about losing days of development because two teams understood a requirement differently. There’s nothing soft about a code review deteriorating into twenty comments because neither person explained what they actually meant.

Since communication affects delivery we should put our focus on it. The best minds should be thinking about how we work together, and what we need to do to fix this.

Protip: The best communication is not to eliminate communication, if that is what you are thinking.

The software industry spends enormous amounts of money teaching developers frameworks, languages, cloud platforms and methodologies but lets software developers figure out communication on their own.

It keeps going wrong in the same predictable way.

As Software engineers we wouldn’t design a protocol where one system sends data and then simply assumes the recipient understood it.

Yet humans do exactly that.

A requirement is written. A Slack message is sent. Somebody says something in stand-up. Communication declared successful.

This would bring the opening system-to-system analogy back near the ending and give the whole piece a satisfying circular structure. Which would actually work.

The Secret Developer’s Take

Developers need to communicate better, more thoughtfully.

This means that before scheduling a meeting, ask whether the information could be written down (if that would help the attendees).

Before writing documentation, ask who needs it and whether they’ll actually find it. Who will maintain this.

Before giving a stand-up update, ask whether anything you’re saying changes what somebody else needs to know or do. How are you helping the team

Before answering someone’s technical problem, make sure they’ve finished explaining it.

And before leaving a pull request comment asking a question, perhaps read the pull-request description.

What I’m saying is the quality of communication is told by the person you are communicating with. As the one broadcasting? You can’t even tell if you are communicating well.

About The Author

Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.

The Secret Developer thinks communication breakdown it’s always the same.