An engineer's guide to asking better questions on Slack

An engineer's guide to asking better questions on Slack

Have you recently found yourself in conversations on Slack that feel days to resolve when similar conversations would be resolved relatively quickly in person. If yes, this article will help you make your asynchronous conversations more efficient.

[Monday 4:00 pm] Michael, a backend engineer with very little knowledge of the frontend codebase gets stuck while trying to solve a frontend bug. In a normal working situation, Michael would go to John's desk, the frontend engineer in the team and clarify the doubt in person. But since the whole team has been working remote since the pandemic, he drops a message to John on Slack. He attaches a code block in the message and asks Hi John, can you guide how can I make this code work successfully?.

[Tuesday 09:00 am] John starts his morning routine of going through the previous day's slack mentions and notices the above message from Michael. Although John is the most experienced frontend engineer on the team, John has no clue how to respond to the question since he does not know what problem is Michael trying to solve. John drops a message to Michael asking for a link to the bug that John is trying to solve.

[Tuesday 03:00 pm] Michael is going through his slack notifs after lunch and notices John has asked for the bug link, so Michael messages that link to John.

[Wednesday 09:00 am] John notices the bug link from Michael in his mentions, he goes through the bug and thinks of an alternative solution to the one that Michael gave and drops a message to Michael with that solution.

[Wednesday 10:00 am] Michael has been more frequent to check his slack in anticipation of John's reply. He notices the alternative solution proposed by John, but turns out he has already tried that solution and it does not quite solve the problem due to a weird edge case. He gets back to John with the details of his previous attempt.

This back and forth keeps on going on till Friday when John finally realizes on how the bug can be solved from Michael's information. The conversation around the bug took them 4 days to resolve. If both of the engineers were working in person, would this conversation have taken them 4 days to solve with the questions asked same way line to line? The answer would be no, since all of John's question about the problem would have been answered immediately instead of waiting for hours. The conversation would have taken at most an hour to resolve instead of 4 days.

What's the problem here, is Michael just bad at asking questions? But that can't be, Michael has been asking questions the same way as he did before. The example here is a bit of an hyperbole on how expensive asynchronous communication can be sometimes if we follow the same rules as real time communication. Following are points to keep in mind when trying to ask questions asynchronously:

  • Give the full Context. (Clearly state what you're trying to do)
    Instead of just trying to ask what's wrong with the code, Michael could have started his message with Hey, I was trying to solve [bug_link_here], where the popup doesn't appear on condition x . This message would give John more context on what's the problem in the first place. Additional thing to keep in mind when trying to give John context is to assume that John is completely clueless on the ideal behaviour of that part of the codebase, since John is not an all knowing deity.
  • Outline your previous attempts to solve the problem.
    Michael had tried 2-3 solutions that didn't work before going to John for help. It would help John narrow down the problem if he was aware of those attempts and what Michael had already tried.
  • Describe what's the problem that you're facing in your attempt.
    Just describing your attempts isn't enough, please describe what you've tried before.

Aside from the points described above, please be specific in what you are trying to point i.e. use this, that and it as less as possible. E.g. if you're referencing a column, explicitly name that column, don't assume the person on the other side knows what you're talking about. If you're referencing a commit, give a hash of that commit or even better, drop a link to a specific line of code at a specific revision on GitLab/GitHub.

Although these points might help you frame your better questions, the best way to get better at asking questions would be to ask a co-worker of yours to help you create a feedback loop. You agree that whenever you ask that co-worker any question, that co-worker would point out the flaws in your questions immediately and help you give feedback then and there on how you could you have better framed the question to help your co-worker understand the problem in the first go.

Show Comments