DHH

You might have heard: The bigger the scope of your problem, the more rigorous your approach must be. It applies to projects and organizations alike.

It’s a correlation often associated with the notion of “getting away with something”. Like, you can get away with not having large, frequent status meetings because you’re still small, but when you grow, you’ll have to do it. So might as well start now!

But what if you don’t grow? What if you don’t want to grow? Adopting all the rigors of a supertanker when you’re sailing a rowboat doesn’t make for a better journey. It doesn’t mean supertanker rigor isn’t worthwhile for the supertanker, it just means it isn’t for you. Premature rigor can kill the spark long before it has time to start a fire.

This applies to all aspects of the endeavor: Policies, processes, metrics, and certainties. It’s so much easier to wing it, when all it takes to lift you up is a single gust of wind. But not only is it easier, it’s the right thing to do! You’re not cheating; there’s nothing to feel guilty about.

In fact, working without all the rigor required of a mega operation is a time to relish. It’s the time for play, fast moves, and fun excursions. You may well have to grow rigid and process-bound soon enough. Don’t be in such a rush to get there.

Because increased rigor and sophistication is generally a one-way street. Once you’ve set up all manners of systems, hired all the people, and taught yourself that this is the bar for proper work, there’s rarely a way back. Projects and organizations are supposed to grow like this, so unwinding feels like going backwards. Nobody likes to regress.

It’s kind of like growing up. I remember at times doubting whether finishing high school was worth it. I already knew computers, I already knew how to make money. Surely I could just get a job and really start living life…

Then my mom asked me: Why are you in such a rush? You literally have the rest of your life to work. Most people never go back to school. Take the time to live the present.

I didn’t have a good answer. So I let life run its natural course. Yes, annoyed with the math papers and the other high school subjects I didn’t find of interest, but also pleased by so many other opportunities and extracurricular activities that only that time of my life had to offer.

Think about that when you’re inclined to or offered a path to fast-track the rigor, sophistication, and complication of your project, organization, or life. Why the rush? Could it be that right now, right here, is a great place to be for now? It just might very well.

---

We’ve been growing Basecamp as both a company and a product with an eye to enjoying every phase for the past 12 years. Resisting the lure to rush bloating headcount or features. Yes, rigor slowly accumulates, but at a digestible pace. And when it gets too much, we try to hit restart and gather our best thoughts again. Basecamp 3 is such a reset, such a collection of best thoughts. Give it a try!

So you got a lot done this week? Good for you. But what exactly did you get done? Was it work you’ll remember next month? Was it work that’ll matter next year? Did you learn anything that’ll help you tomorrow?

High productivity doesn’t mean squat if the things you’re getting done aren’t truly important. It’s far better to get a few top things done, and done well, than to crush a mile-deep todo list of trivial bullshit.

But it can be hard to tell the difference when we constantly celebrate things like inbox zero. What about all the things that didn’t have an email or explicit todo attached? It’s easy to fool yourself into thinking you’re on top of it all when all the app counts say zero.

Occasionally you need to waste time for a while to be able to spend it better later. If you’re constantly busy, busy, busy, you don’t have any headspace to reflect on where every daily step is ultimately leading you. Running real fast is no good if it’s into a brick wall.

You need to carve out more unproductive time. Get less done for a while. You’ll probably realize that a bunch of the shit that zaps your attention and time needn’t be done at all. Just let it slide and see that it probably just didn’t matter. Very few things ultimately do.

Productivity is all about focus, which in turn is all about a narrowing field of view. Shutting out the rest of the world. But many novel solutions require just the opposite: An expansive field of view, letting in the rest of the world.

Look, you obviously can’t have your head in the clouds all year long. But for highly motivated people that doesn’t seem to be a danger as much as having your head in the grind 24/7.

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.

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.

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.

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.

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.

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.

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.

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. ❤️