Remote work in review

I recently read two books on remote work.  Scott Berkun's Year without Pants and Remote: Office Not Required by Jason Fried and David Heinemeier Hansson.  The first book describes Scott Berkun's year as a remote manager at Automattic, which runs Wordpress.com.  The second book describes the authors' experiences at the fully distributed company 37signals, which has since renamed itself to Basecamp to reflect the importance of its flagship product.  Both books were interesting reflections on the nature of remote work in the context of their respective companies.  They were not books that addressed the nature of remote work in general, but described the approach they felt was successful within their companies. Of the two books, I would really recommend reading the Year Without Pants.  Remote isn't as compelling but it's a short read.

Some notes from "The Year without Pants" 


Communication
"To work at a remote company demanded great communication skills and everyone had them"

Culture
Chapter 4 on culture always wins is  is a fantastic read, it's available for free on his website. 

"Trust is everything". 

"1. Hire great people
 2. Set good priorities
 3. Remove distractions
 4. Stay out of the way"

In other words, treat people like grown ups and they will do good work.
 
"In every meeting in every organization around the world where bad behavior is happening, there is someone with the most power in the room who can do something about it.  What that person does shapes the culture.  If the most powerful person is silent, this signals passive acceptance of whatever is going on."

Wow, this is very significant.  If you are the most powerful person in the room, speak up and call out bad behaviour.  The people with less power are often hesitant to speak up because there may be consequences for them and they feel they lack authority.

 Hiring
"Hire self sufficient, passionate people"

I often get questions from people who don't work at home how I don't get distracted and goof off all day since I work from home.  It's simple.  I love my job.  It's a lot of fun.  I want to be shipping, not slacking.

Shipping
Shipping every day gives people a sense of accomplishment.  Many bug fixes are deployed to Wordpress.com every day. No gatekeepers to deployment but the people deploying the change are expected to watch the site after they deploy for a few hours to ensure there aren't unexpected problems.


Some notes from "Remote: Office Not Required"

Communication
The book suggests asking managers or employees to work from home a few days a week to level the playing field with respect to communications between employees who work in an office and those who are remote.   This will ensure they appreciate what hinders communication and take steps for improvement.  And it will reduce the tendency to treat remote workers as second class citizens and cut them out of essential conversations.

Culture
"...coming  into the office just means that people have to put on pants.  There is not guarantee of productivity."

"If you view those who work under you as capable adults who will push themselves to excel even when they're not breathing down their necks, they'll delight you in return"

Again, trust people and have high expectations of them and you'll be rewarded with excellence. 

Hiring
The authors note that international exposure is good as a selling point with clients.  Hiring around the world increases the talent pool available, but is not without tax or legal complications.  Also, given the degree of written communication with remote work, it's best to hire people with the language skills that can thrive in this situation.  

Productivity
The book stresses that workflow tools need to be available to all team members at all times in order to be productive. i.e. recording the state of a project in a wiki, bug tracker and recording meetings.  If a team member is working in a timezone offset from the majority of team members and doesn't have this in place, it can be a productivity drain.

 "Would-be remote workers and managers have a lot to learn from how the open source software movement has conquered the commercial giants over the past few decades. Open source is a triumph of asynchronous collaboration and communication like few the world has ever seen."

Absolutely.  I learned so much working in open source for so many years.

The authors also mention that you'll have to worry about your employees overworking, not underworking.  Because they office is physically in your home, it's easy to get sucked in at all hours to just work on one little thing that takes longer than you expect.


My thoughts on remote work
If you had asked me five years ago  if I ever thought I'd work full time from my home my answer would have been a definitive no.  But I wanted to work for Mozilla, and wasn't interested in moving to an city where they had a physical office. Here are my personal suggestions for working successfully on a remote team, given my two years of experience being a part of one:

• Work for a company with strong culture, tools and process that support remote work.  Mozilla is a great example, there are many others.  It's not optimal to be the only remote worker in a company that has no experience or culture that supports distributed collaboration.
• Get up, shower, eat breakfast and put on clothes you wouldn't be ashamed to seen in outside the house.  Despite the title of the book I reviewed above, this means wearing pants.
• I think it's helpful that I have people on my timezone that I collaborate with on regular basis.  I think I would find my job much more difficult if this was not the case.
• Do stuff to get out of the house on a regular basis - visiting friends, family or regularly scheduled activities such as sports or hobbies.  Otherwise, you will become, as Laura Thomson so eloquently put it a "lonely code hermit".  This isn't healthy.
• Talk about stuff not directly related to code with your coworkers so you have some rapport for them as people outside the context of work.
• Meet up with your team in person on a regular basis.  At Mozilla releng, we do this three or four times a year.  As much as irc, bugzilla, wikis, video conferencing and other tools are great for collaboration, there isn't anything that can substitute for talking in person.  Also, it's great for getting to know them more as people.  And when you know them as people, you are more willing to help each other and feel more cohesive as a team.
• Ship.  If you are worried that you don't appear to be productive because you aren't physically in the office, ship awesome stuff.  Then nobody cares where you're sitting and you get to have a 30 second commute.
• If you work in software, you aren't constrained by geography to determine the kind of job you can have.  If you don't want to work for the software companies that have offices in the town you live in, you have a choice to choose a better job.  Life is too short to get up every day and work at a job you don't like.   There's a lot  opportunity for those who work in many fields to work remotely.

As aside, I was supposed to be at a Mozilla work week in Portland this past week.  But I didn't fly there because I came down with a bad cold.  Despite this, I could connect to the same room the they were in and see all the talks they were giving and also give a presentation.  This was so excellent.  Since we are so used to being a distributed team, having one person remote when we were supposed to be all together wasn't a problem.  We already had the culture and tools in place to accommodate this. Thank you Mozilla releng for being such an amazing team to work with.

My idea for another book on remote work would be to have one with the format where there were about 10+ chapters, each written by an employee from a different company about how they approach it, what tools they use and so on. I think this could be a very interesting read.

I'll close with some thoughts from Scott Berkun's book on whether remote work is for everyone 

"For me,  I know that for any important relationship I'd want to be physically around that person as much as possible. If I started a rock band or a company, I'd want to share the same physical space often.  The upsides outweigh the downsides.  However, if the people I wanted to work with were only available remotely, I'm confident that we could do great work from thousands of miles away."

What do you think are the keys to successfully working as a remote employee?

Further reading
John O'Duinn's We are all Remoties Talk

Read more...

Thoughts on Making Software

My husband (aka Mr. Releng) and I were driving home from his office party in mid-December and had the following conversation.

Me:  A publicist from O'Reilly emailed me today and asked if I would like a free copy of Making Software.

MR:  Huh.  Why did they offer you a free book?

Me:  I don't know. I mentioned to one of my Eclipse colleagues on Twitter  that I thought it would be an interesting book to read.  Also, one of the editors is Greg Wilson, who's also the editor of the upcoming The Architecture of Open Source Applications.  (I contributed a chapter on Eclipse to AOSA).

MR:  Next time, mention on Twitter that you'd like a free car. What's the book about?

MR: Free car from Twitter?  Don't get your hopes up.  The book investigates the evidence that supports common software engineering practices. In medicine, a clinical trial is conducted to see if a new drug has a statistically significant effect compared to placebo or an existing treatment. The same evidence based principles can be applied to software engineering to determine if TDD or Agile methods are actually effective.  I've always thought that there was a lot of shouting but scant evidence to support different software development practices.

MR:  Yeah, undergraduate computer science is engineering.  Graduate level computer science is math.

From xkcd

As you may have guessed, I'm married to a mathematician.

In addition to being a fan of open source, I also enjoy reading about different scientific disciplines.  I love reading scienceblogs and have read many great books over the past year about evidence based medicine. So when I heard that there was a book available that examined what software engineering practices actually work, I was intrigued.

In any case, I finished reading it recently.   It was very interesting and I learned a lot!  The book is split into two sections.  The first section dealt with different research methods.  For instance,

• How to conduct a systematic literature review
• Empirical methods that can be applied to software engineering studies and why software engineering is inherently difficult to measure quantatively.
• How to decide on the papers to include in a meta-study. 

From xkcd

 
The second half of the book examines the evidence for different questions in software engineering.  For instance:

• How do you measure programmer productivity?  Are some developers really an order of magnitude more productive than their team mates?
• Does test driven development result in better software?
• What's the cost of discovering a bug early in the development cycle versus after the product has shipped?
• What working environment (cubicles/offices/open concept etc) are the most productive for software developers?
• Is there a measurable difference in software quality between open and closed source software?
• What are the reasons for the low proportion of women working in the software industry?
• Does the use of design patterns improve software quality?
• How do mine data from open source repositories for your own studies (Chapter 27 uses the Eclipse project as an example :-)

All in all, I found it a very interesting book that examined the actual empirical evidence to support or refute some of the sacred cows in software engineering. I think this this is a refreshing step forward for our profession.  If there aren't numbers to support that the way we work is effective, shouldn't we alter our path to use better methods?

Further reading
Software Carpentry: Empirical results

As an aside, some great books on evidence based medicine are
Bad Science by Ben Goldacre
Trick or Treatment by Simon Singh and Edzard Ernst
Snake Oil Science by R. Barker Bausell

Read more...

Thoughts on Being Geek

Sitting on the plane travelling to Nova Scotia for the holidays, I read Being Geek: The Software Developer's Career Handbook by Michael Lopp. I've wanted to read this for a while so I was happy to finally have some time to do so.

It was a very informative and funny book, especially for someone like me who has spent a long time working in the software and IT services industry. Some key points it covered:

• You are responsible for your career. Don't depend on your manager or HR. They are looking out for their own interests.
• The importance of mentoring and having a career plan.
• How to negotiate your salary and benefits for a new job, and how this calculation should be altered if you are looking to move to a start-up versus an established company.
• Evaluating organizational culture outside the boundaries of hierarchy.  Where is the informal power  within an organization?
•  I really liked the chapter entitled "Your People" on the art of networking and the importance of connecting with people in your community face-to-face and getting to know them better.  As I read this I thought, my people are the Eclipse family. 
• Strategies for dealing with different types of managers and co-workers.
• How to decide if you want to be a manager.
• Dealing with a crisis situation such a major bug just before the ship date.
• The downsides of working in our industry.

As an Eclipse committer, this quotation from the chapter on selecting the tools to use as a developer made me laugh.

"Yeah, I know all about the glory of integrated debugging, and I see all you Eclipse guys having a ball, but what I have found in many years of developing is that embracing fancy tools means tinkering with tools to get them to behave how you want."

-Michael Lopp, Being Geek

There's something to be said for simplicity.

My only criticism about this book is that the example software developers in the book were overwhelmingly male.  There were very few female software developers if any used to as characters in his stories. Legend has it that they do exist.  All the examples of women in the book seemed to be in product marketing or similar roles.

Anyways, if you are interested in a thought provoking book about strategies for managing your software career this is definitely a good one.

Read more...