(See continuation – 10 more communication quick wins for developers)

I like a quote from Uncle Bob:

Honesty in small things is not a small thing.

In my book communication is one of those “small things” that is a foundation of everything else, yet tend to not be treated honestly.

In my standpoint software development is difficult enough. I wouldn’t burden other people with unclear communication. Your standup statuses, your messages on Slack, your emails, your comments in the code – they all are received more often than sent. A tiny bit of effort before sending a message can save a lot of time for the other side.

You don’t have to read tons of books about communication. This isn’t rocket science. Just pay attention to how you communicate. Place yourself as a receiver of a message and imagine what they could miss. Improve little by little.

Take these tips to start.

1. Use text formatting

  • Bulleted lists
  • Numbered lists
  • Bold
  • code format for code inlines

To fluently use these four you need to:

  1. spend very little time
  2. have mental abilities of a 5-year old

But what you gain in exchange is undying gratitude of whoever reads your messages, their better understanding, and improving your communication skills by 90%.

Yup, I made up that number. But seriously – by a lot.

2. Patch your messages

When somebody got confused about a part of your message (Wrong link? Too many zeros in a number?), please correct the original. Even if it’s possible to get everything crystal clear by reading an attached discussion. New people will come and read this message. Why would you make them go through it all?

While fixing a typo is nice, fixing misinformation is a necessity.

You could also include a stamp like (edited) next to the updated part. This is less important, but come on, it takes 2 seconds.

3. Provide a link

People work in their own loops. When mentioning a Trello card, a pull request, a Slack message, anything linkable – include a link to it.

They will be grateful in three out of four cases. The remaining one they won’t mind.

4. Tell what you assume

Ideally, instead of assuming we should ask to make sure. But let’s be real.  This is hard, even if pride is the only reason.

Instead – feel free to assume everything, but tell them. This way you will give them a chance to correct you.

5. Don’t send private messages

Simple as that.

6. Dismiss the question after replied

Hover over your Slack massage -> More actions -> Edit message -> append with (nvm I got this) -> Enter.

Editing is better than deleting – people may question their mental sanity after the latter. The worst thing would be to leave it untouched and most likely waste everybody’s time (and potentially yours).

7. Don’t say just “hello” in chat

The same for @channel / @here on Slack. This is just mean.

8. Abstract your message…

…like you abstract the code.

Just a reminder: the idea behind standups is to keep it short. If you really have to say more than 3 things (or maybe 5 or 7 – you get the point), consider wrapping some of them within a common namespace – “minor changes to UI”, maybe?

Sometimes it’s important to mention that the meeting went much longer than expected. It’s fine, but most of the times the length of the meeting is just a detail. Hide it from your recipients.

Let other people think of your story on a single (high) abstraction level. If needed, they can ask, just like they can check the implementation of a method.

9. Written trumps spoken

As a sender, this makes you structurize your speech, ask proper questions (think rubber duck debugging).

As a recipient, you can steer the flow of written messages. People can read your email when it’s time for it; they can’t do the same with you standing next to them.

Not to mention that written communication is:

  • Pro-async – easier to reach currently AFK people
  • Pro-broadcast – easier to reach more people at a time
  • Pro-introvert – less pressure for immediate answer
  • Less ephemeral – you can refer to a message later

I find it pretty funny that some people don’t get something that ancients Romans knew 2000 years ago.

10. Address all the questions

Oh man, that sounds like an elementary school, but seriously. This happens way more often than it should.

I hated only one client in my life. It was a guy who, when asked 5 questions in an email, would answer only one of them. It was usually the last one. Maybe he had a very short memory? Anyway, he successfully discouraged me from asking questions. Good job. Agile at its best. You will have a great product, exactly how I imagine you imagined it.

Back to developers, sometimes people don’t address all the comments on a pull request. How about quick Let me check or Will do or This is invalid now or Let's discuss it online or whatever, just to tell other people that you read it and what you think about it?

The question has been asked for a reason. Not replying seems like rude ignoring.

What do you think?

Does any point sound like a “too-much-work-and-I-am-so-busy”?

Can you share your communication quick wins?