Geeks in Boston

Last week I wrote about the perils of working from home. I’ve been working from home for over three years; I wasn’t trying to seal a verdict on working from home, but to recognize and explore what can make it difficult. Now I’m going to look at what makes it rewarding and worthwhile, despite those difficulties.

Most of the benefits of working from home are obvious: no commuting, no cubicle, improved control of your schedule and diet, and, hallelujah, fewer pointless meetings. Everybody sees the benefit to these things, so I won’t dwell on them here.

One slightly less obvious benefit of working from home is increasing your “concentration span.” This is the amount of time you can spend totally focused on your work– time in the zone when you’re working without interruption or distraction.

To programmers, increasing the concentration span is like widening the Panama Canal. Even a small increase can enable tremendous gains. If your concentration span is 15 minutes, you can’t even start to code anything remotely complex; at an hour, you can get some work done; at two hours, you can get deep enough to fix a fairly complex bug or implement something novel. One of the major appeals of hacking late at night is the availability of this deep focus, but if you look at a typical office, you’ll
find the opposite environment: frequent interruptions from coworkers, meetings breaking each day into tiny chunks, phones ringing, gossip in the next cube.

Here’s a hypothesis about this: if you looked at a standard cubicle-filled engineering office, and just measured what times of day each person was in their cubicle, you could identify the most critical team members simply by picking out those who tend to be at their desks when most of their coworkers
aren’t. Those are the folks who come in, find out where the build broke, and fix the bugs before the rest can come in and schedule a meeting about it.

Working from home is a way of reserving the privilege of focused concentration by default, without having to drive in at 6am or work late in the evening.* This is one major upside to reducing feedback — it gives you space to work on things without having to constantly explain or justify what you’re doing. As I wrote previously, this can be a liability– it’s way easier to veer off in an unproductive direction or miss out on useful advice– but it also makes astonishing productivity possible. If you want people to do unusually great things, you have to suspend the usual constraints from time to time.

The same reduction in feedback can also make possible a greater honesty within the team. Imagine a coworker proudly explaining a module they just wrote. About two minutes in, you realize they’re describing an amateurish implementation of Patricia trees. If you’re looking at them face-to-face in a meeting room, you might plant a quizzical expression on your face. And if they successfully ignore that expression until Q&A time, you can bet they’ll feel like idiots if you point out that they just spent all week reinventing the wheel. Most humans will see the potential for disappointment and hold back a comment that might hurt. But if you’re just a few lines into a IRC discussion, it’s natural to ask “isn't that a lot like http://en.wikipedia.org/wiki/Patricia_tree ?” and recenter the conversation on using an existing, tested implementation. After all, we all screw up and reinvent the wheel sometimes; a team that can recognize, forgive, and resolve mistakes will do better in the long run than one that fights to cover them up.

So what’s the verdict, then? There are some strong upsides but also some strong downsides to working from home, and the way they affect a person depends on that person, what kind of work they’re doing, and whom they’re working with. Personally, I like a mix– working from home most of the time, but with a day or two each week at an office or coworking space. A lot more people are facing this choice, and the variety of work spaces and styles will only continue to increase. And whether you’re starting a company or just seeking a job, it’s worth thinking about what those options mean, and realizing that your own emotions, coworkers, and job requirements aren’t always best served by the default choice.

I’ve been working from home for three years. I started in 2005, when I left a cube-farm commuter job and joined a small company based about an hour’s drive from my house. The plan was to commute in as needed, perhaps once a week, but work from home most of the time.

I had no idea, absolutely no friggin’ clue, how much it was gonna suck. My typical day went like this:

• get up
• check company IRC, say good morning, make sure nothing’s on fire yet
• lunch, maybe some scrabble or a TV show
• meeting about something. with phone muted, can watch youtube videos
• work some more, but with more interruptions
• dinner, hopefully in proximity to another human
• hack on the side project du jour
• go to sleep

This post is half of a pair of posts on working from home. I’m giving you the bad news first. Here’s the most important thing you should know:

It’s not just a matter of feeling lonely: all kinds of emotions depend on regular, face-to-face human interaction, and you run a serious risk of becoming unproductive, uninspired, and even depressed without it.

Let me reiterate: feeling lonely at work isn’t the only–or even the primary–way that working from home screws you. Well before your soul starts to scream with loneliness — which might never happen if you have family or friends you see regularly — you will suffer from being alone.

The first thing to go is probably motivation. For this you can blame a massive cut in feedback. In an office you get feedback constantly. At the coffee pot in the morning, eye contact shows interest in your latest tasks, or nods express sympathy about difficult colleagues and bosses. When you have a question about something, your coworker’s eyes and facial expressions will tell you, consciously or subconsciously, if you’re sounding smart or stupid. Chances are, you depend on this feedback more than you realize. You need it both for work-specific communication, which is easy to see, and for maintaining your self-image, esteem, and motivation–which is harder to see because the mechanisms are subconscious.

You don’t get rich feedback when communicating over a phone, email, or text chat. No facial expressions; no idea whether a persons eyes are wandering or locked on; maybe some hint of tone of voice. All this feedback is distilled and distilled away when you’re not there to pick it up in person, and this will affect you quickly and constantly if you work remotely.

You might say, ah, the hell with it, I’ll learn to live without that feedback. After all, doesn’t Paul Graham say that people with “unlimited self-generated morale” are almost guaranteed to succeed? Don’t you want to be like that?

Chances are, you could be more determined. But there are very few people — perhaps mostly sociopaths and the autistic — who can pursue a goal indefinitely without feedback. Be aware of the feedback you need, and work on making it possible. And remember that when you’re considering working from home, you’re going to tear away a lot of that feedback.

Coming soon: Why Working from Home is Wonderful.

A couple of years ago, I worked on a service that was supposed to help you chat live with other folks who were looking at websites on topics similar to yours. We were really concerned that a lot of people exchanging messages in real-time would overwhelm our servers, so we spent a lot of time developing a highly scalable back-end. I think we did a really good job of it: we used some technology that had handled similar challenges quietly and reliably for many years, and went through several informative rounds of load testing and tuning until we felt comfortable handling tens of thousands of users.

We never got tens of thousands of users. The engineering effort was a fun challenge, and quite educational, for me and my colleagues. But it turned out the product didn’t attract enough users to warrant any scalability concerns at all. There were much more elemental problems, like the way you installed it and the initial marketing work to get it off of the ground. All things we engineers earnestly hoped and believed were not our responsibility, because they didn’t feel like engineering, and weren’t amenable to our preferred methods (i.e. writing lots of good code). In other words, we were sunk by problems we never even considered.

The problem is that we’re surrounded with information that confirms the threats we recognize. There are all those competitors that flubbed it because their engineers weren’t as smart. They got themselves Techcrunched and crashed under the pressure. Or they had some great feature but made it too hard to use.

The flaw in this sample, though, is its survivorship bias. The failures we hear about represent only failures big enough to get mentioned in the news. The more common failure might be the two guys in their garage that never manage to get out of their garage. Or the group of smart engineers that spend too much time working on the problems that are amenable to good code rather than the problems that end up being important to users. Or to the people who would have been users if you had actually done something they cared about!

So, what does the canonical advice formula give us when applied to this story? I think it’s pretty simple: try to fail early. Have the courage to ignore concerns that won’t really threaten you for a few months, because there are other, more pressing things that will hit you first — you just don’t happen to know what they are. They’re probably things you just overlooked: nuances of building stuff people want, or appealing to the right audience, or hiding your best features. If you realize those failures before you’ve spent two months working on scalability, you probably have a better chance of turning things around before everyone gets demoralized.

Follow-up: some great points in the discussion on Hacker News.