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.

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.

We organizers have been working hard and are pleased to bring you:

BarCamp is an unConference, organized on the fly by attendees, for attendees.

There is no registration fee, but you don’t just attend a BarCamp — you can participate in discussions, demo your projects, or join into another cooperative event.

Topics may include, but are not limited to: open source software, startups, UI design, entrepreneurship, AJAX, hardware hacking, robotics, mobile computing, bioinformatics, RSS, Social Software, programming languages, and the future of technology.

More information at http://barcampboston.org/. Hope to see you there!

Writing a program is fun. Like writing an essay, the endeavor has two kinds of results: stuff that gets written down, and stuff that changes the way you think. Sometimes you’re aiming for the written product, to fulfill some external obligation. But other times, you’re aiming for enlightenment. The end product is irrelevant next to the understanding you developed in making it.

Most computer book authors wouldn’t claim to be writing about enlightenment. They’ll tell you that if you learn their language, framework, or methodology, you’ll win clients and impress coworkers. In this category there are a lot of useful introduction and reference books, along with a lot of buzzword-laden crap. But there’s another genre altogether, that doesn’t make these claims; it reflects the geek tradition of explaining interesting because they’re interesting. Looking back on experiences that really shaped my thinking as a hacker— a great algorithms course in college, a talk on “Tricks of the Perl Wizards” by Mark-Jason Dominus, Philip Greenspun’s book on web publishing— it’s clear that the most profound things I’ve learned spring from that tradition. Practical Ruby Projects is an exceptional book because it does, too.

Topher Cyll, author of the book and Cambridge resident, is a friend of mine. In college, Topher and I worked together on a community website for students as well as spending a lot of time in the same computer lab. In both roles, he was always full of clever and thoughtful ideas. Practical Ruby Projects is full of such ideas, expanded to project form and in an approachable buffet layout. The projects are indeed eclectic, from computer-generated music to gaming to genetic algorithms, but their common strand is the curiosity they all reward. If you’re one of the unusual folks who maintained this curiosity beyond school, or perhaps if you’re a professor who wants to assemble an intermediate projects course that will appeal to the most curious and passionate of students, this book is for you. With books like this and an open, curious mind, enlightenment might still be unreachable but at least you’re getting closer.

We do have small, yet vibrant Ruby community in the Boston.

We have regular monthly Boston Ruby Group meetings (every 2nd Tuesday of the month). In fact, there’s one tonight.

boston.rb has also been started recently, largely inspired by seattle.rb. The idea is that we get together on the 1st and 3rd Tuesday of the month, hack on some code for a couple of hours, and eventually produce something worthwhile.

Some of the things we’ve done at these hackfests so far:

• Made test-unit backtraces quieter
• Learned about submitting patches for rails, and hacked on rdoc
• Played with merb, datamapper, and haml
• Started an ambition adapter for sphinx

I myself only started getting involved in the past few months. It’s pretty surprising though, because I feel like I’ve grown a lot as a rubyist in just this short time, all from getting to know other locals, and learning from their ways.

If you’ve living in isolation from your Ruby community, I highly suggest you check it out. Who knows what you might learn?

Want to learn all about Google’s new mobile platform, Android? Google is running a one-day event at the Charles Hotel in Harvard Square. The event is free but registration is limited. See the blog post and registration form.

I’m happy to see even the slightest hint of freedom in mobile software, although I think the best is yet to come in Android. Sure, they can have a nice Java application SDK, but in a world where most important apps are web apps, mobile phone programming will always be a second priority. Why not focus instead on building a really kickass mobile web browser, with something like Google Gears integrated in order to allow connectionless operation?

Maybe I’ll go and ask that question in person.

I got an email today from the PR rep for another YCombinator clone, based in Philadelphia:

DreamIt Ventures is a new pre-seed venture firm launched last week by three Philadephia-area tech entrepreneurs. DreamIt basically takes the Y Combinator approach to funding with the noted difference of providing the entrepreneurs (if they choose) with strategists to help run their new businesses. [press release; discussion on hacker news]

Boston-and-Silicon Valley-based YCombinator pioneered the “buncha dudes make a company over the summer” approach to funding, and as far as one can tell from outside, they’re doing pretty well. They’ve got Paul Graham’s recruiting cachet, plenty of industry connections, and a few years of experience. The clones (Techstars in Boulder, CO; SeedCamp in Europe; LaunchBox in DC; and now DreamIt in Philly) throw in a few variations, touting their own strategists or connections. The ones that advertise teaming with the local lawyers start to scare me — the last thing most 3-month-old companies need is a business prevention department.

But let’s put aside the pursuit of innovation here. Regular VCs don’t try to compete by developing innovative ways to invest; they compete for capital and deal flow and try to pick winning investments. YC may be famous but, with only 25-35 investments a year, must be turning down some good candidates. Can’t our clones fund the best of the rest and do almost as well?

Maybe. Venture investments are very risky; people often guess that 10% perform well and 90% tank. If all the founders apply to YC first, and if YC has a very good nose, they could cherry-pick virtually all of the promising investments before the clones ever get a chance.

On the other hand, seed investments aren’t a sophisticated nation-wide market. If an investor knows a kid who’s got some energy and brains, a little motivational nudge can turn that geek into a business. Getting better connected in schools and companies, especially around a specific industry or in an underserved locale, can probably help a lot.

On the other other hand, though, lowering barriers doesn’t always serve the investor well. Aren’t people who’re willing to move to Silicon Valley more likely to work hard and sacrifice for the business? I mean, we’re talking about an environment useful for running computer companies and playing frisbee, but virtually nothing else (maybe In-N-Out Burger). What about the “strategists” that DreamIt plans to offer? Who’s a better founder: one who will learn accounting so he can understand all parts of his business, or one who thinks an outsider with some stock and a salary can handle that “while I focus on the big picture”? A friendlier investor may be inviting more extra losers than winners. Perhaps the goal should be to tear down social barriers (risk stigma, family expectations, getting taken seriously in deals) while preserving barriers that test competence and perseverance.

In any case, it’s great to see this kind of venture firm growing. Despite the competition, Paul Graham et al. must feel at least a little vindicated to see their hack so widely duplicated. But some–perhaps most–of these firms are bound to fail. How many can succeed? What will the next round of successful “summer-stage” firms look like?

A recent post on Hacker News asks about this question on YCombinator’s just-opened application for their Summer 2008 seed funding round in Boston:

Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.

That’s just a fun discussion question, with a few good stories in the responses. My answer, still kinda computer-related, is that time in high school that my friends and I built a computer lab so we could study Computer Science AP. (Although my treadmill desk and simulation of a door using a paperclip also came to mind.)

What’s yours?