This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!

Adjusting to Working Remotely

One of the most obvious differences I faced when I moved from LMAX to 10gen were the working conditions. I don't mean like being deep underground in some dangerous situation vs being pampered by beautiful slave boys and girls. What I mean is that the working practices at one company necessitated being in the office for core hours, and at the other flexible hours and remote-working are practically mandatory.

At at LMAX we pair-programmed most days, and that meant that being co-located: being in the same office, at the same computer, was pretty important. We could work from home when needed, but pairing is pretty tricky when you’re in a different room.

The drivers' team at 10gen, on the other hand, is a very distributed team. Sure, I'm based in London, and we have an office here. But my main Java "pair" is in Boston, working from his home office. The other driver developers are distributed around the New York, Palo Alto and London offices, with many other working from home in locations like Barcelona, Atlanta, Texas.

And although I like coming in to the London office - because there I feel part of the company, and get to hear what other people are up to - it's really not that important to the day job. There are only 3 developers based in London, and I'm the only Java dev. I started working from home a lot more when I figured I could use those 2 hours of commuting for extra coding time.

I've worked remotely before - I was basically the offshore resource for my team when I worked in New York - I could do out-of-hours releases and support. This was... not the most happy time of my existence as a developer. Moving to a new city, choosing to live alone, and working from home most days of the week would be suboptimal for many people. So in the early days of working here I went to the office by default to postpone the inevitable insanity (insert joke here about my current sanity levels). However, as time has gone on, I've spent more and more time working from home: I get more done, the environment is quieter, and because I actually live with two Java developers, I sometimes have more technical help at home than in the physical office.

But I constantly struggle with the feeling that I'm not productive, that I'm not doing enough. The thing with pairing is you're forced to sit down and code. Not check Facebook, not read your e-mail, not chat to your mates. Code. And when you're stuck, you've got someone to talk to about it. And when you have two or more routes that you think might work, you can decide between you which to take. And if it takes longer than you expected, there are two of you defending that. I am totally sold on the value of pairing for productivity, in terms of number of quality features delivered.

But. The benefits to me as an individual of being able to work from home, wherever that home may be, are enormous. And because of this, a company that embraces this policy can attract all kinds of talent that they would miss if they demanded even as little as one day a week in the office - this limitation still requires your developers to live within commuting distance. And if you have a distributed team, your all-star team of developers, who may not be located in population density cities, might not require all-star developer salaries. Imagine if you can attract the best talent from all over the world without breaking the bank. All because you give them what they really want - freedom.

As they say, with great power comes great responsibility. It was a shock to the system to have this level of autonomy. I've worked in various types of company over the 15 years people have paid me to develop code, but nothing prepared me for this. Sure, you have deadlines, and features, and tasks, and bugs, and support cases. But you also have talks to prepare and blogs to write and tutorials to create and demo applications to code... in fact, there's so much to do it's overwhelming. Being trusted to prioritise accordingly, and to ask for help appropriately, is a real switch from having a prioritised backlog of stories and burndown charts to guilt you into finishing off this story and moving onto the next.

Far from skiving off from work when I'm out of the office, I feel more internal pressure to Do A Good Job, to Justify My Existence. When people aren't counting bums on seats, they must surely be measuring you some other way, right? And actually, far from slacking off, one of the big problems with working from home is that you’re constantly on, and drawing a line between work and life is mandatory. I really liked this post as a description of what people have to do in order to be effective working from home.

At this point I should probably clear up some common misconceptions:
  • Working remotely != working from home. Co-working spaces are popping up all over the place these days, some with perks like free coffee and snacks, usually with lockers to keep your stuff in, and meeting rooms so you don’t have to meet customers or interview people in a coffee shop or shared space. I visited workINcompany in Seville last time I was there, and I loved it as a space to create, and get stuff done. Or you could work in a coffee shop or other establishment (I used to sit in pubs to blog, you’ll not be at all surprised to learn), or maybe you’ll borrow desk space at a friendly company. 
  • Remote working != distributed team. Quite a few companies will allow people to work from home (or wherever) one or more days a week, but this still requires them to be able to get into the office regularly, and therefore be within commuting distance. This article talks about the difference. 
As ever, the answer to whether you or your company should embrace distributed working will be “it depends”. I shall attempt to enumerate some of the pros and cons, and I’d love it if other people could share their experiences:

For the Individual (i.e. you): benefits of being in the office
  • The quick pint after work - this is how you really get to know your colleagues, and hear the really interesting stuff. 
  • Overheard conversations that turn out to be relevant to you or what you’re working on. 
  • Feeling like part of the company. 
  • Free food! Free drink! Birthday cake! (Mileage may vary, depending on your company)
  • ...and the company is paying the heating and electricity 
  • Better desk/computer/monitor(s)/chair/set up (although It Depends, of course). 
For the Individual: downsides of being in the office
  • (In many offices) distracting and/or noisy. This does depend though - in a pair programming environment, there’s always a lot of talking, but it was never the same level of distraction as sales guys on the phone right next to you. 
  • Time to commute. 
  • Feel split - half your life is in the office, half of it is at home. 
For the Individual: benefits of being at home
  • (For some) quiet 
  • Or: you can actually listen to music without headphones - yay! 
  • The flexibility to do stuff that needs doing at home or in your personal life (I can’t believe how many places are still only open 9am-5pm) without compromising your work. 
  • You can squeeze gym/exercise into your day in the way that works best for you. This depends, of course - if you’re working with people on the same time zone with the same hours, there’s less flexibility. But the lack of commute generally gives you a bit more time. And you can go when you’re blocked, or when you’ve got an hour’s slot between two video conferences that you wouldn’t use for anything else. 
  • Which leads to: (possibly) flexible hours - in my case, I’m based in Europe but working closely with the east coast, so I could probably work any 8 hours between 8am and 11pm UK time. 
  • Your own choice of desk/chair/computer/set up - in New York my home office was much more comfortable and productive than the hot-desk in the office 
  • Change where you work - I’m writing this on the sofa, because I wanted to be in a more comfortable and creative place for blogging than my desk, which is associated with coding. 
  • More freedom to play and explore the code or new ideas, although this is less about being distributed and more about not pairing every day. Although this could be good for innovation, it's arguably less good for writing actual useful lines of code. So this benefit will depend on what your company needs from you 
  • I love being able to cook in my kitchen. I don’t have to grab a sandwich from Pret or whatever, I can have Real Food. And it costs me less. 
For the company: benefits of a distributed team:
  • In theory, being distributed means a company can hire anyone, anywhere. Which means a) you can get really good quality developers - maybe they're not as effective as they would be if they paired in an agile environment, but if there really is a 5-10x improvement for a good developer vs an OK one, you're still getting a net gain and b) if you are lucky enough to hire people outside of places like NY, London, and Silicon Valley, you can cut costs because you're paying your really good developers a very good local salary instead of a silly one that pays for silly rents and silly commuting charges. 
For the Individual: downsides of being at home
  • Can be MORE distracting - chat, email, errands, babies, dogs, flatmates, XBox. 
  • Difficult to distance yourself from work - there’s the temptation to be always on, to just finish this or just do that. 
  • You need a good space to work, you can’t sit on the sofa or your bed all day, and not everyone has that spare room or spare space. 
For the Individual: downsides of being in a distributed team:
  • I suspect I'm less productive than I was when I worked onsite, pairing, in an agile team. By productive, I mean lines-of-code-that-go-into-production. Not having people there to help you resolve your internal arguments can result in flip-flapping and going down design dead ends. Mind you, I do a lot more stuff than just coding these days, so this might be a result of that, and of not pairing, rather than being in a distributed team. 
  • I reckon it's taken me a lot longer to get up to speed on the code, on the product, on our processes. I can ask people when I'm in the office, and of course there’s chat, but nothing beats pairing for getting up to speed extremely quickly. 
  • Time zone differences - waiting for answers is frustrating for the impatient. Like me. 
  • Text based communication - quite tricky to get the right tone and not inadvertently wind people up 
  • Email. OMGTHEEMAILS!!! When I was in a company that paired every day, we didn’t really use e-mail. We didn’t have time to read them, let alone write them. We got up and spoke to the person. But a distributed team is very e-mail heavy, and I constantly feel like I'm drowning in mail. 
  • More meetings - because you can't just grab people and work ad-hoc, because you can’t have a daily standup in the office, and because it's important to keep people up to date on what you're working on, you have loads more meetings or scheduled updates. I have regular meetings almost every day, and I don’t mean standups. These are necessary because we don’t all sit together and hear what’s going on, but having several hours a week devoted to video conferences is a big change to a place that limited meetings to once a fortnight. 
  • No quick-pint-after-work. Not that I’m an alcoholic. 
So stuff that really works for me/us as a distributed team:
  • Chat/IRC. Indispensable. 
  • E-mail for longer, searchable, async communication. Since our team is spread over Europe and the States (and at some point soon I’m sure we’ll include other continents) you have to remember that not everyone is online at the same time as you. If you have a bright idea at 9 in the morning in UK-time, it needs to be in the inbox of your colleagues in Palo Alto so they can read it when they start work. 
  • Google hangout has made it significantly easier to pop into a video conference whenever you need. Also laptops with built in mics and videos make this easier too, something I didn’t have back in 2008. 
  • Trello and Jira, although I still get so much spam from both I tend to ignore all notifications 
  • Regular face to face meetings. I get to go to New York (yay!) to meet with other developers on a fairly regular basis. And this is really key, face to face is still dead important to humans who haven’t actually evolved as fast as technology has 
  • Driver days / company kick off - department- and company-wide get-togethers to get to know each other and feel part of something. 
Still needed:
  • Good remote-pairing tools 
  • Good tools for code review. As a reviewer, I don’t want to view a patch set with side-by-side differences, I want to be able to see it in an IDE, to navigate it, *and* make comments or changes that the reviewee can see. As a reviewee, I want it to be as easy as “submit this commit / set of commits for code review”. 
  • Some sort of good shared whiteboard. I hate not being able to stand up with my pair and whiteboard ideas. 
I enjoy the freedom of being in a distributed team and working from home, but I actually struggle quite a lot with the autonomy. It's not that I can't motivate myself, if anything it's the exact opposite - while I'm away from the office, away from people who can see I'm working, I feel the need to constantly prove I'm working. In the office, if your computer or network or software starts freaking out and you spend a whole day fixing these problems, by the time you go home in the evening you feel frustrated you didn't get any work done, but you don't feel guilty. If your internet dies at home, or you spend the whole day researching the exact git command you need, or your laptop just freaks out for the day, you feel like you should make up all those lost hours and still do your 8 hours of productive coding (or whatever you were supposed to be doing).

Or maybe that's just me.

I remember when I first started working as an undergraduate at Ford, the idea of being forced to sit in front of a computer from 9-5 was horrifying. And really hard too - you couldn't just get up and take an hour to let things filter through your brain, you had to be seen to be working, sitting at your desk. And in these days of internet, sitting at a computer is almost a guarantee you're NOT working. Going for a run or drinking coffee in the kitchen and scribbling, or even simply thinking, might be more productive.

The point is that it's different working remotely. And if you've been working in industry for a while, the idea of being self-determined takes a bit of getting used to, whether it's because you need to learn how to motivate yourself, or because you need to learn to switch off.


I was chatting to Joel Spolsky at GeeCON (*clang* gratuitous name drop) and he said Fog Creek and Stack Exchange have distributed teams. Other than them, us, and Lullabot (the company whose blog I pointed at), I don’t know of many places that really embrace distributed working. If you have stories to tell, I’d love to hear them.


PS We are looking to hire more Java people, as well as a host of others...

Comments

  1. Really loved this post. I am the Chief Architect of my company (and a woman... gasp!) and I work remotely. The company is based in NYC and I work from my farm in New Hampshire. I resonated with all of your pro points. I have a quiet, comfortable office, much better computer rigs than my company would normally provide, the flexibility to attend to the farm during lunch, etc. I also agree with the cons. It's hard to turn it off. I actually work MORE hours now than I did when I had an in-office job. I miss a lot of the casual conversation so I don't always know when a dev is confused or struggling until they reach out to me. I try to check in with them once a day, even if just on chat.

    I am the only remote worker in the developer department (aside from our colocated offshore team). It works for us, but I do travel to NYC every few weeks for face time with the boss and to do presentations, brown bags, or in depth design sessions. I also lament the absence of a really good shared whiteboard. We use WebEx and I end up drawing a lot with a shared power point. Shameful. Code reviews are live and over web ex with a walk through the IDE and a demo of working code. I find chat, video, email and phone to be key and I don't think being remote has made my career suffer any. I do miss the pint though, but I try to go out with the team when I am in the city.

    I saw one of your presentations at JavaOne last year. Keep fighting the good fight. Great to see your success!

    ReplyDelete
    Replies
    1. Thank you!

      It must be harder being the only remote person, it's easy for those in the office to not realise you've missed all the conversations. Although being in a position of responsibility means that it must be harder for them to forget about you!

      I think shared code reviews are a great idea. We've been trialling a weekly show-and-tell of the code using screenshare in Google hangout, I much prefer this to a static code review. It's even better if you can follow along in your own IDE so you can go and explore rather than just being shown the good stuff.

      Great to hear about your experiences, thank you!

      Delete
  2. We at SoftwareMill ( http://SoftwareMill.com ) are fully distributed company with 21 people (17 devs) working from their homes or co-working offices. We use Skype for txt and TeamSpeak for ad-hoc voice communication. Once a day we have a company standup meeting with video (using self-hosted BigBlueButton). Once a month we organize a face to face meeting day when we socialize, discuss, do company retrospectives, etc. It really helps to build bonds between people and as a result later when we work from homes, communication is much easier.
    If you have any questions w.r.t remote work, I think we could share some insights :)

    ReplyDelete
    Replies
    1. Thanks!

      You're all in the same country, aren't you? I think it helps when you don't have to worry about different time zones. We really only have one time that we can do department-wide meetings, and that's 5pm UK time (midday in New York, 9am in California), we can't do company-wide meetings sadly because we have Australia to think about as well.

      I've used TeamSpeak before for gaming, it never occurred to me to use it for remote working, thanks!

      Delete
    2. Yes we're all in PL, but we have clients from all over the world so a project team has to worry about timezones, but if we want to chat "in-company-things" we have the timezones issue sorted out auto-magically. :-)

      Coming back to the post - best writeup about remote/distributed teams I've seen, Trisha! I can't agree more with it - and a huge +1 for not leaving out the psychological effects, like sometimes feeling "guilty" - you're not alone on this one, for example ;-)

      Delete
    3. Thanks Konrad, I appreciate the feedback!

      Delete
  3. I believe that GitHub are setup to embrace distributed working and it looks like it's worked out well for them: http://zachholman.com/posts/scaling-github-employees/

    Being one remote worker in a company that's not well setup for it can be pretty challenging, although the right people will always be able to make it work: http://www.hanselman.com/blog/BeingARemoteWorkerSucksLongLiveTheRemoteWorker.aspx

    Anyhoo..

    Regarding tools, we use git / email heavily for code review, a simple commit hook on a central repo sends an email (and a patch attachment) out to a team code-review mailing list every time a commit goes into a small, possibly work in progress, feature branch.

    It's cheap just to open the attachment and get a sense of what's going on, and what people are thinking (even at early stages) from the changes/diffstat, if you want to have a proper poke a around, just fetch/checkout the branch and hack on it, re-push. You can use the email (yes, yet more email -- you've got to get filters going for this!!) as a starting point to have the conversation. The downside is that the whole team is connected to the firehose (and it's email), but works well when you're trying to build consensus early across lots of timezones.

    Once everyone agrees it makes sense/works, there's an agreement over chat/email that it should be merged on to master/trunk/the mainline.

    Everyone is pushing to the central repo all the time, but it needs buy-in from everyone who cares to get something onto the master.

    Regarding pairing, I've found that VNC works well, it's lightweight and easy for both of you to hack on the codebase at the same time.


    ReplyDelete
    Replies
    1. Doesn't that get very noisy, seeing all the commits everyone's making? And/or doesn't that encourage people to only check in when they've done something interesting, rather than checking in frequently? Just interested in how this works, because I think I'd benefit from greater visibility of code changes.

      Delete
    2. Yes, it's very noisy -- it's like a firehose of all the stuff that people are doing. It reminds me a bit of Twitter. Sometimes I can keep up, sometimes it's too much and I miss a few days, but the machine rumbles on. For us we get 20-40 commits a day into this.

      People still have their stuff they need to get done, and our team rules say that they need to a code review before it goes in. Code reviews are much easier to do on smaller changes, 2 weeks worth of changes hacking the underbelly of the codebase are always going to be hard to get in. Push early, push often means that people can comment early, even on early half-baked ideas.

      The downside is that it can be awkward to keep up to date with what people are up to this way, so you just filter everything out and never check until someone pings you for a code review -- you effectively elect to stay out of steering where the codebase is going and just get your stuff done. But, if you want to get involved, you can, really early on, before there are 4 weeks of fully tested work that's much harder to challenge without upsetting people.

      Delete
  4. We also do distributed working at https://sgrouples.com/ but we are much closer to: "Remote working != distributed" team because most of our team is located in the same city. We have office that is optional so if you prefer to work from there you can. We can do meetings and brain storming when needed as needed. Its really cool it would be very hard for me to switch now. I can be at important times with my family without having to tell excuses and just working out another time. It really helps with work/life balance you can work hard and also have fun. I can work from virtually any place that has decent internet.

    ReplyDelete
    Replies
    1. I think the ability to slot work around family and to work from anywhere is one of the biggest advantages to remote working. I'm not sure I could switch back either.

      Delete
  5. Hey Trish,

    I transitioned to working from home full time a couple of months ago, and really enjoying it. Our company has one co-located office in London, one in Boston, and a handful of distributed developers (Scotland, France, Bristol). For me, timezone difference has been the real barrier, not distance. Even with distributed developers, we aim for pair programming as much as possible (working alone is the exception, most days I pair).

    Google Hangouts have improved leaps and bounds, and with persistent hangouts, you become familiar with which link to go to for team meetings, or if someone in the office wants to join your pairing session. Then there's the usual suspects of IRC/Email/company microblogging like Yammer for other communications.

    Before we moved to Scala, we had a really sweet remote pairing setup. A plugin for Eclipse called Saros, which is like Google Docs for your code, in your IDE. Screensharing is a poor replacement once you're used to Saros. But since Eclipse for Scala sucks, and IntelliJ has no viable alternative to Saros, we're struggling a bit with this again. This kind of highlights how beholden you are to your tools when you're distributed, and the strain it can put on co-located developers who have to accommodate you (I pretty much force them into using Eclipse when pairing, though they prefer IntelliJ).

    2 months so far, and really enjoying working from a place where I can lie down on my own bed for 10 minutes between meetings, or go fuss my dog while I grab a coffee.

    Really enjoyed the post, hope you're well!

    Graham Allan

    ReplyDelete
    Replies
    1. Hi Graham,

      I remember seeing your presentation at the LJC Open Conference about pairing tools. I was really impressed with the Eclipse plugin, but we just can't bring ourselves to switch from IntelliJ. Someone really needs to work on an IntelliJ one!

      Thanks for the feedback, glad you enjoyed it.

      Delete
  6. Hi Trish,

    Very good points. I can absolutely relate to the loss of constant communication that comes from not working in the office, I have even exchanged ideas while facing the wall in the toilet! (and I'm sure most male readers have, although they may not want to admit it). In fact I think the topic is much more deeper than just a matter of pros and cons or hiring opportunities.

    Over the last few years there has been a lot of hype about agile methodologies, all the cool kids want to say they are agile (I touched upon that in this post of mine, but that's a different topic). What I think we don't realise about being agile is that its constant push for information sharing, communication and inter-relations are very good for extroverts, but not so much for introverts.

    As I learnt by watching a TED talk by Susan Cain about The power of introverts, the work environment tendency of the last years (decades?) discriminates introverts in favour of extroverts. Some people thrive in isolation, so by forcing them to be constantly talking to someone else (like pair programming) we're actually make them less effective.

    From my perspective, the whole idea of working from home may not be a question of not decreasing productivity, but increasing it.

    ReplyDelete
    Replies
    1. That's a very interesting point. It's something I had considered, because I remember Joel Spolksy saying for many years that giving every developer a private office will make them more productive (http://www.joelonsoftware.com/items/2008/12/29.html). But from personal experience, I'm pretty sure I was more productive in terms of lines of good quality code delivered when I paired - I asked for help sooner, I had someone to check for errors sooner, and I learnt a lot of those I paired from, making me a better, more productive, developer.

      The other point that I think is interesting is that agile and things like pairing are the sort of tools that are going to change the make-up of people attracted to a development role. I've said before that I think the stereotype of developers being locked in a room communing with the computer is what makes it an unattractive role for many people, when in fact this is generally not how people work these days. I would hate for remote working to be the thing that reinforces this stereotype. Especially as remote working requires better communication skills - disappearing for weeks at a time to hack out hundreds of lines of code is not going to be a productive thing for the team, if they don't know what you're working on and don't necessarily like it when they see it.

      I guess what I'm trying to say is that I think it's a good thing that modern work environments favour extroverts over introverts in order to balance out the fact that stereotypes of us suggest we're all introverted.

      But I do take your point that for those who are introverted, or people who can't handle constance distractions (most of us) being away from the office could indeed improve productivity.

      Delete
  7. Thanks for the blog post. I've been working from home since December 2012. I had been a government contractor in my small country for 16 years and got tired and bored. I got an offer from a small development shop in Chicago to work remotely and decided to jump in. I have to say that it is a little scary. Having a steady job and deciding to take a consultancy role remotely for a company in a different country is not an easy decision.

    I feel a constant pressure to always be productive. Maybe because I'm the only one working remotely. Maybe because I'm the only foreigner in the team. So when I hit a bump in the road, maybe I'm burned out, maybe I'm stuck, maybe I'm blocked by some other feature, it stresses me out; because I feel as if I'm slacking off and I can't justify my part in the team.

    Having said that, there are also the benefits, that you mentioned. More free time for myself. No need to commute so I can walk the dogs in the morning and not have to be rushing to get ready to go to work. I'm learning to switch off after 5 because it is easy to just work all day until I get tired and then go straight to bed. I can also decided to take a siesta when I'm tired. It helps to just take a break after lunch for an hour. I get back to my desk feeling recharged.

    Thanks for the blog post again. It helps those of us that are new to this.

    ReplyDelete
    Replies
    1. It's interesting, I think feelings of guilt are the most common. It sounds like you're starting to get the hang of it, good luck and thanks for the comments!

      Delete

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: How do I read from the ring buffer?