I left my newspaper job in 2007, in part because I wanted to go on a three-week trip.

There was no way to accommodate my being out of the office that long — working remotely was so completely out of the question that the possibility was never even mentioned — so I gave my notice, and the paper lost a valued (I think!) employee.

This year, when I told my boss I was thinking about going to Europe for the summer, his response was something to the effect of “oh, cool. Have fun.”

When you’re already an offsite employee (my house is about 1,000 miles from the Chicago office), for a company that extols the benefits of a remote team, it doesn’t much matter where you’re working from. I took advantage of that flexibility and spent my summer working from Scotland, England, France, and Ireland.

For 37signals, the main advantage of a remote workforce is the ability to attract and hire the best people, no matter where they live. But for me, remote work is a major employment benefit. More than a 401k, more than a health care plan — the fact I no longer have to save up vacation time to take one or two short trips a year is huge. I don’t have to wait until someone gets married or dies before I can go see my family — I can just go see them, and work while I’m there. If my girlfriends are going to Mexico for a week but we’re slammed in customer support, I don’t have to choose between letting down my pals or letting down my team. Gone are the days of spending precious PTO on obligatory holiday travel, resenting how I’ve still never seen Vietnam.

I mostly stayed with AirBnB hosts, anywhere from a few days to a few weeks at a time. Since all I need for my work is my computer and a reliable Internet connection, I just made sure before I booked each place that I’d be able to get online.

Sure, there were snags. If I did it again, I’d want to be more on top of the schedule, more available by phone, and more certain of an always-reliable Internet connection. I felt guilty toward my team and our customers whenever issues along those lines arose. My next computer will likely be an Air — the MacBook Pro is great, but probably packs more oomph than I need, and it’s a bit of a beast to lug around. And I’ll likely be more mentally prepared to work different hours from the rest of my team. Euro hours are quieter and I could get a lot done, but they’re also kind of lonely when you’re used to hanging out in Campfire with your work buddies all day. Of course, now that we’ve hired a few folks overseas, that may be a moot point.

Overall, though, I found my work was highly portable. I could always get what I needed, and my team and my company were super-supportive. I had an amazing time, and felt beyond lucky to work for a company that lets me — encourages me, even — to live a life like this.

To help expand support hours and keep an eye on Will, we hired a few fellows from Manchester, UK to join the support team at 37signals. They’re not invading, but they do work whilst the US-based team slumbers.
You might have already noticed Jim Mackenzie’s picture on Smiley, because he joined us this past July, when we first advertised for a GMT-based support position. He impressed us with his application and has been an excellent addition to the team. He’s been a great help to us as we’ve been expanding our support hours.
Jim gave us such a favorable impression of Manchester that we had no qualms about picking another Mancunian when we went looking for a second European support teamer. Chris Joyce started a few weeks ago, and he’s been a great fit. He has a similar background to Jim and sent us a super application and writing samples. Chris has spent the past two weeks training in Chicago with the team and is already doing a cracking job.
Please help us welcome Jim Mackenzie and Chris Joyce to the team!

When the geography of labour ceases to be an important part of production, attempts to keep foreign workers out of a country become counterproductive. Workers who stay remote will be subject to remote expenses. If those are lower, it’s harder to compete.

Say the cost of living in San Francisco is 100 and the cost of living in Prague is 50. You can thus pay a remote worker living in the latter city 70 and he will have as much disposable income as a local worker in the former earning 120 (both will have 20 in disposable income).

This is much lower than importing labour to San Francisco and “underpaying” them. Say you do that and only pay them a disposable sum of 10. Your labour cost is thus still 110. Not much of a comparable saving to that of going remote.

So if you’re a local worker, would you rather compete against imported labour that undercuts your rate by 10 or a remote worker that undercuts it by 50? That depends on the efficiency of that remote worker, of course. If being remote means they can only do half as good a job, no problem. If they do 90% as good of a job, big problem.

Another angle: What if you pay both the local and the remote workers the same, say, 120? In Prague, that would mean you can attract the same quality of talent that it would cost you 170 to attract in San Francisco (holding all other things equal, for the sake of argument).

As the world gets better at remote collaboration, this is only going to get worse—or better, depending on your perspective. Up until recent history, protectionists have been able to claim that having someone in a remote location is simply too inefficient. So the argument could stay about the process. (Pair programming and other co-location techniques are great fodder for these kinds of arguments).

When the process becomes a minor issue, it’ll have to become about the people, if you want to stay a protectionist. That is the claims will have to be about how the remote workers are worse workers. Not as smart, not as easy to talk to, not as proficient. I reckon those arguments are not going to have a long term future.

Likewise, I reckon that fighting to keep local supply of skilled labour down in areas of work that can be done remotely also does not have a long term future.

Twitter started out life as a wonderfully inclusive society. There were very few rules and the ones there were the people loved. Thou shall be brief, retweet to respect. Under this constrained freedom, Twitter prospered and grew rapidly for the joy of all.

Budding entrepreneurs built apps that made life better for everyone. Better, in fact, than many of Twitter’s own attempts. They competed for attention on a level playing field and the very best rose to the top. Users saw that this was good and rewarded Twitter with their attention. Twitter grew.

Unfortunately this inclusive world was not meant to last. From the beginning, an extractive time bomb was ticking. One billion dollars worth of eagerness for return. Hundreds and hundreds of hungry mouths to feed in a San Francisco lair.

And thus began Twitter’s descent into the extractive. First, they paid lip service to the society. Their curtailing of freedoms was for the betterment of all, you see.

The “consistency of the user experience” was imported as a new ideal. But the populace was nonplussed. Who was this ideal for? Who had asked for variety to be curtailed? Not us, said the people.

But objections be damned, the Twitter lords marched on. After all, they knew the billion was growing restless and the minions in their lair equally so. Turning back now was not on the table, lest they risk the anger and fury of the billion.

So it went that the extractive provisions were rolled out quicker and wider. The initial feigned attempts at covering new rules and restrictions with “it’s in everyone’s interest” fell further by the wayside with every new decree from the lords.

While the original rules were simple and fair—140 characters for all—the new rules were complicated, opaque, and easy to bend for the favored.

Some early app entrepreneurs would get access to 200,000+ users by the nature of their legacy stature; new ones would get half. Favored masters of Big Media would get to break the law of 140. And the Twitter lords themselves would expropriate and evict on a whim.

The populace grumbled and groaned, but like the frog boiled slowly, they adjusted to their new temperature one degree at a time.

Twitter’s billion was happy. Progress was being made to extract the most from these fertile lands it had lent. And with the billion happy, the lords were happy, and so too all of the lair.

“I wonder how long this one will last?”, asked the Web to his friend Email. “Who knows”, said Email, “Facebook is still around”. “Aye”, nodded the Web, “Winter might be longer this time around, but inevitably Spring will return”.

As an ad-agency refugee, I’ve struggled with my fair share of design debates with copywriters, project managers, clients, and everyone in between.

Maybe you’ve been there, too. The copywriter you’re paired with doesn’t think the marketing page you’re working on “feels right yet.” (As it turns out, the tone of voice is just off.)
In dramatic fashion, your client thinks the design you just presented is “way off base.” (You just happened to use a color they absolutely detest.)
It’s been five years since I’ve had a client meeting, yet the road blocks of vague feedback still come back to haunt me within the programmer to designer relationship.
The other day, Nick and I were debating the look and feel of shared code snippets. Or, so I thought…

Back in April, Nick wrote about our on-call programmer schedule. I think this system has worked really well for us, but I’ve noticed something about myself as I’ve taken my turns pitching in on support.

I tend to get really overwhelmed, really easily. And when I get overwhelmed, I become tense, stressed, and just generally miserable.

I’ve thought a lot about why this happens to me, and I’ve realized that it can be correlated to the number of issues currently in the on-call queue. When that pile of issues is small, life is great and I’m all smiles. When that pile grows deep, I begin to feel smothered and oppressed by it.

So, with that insight, I decided to try something new this time around. Initially, I thought that maybe apathy would be the answer. If I was feeling burdened by the queue because I felt a responsibility to clear it out quickly, maybe not caring about the queue would solve it? With this goal firmly held in my mind, I began working through a typically large Monday morning ticket-pile.

After working just a few tickets with this new mindset, I did feel a difference—I felt free of the burden of the queue, and the stress I usually felt on these Manic Mondays was notably absent.

But something else I noticed was that it wasn’t apathy that helped. It wasn’t that I didn’t care, it’s that I had scoped my area of care into something narrower. Instead of caring that the queue was large, or that the next few tickets seemed like they might be tricky ones, I focused my care on the ticket at hand.

Focusing on the moment has made the difference for me. On-call has gone from a roller-coaster of “HATE IT/LOVE IT” to a generally pleasing experience. I do what I have the immediate power to accomplish, and take the day one ticket at a time.

This is the final part of a three part series on how we use Twitter as a support channel. In the first part, I described the tools we use to manage Twitter; in the second part, we built a model to separate tweets into those that need an immediate response or not.

In the arc of a three part series, the final part is supposed to be either a story of triumph or an object lesson.
The triumphant story would be about how we implemented the model we built previously in production, integrated it with our Rails-based Twitter client, and saw massive quantifiable improvements resulting from it. I would look smart, competent, and impactful.
The object lesson is that sometimes practical concerns win out over a neat technological solution, and that’s the story here.

Sometimes good isn’t good enough

The model we built had a false positive rate of about 7%. That’s fair, and in many applications, that would be just fine. In our case, we want to be very confident we’re not missing important tweets from people that need help. Practically, that means that someone would have to check the classification results occasionally to find the handful of tweets that do need an immediate response that slipped through.
After talking to the team, it became pretty clear that checking for mis-classified tweets would be more work than just handling the full, unclassified feed with the manual keyword filtering we have been using. This is a great example of a case where absolute numbers are more important than percentages: while the percentage impact in terms of filtering out less urgent tweets would be significant, the actual practical impact is much more muted because we’ve optimized the tool to handle tweets quickly.
Part of the reason why we’re able to get away with keyword filtering rather than something more sophisticated is because of just how accurate it is with essentially no false positives. There’s actually a surprising amount of duplication in tweets—excluding retweets, the last 10,000 tweets we’ve indexed have only 7,200 unique bodies among them. That means that when a person looks at the first tweet using a phrase they can instantly identify that there’s a keyword that’s going to reoccur (for example, as soon as I started this series, we added “Behind the Scenes: Twitter” to the keyword list) and add it to the keyword list.

Most of the benefit with little effort

The book Why Nations Fail makes the argument that sustained societal prosperity is only possible when economic and political institutions are inclusive instead of extractive. It’s a little long-winded, but the historical accounts of the rise and fall of the Roman Republic and the Venetian city-state in particular are fascinating.

Both societies entered eras of strong growth and prosperity when they allowed larger parts of its citizens to partake in political and economic life. This glory phase lasted for generations, but eventually the elite sought to protect entrenched power and privilege and turned inclusive institutions back to being extractive. Thus began the decline and eventually demise of their success.

This is a drastic simplification and there is much more to both stories, but it got me thinking about just how fragile the commercial freedoms for software developers I listed yesterday are. There are many forces and elites working to turn this wonderland of prosperity and innovation into another wasteland. Here are some of the threats as I perceive them:

• Patents and trolls: When you can be shaken down at any time for bullshit patents, the risk of starting something new rises. Only elites with big protective patent portfolios and huge legal war chests are safe.
• Censorship and regulation: It’s easy to point at China and shudder at their explicit, heavy-handed shutdown of services, but there have been plenty “Why Won’t Someone Please Think Of The Children” campaigns elsewhere too. It usually starts with something like porn, and then everyone else is next.
• Net neutrality: Imagine if you had to enter separate agreements with every ISP in the world to get full-speed access to all your potential customers. Only the established elite would be able to navigate such shark-infested waters.
• The rise of app stores: When you’re at the mercy of the arbitrary whims of an elite landowner, you’re at constant risk of eviction or expropriation. This on top of, in classic extractionist style, working for free two days out of the week (30% cut).

If history is any guide, the amazing freedom and the prosperity we celebrate is easy to take for granted—right up until it’s gone. Progress often begets regression. The dark ages of commercial freedom is never more than a few elite power grabs away.

This is the second in a three part series about how we use Twitter as a support channel. Yesterday I wrote about how we use Twitter as a support channel and the internal tool that we built to improve the way we handle tweets.

One of our criteria in finding or building a tool to manage Twitter was the ability to filter tweets based on content in order to find those that really need a support response. While we’re thrilled to see people sharing articles like this or quoting REWORK, from a support perspective our first goal is to find those people who are looking for immediate support so that we can get them answers as quickly as possible.
When we used Desk.com for Twitter, we cut down on the noise somewhat by using negative search terms in the query that was sent to Twitter: rather than searching just for “37signals”, we told it to search for something like “37signals -REWORK”. This was pretty effective at helping us to prioritize tweets, and worked especially well when there were sudden topical spikes (e.g., when Jason was interviewed in Fast Company, more than 5,000 tweets turned up in a generic ‘37signals’ search in the 72-hour period after it was published), but had it’s limitations: it was laborious to update the exclusion list, and there was a limit placed on how long the search string could be, so we never had great accuracy.
When we went to our own tool, our initial implementation took roughly the same approach—we pulled all mentions of 37signals from Twitter, and then prioritized based on known keywords: links to SvN posts and Jobs Board postings are less likely to need an immediate response, so we filtered accordingly.
Using these keywords, we were able to correctly prioritize about 60% of tweets, but that still left a big chunk mixed in with those that did need an immediate reply: for every tweet that needed an immediate reply, there were still three other tweets mixed in to the stream to be handled.
I thought we could do better, so I spent a little while examining whether a simple machine learning algorithm could help.

Lessons from email

While extremely few tweets are truly spam, there are a lot of parallels between the sort of tweet prioritization we want to do and email spam identification:

• Have some information about the sender and the content.
• Have some mechanism to correct classification mistakes.
• Would rather err on the side of false negatives: it’s generally better to let spam end up in your inbox than to send that email from your boss into the spam folder.

Spam detection is an extremely well studied problem, and there’s a large body of knowledge for us to draw on. While the state of the art in spam filtering has advanced, one of the earliest and simplest techniques generally performs well: Bayesian filtering.

Bayesian filtering: the theory