The Handover

Yesterday I walked into the kitchen to see how lunch was going and my boyfriend handed me a knife, a part-chopped hard boiled egg and said "finish this, I need to have a shower". As you do. Apparently there were two things that needed doing - "this" needed finishing, and I needed to keep an eye on the fish.


Continue reading "The Handover"

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...

Tales from the Other Side: Confessions of an Offshore Resource

After the acquisition of a company with offices in New York, I pestered my company outrageously until they got fed up and finally relented – they agreed to send me to the US.

To ease the transition, I chose to move onto a project which would allow me to start working in London and continue on the same team after I had moved to New York.

In the extreme over-excitement that followed my relocation, it took me a little while to realise that effectively I was an offshore resource, no different really from any of our Indian test team, and the team needed to manage this appropriately.

I learnt a number of lessons whilst playing this game. Some of these points are also valid for teams with remote resources (e.g. people working from home).

The Time Zone Difference is the First Problem to Overcome
Yes, the geographical separation and remote access is important to consider, but it’s the time difference which is the killer. When your working day only (officially) overlaps for 4 hours, you have to make the most of that overlap time. Some of the steps we took to overcome this were:

  1. Moved the daily team meeting from 9.15am GMT to 4pm GMT/11am EST. Therefore I got to participate in the meeting rather than just having my instructions passed on to me. This greatly improved communication of issues between all team members, and, more importantly to me, helped me to feel like I was still a part of a team instead of just a resource.
  2. Updated the team plan so that instead of simply representing AM/PM activities for all team members, my time was staggered to better represent my working hours. E.g. Originally the plan looked like:

    But the daily meetings would invariably go something like this:

    Team Lead: Ms US Minion, it’s Monday 4pm, you must be nearly finished with task 9, right?
    Ms US Minion (Me): Dude, it’s Monday morning, I’ve barely finished checking my e-mail yet, I’ve just about glanced at the spec let alone started on the code.
    TL: Oh yeah, I forgot. Well, it’ll be done by the end of today, right?
    USM: Sure, no problem.
    TL: Right, so Bob can kick off the build before he goes home and it’ll be sweet by tomorrow morning
    USM: Oh wait, you mean the end of YOUR day? Erm, no, that’s not going to happen…

    After a number of these types of conversations we got bored of forgetting this key point and changed the plan:

    Subtle change really, but it was astonishingly useful at helping us to get our heads around when things would be delivered. If something HAD to be finished before close of business GMT, then it would be clear from the plan if that was achievable.

  3. Plan to use the overlap time to best advantage. Otherwise something that would have had you waiting for help for an hour or two has you waiting for a day. I never really got good at this, mostly because I’m used to using my mornings for catching up on mail (which was particularly cumbersome when you have nearly a whole day’s-worth of UK-based mail to get through), checking out industry news, meetings, phone-calls to the UK etc. I don’t usually get into the coding zone until after lunch. Unfortunately, by 1pm EST, most of the team is wandering off home and I’ve forgotten to ask Bob for some pointers on task 10 which I know he’s looked at before. Which means now I have to wait until tomorrow for that.

    Some of the ways I tried to overcome this problem:

    • Save non-critical or US-based e-mail replies until the afternoon. Only deal with the time-critical ones in that early-morning e-mail frenzy.
    • In your daily TODO list, clearly mark the items which require help from the team and do those in the morning, EVEN IF they’re not as “important” as the other items.
    • For items scheduled for the afternoon, take a look at them in advance, even if it’s just the morning of the same day, ensuring there aren’t dependencies on people in the UK. This is particularly vital for time-critical tasks like releases that need to go out that afternoon.

    What not to do
    Stop taking lunch. I fell into this trap to try to increase the overlap time between me and the UK. At the start of my time here I would not take lunch until the UK had gone home - it felt like using that hour, which falls at the end of the UK day, for “recreation” was a waste, it meant I only had 3 hours overlap with the team (if they all went home on time, and luckily for me they frequently did not). But, this is a dumb idea. For a start, the rest of the team frequently did not go home on time, leaving me pining round the office starving to death. I’m one of those people who a) likes to take lunch early and b) gets moody and irritable when hungry. So, for everyone’s sanity, it’s best if I take lunch. The second reason this was a poor tactical move is because I was providing second-line support for the application. So, it was all very well making myself available for the development team in the UK, but if I was away from my desk when they had all gone home, that meant the support guys who needed the development team as second-line support had no-one to turn to if I disappeared. So, all in all, not a wise course of action.

    Do Not Underestimate How Important Face to Face Contact Is
    It really is. Well, maybe it’s just me, I’m only writing about my own personal experiences here, and on top of that I am A Girl so maybe we are a different species after all. But do not neglect this facet.

    I had daily conferences with the team, I was including in all mails, we had a team chat channel and I regularly spoke, in one form or another, to the client and to the support guys. But all of that cannot replace the inadvertent wince from someone when you talk about some aspect of the system, the tension you can read in someone’s shoulders when you’re talking to them, the cheeky grin or pleading look when someone asks you to do something they know isn’t in your remit but could really use from you.

    I was fortunate, because I already personally knew all the people I had to interact with through having been on this project in the UK - it makes it a little easier to judge who they are and how they react to things. Even so, I found that getting communications without seeing the person put a strain on relationships – it’s so much harder to read a person’s intentions when you can’t see them: to excuse them for being offhand because they seem stressed; to phrase things carefully so as not to upset someone because it looks like it might be a sensitive subject. That sort of thing.

    I also found conferencing into the team meetings a little harder than being there - it’s more difficult to gauge when to add your piece to a discussion, since you can’t see people’s faces to see if they’re going to say something. You can’t catch someone’s eye to see how they feel about something. You can end up in one of two opposite situations: a) you don’t say much, because you don’t know when it’s appropriate to say something, and/or people forget to include you when you’re not there, and/or the volume is up too low on the other end for it to be obvious when you want to speak or b) you talk too much – you can’t see when people want to interrupt you or add something and/or you can just keep talking loudly and everyone else in the room has to stop and listen to you (unless they hang up on you!).

    Lack of face-to-face contact with the client pretty much ruled out doing any work that required feedback from them. This will depend upon your client, of course. In the case of this client, they were very good at responding to well-planned e-mails which asked them to choose a solution from one or more options (provided the implications were well-described). However getting to the point where you have enough information to come up with these options and their implications was almost impossible if you didn’t sit down in the same room as them and talk things through. Theoretically this could have been done over the phone, but it almost always needs diagrams and visuals, scribbling on paper and whiteboards etc., making the phone an inappropriate medium. As a consequence, as soon as I moved offshore, I was no longer involved in any but the most basic requirements gathering.

    Well, there aren’t any really. You’re not there, you can’t see people. You can, however, be aware of this situation and work around it. For example:

    1. Don’t expect an offshore resource to be able to gather complex requirements from a client.
    2. Don’t expect an offshore resource to be able to explain complex issues / potential solutions to a client. The client can ignore e-mails they don’t understand and trying to explain over the phone is difficult, and also requires finding a window that fits both schedules and both time zones.
    3. Team members in all locations need to cut each-other a little slack – try to be precise in communications so that people can’t get hold of the wrong end of the stick, and in return try not to see the worst in someone’s hastily composed e-mail / train-of-consciousness chat.
    4. Ensure a regular meeting with a more human element, e.g. conferencing into team meetings. Interacting in a group like that even if you can’t see people a) helps improve the sense of team and b) provides a bit more context and feedback than simple e-mails or chat. If you can get a video conference, even if rarely, that will help. I can have very visual thought-processes, and something I did to help the team to think of me as a person and not just a voice or a spam-bot is to take photos of me in my working environment, and to take the team on a web-cam tour of the US office. In return, they shared photos of the new office they had moved to since my relocation to the US. It was fun, and helped us to connect on a more human level.

    Communication is, unsurprisingly, the key to productive working when the team is geographically split. The processes we put into place to help enable this were:

    1. Daily team meeting for the development team, at a time when all members can participate and providing facilities for all members to participate, remotely or locally (e.g. conference call). This is not just to enable communication amongst the team, but also to help offsite resources to feel a part of the team – a little “chat time” in this meeting, rather than being all work, is fundamental for remembering we’re all human, blowing off a little steam, and generally bonding.
    2. Weekly team meeting for development team plus client plus support team, again providing a way for everyone to participate. This allows us all to swap ideas and issues regardless of where we are.
    3. Work needs to be allocated at least 24 hours in advance. This works both ways - it cannot be expected that if I’m asked to do something as the UK team goes home, they expect it complete (or even started!) by the time they get in the next day – I might need support from the team, or from other people in that time zone. Similarly, I can’t fling stuff back to the UK at the end of my working day and expect it to be worked on by the time I get in the next day, as they might have questions for me. And I personally get grumpy when woken up at 4am by a phone call.
    4. A project plan needs to be kept up-to-date and visible to all team members. This plan is better if it clearly represents the time zone differences between team members.
    5. Although ideally all team members should be treated equally, limitations of remote-working need to be considered when allocating work – any task which requires extensive support from the rest of the team or close relations with the client is probably not appropriate for someone who doesn’t work in the same location or the same hours as the team and client.

    I was lucky:

    • I had a team I knew and a client I knew on a product I was familiar with (although I had to learn a LOT more in order to support it independently during the afternoons).
    • The UK team were workaholics and generally provided more of an overlap with my working day than I think is healthy for a bunch of 20-something males.
    • The UK Team Lead went above and beyond, being accessible by phone until about midnight GMT (7pm EST). I tried not to abuse this but it definitely helped resolve pressing issues instead of having to wait another day. In return, where possible I would check my mail and chat, however briefly, when I got up so I had a quick heads-up of the state of play at mid-morning GMT, well before I got into work.

    In addition, I was a senior developer who had also had experience leading the UK team and gathering client requirements so I had a good view of the bigger picture of the project. So sometimes this meant I would irritatingly question every piece of work I was allocated and be nosy about the motivations behind something, but it also meant that I had the knowledge and ability to work pretty independently from the rest of the team. This may not apply to all offshore / remote resources.