Software Engineers are hot shit right now. Recruiters pander to us by calling us rockstars, ninjas, and gurus. We are revered for our intellect, our problem solving skills, our powerful working memory, our familiarity with mysterious tech –but not for our communication skills. Why is this ok? If we’re expected to be smart, shouldn’t we be expected to grasp effective information exchange with fellow humans? Why is modern society still excusing coding “rockstars” from having to come equipped with high quality communication skills?

Photo by Gratisography

How do I know that software engineers aren’t expected to have stellar communication abilities? While I don’t have hard data, I have met, worked with, or listened to a lot of engineers who have sub-par comm skills. And no one makes a big fuss of it, which makes me think no one has high standards for the skills I’m talking about.

On top of that, job interviews target coding skills, web tech trivia, and algorithms with minimal examination of proficiency in structuring arguments, explaining complex concepts, and intelligent discussion. There’s a pretty great article by the CTO of npm that drills into this topic.

Maybe it’s all rooted by the tendency for engineering schools to suck at emphasizing communication in their curricula. My time in college certainly didn’t include any lessons on effective speaking. You often hear schools talk about the importance of group projects and working together, but they never explain what good teamwork looks like, what common pitfalls plague discussions/meeting, etc. Instead, they focus on teaching the hard sciences and math. Then class after class of students walk away with little or no appreciation for the subtleties and subjective nuances of conveying ideas to one another.

I find it so funny that programmers laugh at all these subjective fields of endeavor when that is what they do.

The ability to “work well with others” is often mentioned as a requirement in job descriptions for programming positions, but how many interviewers and interviewees really know wtf that means? Does it mean employees are expected to avoid conflict like their lives depend on it? Is it benchmarked by low quantum of drama? Should it be deeply linked to “likeability”?

No. It’s about empathy, open-mindedness with regards to homo sapiens, and communication skills (among other things).

Who died and made you king of communication skills?

My point is that it’s time to stop letting engineers off the hook for lacking skills in listening, speaking, presenting, asking, writing, and critiquing. I’m no master in these subjects. My own skills are far from honed, but you don’t need to be a master to have some ideas on how to improve. Also, it can be fun to explore communication issues just like how it can be fun to solve mysteries in web app development. Besides, as engineers, we pride ourselves in being good at what we do, so shouldn’t we put some effort into gaining communication skills that make us even better at what we do?

If you’re pondering my motivation for making such a big deal out of all this, then let me just say that impatience is a potent impetus. I started analyzing communication when I started noticing miscommunication and the toll it took on my patience. I’m not just talking about miscommunication during meetings at work. I’m also referring to poor presentations at meetups, chatting at networking events, conversing during job interviews, writing open-source documentation, writing test descriptions, etc.

When I don’t understand someone, I tend to wonder, “Wtf is this person even saying?” Then that little voice in my head chimes in, “Don’t be so harsh, Jeff. Maybe you’re just too dumb to understand.” After that, another inner commentator adds, “Fellas. Shut up. Let’s use our detail-oriented brain to brainstorm reasons why communication has fallen apart here.”

Let’s Do This

We engineers are problem-solvers, right? Well here’s a problem: miscommunication. So let’s solve it. What’s the first step for solving stuff? Comprehend the problem space. Break it down. Then divide and conquer.

Breaking it Down

We’ve confirmed miscommunication. Now what are the root causes? There are too many possibilities to cover now, but here are a few:

• Knowledge Imbalance: Person A knows something person B doesn’t know. The imbalance results in lack of context or incorrect assumptions.
• Ambiguity: Is the person talking about this? Or is the speaker talking about that? What is this? What is that? Maybe we’re referring to different things. Perhaps less ambiguous nouns are needed.
• Suboptimal Terminology: Lack of or misuse of terminology and jargon is pretty common in programming. For example, does everyone know what you mean when you say “collection”? Are you referring to an object literal that has a bunch of properties, an array with a bunch of elements, a MongoDB collection, or a more abstract thingamabob that “collects” stuff?

Divide and Conquer

If X, then Y.

• If there is a knowledge imbalance, then identify who needs what info and let the glorious sharing of knowledge begin.
• If something is ambiguous, then ask clarifying questions.

Et cetera. One at a time. We can get through this together! Let’s hold hands! –or not. Because even the nicest people fail to wash their hands frequently enough to earn hand-holding privileges. Don’t let your guard down.

What’s Next?

The next blog post in my Communication for Engineers series will focus on tips for presenting a tech talk. I’m oddly excited about it. I haven’t done any big tech talks, but I’ve attended plenty. There are some easy ways they could be better. There are common issues that are easy to solve. That said, I’m also working on a blog post covering web security fundamentals. In due time, I will write tips for:

• Presenting a tech talk
• Conversation (with emphasis on listening)
• Asking Questions

If I’m not burnt out from writing about communication skills, I will also blog about:

• Giving & Getting Feedback
• Writing (with emphasis on concision)