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.

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.

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.

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.

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.

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.