Software shenanigans

This content originally appeared on DEV Community and was authored by Agustín Tomas Larghi

I've decided to start a new series of posts ("Software shenaningans") oriented to soft-skill improvements, communication, how to coordinate things with your team, the kind of things that - opposite to software technologies - won't get outdated.

Since the pandemic started, I've noticed many companies have turned onto remote work, yet many people are not used to working remotely. So I thought about writing a quick post about a few things I've learned to improve productivity when working remotely.

FYI, I've been working remotely most of my career, even before COVID, so most of the things I'm going to talk about here come from my remote work experience.

I've seen many talented engineers fail because of communication issues, sometimes because they can't communicate their ideas properly, but more often than not it is because of their own insecurities. I've seen engineers get anxious over having to ping a manager, schedule a meeting, or do an @here on the Slack general channel. I'd like to think that I'm very loud on Slack, I'm not afraid of hitting that @here to get people in sync, and no one ever has slapped my wrist by doing so. No one is ever going to yell at you because you are trying to express your ideas.

If you are an over-thinker here’s a simple diagram to help you figure things out.

Let's go through some examples:

Is this okay? ?‍♂️ No, don't ping the whole channel just to say hello. Is it okay - and I encourage - being cheerful and polite, but don't disrupt people unnecessarily. Thinks that as soon as you do an @here you will have most people on that channel context switch from whatever they were doing onto Slack.

Is this okay? ?‍♂️ No, if things are getting on ? ping everyone, the faster you all address the issue, the better. Again, think that most people when they look at Slack they will see something like this ?

All channels highlighted all the time, unless you ping people directly, chances are they won't notice what you just write until the end of the day ?.

Is this okay? ? Yes, the same thing we were talking about before, if you need someone to take immediate action on something that is blocking you, ping that person directly.

Yet More Slack tips

1️⃣ Keep ? conversations

If you don't keep the conversation flow tidy on Slack, things can get messy. For example, picture you jump on the #engineering channel, and you see you are 30-something messages behind this convo ?

Not easy to catch up, right? For new people joining this conversation, it may be hard to get the context of what's going on when you don't know where the conversation started. And it will very likely take you a considerable amount of time until you do catch up. Plus, things can get muddy if other people are talking about different things.

Keeping threaded conversations may mitigate this issue ?

Also, you can later link this conversation to Jira/Azure/Trello tickets - or whatever CMS your team uses - for future reference. Same for the PRs, you can link the Slack conversations so whoever reviews your PR can have a little bit of context about what the changes are for.

I'm a big fan of using PR templates, and linking the Slack convos to the PRs gives much more context to the person doing the review.

2️⃣ Using the /remind command

Usually, on my day-to-day, I do almost all my work following the reminders of the day before. The /remind me command is quite helpful to keep track of things.

Let's say you were discussing something with someone and you need to follow up later ?

You can target the /remind command to different people or channels, not just to yourself.

For me this is the most powerful tool on Slack.

3️⃣ Grouping channels into sections

As we were saying before, most of us, when we open Slack in the morning, the first thing we see is just a humongous list of highlighted channels. Some of them we don't even care - for example, a #random channel just for fun, channels that are completely unrelated to the work we do, etc.
So instead of having to waste time going through each channel, sort out the channels by priority using sections.

Something like this ?

Becomes this ?

That way you can check the truly important channels first, and if you have time, go through the rest later.

4️⃣ Rule of thumb

Avoid DMs as much as possible. Try to post on public channels as often as possible, in my experience, teams who communicate through public channels perform better than the ones who rely mostly on DMs. Think that if you are discussing something with someone else via a private DM ?️ other people won't be able to catch up with what you are talking about, you may be talking about some technical adjustments in the back-end with just one single engineer, what if some other engineer had something to say about but he couldn't because he didn't know about this conversation? ?️ Also, you cannot link or reference private DMs, if someone new joins the DM he won't be able to see any previous conversation.

Finally, speaking on public channels encourages people to speak up, be more transparent, and it removes that feeling that some people have of--"Oh, I better not talk about this here so I don't open a can of worms!"

Always try to ping people directly. It is unlikely that people will reply immediately to you if you don't ping them directly ?

I've seen so many people so quick to jump the ? and hit the SEND button way too soon when sending emails. A bad email can cause more confusion than anything else, and if the tone set in the email sounds rude it can complicate things even further. So, I'll just drop some tips I've found useful:

Read your emails aloud before you send them. The tone in an email is key. I remember once I had this lengthy email thread going on with a back-end engineer from a contractor company working with us. We would only talk via email, so that made things even more difficult. And these guys were working in a completely opposite time zone than ours, so it was basically sending an email, and waiting for the response to come back the next day. I'm not going to lie, I was getting annoyed by the whole situation ?.
The whole thread was about us asking for some credentials to use an SDK in the front-end, and we were going back and forth with the back-end guys because they would provide the credentials but this wouldn't work as expected. So at some point, I replied something like this ?

John, I know this is doable because I've seen it in the documentation here: http://somelink-to-some-documentation.com

Of course, one minute after hitting send, I'm pinged via Slack by one of my Engineer Managers - and rightly so - and he asks me to read my response aloud, and then I realize that I'd completely dropped the ball. The tone was rude, and it didn't get us any further into solving the issue.

Double check names. Many people, myself included, can get annoyed when other people misspell their names. Just take a minute to double-check that you have correctly written the name of the person you are addressing. Once, in one of my previous jobs, I was helping a new hire, a new Android engineer getting on board. We would talk over email because he didn't have his Slack credentials set yet. I usually go that extra mile when onboarding someone because I want them to have a pleasant experience. But this person would keep misspelling my name on every email. Augustin instead of Agustin. So, I let the first email pass. Then in the second email, I bold my signature so he could see my name. The same thing again, so I finally add a PS on the third email -- "FYI my name spells Agustin ?". So, take that extra minute to double-check names. Don't skip accents on the letters. Otherwise, it looks as if you don't care about the email content.

If you are not a native speaker, use some tools to enhance your grammar. A text with spelling mistakes won't be taken as seriously as one that's not. There are some great tools out there to avoid common grammar mistakes. Like Grammarly or Ginger. Both are great tools to prevent those little details, that especially us who are not native English speakers, often do.

A good intro is a nice way to start a new job with the right foot. I always encourage people to present themselves when they are about to join a new team, just doing a quick intro on the Slack #general ?

I would even recommend that you ask your manager if it would be okay to send an email to your whole team presenting yourself more in detail ?

And you know, try to be personal, don't be like -- "Hi, I'm Agus and I like coding, and coding is also my hobby". I don't think anyone has so little going on in their lives. Also, sometimes using emojis helps to set the emotional tone in a message.

1️⃣ Always have your camera turned on. Seeing someone else's face on the screen helps people connect more, and it also helps you being taken more seriously by your teammates. I mean, if someone has their camera turned off, you don't know what they are doing, right? Are they paying attention to what you're saying? Are they watching Netflix?
If you feel uncomfortable by having 50 people stare at you through your webcam during a meeting, just switch tabs. I often do that if I have to talk at a meeting where I know there's going to be a lot of people, I just switch tabs so I don't have to see the amount of users or anything else, but I keep my cam turned on so everyone else can see me.
It is okay if you don't want to turn on your webcam during a meeting because you're having lunch - although I don't recommend having lunch in front of your laptop, it's not healthy ? - or because of something else. But do so once you've become comfortable with your team.

2️⃣ If you are in a noisy environment use audio filtering.You can buy a headset with noise filtering included or use audio filtering software such as Krisp. Most people won't even tell you if you have noise in the background out of shyness or because they think it would be disrespectful. So, make sure no one has to try to figure out what you are saying behind the barking of your ?.

3️⃣ If you need to say something, but feel uncomfortable interrupting people, use the chat section.

4️⃣ Watch out for the "radio silence" during conversations. When you start working with a new team where each member knows little to nothing about each other, or if you start working with a team that isn't used to work remotely, you may run into those uncomfortable situations where someone asks a question, a minute goes by, and no one answers. Then, what can we do to solve these situations?

For example, let's say we are on a Zoom call, and one of the front-end engineers asks a question like:-" How is the UX supposed to look like when we navigate into this section, and there's no internet connectivity?" Let's say 10 seconds go by then:

• 1️⃣ If you think you know to answer the question, answer it. It doesn't matter if you think it would be a dumb answer, it will prompt someone else to chime in.

• 2️⃣ Redirect the question to someone who may know how to answer the question. For example, if a front-end engineer wants to know how to implement the UX for a specific edge-case scenario, redirect that question to one of the designers.

• 3️⃣ If no one knows how to answer the question, they are taking too much time, or just going back and forth, then park the convo and propose to follow up on a Slack thread later.

Something else to keep in mind is that these situations may be a direct result of a lack of ownership across team members. It takes time and effort to boost people into taking more ownership, this is something that the team achieves through regular 1:1 meetings and giving honest feedback to each other.

• Reach out to people. Don't overthink about sending messages or scheduling a meeting with your teammates. That's what we are paid to do.
• Don't be an emotionless drone. Talk to people over Slack as if you were in a real office.
• Step up, have ownership of the product. Even if sometimes you think it is not your responsibility to lead some initiative or organize something, just do it. It will make everyone’s work - including yours - easier in the future.

This content originally appeared on DEV Community and was authored by Agustín Tomas Larghi