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, SMARTCUTS, and 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.
(Phew.)
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?