We’ve been documenting the effect of stereotypes and bias in relation to issues of race and gender for a long time. When students are primed to believe that boys are better than girls at math, for example, the boys will outperform the girls. But when they’re told boys and girls are equally capable at math, the scores even out.

As software engineers, we’re often faced with the stereotype that technology is the polar opposite of the communications world. Just look at how engineers are portrayed in the media - from HBO’s Silicon Valley to the Big Bang Theory, it’s almost like poor social skills are a prerequisite for doing our job.

silicon valley

At the same time, marketers and business people are told that technology is a “hard” skill while they are “soft” skill experts. This fosters an environment where business folks fail to develop basic technical knowledge that could greatly benefit their career.

The good news is: We can outsmart stereotypes. Let’s throw away the notion that communication skills and technical skills are incompatible. Instead, let’s accept that we live in a collaborative digital world in which both skill sets have an equal and important place.

But seriously, why should engineers care about “soft” skills?

Ok, we all know that coding is all about sitting alone in a dark room hacking at a mainframe, right?

hacking the mainframe

Of course not. These days, big projects are accomplished by teams of engineers, designers, business types, and financial stakeholders. We’re constantly communicating with members inside and outside our team to establish workflows, give feedback on code, create mockups, finalize requirements, establish timelines, and conceptualize codebase architecture.

Effective communication allows everyone to get their job done efficiently - with minimal missed connections and unnecessary back-and-forths. It means setting expectations for everyone around you, allowing business owners to allocate resources appropriately and plan their own projects around accurate development timelines.

Regardless, even if you DO want to hack the mainframe, there are countless awesome projects you can tackle as a technical person with superb communication skills. For example, when brainstorming a title for this post, I thought back to my enterprise security marketing days. Social Engineering is an attack vector that relies on human communication - tricking the doorman into letting you into someone’s server room, for example.

Clearly, when you’re a software engineer AND an expert communicator, world domination is right around the corner.

Your Communication Skill Set

A process by which information is exchanged through a common set of symbols, signs, or behavior. - Merriam-Webster.

If this definition sounds familiar, that’s because it is. The dictionary definition of communication is essentially a verbatim description of software development. In truth, we technical folks are already great communicators whether we think so or not. It’s just that our language of choice is Ruby, JavaScript, or C instead of English, Dutch, or Chinese.

Embracing this parallel allows us to apply the same concepts we use to get better at programming to build our skills as great communicators.

It also means that in the end, like programming, we can improve by following reusable, predictable patterns and guidelines. It just takes a bit of conscious time and effort, and the realization that “soft” skills are a key asset in our professional toolbox.

Here are 3 focus areas that can make a significant impact for software engineers:


Jargon just means language that is not well understood outside of a specific context. As software developers, we often forget how many of our words and phrases constitute technical jargon. We casually throw out words like database or the names of services like GitHub or AWS all the time. And in engineering circles, that’s fine!

But what happens when you’re trying to explain a project to one of your designers, a marketer, or your CEO? Jargon becomes a big issue.

  1. Be aware
    • It sounds cliche, but this is the best thing you can do to avoid overuse of jargon in non-technical contexts. Just watch yourself, be aware - if someone looks confused, ask them why, and see if technical jargon is the culprit.
  2. Translate
    • When you discover a piece of jargon and a nice non-technical translation, write it down! Maybe create a little command line program for yourself to save the translations and look them up later.
  3. Know your audience
    • Do you need to give a presentation to the marketing team? A designer? A venture capitalist? Your audience might use jargon of their own, and if you can learn it beforehand and use it correctly, you can boost the weight and clarity of your message accordingly. For example, maybe the business folks at your company speak in terms of ROI and KPIs - it’s up to you to find out.

Grammar & Syntax

How many of us have accidentally sent out a really important email to a really important person, only to realize one second later that it contained a super embarrassing grammatical mistake?

…and why was that experience horrifying?

Because it makes us look stupid!

Especially with our native language, grammar is the easiest and hardest thing to get better at all at once - mainly because we take it for granted. The truth is, most of us haven’t studied the language we speak and write in for many years, and there are words and rules we certainly knew back in grade school that we no longer remember today.

How to improve:

Sitting down with a book on grammar, a thesaurus, or an online writing tool is the equivalent of sitting down with the Ruby documentation or a book on programming style. Doing so will help you sound more intelligent by making your sentences clearer and your vocabulary more precise. (See, it’s that easy!)

No but seriously, the hardest part is just taking the time to do it.


The word tone literally pertains to the rising pitch of your voice. Tone has a significant impact on the quality of our communication, because the same words can be interpreted in very different ways depending on the pitch of your voice.

Was your comment offensive, friendly, angry, helpful, or sarcastic? Will this create more work for you later, because so-and-so needs to have a sit down talk about the tone of your latest email?

How to improve:

  1. Read Aloud
    • One of the best ways to improve tone is to read your thoughts aloud. Even better - read them to a friend, and see how they interpret your tone. This is especially important when working with a second language, as tone can be highly dependent on cultural norms that may not be familiar to you.
  2. Refactor
    • Style affects tone, and improving writing style follows similar rules to refactoring code. Keep sentences short (8-12 words), leave white space between paragraphs, use punctuation appropriately, and use special formatting sparingly.
  3. Reflect
    • Even when writing, your emotions will come out in the tone of the language you use. If you’re feeling emotional - overly excited, angry, or nervous - it’s ok to put off an in-person meeting or important message for a day. If you absolutely need to communicate immediately, write your thoughts down, read, and refactor, making a conscious effort to come across in a tone that works to your advantage.

Setting Expectations

Now we loop back to what all this work comes down to: setting expectations. When we communicate effectively, the people we work with know what to expect from us and our team. Projects move forward with the resources they need, and we can all get our jobs done efficiently.

This isn’t about how you say something, but WHAT you say.

How to improve:

  1. Clarify requirements
    • A lot of people really suck at communicating, and we can accept and work around that to our advantage. This is especially true when non-technical people give project requirements, and your biggest task in this scenario is to ask questions.
  2. Say “I’ll get back to you”
    • Figuring out how to estimate software projects takes time and mental effort. Give yourself time to think. If someone comes to you asking for an estimate or your thoughts on a new project, practice saying, “I need to look into X, Y, and Z - let me get back to you on that”. Research done upfront can help you avoid time-intensive backtracks down the road.
  3. Continue communicating
    • Especially with software projects, it’s not until we dive into the codebase that we figure out how long something will take, and that’s ok. Just remember that as software developers, we are often the ONLY members of our team with access to the codebase and the ONLY ones who understand this aspect of our job. It’s therefore our responsibility to communicate what’s going on, as soon as possible. Never feel guilty for bringing up that a project will take longer than you originally thought - so long as everyone knows what to expect, deadlines and resources can be moved around in time.

Can you update some website copy for me?

Sounds great. Where is that copy? Can you show me that page on the website? Do I need to write the copy? Does this need to be reviewed? Will this copy change again in the near future? Does it need to be up on the staging website first? Is this copy saved as text, or is it an overlay on an image somewhere…?

Tomorrow’s TODO List

Communication skills can be improved with just a small amount of effort on our part, and it’s something we can work on over time - just like learning a new programming language, or picking up Vim.

  1. Call the least tech-savvy person you know - Explain your latest project, then ask them to explain it back to you. Did they really “get” it? Did you find any words for your jargon translator?
  2. Read your docs - Skim a grammar guide for concepts you forgot you knew.
  3. Learn a new vocabulary word - Find a word that is a more precise version of a word you’re using now.
  4. Estimate coding time - Take a guess at how long one task will take you, start to finish. Compare after your production deployment, and see how well you did.

In the end, my hope is to break down the “soft skilled people” vs. “hard skilled people” stereotypes, and instead focus on how both sides can foster an environment where technically skilled, communicative developers can more efficiently build bigger, better collaborative projects.

This blog post was adapted from my talk at NLHTML5, and you can check out the slides here.

Don’t forget to also follow us on Twitter @SpringestOps, where we practice our communication skills on the regular.