Communication, not programming ability, is the most important thing that will make you stand out as a great developer as opposed to just a good developer. If you can’t understand others or communicate well, it doesn’t matter how well you program because you’ll most likely end up doing the wrong things. As a remote developer, it’s even more critical that you take time to communicate effectively. I’ve worked remotely for over seven years and here are some tips I’ve learned about how to work better remotely.
Use Video Calls as much as possible
I’ve worked remotely for a company where we had daily stand-ups using video and companies where we would just have calls as needed and usually just by voice. By far, I found that having regular video calls made a difference in feeling more connected with co-workers. With adhoc voice calls, I felt that communication was lacking. There is a lot that we communicate visually. By not using video, you are missing out on that part of communication.
At one company where I worked remotely, I was asked to mentor a junior developer who was struggling with programming. Without being able to see him and his body’s reactions, I found this to be a very difficult task. I wasn’t able to pick up those very important visual cues that would have told me the parts that he was having the most trouble with. Sure we did screen sharing together but it wasn’t the same as sitting next to him. Communication will always improve as you go from chat -> voice -> visual -> physical.
Stand-ups are Important
I know there are developers who loathe stand-ups but it is especially important as a remote developer that you have at least daily communication with the rest of the team. They shouldn’t be long – generally no more than 15 or 20 minutes. Daily stand-ups give you the chance to know what other people are working on. While it’s not that useful all the time, there will be times when you may be working on a part of the codebase and get stuck. Stand-ups help you realise who you should ask for help because you may have heard someone mention that they know about what you are stuck on.
Stand-ups also give you a chance to communicate what you are working on. It’s human tendency to have an “out of sight, out of mind” attitude. As a remote developer, it’s your job to overcome this limitation. Keep a list of what you have accomplished on a daily basis so you can go through it at the next stand-up.
Without regular stand-ups or team communication, there is a tendency to get tunnel vision. You’ll only know about what you are directly working on and will miss the big picture. Without stand-ups, there are missed opportunities for you to help out other developers in areas where you have expertise and vice versa. Try to have scheduled calls where you discuss more big picture stuff. This could be daily/regular stand-ups or just a weekly check-in of sorts. It will really help with getting the big picture.
Have a System to Deal with the Non-Urgent
This is a good practice whether you work remotely or work in an office. There will be things that come up that are not directly related to what you are currently working on but which may be important to the other person and the business. It could be something like a co-worker asking a question about how you did something in the past or a request to look into a new technology “when you have the time.” Don’t let these requests linger. Carve out some time of your day to deal with these queries. You don’t want to be the developer that needs to be constantly reminded. Yes, you probably enjoy doing your work and want to get things done, but as part of a team you do need to help out others now and then.
At my last place, one thing that fell into this category was code reviewing other people’s work. We used Confluence and I would get email notifications when other people marked their work as being ready for code review. Generally, I would spend a little time before lunch or at the end of the day going through these all at once to get them out of the way.
Keep Notes on Each Issue
When an issue gets assigned to you, you might have a call or chat with someone to go over the details. One important thing you can do is keep very detailed notes from this call. You will most likely need to refer back to them over the course of working on the issue especially if it’s a new feature or something non-trivial.
I keep notes on each issue I work on. Generally when having a call, I’ll write things down and then type them out after the call. I keep separate text documents for each issue, usually named by the issue ID plus a brief description. It helps two-fold to do things this way. One, I can search through my text documents if I need to find something that I forgot which issue it was apart of. And two, typing them up again makes me think through what we talked about and etches things in my mind. It also helps to bring anything we missed to fore front and I can add that to my question list.
Batch Questions
For anything non-urgent or non-blocking, keep a question list. Write down the person’s name as the heading for who you need to talk to and, under their name, write down any questions that you need to ask them the next time you talk to them. I started doing this pretty early in my career. At my first job, when I got stuck, I would walk over to my supervisor and ask him about the thing I was stuck on. I probably did this every hour when I first started. Then a co-worker took me aside and pointed out that a) when I’m talking to him, there are two people working on the issue so it’s doubly expensive for the company and b) he has his own work to do. By constantly interrupting him, I’m preventing him from getting his work done.
Since that day, I started keeping a list of questions that popped up. Now I only approach someone for help when I’m really stuck. I noticed a couple of benefits from this. First, it saved a lot of time as I could several questions at once. Secondly, it forced me to try to work through the problem on my own. Often times I found, with just a little more effort, I could figure out the answer myself.
The same advice applies to working remotely. It can be tempting to ping a co-worker if you have a question but each time you do that, realise you might be interrupting what they are working on. If it’s not urgent, mark it down and then bring it up at your standup or wait until you have a few things to go over and then get in touch.
Write Documentation
I know. No developer likes writing documentation. However, developers do like efficiency so let me show you how writing documentation makes you more efficient.
If you are just starting a new company, probably someone will help you get your development environment setup. At most places, I’ve found there is no documentation for this process. Someone will just walk you through it by memory. Take notes as you go along because you’ll most likely need to remember these details later.
Take a little bit of time after getting setup to format your notes and put it in the company’s documentation system. This will help save a lot of time the next time they need to onboard someone. You may also need to refer back to it later as well. It will also help you make a favourable impression to your co-workers. First impressions matter a lot so doing something like this will help you get off on the right foot.
As you work on more specific parts of the codebase, you’ll most likely find that you start to become an expert in one area and you know more than your co-workers who may have been around longer than you. Anytime you become the go-to guy for questions about a part of the system, it’s a good indication that you should create some documentation for it.
For example, at the last place I worked, I was responsible for refactoring and simplifying the email sending process. There had never been any thought put into email sending so there were dozens of separate pieces of code that sent email. I ended up refactoring all those places to send email through a common library. Other people knew I was working on this from our daily stand-ups so when they needed to send email, they came to me with questions about how to send using the new format. Whenever someone would have a question, I would add the answer to the documentation. Then this could help other people who had the same question in the future.
Think of documentation like solving a bug. Ideally, when you fix a bug, you should write a test case for it so that you will never encounter the same bug in the future. Look at documentation the same way. If someone asks you a question, write down the answer in the documentation. If somebody else asks you the same thing in the future, you can simply point them to the document. It will save you a lot of time.
Get to Know Your Colleagues
The biggest difference I’ve found working remotely versus working in an office is that it can be much more difficult to get to know your colleagues on a personal level. Natural chit-chat doesn’t seem to happen as much. When having calls or chats, try to spend a little time getting to know them personally. Ask about their weekend plans or their hobbies. If you can connect with your coworkers above and beyond just work, it will help you enjoy working with them more and they with you. I know some companies try to solve this issue by bringing together everyone to the same place a couple times throughout the year. I haven’t worked for a company like that before but I can see the benefits from doing so.
Another thing that I have done on occasion is to send a physical gift to remote people I’ve worked with. Even though a lot of developers are used to working with virtual things, there is still a lot of value for people in receiving a physical gift.
Working remotely requires that you pay attention to communication more than you would in an office setting. It doesn’t need a lot more effort but it is an investment. Any extra effort you make to communicate well will make it easier for you to get more done and enjoy your work more.