The Art of Strategic Laziness

David Heinemeier Hansson ("DHH")

David Heinemeier Hansson (“DHH”)

The following is a guest post by Shane Snow, a frequent contributor to Wired and Fast Company.  Last year, he wrote about his two-week Soylent experiment, which went viral and racked up 500+ comments.

This post is adapted from his new book, SMARTCUTSand it will teach you a few things:

  • How to use strategic “laziness” to dramatically accelerate progress
  • How “DHH” became a world-class car racer in record time, and how he revolutionized programming (they’re related)
  • A basic intro to computer programming abstraction

Note: the technical aspects of programming have been simplified for a lay audience.  If you’d like to point out clarifications or subtleties, please share your thoughts in the comments!   I’d love to read them, as I’m thinking of experimenting with programming soon.

Enter Shane Snow

The team was in third place by the time David Heinemeier Hansson leapt into the cockpit of the black-and-pink Le Mans Prototype 2 and accelerated to 120 miles per hour. A dozen drivers jostled for position at his tail. The lead car was pulling away from the pack—a full lap ahead.

This was the 6 Hours of Silverstone, a six-hour timed race held each year in Northamptonshire, UK, part of the World Endurance Championship. Heinemeier Hansson’s team, Oak Racing, hoped to place well enough here to keep them competitive in the standings for the upcoming 24 Hours of Le Mans, the Tour de France of automobile racing.

Heinemeier Hansson was the least experienced driver among his teammates, but the Oak team had placed a third of this important race in his hands.

Determined to close the gap left by his teammate, Heinemeier Hansson put pedal to floor, hugging the curves of the 3.7-mile track that would be his singular focus for the next two hours. But as three g’s of acceleration slammed into his body, he began to slide around the open cockpit. Left, then right, then left. Something was wrong with his seat.

In endurance racing, a first place car can win a six- or 12-hour race by five seconds or less. Winning comes down to two factors: the equipment and the driver. However, rules are established to ensure that every car is relatively matched, which means outcomes are determined almost entirely by the drivers’ ability to focus and optimize thousands of tiny decisions.

Shifting attention from the road to, say, a maladjusted driver’s seat for even a second could give another car the opportunity to pass. But at 120 miles per hour, a wrong move might mean worse than losing the trophy.  As Heinemeier Hansson put it, “Either you think about the task at hand or you die.”

Turn by turn, he fought centrifugal force, attempting to keep from flying out while creeping up on the ADR-Delta car in front of him.

And then it started to rain…


When Heinemeier Hansson walked onto the racing scene in his early 30s, he was a virtual unknown, both older and less experienced than almost anyone in the leagues. A native of Denmark, he’s tall, with a defined jaw and dark spikey hair. At the time he raced 6 Hours of Silverstone, it had been about five years since he first drove any car at all.

That makes him one of the fastest risers in championship racing.

Despite that, Heinemeier Hansson is far better known among computer programmers—where he goes by the moniker DHH— than car enthusiasts. Though most of his fellow racers don’t know it, he’s indirectly responsible for the development of Twitter. And Hulu and Airbnb. And a host of other transformative technologies for which he receives no royalties. His work has contributed to revolutions, and lowered the barrier for thousands of tech companies to launch products.

All because David Heinemeier Hansson hates to do work he doesn’t have to do.

DHH lives and works by a philosophy that helps him do dramatically more with his time and effort. It’s a principle that’s fueled his underdog climbs in both racing and programming, and just might deliver a win for him as the cars slide around the rainslicked Silverstone course.

But to understand his smartcut, we must first learn a little bit about how computers work.


Think of the way a stretch of grass becomes a road. At first, the stretch is bumpy and difficult to drive over. A crew comes along and flattens the surface, making it easier to navigate. Then, someone pours gravel. Then tar. Then a layer of asphalt. A steamroller smooths it; someone paints lines. The final surface is something an automobile can traverse quickly. Gravel stabilizes, tar solidifies, asphalt reinforces, and now we don’t need to build our cars to drive over bumpy grass. And we can get from Philadelphia to Chicago in a single day.

That’s what computer programming is like. Like a highway, computers are layers on layers of code that make them increasingly easy to use. Computer scientists call this abstraction.

A microchip—the brain of a computer, if you will—is made of millions of little transistors, each of whose job is to turn on or off, either letting electricity flow or not. Like tiny light switches, a bunch of transistors in a computer might combine to say, “add these two numbers,” or “make this part of the screen glow.”

In the early days, scientists built giant boards of transistors, and manually switched them on and off as they experimented with making computers do interesting things. It was hard work (and one of the reasons early computers were enormous).

Eventually, scientists got sick of flipping switches and poured a layer of virtual gravel that let them control the transistors by typing in 1s and 0s. 1 meant “on” and 0 meant “off.” This abstracted the scientists from the physical switches. They called the 1s and 0s machine language.

Still, the work was agonizing. It took lots of 1s and 0s to do just about anything. And strings of numbers are really hard to stare at for hours. So, scientists created another abstraction layer, one that could translate more scrutable instructions into a lot of 1s and 0s.

This was called assembly language and it made it possible that a machine language instruction that looks like this:

10110000 01100001

could be written more like this:

MOV AL, 61h

which looks a little less robotic. Scientists could write this code more easily.

Though if you’re like me, it still doesn’t look fun. Soon, scientists engineered more layers, including a popular language called C, on top of assembly language, so they could type in instructions like this:

printf(“Hello World”);

C translates that into assembly language, which translates into 1s and 0s, which translates into little transistors popping open and closed, which eventually turn on little dots on a computer screen to display the words, “Hello World.”

With abstraction, scientists built layers of road which made computer travel faster. It made the act of using computers faster. And new generations of computer programmers didn’t need to be actual scientists. They could use high-level language to make computers do interesting things.

When you fire up a computer, open up a web browser, and buy a copy of my book online for a friend (please do!), you’re working within a program, a layer that translates your actions into code that another layer, called an operating system (like Windows or Linux or MacOS), can interpret. That operating system is a probably built on something like C, which translates to Assembly, which translates to machine language (1s and 0s), which flips on and off a gaggle of transistors.


So, why am I telling you this? 
In the same way that driving on pavement makes a road trip faster, and layers of code let you work on a computer faster, hackers like DHH find and build layers of abstraction in business and life that allows them to multiply their effort.

I call these layers platforms.


At college in the early aughts, DHH was bored. Not that he couldn’t handle school intellectually. He just didn’t find very much of it useful.

He practiced the art of selective slacking. “Some of my proudest grades were my lowest grades,” he tells me.

We all know people in school and work with a masterful ability to maintain the status quo (John Bender on The Breakfast Club or the bald, coffee-swilling coworker from Dilbert), but there’s a difference between treading water and methodically searching for the least wasteful way to learn something or level up, which is what DHH did.

“My whole thing was, if I can put in 5 percent of the effort of somebody getting an A, and I can get a C minus, that’s amazing,” he explains. “It’s certainly good enough, right? [Then] I can take the other 95 percent of the time and invest it in something I really care about.”

DHH used this concept to breeze through the classes that bored him, so he could double his effort on things that mattered to him, like learning to build websites. With the time saved, he wrote code on the side.

One day, a small American web-design agency called 37signals asked DHH to build a project management tool to help organize its work. Hoping to save some time on this new project, he decided to try a relatively new programming language called Ruby, developed by a guy in Japan who liked simplicity. DHH started coding in earnest.

Despite several layers of abstraction, Ruby (and all other code languages) forces programmers to make countless unimportant decisions. What do you name your databases? How do you want to configure your server? Those little things added up. And many programs required repetitive coding of the same basic components every time.

That didn’t jibe with DHH’s selective slacking habit. “I hate repeating myself.” He almost spits on me when he says it.

But conventional coders considered such repetition a rite of passage, a barrier to entry for newbies who hadn’t paid their dues in programming.  “A lot of programmers took pride in the Protestant work ethic, like it has to be hard otherwise it’s not right,” DHH says.

He thought that was stupid. “I could do a lot of other interesting things with my life,” he decided. “So if programming has to be it, it has to be awesome.”

So DHH built a layer on top of Ruby to automate all the repetitive tasks and arbitrary decisions he didn’t want taking up his time. (It didn’t really matter what he named his databases.) His new layer on top of programming’s pavement became a set of railroad tracks that made creating a Ruby application faster. He called it Ruby on Rails.

Rails helped DHH build his project—which 37signals named Basecamp—faster than he could have otherwise. But he wasn’t prepared for what happened next.

When he shared Ruby on Rails on the Internet, programmers fell in love with it. Rails was easier than regular programming, but just as powerful, so amateurs downloaded it by the thousands. Veteran coders murmured about “real programming,” but many made the switch because Rails allowed them to build their projects faster.

The mentality behind Rails caught on. People started building add-ons, so that others wouldn’t have to reinvent the process of coding common things like website sign-up forms or search tools. They called these gems and shared them around. Each contribution saved the next programmer work.

Suddenly, people were using Ruby on Rails to solve all sorts of problems they hadn’t previously tackled with programming. A toilet company in Minnesota revamped its accounting system with it. A couple in New Jersey built a social network for yarn enthusiasts. Rails was so nice that more people became programmers.

In 2006 a couple of guys at a podcasting startup had an idea for a side project. With Rails, they were able to build it in a few days—as an experiment—while running their business. They launched it to see what would happen. By spring 2007 the app had gotten popular enough that the team sold off the old company to pursue the side project full time. It was called Twitter.

A traditional software company might have built Twitter on a lower layer like C and taken months or years to polish it before even knowing if people would use it. Twitter—and many other successful companies—used the Rails platform to launch and validate a business idea in days. Rails translated what Twitter’s programmers wanted to tell all those computer transistors to do—with relatively little effort. And that allowed them to build a company fast. In the world of high tech—like in racing—a tiny time advantage can mean the difference between winning and getting passed.

Isaac Newton attributed his success as a scientist to “standing on the shoulders of giants”—building off of the work of great thinkers before him.

Platforms are tools and environments that let us do just that. It’s clear how using platforms applies in computer programming, but what if we wanted to apply platform thinking to something outside of tech startups?

Say, driving race cars?


David Heinemeier Hansson was in a deep hole. Halfway through his stint, the sprinkling rain had become a downpour. Curve after curve, he fishtailed at high speed, still in third place, pack of hungry competitors at his rear bumper.

LMP cars run on slick tires—with no tread—for speed. The maximum surface area of the tire is gripping the road at any moment. But there’s a reason street vehicles have grooves in them. Water on the road will send a slick tire drifting, as the smooth rubber can’t channel it away. Grooved tires push water between the tread, giving some rubber grip and preventing hydroplaning. The slicker the tires—and the faster the speed—the more likely a little water will cause a car to drift.

That’s exactly what was happening to the LMP racers. As the rain worsened, DHH found himself sliding around the inside of a car that was sliding all over the race track. Nearby, one driver lost grip, slamming into the wall.

Cars darted for the pits at the side of the track, so their teams could tear off the slick tires and attach rain tires. Rain tires are safer, but slower. And they take a precious 13-plus seconds to install. By the time the car has driven into the pits, stopped, replaced the tires, and started moving again, more than a minute can be lost.

DHH screamed into his radio to his engineer, Should I pit in for new tires?

Like I said, DHH wasn’t the most experienced racer. He had gotten into this race because he was skilled at hacking the ladder. A few years into 37signals’s success, and with Rails taking a life of its own, Hansson had started racing GT4—essentially souped-up street cars—in his spare time.

Initially, he finished in the middle of the pack with the other novices. But after studying videos of master drivers, he started placing higher. High enough that after six races, he was allowed to enter into GT3 races (the next level up), despite zero first-place wins. In GT3, he raced another six times, placing first once, third another time. He immediately parlayed up to GTE (the “E” is for “endurance”). While other racers duked it out the traditional way, spending a year in each league, and only advancing after becoming league champion, DHH “would spend exactly the shortest amount of time in any given series that I could before it was good enough to move up to the next thing.”

There’s no rule that says you have to win the championship to advance from GT4 to GT3. Nor is there a rule saying you have to spend a year in a given league before moving up. That’s just the way people did it. Instead, DHH compressed what normally takes five to seven years of hard work into 18 months of smart work. “Once you stop thinking you have to follow the path that’s laid out,” he says, “you can really turn up the speed.”

On the rainy Silverstone course, however, parlays couldn’t help him anymore, and slacking was not an option. DHH had to drive as fast as safely possible, and every microsecond counted. In such tight competition, the only edge a racer had was raw driving skill.

Or, as it turned out, a better platform.


SHOULD I PIT IN? The man who hates repeating himself repeated over the radio. I’m going to end up in the wall!

His engineer told him to tough it out. The rain is about to clear up.

G-force pounding his body, DHH cautiously hugged the curves for another lap, and sure enough, the downpour began to subside. By two laps the course was dry. Heinemeier Hansson’s slick tires gripped the track with more friction than his competitors’ newly fitted rain tires and he sped ahead. The other drivers now had to pit back in for slick tires, for a total of nearly two minutes’ delay that DHH entirely avoided.

At the end of his leg of the relay, DHH jumped from the car, having demolished the competition.

The slick tires provided DHH a platform advantage, more leverage to drive faster with the same pedal-to-floor effort. And though driving slick in the rain had been risky, his skill learned by imitating master racers kept him alive.

Reflecting on his rapid ascent in racing, DHH says, “You can accelerate your training if you know how to train properly, but you still don’t need to be that special. I don’t think I’m that special of a programmer or a businessperson or a race car driver. I just know how to train.”

DHH had proven he had the skill to race. Videos of master drivers had helped him to learn quickly. His tire advantage had pushed him ahead of equally skilled drivers, and propelled him to the next level. And the advanced racing leagues themselves became a platform that forced him to master the basics—and faster—than he would have at a lower level.

When DHH returned to visit his home race track in Chicago, the same set of drivers still dominated the lower leagues.

He came back and effortlessly beat them.



Effort for the sake of effort is as foolish a tradition as paying dues. How much better is hard work when it’s amplified by a lever? Platforms teach us skills and allow us to focus on being great, rather than reinventing wheels or repeating ourselves.

“You can build on top of a lot of things that exist in this world,” David Heinemeier Hansson told me. “Somebody goes in and does that hard, ground level science-based work…”

“And then on top of that,” he smiles, “you build the art.”


Question of the day (QOD):  What other selectively “lazy” innovators can you think of?  People who’ve looked at problems in novel ways, or solved them in non-obvious ways? People who’ve opted for simplicity when most “experts” are choosing complexity?

Please share in the comments.

Posted on: August 25, 2014.

Watch The Tim Ferriss Experiment, the new #1-rated TV show with "the world's best human guinea pig" (Newsweek), Tim Ferriss. It's Mythbusters meets Jackass. Shot and edited by the Emmy-award winning team behind Anthony Bourdain's No Reservations and Parts Unknown. Here's the trailer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Comment Rules: Remember what Fonzie was like? Cool. That’s how we’re gonna be — cool. Critical is fine, but if you’re rude, we’ll delete your stuff. Please do not put your URL in the comment text and please use your PERSONAL name or initials and not your business name, as the latter comes off like spam. Have fun and thanks for adding to the conversation! (Thanks to Brian Oberkirch for the inspiration)

98 comments on “The Art of Strategic Laziness

  1. Love this analogy between coding, racing, and business!
    Being a web designer myself, I know how time-saving layers of abstractions, or platforms as you call them, are. They’re leveraging my time every single day!

    Coming to business, I’d translate those platforms into leveraging more successful people, who already achieved what you want to achieve. I try to build relationships with people and understand why they’re doing what they’re doing. Found that this is a good way to speed up learning and grow a business faster.

    Great stuff!

    Liked by 2 people

  2. As for your QOD: There is actually a company in The Netherlands called Strategically Lazy (Strategisch Lui). It’s run by one smart guy who helps people to use time wisely and have loads of free time, just like him, and he is good at it!

    Liked by 3 people

  3. Awesome post! But I am going to use up this space to ask an unrelated question:

    Tim, is there any way you could share the Q&A of August 11?

    I can present an argument about how I am in need to hear your profound and entertaining answers again. But the real truth is: you say my name in it. And it might be a once in a lifetime thing. .


    • Hi Viyan,

      Thank you for the comment and kind words. No worries on the Q&A. If you signed up for the emails and attended, just see the email that came right *after* the Q&A. It contains a link to the recording of the Q&A :)

      All the best,



      • Tim, unfortunately the Q&A is no longer available in Spreecast.

        I get this message: This Spreecast has expired
        Spreecasts created with a Basic account expire after 7 days.

        Could you please enable it or upload it? I could only listen to a part of it and it was very interesting. I hope you or someone has a copy!


        Liked by 1 person

      • Hi Tim,

        Thank you for your kind response. Like Alberto says, I forgot to mention that the video on Spreecast expired after 7 days. I hope you can do something about it!

        You are amazing.Take good care of yourself now you have Lyme disease :).




  4. Great. Really love that the guy was able to progress in Motor racing by using videos of professionals, really inspirational story, also didn’t know Ruby on Rails’ back story which was great to learn.

    However, and this is my biggest problem with all hacking of what are traditionally time served skills, how do I know what are the fundamental lessons to learn?

    I have no issue with the basis of the concept, but if I could have chosen between an A and a C at school / college, based on the 95 / 5% indicated, what do you think I would have chosen. The issue is, I needed to do my best each and every time, to make sure the work I did was up to spec (the difference between any A’s and C’s was my comprehension of the subject, achieved through time served work)

    The A’s to C’s variation above sounds more like knowing the requirements of the test and learning the C stuff, without achieving the comprehension for the higher grades, but, and where this falls down, most stuff in life doesn’t have specific answers for specific questions like a course exam, they are more fluid and move able subjects, or subjects where the requirements aren’t written down.

    Knowing the fundamental lessons means knowing what you are learning. An example in my eyes is I have no clue about Quantum mechanics, so I will make up a few principles and learn those.

    When you don’t know anything about a subject, how do you know what are the right things to learn?

    Whilst I don’t want to push the point on this, because who doesn’t want to use this technique to save time learning what I need to know, to be able to get to the juicy bits of what comes after, The question to the pit crew about what he should do, was at minimum lack of knowledge from time served, and at most blatant luck. The weather reports that come back can be a little off, and as such, the same decision in a different race would have had disastrous consequences, and you wouldn’t be singing his praises. This was a poor example of skill hacking.

    Liked by 2 people

    • To synthesize and echo Tim’s comments throughout the books; Knowing what to study is the result of taking the time necessary to Deconstruct.
      There is time involved in this, of course, but as we’ve seen time and time again, front-loading the work needed to work smarter allows you to then focus on what’s really important.

      Instead of spending 40 hours from beginning to end, spending 5 hours to deconstruct, then 20 on sequencing, learning and practice.

      From the beginning, this can feel like “it’s going to be 5 + 40; so much extra work!”, but in reality the effectiveness of the work is what’s going to propel someone to higher levels.


  5. best laziness trick I learned – naps. Instead of slogging through the rest of my day, I take a 15-30 minute nap when I get home from work (1 hour on weekends) and I feel more alert for the rest of the evening. And that might mean the difference cooking a healthy meal vs ordering a pizza, or going to the gym vs watching TV.


  6. This article was a great read, thank you. But it’s also left me a little bit puzzled because I am not sure what I am supposed to learn from it.

    I get the strategic laziness idea, and that’s how I got through school too. But I’m not sure how the racing or development of rails is supposed to fit into this. The racing example seems like a lucky break to me. DHH and his crew took a gamble that the weather would clear up, and they were right. This doesn’t sound like strategic laziness, this sounds like a top performer who was willing to take extra risks to win, and who lucked out with the weather in the process. Look up the story of Niki Lauda to see how that could have ended. I worry the wrong lesson is being imparted here.

    The Rails example also didn’t sit right with me. It’s an awesome story, but it takes way more programming effort to write a framework than it does to use inferior tools. It just happens to be a hell of a lot more rewarding, and in the case of DHH it was well well worth it because of where Rails went. Lots of good lessons here, like DHH saw a market need and filled it. But I don’t really see how he took a shortcut.

    I don’t mean to knock the article (and big props to DHH on all his accomplishments). But I’d really like to know what the author of this article thinks in response.


    • What I got from this is looking at tasks where I am repeating myself. And see if I can do everything in a smarter, more evolved way. And maybe even change the ways things are being done in my industry. So thanks!

      Liked by 1 person

  7. Tim, learning your first programing language is like learning math for the first time, most people get the hang of it within one or two semesters. For best results, work on a project you find interesting, ie a game or vanity website, and you’ll learning ability will dramatically accelerate, it will even be fun.

    Programing, similar to Spoken languages, once you learn one, you can quickly learn all others with only a fraction of the effort, sometimes as little as a couple weekends. have fun.


  8. Blown away by the serendipitous timing of this post. Just made a major decision this morning, before finding this article in my inbox, to reengineer my life based on smarter-not-harder, efficiency focused thinking. Such an inspiring read. Thank you!

    Liked by 1 person

  9. Really interesting story! David’s approach, being smart by being lazy, has without a doubt been a big inspiration for many techies. Not only in programming, but also as an approach to business.

    My latest piece of art, built on top of “ground level science-based work” is – the fastest way to record your screen and send it to a colleague or client.

    Apple’s talented developers consistently releases great API’s that programmers can built on top of. In my case, this meant that I could spend more time focusing on user experience and less time developing algorithms.


  10. I fully support the principles in the blog and would further suggest the use of checklists for faster project execution to avoid ‘re inventing work, and take a look at ray dalio’ s five behaviours. Use of these will get you to your desired results super fast.


  11. I just saw a startup on TechCrunch today that makes investing strategically lazy. The idea is like Bank of America’s “Keep the Change” where all of your transactions are rounded to the nearest dollar and invested. Except that they invest it in a balanced fund of ETFs instead of a pitifully low earning savings account.
    It takes a few minutes to set up and it’s always a pain to find your account/routing numbers and enter bank passwords on a mobile device. But once you’ve done that, you can set it on “Auto” mode, and every time you spend money on your credit card, it’ll round that amount up to the nearest dollar, deduct it from your checking account, and invest it in your portfolio.



  12. I use something along those lines at the office; I have the “keep the lights on” work that is boring but (mostly) necessary* and the stuff that’s fun and helps drive the business forward. I spend as little time as possible on the former – the C grade; enough to get the job done but not enough that anyone will look at it and say “he’s so good at that he should be doing it full time” – and reserve the vast majority of my day/week to absolutely rock on the stuff I enjoy doing that I think has the best impact on the business.

    The result over the last year (since I started doing that) has been incredible: the “keep the lights on” stuff slowly gets pushed to others, the fun projects head my way and I have people from other organizations coming to me asking me how I am as effective as I am (along with a couple of job offers).

    Obviously it’s a little different in a corporate environment than in the personal life or as a sole proprietor, but the concepts still apply (just substitute “virtual assistant” or “kids” or “temp agency” or whatever for co-workers).