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”.

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.

It’s easy to take for granted just how good we have it as software makers selling on the internet. This is truly a unique period in human history with unprecedented commercial freedom. It bears celebration and recognition.

Let me count the ways I love thee, unregulated internet:

• Access to world markets: Out of the 195 countries recognized by the US state department, we have customers in 191. There are no import tariffs to pay. No customs to clear. No multitude of electrical standards to comply with. Heck, we don’t even need to translate our products.
• Direct sale to customers: There are no distributors and no retailers with their hand out to take a cut. And we, the makers, get to talk directly to our customers—not someone else with a million other products to sell and none of our expertise.
• Free tools and education: All the software we needed to build our business with was not only freely available off the internet, it came with a wealth of free education that would shame any university. Programming languages, database systems, web servers, load balancers, operating systems. It was all there for the taking.
• No capital requirements: We didn’t need offices or fax machines or secretaries to get going. We could rent all our computing needs for next to nothing until customers with cash in hand started using our services and taxing our servers. This meant basically “no money down!” and no need to go hat in hand begging banks or venture capitalists for money.
• Self promotion can build a brand: We didn’t have to either convince journalists to write about us or buy expensive ads to get our name out. We “just” had to be interesting! It might not be easy, but it’s generally free. Aggregators like Reddit, Hacker News, and retweets have accelerated this power even more so recently.

Compare these extraordinary freedoms with just about any other business in the world. Nobody has it as good or are as free as software makers selling via the internet.

All we needed was an idea for a product that people were willing to pay for and the skills to pull it off. Ideas are all around us and the skills are learnable by self study.

You really can create something from nothing.

When I started racing cars, I thought it would be great if I could just settle in mid-pack in a respectable gentleman’s cup series. After all, racing to me was all about getting access to long stretches of flow, that sensation of being so completely engrossed in an activity that you lose track of time and place.

It didn’t take long before my ambition swelled, and I upped the goal from finishing mid-pack to top 10. Of course, not before taking a brief moment to bask in the glory of reaching that first goal, enjoying success per my own definition. A definition that would surely have qualified as utter failure for many others (what schmuck is happy to be mid-pack among gentlemen?! At the time, me!).

And thus, the goal creep was on. It crept from top 10, to podium, to moving up to a bigger series, a faster car, more downforce, tougher competition, longer races, a better team, and on it went.

The key is that it was all a bite-sized progression. While the ultimate goal might have been entering the 24 hours of Le Mans (a goal that itself has crept from entering, to finishing, to winning the class), that wasn’t really part of the detailed goal posts that has driven the pursuit forward.

You can think of goal creep as the test-driven development of a real-life pursuit. In TDD, you don’t try to design your entire program upfront. Instead, you just write a simple test and then implement just enough code to make that test pass.

Setting small goals, like writing simple tests, keeps the pursuit from becoming overwhelming. Making the mental jump of going straight from playing Forza Motorsports to getting on the grid at Le Mans is an insurmountable idea for most. It certainly was for me.

But these small, underwhelming goals trick your brain into constantly experiencing a steady flow of success. It’s incredibly important to celebrate these successes, however modest, as they’re the fuel that’ll keep you going and reaching for more.

The same was true when we started working on Basecamp and I was learning Ruby. If the goal had been to create an application used by millions and a framework that would rock an industry, I would never have put down the Xbox controller and gotten started.

Even our economic goals were incredibly modest when Basecamp launched. While others were thinking of millions of users and millions of dollars, we had the goal of making $4,000/month from Basecamp after a whole year.

We met that goal in a couple of weeks and were able to celebrate a success that would have been utter failure to many others. And after a year, when Basecamp made just enough money to pay all the bills and relieve us from having to do consulting work on the side, we celebrated again.

I guess the point is to define your own goal posts. Don’t be so eager to adopt the goals of others. They are starting from a different baseline than you. If you adopt “shoot for the stars,” you might well run out of propulsion before you even get to the yard.

We’re constantly working on new features, improvements, and technical upgrades for Basecamp. Many of these changes need to be experienced in the wild to guide their evolution. We need to live with them in our daily use of Basecamp to see whether what seemed like a good idea is actually a good idea.

To this end, we run six different beta servers that all point to the same production database. We’ve found it impossible to accurately evaluate a feature unless it’s being used in anger with real data that actually matters. Evaluating changes against a staging server that’s running an old copy of the database just doesn’t cut it.

The way we book a beta server for use with a certain branch is simple: It’s just in the title of the BCX Campfire room.

When you’re done with a beta server, you change the title to “available”. When you need a beta server, you change it to the name of the running branch.

To select a given beta server, we’ve added a drop-down to all 37signals’ staff accounts within Basecamp itself.

You just pick the server you want to run on and it’ll route you to the beta environment running the branch you’re looking to try out.

Long-term exposure to upcoming features is a great way to get them just right. But it’s also a great way to realize that what you thought was a great idea just wasn’t good enough to ship. We’ve killed many features and changes to Basecamp after living with them for a few weeks. Often times, the most important features are the ones you don’t ship.

Many programmers have a natural preference for short variable and method names. I doubt many would recognize this preference as a trade of brevity for clarity, but that’s often exactly the result. This is especially true if you subscribe to the ridiculous Church of 80-character Lines.

It need not be that way. Writing terse code can be a joy even if you spell things out in abundant detail. Modern programming languages are expressive enough that what you save in laborious boilerplate can be spent on clarity — and you’ll still have plenty of lines left over for a dance.

And most certainly, you’ll hardly ever need to abbreviate anything. I cringe when I see ext for extension, cp for copy, or worse, application-specific abbreviations sure to be forgotten two months after you left the project.

At times being exceedingly clear will seem almost silly at first glance. The name of the method or variable can be longer than the operation being performed! But the silliness quickly dissipates the first time you return to a piece of code and know exactly what it does.

Here are a few examples of long method names from the new Basecamp code base:

def make_person_an_outside_subscriber_if_all_accesses_revoked
  person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank?
end

def shift_records_upward_starting_at(position)
  positioned_records.update_all "position = position - 1",
    ["position >= ?", position]
end

def someone_else_just_finished_writing?(document)
  if event = document.current_version_event
    !event.by_current_creator? and event.updated_at > 1.minute.ago
  end
end

If you work hard at being clear in your naming, you’ll also rarely need to write comments for the code. Comments are generally only needed when you failed to be clear enough in naming. Treat them as a code smell.

Formality is like a virus that infects the productive tissue of an organization. The symptoms are stiffness, stuffiness, and inflexibility – its origin never with those who do but with those that don’t.

When did you last hear a programmer or designer clamor to wear a suit to work? The order always come from the executives (followed shortly by a request for those TPS reports!)

Formality is more than a dress code, of course. It infects how people talk, write, and interact. It eats through all the edges and the individuality, leaving only the square behind. In other words, it’s all about posture, not productivity.

And once you place being proper above getting great work done, it’s unlikely that you’ll attract the best and most creative minds to work for you. (Though you’ll surely have no trouble filling the ranks with folks who can fit the existing molds.)

Formality is so ingrained in much of our working culture that even though people intuitively understand its harm, as in the colloquial “it’s just a formality, but we have to…”, it lives on.

Thankfully, there seems to be a cure: Companies started and run by doers. People close enough to the work to see the damage of formality and who’ll have none of it.

In technology, the best and brightest have long belonged to this class. Their images are iconic: Bezos in his jeans and sports coat, Jobs in his turtleneck and New Balance shoes, Zuckerberg in his hoodie.

Contrast this to the suits running RIM or Nokia or IBM. They’re either in literal decline and despair or they’ve found a second life of relevance in the tombs of The Enterprise.

We’re breaking down the stranglehold of formality everywhere. No more personal secretaries, memos on official letterhead, meetings that must happen in person. There’s never been less mental mask switching between work and play. We wear the same clothes, use the same technology. It’s a liberation of the mind and it’s the new world order.