Skip to content

1.1 Communication

← Non-Technical Skills | Home | Next: 1.2 Teamwork →

Email Etiquette

Core principles: Be clear, be respectful, and be mindful of the reader's time.

Key rules (18-rule framework):

  • Make sure email is the right channel. Not every message belongs in an inbox. If the topic is sensitive, emotionally charged, or likely to require back-and-forth clarification, a phone call, video meeting, or in-person conversation may be more productive. Email works well for confirming or aligning on next steps, sharing decisions, or reaching multiple people at once.
  • Use cc, bcc, and reply all carefully. Use cc (carbon copy) when others should be aware of a conversation but are not expected to respond. Use bcc (blind carbon copy) when sending to large groups or when recipient privacy matters. Use reply all only when your response is relevant to everyone on the email thread.
  • Use clear subject lines. An effective subject line acts as a preview of the entire email. Instead of writing something vague like "Hello" or "Checking in," state the main point so the recipient immediately knows what it's about and how to respond.
  • Include a greeting and sign-off. Every email should open with an appropriate greeting and close with an appropriate sign-off that matches the conversation's tone. When in doubt, lean more formal and adjust.
  • Be concise and complete. State your purpose in the first few sentences. Avoid packing multiple conversations into one email or padding with unnecessary details. Include all relevant information in a single email so the recipient can act without asking clarifying questions.
  • Use a professional tone. An overly casual tone can undermine your credibility; a curt tone can come across as passive-aggressive. Aim for politeness and warmth while projecting confidence.
  • Be careful with emoji and humor. It's generally best to skip emoji in professional emails, especially in external communication. The same caution applies to humor—tone is hard to read in text.
  • Describe any email attachments. When you include an attachment, tell the recipient what it is and what you'd like them to do with it. Use descriptive file names, stick to common file formats, and keep file sizes manageable.
  • Reiterate in-person and phone conversations. After a meeting or phone call, send a follow-up email that recaps what you discussed. This creates a written record and prevents misunderstandings.
  • Treat every email as a permanent record. Anything you send can be forwarded, screenshotted, downloaded, or printed. When you're upset or frustrated, resist the urge to draft in the moment.
  • Proofread, proofread, proofread. Look carefully for spelling, punctuation, and grammatical errors. Double-check key details like dates, deadlines, and your recipient's name.
  • Wait 24 hours for follow-ups. Aim to respond to every email within 24 hours. When following up, wait at least 24 hours before sending a follow-up email.
  • Use an auto-reply when you're away. Set up an auto-reply before heading out on vacation or any extended absence so people aren't left waiting in the dark.

The "7 C's" framework for evaluating email quality: Clear, Concise, Concrete, Correct, Coherent, Complete, Courteous.

Chat Best Practices

  • Use threads to organize discussions. Threads help you create organized discussions around specific messages. They let you discuss a topic in more detail without adding clutter to a channel or direct message conversation.
  • Minimize interruptions. Avoid "ping"-style messages with no content.
  • Avoid unnecessary @channel or @here mentions.

The True Cost of Interruptions

Findings from Game Developer Magazine's analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio, and a survey of 414 programmers:

  • People need roughly 23 minutes to go back to their tasks after a major interruption, but for programmers, add at least 10 minutes—that's a solid half hour lost whenever someone approaches you.
  • When interrupted during an edit of a method, the person resumed work in under a minute only a modest 10 percent of the time.
  • There's only one uninterrupted two-hour session per day in which a programmer can work in silence.
  • The worst time to be interrupted is when you have the highest memory load.
  • Transitioning from a high memory state to a low memory state takes about seven minutes, so the interruption is almost never without consequences.
  • The time spent away from tasks is directly proportional to the amount of time needed to resume work.

Paul Graham's Maker's Schedule vs. Manager's Schedule

  • Maker's Schedule: When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. There's a cascading effect: if you know the afternoon is going to be broken up, you're slightly less likely to start something ambitious in the morning. "A small decrease in morale is enough to kill ambitious projects."
  • Manager's Schedule: There's always something coming on the next hour; the only question is what. For managers, meetings are not a problem—the schedule is organized by the hour by default.

Countermeasures: establish core coding hours ("no meetings before noon"), use Pomodoro timers, minimize instant message interruptions, and favor asynchronous communication over synchronous interruptions.

Sources

  • Grammarly — Email Etiquette: Definition, Rules, and Examples: https://www.grammarly.com/blog/email-etiquette-rules-to-know/
  • Slack Help Center — Use threads to organize discussions: https://slack.com/intl/en-es/help/articles/115000769927
  • devm.io — And it's gone — The true cost of interruptions: https://devm.io/careers/aaaand-gone-true-cost-interruptions-128741
  • Paul Graham — Maker's Schedule, Manager's Schedule (referenced within)

← Non-Technical Skills | Home | Next: 1.2 Teamwork →