💬 3 Common Digital Communication Mistakes

Welcome to the thirteenth issue of the Software Mastery newsletter.

In this issue, I want to talk about three common communication mistakes people make on tools like Slack and Teams:

1. No Hello

2. Don’t Ask to Ask, Just Ask

3. The XY Problem

I learned these concepts while working at Amazon and occasionally see them in the wild, especially by new hires.

No Hello

“No Hello” is the idea that you should never send a message to someone with just a greeting (e.g., “Hello,” “Hi,” “Are you online?”).

The reason is that they get pinged after you send your greeting, causing them to check their notifications, but since you haven’t asked your question yet, they have to wait for your next message before they can think about and write a response.

Instead of an interaction like this:

[Bob]: Hi Alice, are you online?
[Alice]: Yes, what's up?
(Alice waits a minute or two while Bob writes their next message)
[Bob]: I have a question about X. Do you know if Y?
[Alice]: Yes, and the reason is Z.

It is better to just lead with the question:

[Bob]: Hi Alice, I have a question about X. Do you know if Y?
[Alice]: Yes, and the reason is that Z.

Don’t Ask to Ask, Just Ask

“Don’t ask to ask, just ask” is the idea that you should never ask for permission to ask a question; just ask the question.

For example, don’t go into a public forum and lead with a question like:

[Bob]: Hi, is there a Docker expert here I could speak to about something?
[Alice]: What's your question?
[Bob]: I am trying to do X because Y, but I am getting Z.

Instead, as before, just ask the question directly:

[Bob]: Hi, I am trying to do X because Y, but I am getting Z.

The XY Problem

“The XY Problem” is a common phenomenon where people ask questions about the attempted solution instead of the underlying problem.

It often manifests like this:

• Bob has problem X.

• Bob isn’t sure how to solve problem X but thinks they can solve it by doing Y.

• Bob doesn’t know how to do Y.

• Bob asks how to do Y.

• Alice wants to help Bob, but Y is a weird problem to want to solve.

• After some communication, Alice realizes that Bob wants to solve problem X, which has a straightforward solution.

Here’s a concrete example:

• Bob uses Dagger as a dependency injection framework but notices that the code autogenerated by Dagger doesn’t have unit test coverage, lowering their service’s code and branch coverage.

• Bob asks around on Slack if anyone knows how to unit test Dagger’s autogenerated code.

• Alice talks through the problem with Bob, only to realize the real reason Bob wants to unit test Dagger’s autogenerated code is that the code doesn’t have test coverage.

• Now that Alice knows the real problem, she suggests that Bob exclude Dagger’s autogenerated code from test coverage reports.

To avoid the XY problem, add more context that includes the actual problem you’re trying to solve. For example, Bob could’ve written a question like this:

[Bob]: Hi, I noticed that Dagger's autogenerated code isn't getting covered in our test coverage reports, causing our line and branch coverage to drop. I tried to fix this by writing unit tests for Dagger's autogenerated code, but it's hard to cover all the branches. Am I doing something wrong here?

Your Turn!

Thanks for reading this newsletter!

If you’re currently making these mistakes, it’s okay; now you know what to do instead.

Do you have any digital communication tips? Reply to this email or comment below!

Until next week,

Sammy