How to Better Use Group Chat or Slack for Practices

AZ - Austin Zhao's photo
AZ - Austin Zhao
·Feb 18, 2022·

4 min read

Subscribe to my newsletter and never miss my upcoming articles

Clear then efficient communication is the precondition for us developers to understand and solve problems. We will see different ways of communication applied in the workspace, like meeting, face-to-face chat, phone calls, emails, and text messages. When emails are more used for informing or reaching help out of a team, and meetings are used for presentation and live discussion, text messages are more frequently used in the team to discuss the issues in more detail and engage with our teammates to work on tasks.

A thought always came to my mind, if certain things frequently show up in life:

any patterns we could see from them and how could we better deal with them?

Targeted to save teammates’ and our own time for typing around, I wrote some reflections about using our group chat or slack in a better way.

Understand the Context First

Context is an interesting concept that we met in school and the workplace, like understanding a word in a paper and many API docs. What is it for, generally? A simple understanding of mine is the information helping us understand a relatively abstract idea.

A word or sentence could mean different things, so here we need to understand the context and understand what will be a more specific message delivered by the word/sentence.

When being applied to group chat, it is always better or necessary to understand what are the things being discussed or chatted about. For sure, we want to raise our questions or concerns. But perhaps see if there are already some similar things discussed in a thread or more serious being resolved at the moment. If so, just hold on our “fire”, understand the issue on the way, and perhaps see if more details we could add into or problems we could pick out from, in our self perspectives.

Listening to Converstation

But note here, always a good thing to have our own thinking and decision – see if the issue we want to say is the thing that needs instant awareness based on our experiences + believe in our senses from logic.

One more tip here. Check if there is a better channel/group and a better time to mention the thing with our team.

Group and Format Content

It is human nature to prefer better organized and formatted information, which also helps us deliver the information clean and clear. Just recall when is the last time that you received loooong series of pings about one or more issues, mentioning here...and there...in some short and vague sentences...even worse, the shared code is raw...mixed between code and command lines...

Ughh. Just save others and us here – Thinking about organizing the information a bit and doing proper formatting.

Personally, I like to organize the thing into a single ping with several lines, which should be grouped into/

An example here:

Hi… a question related to… (one-line to brief the thing)
(context) when I tried to xxx, did xxx, but found xxx

here the code/cmd
xxx (formatted ones)
xxx 

(Some our own thoughts) I am thinking if…
(Asking for help) how do u think? / do u know more about xxx (some specific points here)

Just imagine we were the people being asked for this problem. One “Bing” sound, we got several-line information fitted into around a phone screen, understand the issue from the head, and then get more by reading the following. The code mentioned here is formatted and different from others text words, so we could freely go for a quick running to see if the issues behave the same on our side.

Wow. We may not like taking more issues but definitely will love the issues coming with some clean “dress” like here. So again, when we start to think about making others’ lives easier, we will begin to make our own lives easier.

Proofread, Perhaps 2 Times at Least

Small things, but will make more difference in the long term. A key point for us developers, working with logic to solve problems, is clearly presenting and understanding problems and communicating to draft & refine the solution iteratively, then finally deliver it.

So proofread after we wrote down the whole message, see if correct, accurate and complete for mentioning our problems. And a quick proofread it again at a higher level to see if some space and format were needed here. And better one more proofread or 3 to 5 seconds blick over the message after we sent out, see if it just show as we expect, like the attachment or links.

As a part of AZ efficient series, here will continue to write down my reflection on how to be a better Dev. Even I also can’t action every time just as I calmly sat down and wrote here, but guess here the thing is – we worked and tried just for a bit better, for the long term and on average.

 
Share this