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

Be an Ambassador!

You know how I keep banging on about attracting different types of people into programming?  You know how we say we need to get them young?

Typical Mathematician?

A little while back I decided to put my money where my mouth was, so I signed up to be a STEM Ambassador.  STEMNET is an organisation that aims to inspire children to go into Science, Technology, Engineering and Maths careers, and it does this by creating a network of mentors (people like you and me) and schools.  So schools can publicise the sorts of events they're running, and find mentors in an appropriate field for this event.

I was a STEM Ambassador years ago, when I worked at Ford STEMNET came there looking for people like the graduates to come and talk to kids - STEMNET likes to have a large proportion of their ambassadors close(ish) to the age of the kids, so they grab graduates working in large organisations and apprentices.  Those just starting out in their careers often think they don't have a lot to offer as mentors, but they're wrong - making that transition from education to work is a worrying thing for kids, so speaking to people who have recently done this is dead useful.

Typical Engineer?

I cheated when I was an ambassador the first time - I volunteered at my old school, where my parents were also teachers, and helped teach ICT to the boys in year 9.  It was eye-opening for me - ICT is not programming.  Tech-savvy kids were bored and the other kids didn't really know why they needed to learn Powerpoint/Word/Excel.  Personally I thought the Powerpoint lessons were useful - I was working in a large organisation where we were expected to give internal presentations, and had never been taught how to use a presentation tool, despite having various NVQs in IT that taught me all I would ever need to know about Word and Excel (these were very useful qualifications and that knowledge was relevant for many years - and no, this is not sarcasm).  But teaching kids Powerpoint when they're 13 is not useful.  By the time they get to use it their knowledge is rusty and out of date.

We were taught BASIC programming in my primary school.  And it was basic - 20 GOTO 10 stuff.  It wasn't that hard.  I mean, it wasn't for everyone, but it was fairly easy to get going, and you got the point of it - you told the computer what to do, and it did it.  I think that's what has always appealed to me about programming (insert joke here about programmers preferring computers to people because they do what they're told - if you're not a programmer, then you really don't know how much the computer can rebel against you ever damn step of the way, like a child.  A very stupid child).  I was really struck by Jason Gorman's idea that learning programming was quite a lot like learning music, and he proposed a grading system for programmers similar to that of music.  I can see the similarities between music and programming, certainly in my background - in primary school we were given introductory lessons in both music and programming as a whole class, and those who showed an interest or aptitude for either subject took up lessons at lunchtimes or evenings.  With music, that's fairly straightforward, many schools have access to at least one music teacher for the usual instruments.  For programming, this is much more difficult.  It's usually a keen teacher who's self taught leading this class.  Which is great, but many schools do not have this keen teacher.  And this keen teacher, should he or she exist, is looking for someone to learn off as well, just like the rest of us.

Typical Scientist?

We are the people the schools are looking for.  We have the experience - years of it.  We have the context for that awkward question "but when am I ever going to use this stuff?".  We can show them why it's fun.

But what's in it for us?  Well, it looks great on your CV, of course, and you'll get to network and meet with other professionals, including those in different but overlapping fields.  Kids also have really interesting approaches to problems.  It has been known for groups of children to provide novel answers to problems that have stumped professionals.  And doing something like this is really great for your confidence - if you can speak about what you do in front of a group of children, all staring at you, then speaking in meetings or conferences becomes infinitely easier.  I honestly believe that all the times I spent in a classroom helping out one or other of my parents is the reason I'm more relaxed speaking at conferences than I ever thought I would be.

Typical Technologist?

Sadly, I let my Ambassador status lapse when I got a "real" job in London, it became so much more difficult to create the time to go into a school, since clearly it needs to be during work hours.  But nearly ten years later, after talk of Devoxx4Kids and a bunch of other initiatives to get kids coding, I decided I needed at least to get my CRB (now DBS) checks done so I could work with children if the opportunity came up.  If you sign up as an ambassador, STEMNET will sort this out for you for free, which is one of the main reasons I chose to sign up with them again.

Another great thing is the induction - they're not going to let you loose with the kids without providing a bit of help and guidance.  It's only a couple of hours out of your day, and, if nothing else, gives you an opportunity to meet interesting people in other STEM jobs.  On my induction there were surprisingly few IT people (maybe 3-4).  There were various apprentices, structural engineers, dentists, ex-teachers, PhD students and... oh I've totally forgotten what everyone did, but it was interesting and sciencey.  And about half of the inductees were women, which enormously surprised me.  I couldn't help but wonder if programming is lagging well behind the other STEM jobs in terms of women doing the role, but I don't think you can draw a conclusion based on a group of people who either chose to be mentors or were pushed gently (or not so gently) in that direction.

The induction covers stuff that I've already talked about here - like why you should do this and what teachers, students and ambassadors get out of it - and some basic dos and don'ts for working with kids.  Nothing too scary, and even though I've done this before I found it useful and made me more keen to be involved.  The minimal commitment is one event a year, and this can even be something you've arranged yourself (like going into your own kids' school).  And although I've signed up for the London area, it's not necessarily geographically constrained - one of the ideas I liked the most is taking kids for a Skype tour around your office, showing where you work, how you work, etc.  I think that will help blow away some of the preconceptions around programmers anti-socially sitting in their own rooms hacking out lines of code, for example.

You'll notice the rather lovely drawings littering this post.  The first exercise we did in the induction was to draw a stereotypical scientist, technologist, engineer, and mathematician.  The point of being an ambassador is to help combat these stereotypes, giving kids real role models to look to, people who can help them see what's out there for them.

These kids don't necessarily want to be Bill Gates, Steve Jobs or Mark Zuckerberg.

Some of them want to be just like you.

My Summary of GeeCON, Krakow

Last week I was in Krakow, Poland for GeeCON.  Which was excellent!  I find it really interesting that conferences all have their own personalities, that they are not all the same.

GeeCON had its own distinct personality.  If you're a Java/JVM person based in Poland, I would highly recommend it - more than 90% of the attendees were Polish (probably the remainder were largely speakers) so this conference is very much for you.  The quality of the speakers was really good too, I learnt a lot off many of them.

From a speaker's point of view, there were some cultural things which took a bit of getting used to.  One of the good things was that the audience was very keen on asking questions, they were much more interactive than a typical London audience (for example).  However, I'm accustomed to quite short questions, and I found that the audience liked to give a lot of detail in their questions and frequently ask more than one at once - this meant that all the speakers really needed to allocate a lot more time for Q&A than expected.  One of the other things I found unusual was the number of people who would walk in and out of the room during sessions - this wasn't just everyone fleeing my session (I hope!), I saw it happen in all the talks, even the keynotes.

My stuff
On the first day I was on a panel about diversity in IT, which was basically about women programmers (again).  It was a good panel to be on, actually, because there were a range of opinions, including downright disagreement, which made for a more interesting discussion.  Sadly it left the audience with too little time to contribute though.

On the second day I was presenting "What do you mean, backwards compatibility?", which elicited a lot of responses from the audience.  I think I got the balance right between providing food for thought for any Java programmer, and enough of a look into what we're considering for the new MongoDB Java driver, that it felt like I satisfied the two audiences - those who are interested in MongoDB with Java, and those who... aren't (yet).


But it wasn't my experience as a speaker which really made GeeCON for me.  For the first time in ages I felt like I learnt something as an attendee.  I don't know if that's because a) I only had one presentation to prepare so I had time for a lot of sessions b) we have some specific problems we're trying to solve on our code right now that we're looking for answers to or c) the conference inspired it, but I came out of a lot of sessions excited about things to try.

Testing
My first take-away point is to try Spock.  I've been told for ages that I need to give it a go, but the session really sold it to me.  It seems to have features that will solve specific things we're looking at right now, including:

• Simplifying mocking
• Annotating tests with properties (e.g. @Slow)
• Running the same test with different sets of data, instead of having to copy-paste the test a bunch of times
• Reporting of failures, particularly power assert and @Unroll, make diagnosing failures much simpler.
• Using BDD terms as keywords (given/when/then) means the tests really do document themselves.

I'm totally sold on it.  I was concerned, because we're writing an open source Java library and I want the unit/integration tests to be understandable to Java developers, and I worried that adding Groovy tests might make the learning curve steeper.  But I think it's an idea worth playing with.

Asynchronous IO
So one of the things we're working on is trying to figure out the best way to provide an async Java driver.  Erik Onnen's talk around performance network programming on the JVM was really interesting.  Most usefully, it compared sync to async communication, outlining the pros and cons, and how you can do it on the JVM.

Build the right thing before you build the thing right
The first keynote was about Pretotyping - Patrick Copeland from Google was talking about ideas and innovators, and blowing away the myth that all it takes to make money is a single great idea.  He highlighted how really great ideas aren't necessarily successes, and some ideas that sound great don't feel right in practice.  Pretotyping is a way to test things like:

•  Would you use it / do it?
•  How would you interact with it?
•  Is it socially acceptable to use it in the circumstances.

Because it's very low tech, very low effort (think post-its and note pads, not HTML prototypes) it facilitates fast failure (therefore reducing the cost).

The session was videoed, so hopefully it will be available to see.  If you're thinking of An Idea, I highly recommend this talk.

Many users = anthropology, not user experience

Joel Spolksy, the man who inspired me to start this very blog (well, earlier incarnations of it) talked about the experiences of growing stack exchange.  This was interesting because it was not about the technology, but about subtle things you can do to influence user's behaviour - for example, reputation rewards "good" behaviour, and a better reputation means you are trusted to do more on the site.

This was another inspiring talk if you're interested in creating a product or company.

As always, I also met a lot of really interesting people who gave me a lot to think about.  I've come back more motivated than ever to work on my various projects.

So, Krakow is beautiful, and GeeCON is a good learning experience.  Go next year if you can!

How are you using MongoDB with Java?

So, like one of my presentations, I have a question for you.  Actually, I have more than one question for you.  I'm not going to bother with survey monkey or whatever, I want to share the answers so please, answers in the comments:

1. Are you using the Java driver for MongoDB in your application?
2. Are you using the Java driver directly, or are you using a third party library like Morphia, Spring Data, the Scala driver, your own abstraction layer, etc?
3. If you're using a third party library, why did you choose that over using the Java driver directly?
4. If you're using the Java driver directly, what do you like about it? 
5. If you're using the Java driver directly, are there any areas that give you pain?  Areas for improvement?
6. Which version of Java are you using?

Feel free to leave additional information if you have it.  And this is a public blog, so if you're really mean I'll just delete your comment.  So there.

Good overview of the NoSQL hype for Real Developers

Last Tuesday I went to a London Java Community talk which promised to debunk the hype around NoSQL.  Whether you're already bought into a NoSQL technology, or you're just wondering what all the noise is about, it's worth an hour out of your day to see Akmal Chaudhri's comprehensive summary of the technologies out there.

Skillsmatter recorded the whole thing, as usual, so you can watch the presentation for yourself.  I promise neither I nor anyone else from 10gen paid him to mention MongoDB so much.

2013 is looking a lot busier than I planned...

So, despite promising myself that I would only do one event a month for the rest of this year, looks like I'm going to be a bit busier than that.

In case you're wondering what I'm up to (or, even better, hoping to see me talk or meet me), here are my confirmed engagements:

15-17 May - GeeCon, Poland
18-20 June - GOTO Amsterdam - whole day tutorial on the new (unfinished) MongoDB Java driver.
24th June - STAC Summit, London - something MongoDB-shaped (i.e. not Java-specific)
27th June - Technology Transformation Network, London
1-5th July - In Dublin, hoping to talk to a MUG or JUG while I'm there.
22-25th July - JavaOne Shanghai (CON1148). So excited to go to China!
August - Looks like I'm going to be in Spain a couple of times (Madrid/Seville).
11-12th Sept - Love to go to JavaZone, Oslo.  We'll see.
22-26 Sept - JavaOne, San Francisco.
30th Sept - 2nd Oct - GOTO Aarhus - very pleased I can make it this year!
17-18th Oct - GOTO Berlin.
28-30th Oct - JAX London.
December - YOW Melbourne, Brisbane, Sydney - Australia.  I've never been to Oz, I can't wait!

If you've either clicked through those, or you've already been stalking my talks, you'll see I haven't actually made up my mind what to call this year's main presentation:

1. What do you mean, Backwards Compatibility?
2. Design is a process, not an artefact
3. Design is a process, not a document

This is mostly because when I signed up for some of these conferences, I thought I was going to be talking about how hard it was to write backwardly-compatible libraries (which it is).  But when I wrote the presentation, it turned out to be about software design.  And then I found out artefact/artifact can be spelt two ways, ho hum.

I'm still not sure yet if this will actually be the same (but evolving) talk under two different guises, or if they are two subtly different talks.  I guess we'll see what I end up writing the week before I'm due to present "Design is a process, not a document".