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.
I’ve now been freelancing long enough that I can talk about some of the things I’ve learned from it. And without a doubt, the biggest thing I’ve learned is the link between effort and reward.
In a normal job, this link is pretty nebulous. You can work for two hours, catch up on some blogs or TV, and run some errands, but if you manage to say one or two clever things in front of your boss that day you will probably remain employed.
If you’re in the top 10% smartest workers, an average of two or three hours of work a day is probably enough to exceed the productivity of almost all your coworkers, and not only keep you employed but keep your bosses somewhat impressed. You can earn a comfortable living this way, and have a more relaxed lifestyle than just about anyone who’s not retired. But you will not be challenged.
Billable Hours
Freelancers usually bill by the hour. An hour of hacking on the project is billable. An hour of reading blogs about technologies you might consider using in the project a few months from now is not billable. An hour spent at the grocery store at mid-day is not billable. Even twenty minutes spent “resting” in the “restroom” is not billable.
You might not believe me unless you measure, but I think an average workday for most computer programmers involves about 3 billable hours of work. Furthermore, there is great variance in the amount of billable time you’ll get each day over a week or two. Some days you’ll rack up 6 or 7 billable hours, maybe even 9 if there’s a release coming up and you’re loading up on coffee. But you’ll easily revert back to a low average with a day of zero billable hours.
I found this out when I started noticing that on a low-energy, mediocre day of freelancing, when I felt I had basically been at work all day, I’d often end up with as little as half an hour of billable time.
Half an hour. I don’t think I’ve ever been exceptionally stupid or exceptionally lazy, but I do tend to procrastinate, and by golly, I’m good at procrastinating. I am so effective at delaying work that I didn’t even realize how effective I was, until I thought about how much money I made on one of these days and realized that it wouldn’t even cover my rent for the day. Let alone ramen noodles.
The billable hour is, to me, a matter of professional ethics. I don’t assume that a workday consists of eight billable hours, and just parcel up whatever I did that day into those buckets. I consider time billable when I’m actively creating value directly for the client. I’m sorry that sounds nauseatingly corporate, but it’s the best I could come up with.
So getting more billable hours, i.e. making more money, is not a matter of being clever or knowing some trick. It’s a matter of stamina.
Programmer Endurance Training
Once you start to see your monthly paycheck as an endurance challenge, a few things change. You start to value consistency more, and brilliant ideas less.
That was kind of hard to write. Putting it that way seems to hide the intellectual challenge of making software, as if it’s just a matter of putting in the time and following a plan, like painting a house. What if I just become a thoughtless code factory, like some sort of pathetic outsourced ASP.NET programmer who just wishes he could charge by the line of code?
That hasn’t happened yet. Instead, I’m awakening to the patterns of lies I used to tell myself about the quality of my output. I know I can’t reach perfect consistency: sometimes I’ll have awesome days when I get a zillion things done in six hours, and other days I’ll only be able to crawl along for four hours of work before some welcome distraction proves irresistible.
On the other hand, I’m now acutely aware of when something I’m doing doesn’t qualify as work. I have a good idea of how many billable hours I can work daily without burning myself out. And this way of thinking and planning is useful not only for doing the work that pays my bills, but for any work I care about.
And so, after a few months of freelancing, I know that I have learned to work much, much harder than I ever did back when I had a salaried job. And I can work that hard for a client, or for myself, or a bit of each.
Really, I can hardly believe how lazy I was.
Full Entries RSS