I get a lot of questions about the fine details of what remote working actually involves for software development. So here's a few descriptions of how various activities play out when I'm working from home.

Bear in mind these are what I do, I'm not saying they're the great ideas or will work for everyone, they're just what I do, and show that remote working can work well (I've been doing this for nearly ten years).

Also bear in mind that I'm talking about working in a team of developers, at least half of us are full-time remoties and the office is in another country on the other side of a sea. So there's no popping into the office to sort things out.

Commuting to work

The morning routine. Almost the same as with an office job, except for the bit between leaving one building and arriving in the other building.

1. Get up
2. Turn on remote working kit (it needs 15 mins or so for the full boot up, VPN connection, phone sync)
3. Get sorted (shower, breakfast, walk the dog, whatever)
4. Log in
5. I am now at work, not at home - usually by 9:15 at the latest, we do flexi-time.
6. IM, email, browser, IDE, any other regular stuff is set to start automatically
7. check email - did anything drastic happen last night? Does anything need doing ASAP?
8. check phone - missed calls either mean someone came in early and has a problem, or someone has a boring task to do today and wants to put it off ;-)
9. check calendar - hope for no meetings!
10. check IM - say hi in the chat room and join in if there's something exciting going on
11. if there are no panic jobs, get a fresh mug of tea
12. if there's a todo list waiting for me, or there's email to deal with, get cracking on them
13. if not, get the mental gears grinding and get to work

Picking up a bugfix/request

We're still trying to train a lot of our business teams to use Jira themselves to create bug reports and requests, but most still start with either email, phone call or a minimal Jira saying the equivalent of "argh I've got a problem, call me!!!!"

For the moment we're being polite and educational, working with them to help construct a useful Jira entry we can use to work on the issue. There are varying levels of optimism on whether the education will work, or whether we're doomed to be Jira sock-puppets forever.

For this recipe, I'll assume there's no Jira to start with, but I am already working on the project the caller is talking about.

1. Answer phone - always using a headset, I'm going to be driving my dev box at the same time
2. From then on, the goal is for us both to thoroughly understand the issue. Being remote doesn't seem to make this any harder.
3. While we're talking, I open up the app/doc/page/etc so we can view the same apps, pages and documents.
4. I also check Jira and the Wiki in case the same issue or something related has been mentioned before.
5. Once we both understand the issue and have both seen it on our screens, we agree what to do about it.
   • If there's and existing Jira for the issue, we decide if there's anything new to add.
   • If there is documentation about the issue, I either read the relevant bit or point them at it and may agree a follow-up call
   • If they can now sort it out themselves, I update the Jira or docs to mention any new info from the call.
   • If it's something major, I ask them to either raise the Jira themselves and add all the info, or email me and the project manager.
6. For new minor issues, or an alteration to an existing one, I create/update the Jira entry, assign it to myself and ask the reporter to confirm the details match what they expect.

From here, it's as if we're picking up a nice neat Jira. and that's almost identical for the remoties and techies in the main office. Apart from:

• Discussions are via phone rather than meeting room.
• Any show-and-tell happens by either screen-sharing or we look at the same app doing the same thing on each of our screens.

Asking for help

First things first, I check all sources of documentation I can thing of. That means I've searched the wiki, any docs in source control about the project, Jira, SVN comments and the most obvious hiding places in our document pit-of-doom (Sharepoint). Then Google and StackOverflow (natch). If that hasn't helped, or I've spent too long wandering lost in a maze of code, it's time for the bat-phone.

1. Get the questions ready. Think about what the fundamental problem is and what help I need.

2. Pick the person I think is most likely to know.

3. Give them an IM nudge - something like "you free for a mo', to ask about XYZ?"

   • If they say no or don't answer, either wait or pick someone else.
   • If they're busy, either agree a time and shut up until that time, or pick someone else.
   • If they say ok, yay - the cavalry has arrived!

4. Pick a comms channel: IM, phone, phone + VNC, phone + Jira/Crucible, etc

5. Explain the problem. Show it happening if possible. I'm after a "oh yeah, I see the problem".

6. Work through it, let them drive the screen or edit whatever they want.

7. Once I get to the point where I can see the answer, that's it, get out of their way.

8. If they have a time limit, or we're going in circles, or both stuck, again I'll get out of their way.

9. Many thanks, be happy they helped.

10. Hang up, shut up, tidy up. That includes closing share sessions, saving any code/doc edits, binning temp/debug files.

11. Write it down. Quickly, before it falls out of your head! If it's code or any kind of file, get it saved. If it's process, write some notes.

12. Tea and biscuits and a walk around.

It's possible that while you're waiting for them to be free, you'll figure it out or see the answer yourself. Use IM to say a quick "no need - I've found/fixed it. Thanks"

Getting asked for help

It does occasionally happen that I can help other people too :-)

If it's a techie, they'll usually be following the recipe above, so I'll 1 get an IM (or email) nudge. If I'm in the middle of something 2 I'll either pick a good time for me to take a break or point them at someone else. If it's a "servers on fire" problem, I'll take the context switch hit and drop what I'm doing.

Hopefully they'll already know how it'll be best to discuss the problem, otherwise we 3 agree comms channels and start talking. The main thing is to 4 get to "show me" as soon as possible. Once I can understand the problem, we can start to work on it.

If we're on VNC looking at their screen, or we're both editing the same online resource, then we agree who has control at any moment. A bit like dual controls in a car/plane, we do the equivalent of 5 "I have control" and "you have control" to avoid fighting over the resource.

Once we've agreed that either we've got a fix/solution or there's at least a way forward, then usually they'll either want to get on with the work or write up what we've sorted out. At that point we'll 6 agree to end the session and they can take things from here.

I try to remember to 7 shut down and log out of any shared sessions and save any files we've been working on, but usually they'll be doing that too, so things like VNC/RDP windows will close themselves and debug sessions will end as they close down the app.

After that I'm 8 off for tea and biscuits and a walk around.

With non-techies, there can be less understanding of the implicit "do not disturb sign" on our phones while we're working, so rather than an quiet IM/email nudge, they'll start with a phone call and straight into talking about the problem. I'll accomodate this if it sounds actually urgent, or it's related to what I'm currently doing, but otherwise they will get a "I'm just in the middle of something, can I call you back in 15 mins?"

There are a few reasons for doing this. It means I can get stuff saved and write some scribbles about whatever I'm doing to help pick up again afterwards. It gives me time to get some tea, go to the loo, and generally get ready for what could be a long call. It also acts as a reminder that as remoties we're not just sat by the phone waiting for calls. That shouldn't be necessary, but for some of our office-based staff remote working is a hard concept to accept.

Importantly, I'll always call back in 15 mins or less. I'll also introduce IM chat to them as part of our call, sending urls or snippets via chat rather than reading them out or emailing. Hopefully this starts getting them used to the idea of using a messenger app.

Code reviews

We use Atlassian's Crucible for all non-trivial code review now. It's a bit slow and clunky, but it's a damn good idea!

It means that for the majority of reviews there is no difference between being co-located or remote. The author, reviewers and any interested parties can all view the review, add comments and answer questions, and even make corrections, all within the online app, with a persistent history and an agreed set of sign-offs.

So I don't really have a recipe for this - just get on with it, using whatever code review app allows for remote reviewing.

The only difference being remote is handling the knotty review issues. We have to use the phone rather than either getting a room or sitting uncomfortably around the same monitor. We've found that the phone itself is a moderator, as remoties we seem to have fewer full-on arguments and raised tempers during code reviews than those between the people in the office. Things rarely get to needing a call and when they do, the views tend to be more moderate and negotiated settlements are quicker to agree.

Team meetings

I've written a separate post about our regular remote meetings

The summary of that post is basically:

• Don't do huge high ceremony con-call based meetings. Especially not when the phone system can't cope, the purpose is poorly thought through and no one wants to be there.
• Do have an informal, optional meeting which allows people to vent in a supportive group, and still provides the required reporting output.
• and consider doing some regular meetings via permanent IM chat rooms - it works surprisingly well once the etiquette settles down.

Kit trouble

It doesn't happen very often, but occasionally stuff does stumble or die. The most common problems we've seen are losing connection to the office, a dev machine crashing, or the VOIP phones sulking.

In almost all cases, the solution is 1 first turn off and on again at the remotie end. If that doesn't work, then it's time to 2 start checking the local stuff. Is my router working? Does the internet work from my home PC? Are the company's public servers accessible?

If the local stuff and our connection to the world all seems fine, it's 3 time to phone the IT team. If the phones or network are dead, then we call/text someone in the office on a mobile. Usually the IT guys will either bounce the dev machine, switch our phone to a backup VOIP switch or check what's gone wrong with the VPN connection.

If there is a network or system-wide problem at their side, they'll know about it already due to having some good monitoring systems, so the IT team can tell us to 4 wait it out while they put out the fire (hopefully metaphorically!)

Usually the problems are fixed in a few minutes, and that's just counted as part of modern office life. On the very rare occasions that there's a serious problem (someone digs up the wrong road, a switch catches fire, etc) we'll 5 sort out some way to keep working.

I haven't experienced this myself, but when an outage has lasted days remoties have been known to bundle their kit into the car and commute to the nearest fellow remotie for a day or two. Alternatively they have booked short notice holiday and come back when it's all fixed. There has also been the suggestion of a "reading day" or two being allowed where we can catch up on any ad-hoc training or refresher reading we might have planned.

Again, not something I've had happen, but if the problem is dead remote working kit the IT team have been able to get replacements couriered over the next day. The conclusion from all this is probably pretty clear - you need a good IT team and you need to talk to them when things go wrong.

Socialising

Socialising is a personal thing, we all do it differently, we all have different needs and things we enjoy. We all need differing amounts of human contact. There's only really one thing I'd say to anyone who is permanently remote:

But I guess you knew that already. It's been said many times and hopefully it's fairly obvious. So I'll also waffle some more here about the different types of social life I've seen working, and those I've seen cause problems.

family - if you live at home with a family (that you talk to), you have a social life. If that's all you have outside work, that's enough - if it puts a smile on your face, gets you moving and out of that office.

get out of the house - If you're permanently remote, especially if you live alone, it's really easy to end up never needing to leave the house for weeks. Supermarkets deliver, Amazon exists, social media means your friends are available on slabs of glass.

Luckily I've only seen one remotie fall a long way into this trap. We eventually realised he was pretty much never talking to anyone and rarely left his house. Kudos to our manager, he did talk through things with the remotie and in the end they left, with the strong suggestion that they really needed help and/or to work in a physical office.

That event was a bit of a wake-up for the rest of us. We became more talkative ourselves and more aware of when we hadn't talked to another remotie in a while. We started to work on our conversation skills (or at least practice talking to a wider set of people about a wider range of topics). I know I also started watching myself for any settling in to house-bound routines.

do something physical - It common advice from medical experts and anyone involved in physical and mental health. You'll no doubt have heard it before. But it's even more important when you don't even need to walk out of the door for your job, or even walk between desks and offices at work.

Personally I've climbed for years. It gets me walking to hills/crags when it's dry and gets me working hard on either rock or plastic whatever the weather. We also have a dog who needs at least a couple of hours walking a day, so I think that's me sorted.

Other remoties have different ideas about physical activity. Most of them in our team have fairly young kids, which counts as physical work in it's own right. One likes running, another lives in the Lakes and bikes up the hills, another goes to music gigs and concerts all the time. It doesn't have to be a gym or a sport, just as long as you're out of the house, with a raised heartbeat, around other people.

online social doesn't count - From the above waffle it's probably obvious that when I say social, I don't mean gaming, or facebook, or whatsapp, or any other "social" activity you can do while sat in the same chair, in your office, on your own.

Going home

The first recipe was about commuting to work remotely. Seems fair to end with the commute home. You've probably figured out it's pretty much the reverse - just like a standard commuting day.

1. Finish up whatever is going on. Save files, commit the good stuff, Manually close the more quirky tools.
2. log out of any servers.
3. Check email and calendar for any surprise early start tomorrow.
4. Scribble a few notes and update the todo list for tomorrow.
5. Finish my tea (or gaze sadly at the already empty mug).
6. Say "bye" in IM.
7. Log out of the remote working kit.
8. I am now at home, not at work - usually by 7pm, we do flexi-time
9. Turn off the kit.
10. Stand up and leave the room.

Previous Post Next Post