See you in a few weeks
Surviving (and Thriving) as a Remote Developer
Back on the 13th March 2020, I said what I thought was a temporary farewell to my
colleagues with a cheery “see you in a few weeks”…what I didn’t know then was that
I, and many other of our growing team of developers, have since visited our office in
Manchester just a handful of times.
Yet, the past year has been KrakenFlex's most successful and productive to date! So how have we contributed to this success and made developing remotely work for us? Here are some things we've learned along the way:
For those of you who don’t know, pair programming is a software development technique in which two programmers work together at one computer. One is the driver who writes the code. The other is the navigator who reviews each line of code as it is typed. Roles are switched frequently.
Remote pair programming works pretty much the same but rather than working together at one computer, you collaborate across Zoom (or video conferencing tool of choice).
And that's it. The way code is checked into version control, gets reviewed, and how applications get deployed remains the same.
Now, we all know the benefits of pair programming. How it increases code quality, leads to fewer mistakes. But the number one benefit for me, especially this past year, has been communication. Speaking to someone. Knowing that there's a human being behind the code, those pull requests, those JIRA tickets.
Given the importance we place on pair programming, it has been vital that we make it a success remotely. Here's what's worked for us:
Tip 1: Rotating Pairs
It's easier to zone out when you're not developing in person. Rotating pairs regularly (for example, every 30-40 minutes) will help you stay engaged and keep your wandering eye away from r/wallstreetbets.
Tip 2: Taking Breaks
When working in person, it feels more natural to take breaks, stretch your legs, and go for a natter with someone over a coffee. Don't feel guilty for taking five/ten minutes away from the screen while you're at home! Take breaks; don't burn yourself out.
Tip 3: Letting Someone Less Familiar with the Codebase Drive
This is great when you're remotely onboarding new starters (which we have!). It allows them to develop muscle memory and build confidence in where bits of the code live, what that button in AWS does, and what ritualistic dance needs performing for the Jenkins server to publish your artifacts.
Tip 4: Not Pairing
"But didn't you just say…"
Yes. Yes, I did.
Pair programming is fun but can be tiring. Pairing for eight hours a day is exhausting. I've found it a lot easier to fall into this trap while working from home. Don't pair for the sake of it. Look for opportunities for you and your pair to parallelise and look for chances to do smaller tasks on your own. You'll feel rejuvenated!
WIAUT (Patent Pending)
One of the simplest and most effective practices we've adopted is to end the day with a WIAUT in Slack. WIAUT standing for Where I Am Up To (or WWAUT / Where We Are Up To if necessary).
The idea is that the last thing you do before signing off for the day is to post a message in your team's channel to, well, let them know where you're up to!
Here's an example:
It's so easy to do. You get an idea of how work is going or if anyone is struggling and needs a hand. It's handy if somebody has to call in sick and the team has a good idea of how to pick up any outstanding tasks.
Other teams bypass the Slack message and gather everyone for a Zoom WIAUT. Both work great! Try one of these out if you work in a team that doesn't do something similar.
Speaking of Slack messages, we've had to learn to overshare:
As delicious as that looks, I was thinking more of this kind of oversharing:
We found it's useful to overshare when:
● You're doing exploratory work and need to do a brain dump of your findings.
● You've found a new tool or library that'll make your life so much easier.
● AWS has released a feature that could be beneficial to the team.
We don't get to have as many of those conversations in passing where you mention something that is the solution to what another team has been wrestling with. Oversharing and not omitting details for brevity has helped us to avoid forming silos around ourselves.
We've missed impromptu whiteboard sessions to hammer out ideas and solve problems (Miro is excellent, but it doesn't replace the real thing… sorry Miro).
We've missed bumping into each other in the kitchen, asking about the cool stuff we've been working on, and having conversations that start with, "Oh, we had that problem. We solved it by using XYZ".
We haven't been perfect. We're still learning. And we still need to adapt.
Our ideas on working life are changing. As restrictions lift and offices open up, the world will have more workforces with a split of in-office and remote staff. This is the next challenge for KrakenFlex.