When working remotely, communication is key to productivity

Every developer should aim to master algorithms and data structures, as well as many other technical skills. But sometimes the big difference between a productive and a failed sprint, in terms of actual output, is being able to communicate well with your peers. While in-person communication has its own challenges, the remote workday takes it to a whole new level.

Before COVID, I worked in an open office, when I needed help on some technical challenge or more details on a story, I could just reach out to someone and get it in a matter of minutes if they were not very busy. In fact, sometimes the amount of interruption you get on those types of offices can be really detrimental to software development productivity.

But when you work remotely, you will certainly miss having your colleagues in the same building as you; even more important, in the same time zone as you.

Just to illustrate that: the first week I started working on a company with devs all around the world, I needed technical support from a team in Asia and approval from my manager in the west coast of the US… it took days between clarifying what was needed, getting approval and getting it done.

Getting a more detailed explanation on a story and getting help with a technical challenge as soon as possible may be the difference between having 3 or 5 productive days in a workweek. The thing is, since you cannot count on your colleges reading your messages as you type them, and you also should not take their time for granted, so using asynchronous communication can actually boost your productivity if you know how to leverage it.

When using asynchronous communication (Slack, Email, etc) to talk to a teammate, don’t just say “Hi” and wait for a response. Your colleague might be busy for hours and may only see your message after you have stopped working for the day, so you should help them help you, leaving the necessary information for taking action even if you are not there to respond immediately.

That is not done by leaving all possible information, on the contrary, leaving too much information might make it even more confusing for them to try to help you. You must structure what you need in a way that is simple to understand and leaves no doubts about what exactly it is that you are struggling with. Let’s go through an example, suppose you are reviewing a Pull Request where your colleague is using an EC2 instance family (fancy AWS name for virtual machine type) you are not aware about and you want to ask why they are using that instance family in that specific context.

You should always try to help yourself first and also make a more informed and precise question. So your first step is always to research the topic you want to ask about. Get to know the instance family and the context where it is being used. So instead of asking:

"Hey, why are you using a t3a.small instance on that CF template?", you may ask something like: "Hey, I say that you used a t3a.small instance for the EB template of our frontend. It's good that we use those instances because they are a little bit cheaper. What load are we expecting to take on this particular system?".

So instead of asking just a broad "why are you doing that?" question, you are narrowing it down to the specific context you are dealing with, making it easier for your college to provide the answer you are looking for.and the help you need as soon as possible so you can get unblocked.

There are, of course, moments where you will need to ask straightforward questions, most of the time, those questions aim to clear your path into a more productive day.

Suppose I’m working on improving our deployment pipeline and I need to know if I can deploy both our Frontend, Backend and CMS at the same time. Deploying them all at once will save me many hours, since I might need to deploy them many times for testing purposes. So you might just ask “Hey, is there any issue with deploying all 3 environments in parallel?” and a simple answer such as: “Kinda, you need to deploy CMS first but Frontend and Backend deployment can be parallelized” will save you many hours. The last topic I want to touch on right now are video calls: don’t treat them as a podcast or background noise while you do your task in parallel! Prepare for the meeting and try to be as helpful as possible, it will improve your relationship with your peers and make it easier for yourself to get help as well.

Many people just jump into a meeting and simply answer the questions that are asked them, such a passive approach will not help you bond with your team and understand all the requirements for what needs to be done. The best way to attend a meeting is with notes and checklists for everything you need to get done on it, it might be the only synchronous communication you get with your colleagues that day, so make the best of it!

Also, leverage the technology you have to make the meeting more interactive: share your screen, have your webcam on, use the right voice tone. Remember that most of the in-person communication is non-verbal and when restricted to verbal communication only we need to use all resources on our hands to make as clear and on-point as possible.