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.

Everything is possible but nothing is free


Every developer has been asked whether building a certain feature is “possible”. The short answer is virtually always YES. It’s possible. Software is the clay of dreams; everything is possible.

What those asking really want to know, though, is one of two things:

  1. Can you just build this thing I want, in addition to all the other things already on your plate, without moving any of your estimates? In other words, can you invent additional time or work hero hours to make this happen? The short answer to that question is always no. No, developers cannot bend time, invent time, or be long-term productive by sacrificing their downtime for your special-request time.
  2. Is this “easy” to do? And by “easy”, let’s take the vaguest, most fuzzy definition of the word that the two of you will never agree upon. This is like two kids arguing which car is faster: the red one or the yellow one? Without further information, you’re not going to make much progress on either question.

Here’s a simpler approach: I would like to have this and I’m willing to pay up to that.

That’s a basis for a conversation worth having. It’s rarely enough for a developer to give you a definitive answer on the spot, but after a couple of follow-up questions, you’re at least likely to know whether you’re in the ballpark.

The catch with framing the request like that is it requires the person asking to make the hard analysis. How much is my request really worth? What other things would I give up to have this thing instead? It forces them to bargain with reality, which is much less appealing than charming the developer fairy into just giving them want they want, no sacrifices needed.

And many developers are surprisingly willing to play their part in this fantasy, because who doesn’t want to be thought of as superhero with magical powers? It’s an addictive role, but also a broken one. You only get so many magic spells before your book is done.

Successfully and sustainably making progress on software together is based on an open dialogue about costs and trade-offs. The more we obfuscate those critical decisions, the less likely we are to get what we all really want: The best software for the time and money we have.


Basecamp was built by hunting for bargains under a set-the-budget type negotiation tactic as described above. Well, mostly. We still succumb to wishful thinking every now and then too, but when we catch it in the act, we try to whack it. Let me know how you think we did.

Sleep deprivation is not a badge of honor


Forgoing sleep is like borrowing from a loan shark. Sure you get those extra hours right now to cover for your overly-optimistic estimation, but at what price? The shark will be back, and if you can’t pay, he’ll break your creativity, morale, and good-mannered nature as virtue twigs.

Now we all borrow occasionally, and that’s okay if you fully understand the consequences and don’t make it a habit. I did that the other night. We pushed an update to our single-signon system for Basecamp, which had me working until 1:30 AM. That wouldn’t have been so bad if it wasn’t because I got woken up at 5 AM to help deal with an issue that arose. But the costs the following day were typical, numerable, and high:

  • Stubbornness: When I’m really tired, it always seems easier to plow down whatever bad path I happen to be on instead of reconsidering the route. The finish line is a constant mirage and I’ll be walking in the desert for much longer than is ever a good idea.
  • Lack of creativity: What separates programmers who are 10x more effective than the norm is not that they write 10x as many lines of code. It’s that they use their creativity to solve the problem with a tenth of the effort. The creativity to come up with those 1/10 solutions drops drastically when I’m tired.
  • Diminished morale: When my brain isn’t firing on all cylinders, it loves to feed on less demanding tasks. Like reading my RSS feeds for the 5th time today or reading yet another article about stuff that doesn’t matter. My motivation to attack the problems of real importance is not nearly up to par.
  • Irritability: If you encounter someone who’s acting like an ass, there’s a good chance they’re suffering from sleep deprivation. Your ability to remain patient and tolerant is severely impacted when you’re tired. I know I’m at my worst when sleep deprived.

These are just some of the costs you incur when not getting enough sleep. None of them are desirable. Yet somehow it seems that the tech industry still celebrates a masochistic sense of honor about sleep deprivation. At times it sounds like bragging rights. People trying to top each other. For what? To seem so important, so in need, so desired that humanity requires you to sacrifice? Chances are you’re not that special, not that needed, and the job at hand not that urgent.

Software development is rarely a sprint, but mostly a marathon. Multiple marathons, actually. So trying to extract 110% performance from today when that means having only 70% performance available tomorrow is a bad deal. You end up with just 77% of your available peak. Bad trade.

This is why I’ve always tried to get about 8 1/2 hours of sleep. That seems to be the best way for me to get access to peak mental performance. You might well require less (or more), but to think you can do with 6 hours or less is probably an illusion. Worse, it’s an illusion you’ll have a hard time bursting. Sleep-deprived people often vastly underestimate the impact on their abilities, studies have shown.

So get more sleep. Stop bragging about how little you got. Make your peak mental capacity accessible.


I originally wrote this post back in 2008 (and a version feature in REWORK). But after a couple of kids arrived, I remembered just how silly it is to voluntarily subject yourself to sleep deprivation. When you’re responsible for another little human, you have no choice. When you’re just trying to ship a new feature or a product, you absolutely do. Go The Fuck To Sleep.