Tips for Remote Work

During COVID lockdown, I worked remotely. I did all my Code Cop things, e.g. pair programming, code reviews, coding workshops, just in a remote way. All these tasks involved other people and I was severely affected by my "remoteness". After one year of remote work, one of my clients ran an in-house knowledge sharing on how to do that successfully. They invited me and I thought about the advice I would give. What would be my top three tips for remote work?

1. Check-in
When working remotely, the first and foremost thing I use are check-ins. During a check-in everybody says a few words how he or she is here - as a human being. The check-in is not about your role, your expectations or current work. It is about how you feel. When we work separately, I miss your face and body language and we need to be explicit how we are. In a face to face situation I might be able to recognise if you are tired or distracted or upset. I am unable to identify the little hints when you are just a small image on my screen. Now I place more emphasis on the human and emotional side of my peers because it is missing in a remote setting. Some people always reply with "I am OK" and I am fine with that. Nobody has to share. Some people keep talking and I have to remind them what the check-in is about and stop them from taking all the space. Conversation, arguing or discussion break the check-in. And at the end of the meeting I ask everybody to check-out, which is the opposite, asking how they are leaving as human beings.

2. Be Professional
I preach being professional. After all "I help development teams with Professionalism" (as written on the second introduction slide of all of my decks). Professionalism is an attitude, it is how you do your job. This includes also your appearance. In a remote setting, your appearance is the image of your face, the sound of your voice and the background behind your head. There are several implications: Your camera is always on. You are in the centre of your camera's focus and the camera is ideally placed on top of your screen where you are looking at from time to time. On the other hand, when only half of your face is visible, or your face is distorted in some way, it is hard to see and to connect. In communication theory, as the initiator if the exchange, the sender is responsible for the message to be received. Much of your message is conveyed by your voice. For the best audio, use a headset with a microphone so your team mates have a change of hearing you. Next I recommend a professional background. Best is a uniform wall or board. In the beginning of remote work, I hung a blanket between two window handles to provide a uniform, non distracting background during my video calls. Non uniform backgrounds are distracting and make it harder to focus on the face of the person speaking. A Green Screen background helps if you have no option to work in front of a wall or door. Please choose a neutral image with soft colours. Most Green Screen backgrounds are unsuitable.

3. Strive for the same Level of Collaboration
It is harder to collaborate under remote working conditions. For example pair programming is more complicated. Now I do not accept less collaboration than before remote work. There are options and tools to overcome the barrier. Ten years ago, in 2012, I already used tools as TeamViewer or AnyDesk to control the machine of my remote pairing partner. I spent many hours working like that and it worked well. Modern tools I have used include Code With Me, which works with the JetBrains family of IDEs, Visual Studio Live Share, which you can even join with a browser, Floobits, CodeTogether and mob.sh. If you are blocked by remote work, push for some solution to keep in touch and do what you used to do. Do not accept less collaboration than in face to face situations.

We need to keep in touch
After I had put together my three tips, I was surprised. I had expected some technology or tool but all three tips are about connecting. Then it is not a surprise after all, because remote work first and foremost affects collaboration. Most advice of the other presenters was aligned with that. Here are some examples: When working closely with a team you need to keep in touch. You should speak with your team members often, probably talk daily. You should also meet outside work, e.g. remote game events like online escape room. Meeting in person is even better, e.g. visiting each other or visiting the office once in a while.

Video Conference All Day
A team lead shared his story how they had managed transition to remote work. The team used to talk a lot during the day. When remote work started, they kept a video call running. Whenever people would work, they would be in the call, unless they were in a meeting with someone. Many team members used a second device, e.g. a tablet, for this ongoing call. They felt like being in the office and whenever someone wanted to talk, she could talk to the people in the room. Using the video conference open all day, the team kept up the good vibe while fully working remotely.

I am curious about your tips to improve remote collaboration. If you have any, I invite you to comment.

Remote Pair Practice

Deep in my notes of past conferences I keep a quote that says Writing code together is the only true way that programmers communicate. Even if you do not agree, pair programming is still a great way to share with one another. Whenever I program in a pair, I learn a lot. Unfortunately I have a very little opportunity to do so as my team is distributed around the globe. After attending a Test Driven Development workshop at this year's GeeCON I decided to do something about it.

Schedule
I plan for a pair coding activity each week. This seems like a good target to aim for. To free one or two hours each week for deliberate practice should be possible for everybody. Unfortunately I do not reach my target because I might be busy, might still look for a pair or my pair might be busy as well. In the past I only managed to participate in a pairing session twice a month. By writing this post I hope to save time on explaining and to improve the frequency of my pair programming. I found it better to schedule throughout the day instead of the evening. It also seems easier to find a suitable time at work days instead of weekends. Keeping away from evenings and weekends helps because there are still people with some private life ;-). An appointment at a fixed day and time is an option when pairing with the same person again and again, but to meet with different people, one has to be flexible. I do not care for the time as long as it is somewhere in my (European) time zone. To find suitable times in advance I use Doodle.

Pair Programming
A lot of people are afraid of pair programming because they never did it. To get started you should read James Shore's description of Pair Programming from his book The Art of Agile Development. There is even a short summary consisting of 99 words for the people who do not have time to read. In the end the rules how to behave during pair programming, are about practising everyday civility, because all I really need to know about pair programming I learned in Kindergarten. So be especially courteous. Pair programming teaches us to collaborate. I recommend watching Angela Harms' presentation about the (social) anti patterns in pair programming, Does pair programming have to suck? Note that pair programming may be difficult and uncomfortable for the first few times.

Get-Together
Obviously we have to meet in order to pair. In the past I managed a few times to meet during lunch breaks and have a short pairing session, much like Code & Coffee. Now I always bring my laptop when I meet my friends for lunch, maybe he is interested in a spontaneous pairing session while eating?

Remote Setup
Meeting in person is preferable but not always possible. Remote pairing is mainly about the additional tooling and all rules from regular pairing apply as well. My friend Thomas wrote a good post about Pair Programing from which I took all the material of this section. We use Skype to talk and TeamViewer to share our screens. It helps to have Skype contacts exchanged in advance so one can start the remote session by sending a chat message to the other one. As soon as the line is established we discuss who will host the session. A good headset is recommended, otherwise the voice quality is poor.

Then the host starts his TeamViewer and sends his TeamViewer id in Skype. I never had any problems with TeamViewer and it works great, even when connecting Windows and Mac machines. TeamViewer is a commercial tool but free for non-commercial use. A pairing session is definitely for educational purposes, so I do not see any problems with the license. After connecting I recommend changing the resolution of the host machine to the maximum resolution supported by the client. As a client I use TeamViewer's options View > Original and and View > Full Screen to get rid of all these scroll bars. If I have an additional screen I put the Skype window and a browser window there, if I want to look something up quickly. This setup is much like Level Four Pair-adise, except that it is remote.

It happens that I would like to scribble something on a white board. There is a nice Web Whiteboard, which allows drawing and shared editing. It is as simple as a real white board. If you need something more advanced, create a new Scribble in Google Docs which allows shared editing as well. All these and even more advanced topics of remote pairing are discussed by Joe Moore in his excellent talk about Remote Pair Programming: People and Technology.

Code Kata
An educational pairing session looks much like a Coderetreat. We might do a code kata or whatever coding problem seems adequate to work on. A code kata is an exercise in programming which helps a programmer improve his or her skills through practice and repetition. When I meet someone new, I do not impose any special rules. We would just work on a kata, preferably one that we both know, using ping-pong styled Test Driven Development. Todd Sedano compiled a list of code katas sorted by how easy it is to apply TDD. Fizz Buzz and Prime Factors are too short, but all other katas beginning with String Calculator are suitable. In fact the size of the kata does not matter, because it is not about finishing, it is about improving.

The choice of programming language is not important to me. Although my primary language is Java, I have done katas in Ruby, Scala, JavaScript and C# as well as some other, less common languages. After choosing the kata, the language and the development environment to use, we need to agree on the focus of the training session. There are some variations of katas possible, e.g. to use a more functional programming style or not to us any primitives or conditionals, up to the (at least for me) extremely difficult TDD as if you meant it.

With Tomatoes
It happened that we would lose track of the time while focusing on the problem. Later, for example after working on the kata for two hours, we would "wake" up and be totally exhausted. To prevent this, and to create some space for chit-chat, I use the Pomodoro Technique. There is a break of 5 minutes every 25 minutes. I just watch out to stop the Pomodoro with a failing test, so we know where to continue after the break.

Conclusion
As shown my remote pair practice contains everything that is good and holy: pair programming, cool tools like video conferencing and screen sharing, coding, TDD, code katas and Pomodoros. Can you resist?