DEV Community

Cover image for The Communication Shortcomings of Programmers
Adam Nathaniel Davis
Adam Nathaniel Davis

Posted on

The Communication Shortcomings of Programmers

In my previous article (https://dev.to/bytebodger/most-managers-have-no-clue-what-we-actually-do-k07) I railed about my assessment that most organizations have no real concept about what programmers actually do. In that article, I spelled out many depressing truths about the many ways in which devs' efforts are often discounted. So I'm following that article up with some advice.

As frustrating as it can be to deal with people who don't really grok the process of software development, I do honestly believe that we, as programmers, often bring this problem on ourselves. You see, the simple (and painful) truth is that most programmers are pretty piss-poor communicators. If we were great communicators, we wouldn't have chosen a career field where vast portions of our day are spent silently clacking away on a keyboard. And while we can't make everyone else "see the light" about software development, we could do much more to ensure that we're effectively communicating with everyone outside our dev team.


Image description

Mimicking Communication

The first thing I want to point out is something that any salesperson knows very well. One of the most effective ways to communicate with others is to mimic the style in which they already communicate.

No, I'm not talking about trying to copy someone's voice or mannerisms. I'm talking about carefully observing how others choose to communicate, and then, whenever possible, communicating with them in their chosen style.

Devs can be really crappy at this because they tend to have mastered a given communication channel - their preferred communication channel - and then they blow off anyone who doesn't prefer that particular channel.

For example, maybe you hate Slack. Maybe you constantly set yourself as "Away" - even when you're right there at your desk working on code. And to be clear, on occasion, this can make perfect sense. But sometimes there are those who simply refuse to communicate in any way other than Slack. If you know someone like this - especially if it's someone who has input on your work - then you may want to consider getting off your Slack high horse and swapping a few chat messages with them. You won't like it. It may not feel comfortable. But in the end, it will keep that person from seeing you as a non-communicative jerk.

In my last job I had a manager who wanted nearly everything to be written up in a Quip doc. It didn't matter if I'd put copious notes on all my commits and pull requests. It didn't matter if I wrote a tome of detail in the ticket. It didn't matter if I sent him 12 Slack messages and 39 emails. He wanted things written up in an endless stream of Quip docs.

I could spend 20 paragraphs griping about this guy. But the simple fact is that, if I really wanted to "get through" to him, it wasn't going to happen unless I started putting data in the tool of his choice. Most developers despise this. I despised this. But getting angry about it didn't do me a damn bit of good.


Image description

Avoiding Face-Time

When I've joined a new company and I find myself in a group video conference, I can usually identify the programmers in the meeting even before they've introduced themselves. They're the ones who stubbornly refuse to to turn on their cameras.

To be clear, I'm not claiming that you always need to have your camera on. But when you remove the video from video conferencing, you undercut a huge portion of its utility. There are soooo many visual cues that we're subconsciously trained to pick up that fly out the window when one of the key participants just can't be bothered to turn on his camera.

Because of this, the inability to match a face to a voice fosters the mental image that some have of programmers as antisocial urchins. If you think this has no impact on your social standing in the company, you're probably deluding yourself.


Image description

Technobabble

Programmers are notorious at failing to read a room. If you're sitting in a dev meeting - with nothing but other developers - it's fine to debate various approaches to dependency injection or to talk about the possibility that a given bug may be caused by a race condition. But if you're sitting in one of your "normal" business meetings and talking about these concepts, you're almost certainly losing your audience. You may even be guilty of being... a jerk.

One of the reasons why "the business" can be so clueless about what we actually do is because, when they ask us directly, we revel in drowning them in technobabble. When this happens, we often feel smug in believing that we've explained exactly what we're doing. But in reality, we've only made the situation worse.

Have you ever been frustrated when an inferior programmers gets promoted (or some other type of recognition) while your efforts go unnoticed? It's probably because that doofus can describe his work (even if his work is subpar) IN BUSINESS TERMS.


Image description

Voluntary Isolation

Lemme tell you something that some may see as "underhanded". I've known plenty of devs in my career who simply hated talking to some (or, nearly all) of the "business types". They didn't wanna be in meetings. They didn't wanna have to present (demo) any of their work. They didn't wanna participate in any broader company activities. In some of those cases, they would literally ask me to handle the communication overhead. And you know what? I did it.

Months later, they'd be looking for a new job. (Or even, rage-quitting.) Why were they so frustrated? Because I had received a ton of recognition while their efforts went unnoticed.

Now to be clear, I've never claimed anyone else's work as my own. And I've always gone out of my way to try to attribute credit wherever it's due. But when those "business types" come to see me as the "voice of dev", it's only inevitable that they eventually put great value in my position - and they see others as being "expendable".

It's fine to "hunker down" when you're up against a tight deadline. But if you're going out of your way to avoid any contact with anyone outside the dev team, don't go crying in your beer when those non-dev folks fail to understand your contributions.


Image description

Combativeness/Defensiveness

Show me a dev who doesn't enjoy a good fight and I'll show you a purple squirrel. And yes, I'll freely admit that I've too often been guilty of this myself.

I find that most devs have a decent "survival instinct" when it comes to avoiding fights outside the dev team. But when it comes to matters that are code-specific? Matters that are only debated and adjudicated between software engineers...? Well, let's just say that things can get messy.

It's easy to assume that the other devs are "on your side". It's even easy to assume that "normal" disagreements between devs are understood and tolerated as the typical process of building applications. But I've seen far too often that the guy burying his knife deeeeeeep into my back is the same guy who didn't appreciate my argument that we should be using Zustand instead of Redux. And when someone outside the dev team asked him to comment on me, he was all-too-quick to paint me as a malcontent.

Let's be honest here: You can't build a ton of software applications without, occasionally, having a debate with someone about the relative merits of one technical approach over another. But if you want the broader business to focus on your worth - and not on the putative headaches that you bring to the organization - then you need to be very careful about where-and-when to pick your battles. Because once the rest of the organization hears that you're a troublemaker, they'll turn a deaf ear to any other efforts to herald your work.

Top comments (7)

Collapse
 
evergrowingdev profile image
Cherlock Code πŸ”Ž

Very interesting observations. I've come across many developers in my career who struggle with communication especially with wider business members. We can't neglect our soft skills when it comes to working with others!

Collapse
 
jmfayard profile image
Jean-Michel (jmfayard.dev) • Edited

I would say directly that :

We can't neglect communication when it comes to working with others

... and now it's painfully obvious why.

The term "soft skills" is a dumb creation from well paid Human Resources Consultants that is supposed to elevate things but make them sound second class.

"Soft skills" are neither soft nor skills.

Rant: I agree that communication, empathy, writing are super important.

But the way we call things matter, and I find absolutely terrible that we choose the words soft skills as a super broad category opposed to the supposedly hard things.

There are three issues with the name soft skills

  1. communication, empathy, writing, ... are not soft at all. They are the reason why IT projects, most couple, most families fail. Because they are hard as hell. I think that we devalue them by calling them softer than C++. ChatGPT can do C++ but it cannot do empathy.
  2. communication, empathy, writing, ... often not skills either : they are often personality traits. Being kind will serve you in some situations, and you will be abused in others. Being an introvert is not better or worse than being an extravert, but many things presented as soft skills relates in fact to that personnality trait.
  3. there is a not very subtle background of sexism behind those terms. Things that were placed into "hard" box are "traditionnally men skills" while things that were placed in the "soft" box are "traditionnaly women skills".

TL:DR communication, empathy, writing,... are important but the broad category to describe them as "soft skills" is a bad invention from HR consultants.

Collapse
 
freddyhm profile image
Freddy Hidalgo-Monchez • Edited

It's funny because I feel the way this industry is marketed towards newcomers is still as if we were in the early 90s: hackers away in a corner creating genius work.

In reality, all of engineering (not just software) is essentially effective communication with machines and humans. Code is communication, so really it's foundational in my eyes.

Collapse
 
bwca profile image
Volodymyr Yepishev

I am a dev who don't like fights, produce the purple squirrel :)

Collapse
 
ingosteinke profile image
Ingo Steinke

When I read "mimicking communication" my first thought was "pretending to communicate" but that's rather a typical shortcoming of managers and sales people.
Thanks for another great article! I have put them on my reading list so that I can stop procrastinating for now and got back to work. Great series!

Collapse
 
talenttinaapi profile image
talent

Very insightful and I personally have been guilty of some of these things in the past but I am slowly getting better now

Collapse
 
codum_cc profile image
Codum

Super interesting to read your article as we love to hear from programmers experience in the field. One benefit of learning with an accountability partner at Codum definitely is enhancing your collaborative and communication skills since you'll be working and meeting with a random person from anywhere on this planet sharing the same learning goal. Would be interesting to hear your thoughts on it!
Codum