In my career to date I've worked with a ton of very bright, very talented individuals. Unfortunately, software engineers don't always value social skills with the same importance as technical skills. To make the matter worse, it can be awkward for others to address some of the more subtle social pitfalls. Aside from the basics of communication, here are some of the bad habits I've noticed my coworkers (and myself) exhibiting.

Excessive Verbosity

There might be a small nugget of wisdom to be found in Kevin from The Office. Especially in written correspondence, I've found that less is usually more. A habit I've tried to develop for myself is formatting messages like so: issue/request, details, conclusion. People's time is valuable, and if you need something just say it. For example, which of these would you rather have show up in your inbox?

Hey Julie, I was talking to Jeff yesterday regarding the application and user performance report and he has a meeting with some clients on Friday. We'd like some time to review the report prior to the presentation so we can collect feedback and have some time to iterate on improvements. Would you mind sending that over by Wednesday?

Alternatively, you might send a message like this:

Hey Julie, can you have the application and user performance report to me by Wednesday? Jeff is presenting the same on Friday and we'd like some time to review before then.

Both communicate nearly the exact same message, but the former is overly verbose. The reader has to trudge through the what's and why's before finally understanding the purpose of your message. People are busy - you should value their time.

“The Incentive.” The Office, Season 8, Episode 2, NBC.

Needlessly Corrective

A lot of engineers, myself included, highly value facts and technical correctness. However, it isn't always an appropriate time or place to interject that knowledge. To give an example, let's take a look at this interaction:

Doug: "Me and Karlee were investigating the recent performance issues we've been having on production. For those not in the loop, recently we've seen some real slowdowns when uploading data via the POST backend serv - "

Jeremey: "I believe that's a PUT, not a POST."

"Right. Well when we do the PUT request, we've been seeing slowdowns. The data volume isn't any bigger than usual, which is what is really odd. So last Thursday, we decided to switch the app -"

"Last Thursday was a holiday, you mean Wednesday?"

"Oh, correct, yeah...last Wednesday we switched the app log level to debug."

In interactions like this, it's entirely possible (and probable) that Jeremey is completely correct in his knowledge. The issue is that these corrections are interruptive, and don't add much value to the discussion. The exact implementation details, or the exact date, are largely irrelevant. Along with slowing down progress, interactions like this make you less approachable. To be clear, I think most of the time this behavior isn't malicious. The offender is likely just trying to help, or is excited to share their knowledge.

If you find someone saying something incorrect, ask yourself if it's pertinent to the discussion or could cause some confusion later. If so, pick an appropriate time to offer the correction. Using the example above, pretend that Doug went on to describe how they did not see any logs in production on Thursday. At that point, it might be an appropriate time to mention that they were closed Thursday, since they may have checked the wrong log date.

Don't Be the "Um, Actually" Guy

Inappropriate Medium

This point is a bit more nebulous, and there aren't any hard-and-fast rules to abide by. In my experience, there's three main communication methods within companies: email, messaging and verbal. Email and verbal are self-explanatory, and messaging might be something like Slack or other instant messaging platforms. My thoughts on this are that email should be used for any formal discussion, or any discussion which may need to be "recorded." Discussing contracts or service-level agreements, HR policies, or really anything which may have some level of impact. On the other end of the spectrum, messaging should be used for informal discussion or quick asks. Topics like where to eat for lunch, or asking a quick one-off question about a particular issue belong in messages.

Lastly, and most importantly, is verbal communication. This medium, in my own opinion, should be reserved for natural spontaneous discussion and critical issues. The reasoning is that, once again, time is valuable and should be respected. Verbal communication requires immediate attention, and interrupting someone's work to ask them something minor can be frustrating and even disrespectful.


Effective communication requires a lot of contextual understanding, and these types of soft-skills should not be understated in software engineering. In general, you should do what you can to value and respect people's time. From what to say, how to say it and even when is the appropriate time to say it, learning to communicate in a way that is concise and respectful will go far to help foster relationships.