Worker protections for office workers 🇫🇷👏

Let’s hope it won’t take a revolution this time

The French just banned companies with more than 50 people from sending their workers after-hour emails. Well, “ban” is a bit of a strong word for a law that carries no actual penalties and its enactors concede is based on voluntary compliance. Perhaps “strong signal” is a better term, but what a marvelous signal it is!

You’d be hard pressed today to find anyone who doesn’t believe in traditional worker protections. That operating dangerous machines on factory floors shouldn’t carry the expectation of people losing a limb every week. Or working in construction shouldn’t mean inhaling asbestos all day. Or that work beyond 40 hours should be considered extraordinary and be compensated accordingly. It was government regulation, not the good-hearted nature of business owners, that brought this change about.

But that was for the blue-collar factory workers and other manual labor. What about the growing number of people staring at computers all day? The instinctual reaction is probably “ha!”. How hard can it be to type on a keyboard all day? What exactly do these pampered office workers really need to be protected from?

Lots, I’d say. While their limbs and lungs may generally not be at stake, their sanity certainly is. And it’s high time we recognize that just because your body isn’t at risk that all isn’t necessarily swell.

And that’s what the French are saying with this “ban”. That the ever-expanding expectations for when someone is available have gotten out of hand. And they absolutely have. Work emails are ticking in at all sorts of odd hours and plenty of businesses are dysfunctional enough to believe they have a right to have those answered, whatever the hour. That’s unhealthy, possibly even exploitative.

Same goes for forcing everyone to work in an open office. The research is mounting on all the ills that come from persistent noise and interruptions from that arrangement. Sure, it works for some. And not everyone who used the table saw without safety protection lost a limb either. That’s just not good enough.

I have no illusion that the French objection will find any sway with American lawmakers. You’re more likely to see it laughed at. Not just by lawmakers, but business owners (or venture capitalists). Hell, I wouldn’t be surprised if most American workers wouldn’t chuckle at the “silly work-shy French”. Something-something Stockholm Syndrome.

What we need before we can even dream of having something like the French response is a change in attitudes. Less celebration of workaholism, more #WorkCanWait. More recognition that stress from unrealistic and unhealthy expectations and work habits is actually a real hazard to health and sanity.

It’s time for a new look at a new edge. Vive La France for showing the way!


Basecamp 3 has both lots of features that send emails and chat built-in. It’s the perfect storm for keeping workers chained to work after hours. But we realized this from the beginning and launched the new version with worker protections in place: Work Can Wait.

Mainstream precludes cool


When Ruby on Rails emerged on the web development scene in 2004, it was undeniably cool. It brought a new vibe, a new look, a new approach, and plenty of novel ideas about the psychology, culture, and technology to the broader world of web development. It was hip hop assaulting airwaves dominated by techno. It was different.

Culture shocks like that don’t stay shocking. If they’re successful, they cease being the shock and become the culture. The path to widespread adoption is the path to the mainstream. To becoming the new accepted wisdom. From heresy to common sense.

Fighting to remain cool after you’ve won is folly. Movements that conquer the world either accept the role of establishment with grace or find themselves with no role at all. This was the best case scenario. Celebrate it!

That celebration is a lot less dramatic than the battles of the early years. It’s less exhilarating in the fight-or-flight sense of adrenaline highs. But there’s a different, deeper sense of satisfaction from seeing the ideas you championed benefit the many, the masses. Not just a tiny, cool elite of early adopters.

Because make no mistake, you can’t span a spectrum that includes both early adopters and the mainstream masses with any sense of coherent vision. Early adopters were there in part for the thrill of the frontier. The mainstream masses just want the toilets to flush every time.

So you have to be able to say goodbye to a few in order to say hello to the many. That transition can be hard. “Where did everyone go?” is a natural question when you see a handful of prolific frontier fighters make way for a much larger, quieter crowd of people who just want functioning plumbing.

But again, this is what winning looks like. This is what being around for the long term feels like. That doesn’t mean you should stop moving, stop improving. It just means you’ll be doing so at a different pace. In the early days, you can go from 50% done to 60% done in short order. In the later days, it’ll take ten times as long to go from 98% to 98.5%.

Once you accept this new state of affairs, there’s a new sense of calm available. You’re no longer fighting for survival. But there’s always more work to do. A different kind of work. Less revolutionary, more administrative, more marginal. It takes a different temperament to manage the schools and maintain the roads than it does to lead the rebellion.

This is true of all movements, and programming is no exception. When I first picked up Ruby, it was already a decade old. Now it’s been around for a quarter of a century. It’s evolving, but it’s not revolutionizing. That’s how it’s supposed to be!

I spent plenty of time sleeping under the stars on the early frontier, and it was fun. But so is indoor plumbing. It hasn’t constrained my creativity or ambitions to enjoy the sophisticated amenities of modern Ruby on Rails development.

There’s a parallel to the highs and lows of working at an early startup. I thoroughly enjoyed building Basecamp together with three other people, but I’m also OK with the fact that I no longer have to wake up in the middle of the night to save a server. Enjoy the memories, but live in the present.

The same is true of life in general. I had a lot of fun in my 20s, but I don’t look back at them with longing. I traded one set of thrills (like partying) for others (like kids), and I got to enjoy both. My 30s have been wonderful too. And I’m looking forward to my 40s as well.

Enjoy the ride, accept when it’s over, and stop pining for the past.

Provide sharp knives

Ruby includes a lot of sharp knives in its drawer of features. Not by accident, but by design. The most famous is monkey patching: The power to change existing classes and methods.

This power has frequently been derided as simply too much for mere mortal programmers to handle. People from more restrictive environments used to imagine all sorts of calamities that would doom Ruby because of the immense trust the language showed its speakers with this feature.

If you can change anything, what is there to stop you from overwriting String#capitalize so that “something bold”.capitalize returns “Something Bold” rather than “Something bold”? That might work in your local application, but then break all sorts of auxiliary code that depend on the original implementation.

Nothing, is the answer. There’s nothing programmatically in Ruby to stop you using its sharp knives to cut ties with reason. We enforce such good senses by convention, by nudges, and through education. Not by banning sharp knives from the kitchen and insisting everyone use spoons to slice tomatoes.

Because the flip side of monkey patching is the power to do such feats of wonder as 2.days.ago (which returns a date two days back from the current). Now you might well think that’s a bad trade. That you’d rather lose 2.days.ago if it means preventing programmers from overwriting String#capitalize. If that’s your position, Ruby is probably not for you.

Yet it’d be hard even for people who would give up such freedom for some security that the power to change core classes and methods has doomed Ruby as a language. On the contrary, the language flourished exactly because it offered a different and radical perspective on the role of the programmer: That they could be trusted with sharp knives.

And not only trusted, but taught in the ways to use such capable tools. That we could elevate the entire profession by assuming most programmers would want to become better programmers, capable of wielding sharp knives without cutting off their fingers. That’s an incredibly aspirational idea, and one that runs counter to a lot of programmer’s intuition about other programmers.

Because it’s always about other programmers when the value of sharp knives is contested. I’ve yet to hear a single programmer put up their hand and say “I can’t trust myself with this power, please take it away from me!”. It’s always “I think other programmers would abuse this”. That line of paternalism has never appealed to me.

That brings us to Rails. The knives provided by the framework are not nearly as sharp as those offered with the language, but some are still plenty keen to cut. We will make no apologies for offering such tools as part of the kit. In fact, we should celebrate having enough faith in the aspirations of our fellow programmers to dare trust them.

Plenty of features in Rails have been contested over time as being “too much freedom”. But one example that’s currently in vogue is the feature of concerns. This is a thin layer of syntactic sugar around Ruby’s built-in feature of modules and is designed to allow a single class to encapsulate multiple related but independently understood concerns (hence the name).

The charge is that concerns provide programmers prone to bloat their objects with a whole new set of drawers to stuff their clutter in. And that’s true. Concerns can indeed be used like that.

But the grand fallacy is thinking that by not providing a feature like concerns, which when used by even mildly capable hands allows an eloquent partial separation of concepts, we’d put programmers on the path to architectural bliss. If you can’t be trusted to keep the kitchen sink out of your overstuffed concerns, you’re probably not going to end up with a shining beacon of elegance otherwise.

Programmers who haven’t learned to wield sharp knifes just aren’t going to make meringues yet. Operative word here: Yet. I believe that every programmer has a path, if not a right, to become fully capable Ruby and Rails programmers. And by capable, I mean knowledgeable enough to know when and how, accordingly to their context, they should use the different and sometimes dangerous tools in the drawers.

That does not abdicate a responsibility to help get them there. The language and the framework should be patient tutors willing to help and guide anyone to experthood. While recognizing that the only reliable course there goes through the land of mistakes: Tools used wrong, a bit of blood, sweat, and perhaps even some tears. There simply is no other way.

Ruby on Rails is an environment for chefs and those who wish to become chefs. You might start out doing the dishes, but you can work your way up to running the kitchen. Don’t let anyone tell you that you can’t be trusted with the best tool in the trade as part of that journey.


This essay was just today added as the ninth pillar of The Rails Doctrine.

“We only hire the best”


How many times have you heard a company claim that they only hire the best? The top of the top. The crème de la crème. Most of them, by sheer necessity of math, are delusional. There just aren’t that many “the best” to go around.

What these companies generally mean is that they hired “the best” of the candidates that applied. Whoopty fucking doo. That’s what all companies generally do (the special ones hire for best team, not just best candidates).

Failing to see the difference between “best candidates who applied” and “the best in the business” is exactly the kind of Dunning-Kruger thinking that deludes companies into these grandiose proclamations.

This gets even more hilarious when companies willfully narrow the pool of potential candidates with bullshit filters. Like, “must be local to San Francisco” or “10+ years of experience required” or “fancy college degree preferred”.

Here’s stating the obvious: The best people don’t all live in San Francisco. Many of them have far fewer than a decade’s worth of experiences in your current environment. And certainly, the bulk of them did not go to some fancy college you idolize.

You know what the best people I’ve ever met or worked with had in common? ALMOST NOTHING! Certainly nothing that could be codified in the form of a list you can filter candidates through by automation.

The best are generally the best because they aren’t typical. Because they came at things from a different angle that gave them a unique perspective, which happens to provide more insights than the widely-distributed approaches.

But even diving into an examination of what characterizes “the best” is missing the point. First, “the best” is bound to be situational. Someone who can thrive in one environment might get crushed in another. The peak skills that gave them a leg-up in one domain may very well make them unfit for work in another.

What’s more, even if you could assemble an elite squad of all “bests”, it’d probably suck. Because a team can only contain so much peak uniqueness before it’s pulled apart by all this “excellence”. It can’t be all chiefs and no indians. (Did you see Hamilton and Rosberg collide in Formula 1 last week? Mercedes probably wish they had more of a Vettel and Webber kind of dynamic right now.)

Mostly importantly, though, is the myopia of putting the burden of excellence on individual candidates and not on the company itself. Does this company even have a chance of cultivating, let alone keeping, the best? If they’re making delusional proclamations like “we only hire the best”, then the odds are slim and shady.

You’re more likely to find that these kinds of companies mistake excellence for shit like “fancy VCs wrote us a big check” or “we once had a hit product” or “game consoles and colored couches makes staying at the office all night long so FUN!”.

It’s great for a company to have aspirations, but recognizing the difference between what you’d like to be true and what actually is serves as a prerequisite for closing that gap.

Ruby has been fast enough for 13 years

When I started programming Ruby, it was on an Apple iBook G4/800. That beautiful 12” powerhouse of a 800 MHz PowerPC with a rocking 256MB of RAM. A lovely computer that was not only fast enough to run Ruby, but a pleasure to develop the first version of both Rails and Basecamp on.

When Basecamp launched in February of 2004, we ran on a single shared Linux server at Tilted. I don’t fully remember the CPU spec, but I do remember that we had the same 256MB of RAM available. And I believe the monthly cost for this princely server was around $349. It was not only fast enough to run Rails and Basecamp, but good enough to do so on its own for more than a year while we built a business that could pay the salaries of four.

So forgive me if the zombie theme of “Ruby is so damn slow” isn’t striking a recognizable tune with me. Now, I don’t for a minute doubt that Ruby may well be too slow for some people doing some things. But given the fact that Ruby was plenty fast for me in 2003 on a bootstrapped budget with the performance of the day, I think perhaps that tune is out of key for many others too.

We built an application used by millions of people that has made tens of millions of dollars in real money and continues to grow and prosper. No, it’s certainly not Internet Scale™. And it certainly doesn’t prove that Ruby is fast enough to be economical when you get there, but it does lodge an anecdote that it’s probably more than fast enough for most people doing most things.

Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails.

Ruby is a luxury in the most egalitarian sense possible. It’s a luxury that the 99% can afford, but the 1% might struggle with. What a wonderful inversion of tradition!

It’s an incredibly affordable luxury for all those businesses where the cost of people, not machines, dominate the balance sheet. There are many such businesses today, and Ruby has never been better for those.

And again. I’m not decrying speed. The ambitious goals of Ruby 3×3, the continued focus to optimize Rails, and the many performance wonks in the community who work tirelessly to make everything faster do great work that I’m thrilled to benefit from.

It’s just that most of it is gravy for most people. Oh, I can save a few extra instances because of this latest patch? Wonderful. Thank you very much! (If only it served as a drop in the bucket to pay the latest increase in healthcare premiums that arrived in 2016.)

Ruby was fast enough in 2003 to build a business like Basecamp with no impediments. Ruby is so much faster and so much cheaper in 2016 it’s ridiculous. On the other hand, skilled programmers have never been more expensive. Splurge on the luxuries you can afford to keep them happy.

I invite you to suffer

Moments of suffering can serve as effective tutors. Not the physiological suffering or fear of basic safety kind. But rather the suffering of belonging, esteem, and self-actualization.

While I’ve forgotten much of the specifics of organizational theory taught at Copenhagen Business School, I’ve never forgotten how being forced to sit with my screen visible to a busy pass way in a Copenhagen office made me feel. The loss of control and privacy traded for the whims of a boss that “thought it looked better”.

I don’t reach much for the computer science of sorting algorithms in general or binary trees in particular, but the frustration and indignation I felt wrestling with Java Swing to produce a video database for a school project will be with me forever.

Although I actually do remember much of the basic business economics and accounting I learned in school, their importance were never truly driven home until I worked through a string of collapsed businesses due to magical investment thinking of the late 1990s and early 2000s.

These moments and many more lit a rage inside me because the suffering felt so needless. I concluded all of them with a sense of “it doesn’t need to be this way”. As the internet would say: We Have The Technology! (Or, the path to invent what we need seems obvious).

I wasn’t always in a position to do anything about the particular situation, but I was always equipped to store the memory and emotion for latter use.

Harvesting the power of suffering is a thin line, though. It’s easy to store it all in containers of resignation, defeat, and bitterness. That’s not a useful source of energy.

You must pair suffering with hope. The hope that you’ll be able to set this wrong right. And then set about to do just that.

Who wants to live in The Real World?

The Real World must be a truly depressing place to live. It’s apparently a realm where new ideas, unfamiliar approaches, and foreign concepts always lose. I’m told that the only thing that works in The Real World is what its inhabitants already know and already do. No matter how flawed or inefficient that way may be.

People who live there are said to be living Real Life. An existence filled with pessimism, despair, and every shade of pitch black imaginable. Yet strangely, these people living Real Lives seem not to be interested in getting out. They are not looking for a change of scenery of the dreary Real World.

Instead, they’re actually trying to recruit! In arguments everywhere, they’re trying to convince those of a sunnier demeanor that they must convert to Real Life or perish. That resisting the Real World is futile. This call persists even in the face of contrary experiences. Tales of people who actually did things differently and still lived to see the sun rise in the morning.

Please don’t be fooled, there’s nothing even remotely attractive about The Real World. It’s a bleak mirage suitable only as a place of communion for those who have lost all hope.


I originally wrote this piece almost nine years ago. Nothing has changed. Just the other day someone blasted Jason’s piece on Is Group Chat Making You Sweat? as not being of The Real World because that’s a place where “people need to talk”. Heh.

A cocktail for putting dents in the universe

The dose makes the poison

Ignorance is a powerful catalyst for “unrealistic” dreams and ambitions. If you don’t know how hard something is going to be, you’re less likely to be discouraged. If you don’t know it can’t be done, you just might do it.

That essentially describes how I got started with Ruby on Rails in 2003. Not only had I never done anything material in Ruby before embarking on creating Rails, I hadn’t even released or contributed to any open source software! I literally had no idea how much work or how hard it would be.

After release, though, I quickly had plenty of naysayers chiding my ignorance, shouting “you don’t know what you’re talking about!” This was particularly true when it came to the wide array of charges I levied against the dominant ecosystems of Java and PHP at the time.

To some extents it was true, but it was also largely irrelevant. You don’t have to be a scholar in The Way Things Are Done Right Now to critique its methods or values. In fact, you’re probably far less likely to mount any consequential root examination of the ills of the present if you’re steeped in its ways.

There are always a million reasons for why things are the way they are. Reasons that made perfect sense at the time and may continue to in isolation. Stripped of a legacy context that’s perhaps no longer, or far less, relevant, they may also compile to a ludicrous mess.

To survive the horde of entrenched interests pushing these reasons, you’ll need strong defensive walls. Allow me to suggest that arrogance is one such wall, and a very effective one too. It’s rarely used, because most people are afraid to cop to believing they “know better”.

But let me pose this: Why on earth are you trying to change things, if you don’t believe you actually know better? If you can’t muster the conviction to believe in your own ideas, how on earth are you going to persuade others that they’re worth listening to?

To put it on a pin: Arrogance is good. Arrogance works.

It doesn’t mean you have to be arrogant about all the things all the time, but you should be arrogant about the core insight that’s driving your pursuit. Whether you then publicly admit to this arrogance is less important.

That leaves the recipe: Ignorance + arrogance = drive. Ha. That sounds pretty preposterous, doesn’t it? And it is, if you don’t heed the adage that the dose makes the poison. What you need is a dash of both. Enough to weather a storm, but not so much as to kill a nation.

Fair warning: Consuming this cocktail will almost certainly render you ineligible for universal love and admiration. There will be plenty of people who not only don’t buy your vision, but are repelled by your drive.

That’s the price for most kinds of progress. In fact, it’s even evidence of it. If nobody is riled up about what you’re doing, there’s a good chance it just isn’t interesting. Of course, it’s also no guarantee of it. Sometimes everyone hates your idea simply because it’s a bad idea! But it’s hard to know in the moment whether something is truly bad or just alien.

The best this cocktail will give you is a shot of putting a dent in the universe. No guarantees, no money back. But at least you’ll be unlikely to give up just because somebody told you to.


Like Ruby on Rails, Basecamp has often been accused of being nothing more than a todolist that could be done by anyone in a weekend, and that the lack of features were insulting to users. That thankfully didn’t deter millions of people to give it a try, see for themselves, and find a loving operating system to run their business on. ❤️

I fucking ❤ Mondays!

It’s actually more Fridays I have a problem with. Fridays are often the anticlimax of the week. Sometimes you didn’t get as much done as you hoped, your energy is spent, and frankly, you just want to put a lid on it.

Mondays, on the other hand, are always full of promise and freshness. Imagine all the great things this week might have to offer! Imagine finally cracking the hard problem that cooked your noodle last week. Monday is the day of optimism, before reality pummels the week and your spirit into submission.

Keep reading “I fucking ❤ Mondays!”

Don’t pose the question if the answer can’t change your mind

There’s an undeniable appeal in seeking broader consensus from your customers, employees, and partners in decisions big and small. When your direction has the legitimacy of a wide backing, it’s invigorating and enabling. Making progress together is more fun and effective than making progress by edict.

But you should temper your temptation to pose questions to which you aren’t really interested in hearing an opposing answer. Seeking legitimacy is a double-edged sword. When it “works”, and the asked reaffirms your preferred choice, it’s great! But it often doesn’t, and they don’t. This is where problems arise.

And it’s true whether you query for opinion or fact. If you ask your customers what’s most important for us to work on next, you better be prepared to build a faster horse. If you tap the data oracle to see whether your redesign worked, you better be prepared to revert if it didn’t.

The problem is that it’s really hard to formulate a question without falling in love with one of the possible answers. In fact, many questions arise from the infatuation with one of those answers, and serve more as post-hoc justifications than genuine inquest of inquiry.

Say you already have a destination mapped out on your mind’s road map, but you want to be seen as being “responsive to customers”. Or you’re already loving the redesign, but you just want to cover your ass in case business was to drop.

We instinctively know that simply picking a direction based on gut alone is hard to rationalize, both to ourselves but especially to others. So we seek to dress up the instinctual pick in more neutral, objective clothes and pass it off as just an innocent pursuit of the “best answer”. But it’s often baloney and the whiff travels.

Better then to simply admit when your gut is going to be in charge and own it: “We’re doing this because I think it’s the right thing to do, and that’s that”. When you say that out loud, it’ll surely feel a tad uncomfortable, but at least it’ll be congruent. Everyone knows when the leader is just seeking reaffirmation of a choice already made anyway, so dressing it up as a question is merely a ballroom dance of charade. We nod, we smile, but we know.

The other advantage of owning up to the discomfort is it will serve as a natural check on the number of gut moves likely to be made. Few people, however bold, are happy freezing at the top of the mountain alone, even if they get an unlimited stack of edict paper to fill out in return. We all want to be loved and accepted, not merely be effective. Well, most of us anyway.

By the same token, some times you really just need someone to pick a path and go with it. There’s nothing inherently wrong with that. Embrace it (judiciously).

The strong leader is neither someone who makes all the choices or none of them, but the one who knows when to do either.