Writing Better Emails as a Developer

July 14, 2018

Email

There were a number of things that surprised me when I began my first full-time role as a developer. Coming from a completely different industry, I had pictured a development job as a place where I would be expected to produce hundreds of lines of code each day, only stopping to briefly touch base with other developers before diving back into a codebase.

As it turns out, a great deal of my time as a developer is spent in communication with business partners, testers, designers, and other developers. I have no hard statistics on this, but I would guess that the lines of communication I write each week (counting emails, jira, slack, and other forms) outnumber lines of code by a factor of at least 10 to 1.

YMMV depending on your industry - but I would venture to guess that this is true for almost all developers that work in any kind of team environment.

So if it is true that a larger percentage of my job centers around communicating with people than it does writing code, it stands to reason that my written communication skills are easily as important as my coding skills. Unfortunately this is a facet of development that is often overlooked; while most coders I know are decent communicators, few are excellent communicators.

Just like writing clean, modular and reusable code, sending clear interpersonal communication is a skill that can be developed, practiced, and refined.

Since emails are often a primary source of communication within organizations, I thought I’d share a few tips on making them better. Many of these tips could apply to other forms of written communication as well. It’s nowhere near exhaustive, but if you apply these lessons to your written communication they should save you time, confusion, and help you do your job more effectively.

5 Checkpoints for a good Email

  1. Clear Action Steps Why are you sending me this email? It’s easy to get bogged down in details and forget that an email should contain clear actionable items for any necessary parties. What is it that people should do based on this email, and have you stated it clearly and simply?

  2. Brevity Here’s the hard truth: people aren’t reading your long emails. Think about how you process long emails that you receive: you try to briefly scan them for pertinent information. If it is necessary to make an email long, I try to highlight or bullet the important parts, helping the reader quickly focus on what’s important.

  3. Grammar / Spelling I shouldn’t need to include this here, but experience tells me I do. You may be an amazing coder, but if you send emails that look like they were written by a first-grader, it’s going to be hard to get your point across.

  4. Appropriate and Encouraging Again, this should go without saying- but if you’re ever writing anything with a mean tone or with inappropriate/demeaning language, don’t write it. Never, ever fire off an email while upset about something, and live with the understanding that anything you write will live forever somewhere. Along those lines, take the moments you can to express encouragement and gratitude in your emails. Kind words are free, and for many people they make a bigger difference in job satisfaction than a salary increase of several thousand dollars.

  5. Include Pertinent Information Sometimes you’ll need to add someone in to a long email chain to bring them up to speed (how many times have you read the line “Copying ** for awareness”?) When this happens, and in other cases when someone will need to do some catching up, it helps them if you can give a brief summary of info they’ll need to know. Similar concepts include stickies on forums or a master readme in code repos.

I hope this helps you when you sit down to reply to the 50 emails you received while reading this :) Remember, the way you communicate is just as important as the way you code - so go do it with excellence!


John D Potts

John D Potts

Web developer and speaker in Charlotte, NC.