On Writing Software Well


I’ve begun a new YouTube series called On Writing Software Well where I explore the real Basecamp codebase in search of interesting programming topics. It’s less “here’s how to do it” and more “here’s what I was thinking when we made this choice or took this direction”. And it’s intimately grounded in real, production code that’s been used by millions of people.

It’s partly a reaction to the endless debates we tend involve ourselves in as software writers without looking at real code. When you debate without code, you’re likely to get sucked into illusions of disagreement. You argue from your experiences with codebase A, I argue from my experiences with codebase B, and we clash because A isn’t B. That’s just silly.

Yet somehow arguments grounded in production code are rare. Few people seem willing to lift the curtain on such codebases, which is a damn shame. Because that’s where the real wisdom is buried. That’s where people have been forced to make actual trade-offs between competing patterns and practices. It’s those trade-offs and the circumstances around them that are valuable.

Programming arguments based in example code is most often stylized and idealized. It’s Platonic shadows on the cave wall. So easy to dig in and defend a technique when you don’t actually have to worry about guarding the flanks, setting up camp, and getting your supply lines in order. You know, like in real life.

So that’s my mission: To take you into the trenches and have you fight by my side in the battle against complexity and in the search for beautiful code.

Yes, the code is all Ruby and Rails, but the principles should travel reasonably well. So even if you don’t do Ruby on Rails, I’d be surprised if there wasn’t something to in there to pique your interest and rattle your convinctions.

Here are the first five episodes:

Programming with a love of the implicit


It’s always better to be explicit! That’s pretty much a programming truism. Rarely directly challenged, lest one betray the foundational tenors of Proper Programming. But challenge it we should, and head on.

The standard justification for being maximally explicit is a kind one. Give a programmer looking at the code everything they need to understand how it works, right there, as if they knew nothing already. It’s an optimization for fresh eyes, those who see without knowing a surrounding context.

So to challenge explicitness as a core value, we need to start by questioning that optimizing for those fresh eyes. Should their needs really to be the main objective for a programming environment?

It could be. If you expect to have rapid churn of the people working on the code, it’s a fair trade to burden those who’ve acclimated with laborious ceremony, if it means those fresh eyes will have an easier time.

That’s a value judgment based on circumstance and experience. To value the experience of the newcomer at the expense of the productivity of the veteran and the succinctness of the code. In some environments, that’ll be the reasonable choice.

But that’s not the environment I’m interested in. At all. I love implicit code, or, as we call it in Ruby on Rails, Convention over Configuration. Consider this tiny snippet of code:

class Person < ApplicationRecord
 belongs_to :company
 has_many :assignments
end

This beautiful excerpt is bursting with implicitness. Just on the database side, it implies that there’s a “people” table backing the “Person” record. It implies that there’s a single “id” primary key for that table. It infers that there’ll be a “company_id” foreign key linking rows in “people” to rows in “companies”.

Here’s an explicit version that expands those contextual assumptions:

class Person < ApplicationRecord
 table_name “people”
 primary_key “id”

belongs_to :company, foreign_key: “company_id”, class_name: “Company”
 has_many :assignments, foreign_key: “person_id”, class_name: “Assignment”
end

And that’s just the tip of the iceberg. It doesn’t even talk about the implicit validation of a belongs_to relationship or the introspection of columns to create attribute methods.

I’d hate to have to write explicit code like that all day, every day. I’m willing to trade the need for someone to learn the conventional context of Active Record in favor of being able to write succinct, clear, and, yes, implicit code. Slightly higher upfront costs, perhaps, but amortized over a lifetime of working with Rails.

This gets to the heart of examining the values of programming environments. A value stated in isolation does not illuminate. Saying “I like explicit code” without also accepting that this means “I like [writing a lot more, often repetitive, frequently boiler-plated] explicit code” is a disingenuous. Values only shine the light for choices when they’re voiced in opposition to different values that others might reasonably prefer.

It’s the same story with product values. If you say your product is “simple” or “easy”, you’re rarely saying much. Few are the competitors who’d take the opposite side of that plank, selling products that are “complicated” and “hard” (though it does happen occasionally!).

To carve out a meaningful, effective belief system, you must be willing to give up something. To embrace explicit code, you must be willing to accept laborious ceremony and the boilerplate. To embrace implicit code, you must teach the context and unpack its at-first bewildering magic.

I embrace implicit code. I embrace the context. I swoon over magic. If you too fancy such sparkle, Ruby on Rails will probably resonate. If not, no worries, most other programming environments pledge allegiance to the defeat of magic and oppose the implicit. Pick your poison.

Horses for courses

You wouldn’t use a race horse to drag a cart

It’s no more sensible to talk about a single category of programmers than it is a single category of writers. Yes, an intimacy with the language is (usually) shared amongst writers, but otherwise journalists and poets don’t have a whole lot in common as part of their daily work. Likewise, a programmer working on a new database storage engine doesn’t share that many overlapping concerns with a programmer writing a new web-based information system.

Yet companies and individuals continue to lump all programmers together in the big “software engineer” basket. That means sharing everything from interview techniques (like the dreaded whiteboard algorithm hazing) to arguing about aesthetics across vastly different levels of abstraction. It’s not only silly, but harmful.

It’s one of the reasons I for the longest time didn’t think I could become a Real Programmer™. I used to think that all programmers needed to love algorithms and pointer arithmetics. That’s about as sensible as thinking you can’t become a journalist because haikus or sonnets don’t appeal to you.

It wasn’t until I discovered programming at a high level of abstraction, the kind suited for making business and information systems, that I started to realize programming, perhaps, was something for me after all. And even then, the original impression of programming being all about these low-level concerns stuck for years, and kept me from imagining a future where this would be my profession.

The ultimate breakthrough happened when I met Ruby. A language so purposefully removed from the atomic blocks of computers. This was my jam. My level of abstraction. A world and a community that not only wouldn’t scorn me for a lack of interest in algorithms or other low-level concerns, but actively encouraged me to embrace programming as the pursuit of happiness at my preferred level.

The world needs all kinds of people with all kinds of fancies. This is no less true for programming than for any other field of expression.


Would you believe that my first real project in Ruby was Basecamp? The original Rails application from which the framework was extracted. Both projects turned out pretty alright for someone who’d only just considered themselves a Real Programmer shortly before.

Join Basecamp as our new Rails programmer

Basecamp is hiring! We have a rare opening for a Rails programmer to work on new product development within our General Practice team. We haven’t had an opening for this kind of work for a few years, so we’re excited to welcome someone new to the team!

This is a position for an experienced Rails programmer, but you don’t have to be a rock star, a ninja, or a superhero to apply. In fact, if you self-identify in any of those categories, we’d rather you don’t!

We’re looking for someone with a strong track record of putting Rails to work and bringing products to life. This is not a junior position, but, imposters everywhere, this is in reach to YOU. If you ship solid work, you have the experience we’re looking for.

We want strong, diverse teams built from different backgrounds, experiences and identities. We’re ready for the ongoing work that goes into building an inclusive, supportive place for you to do the best work of your career. That starts with regularly working no more than 40 hours a week and getting 8+ hours of sleep a night. Our workplace and our benefits are designed to support a sustainable, healthy relationship with your work.

Today, our team works from 32 different cities spread across 6 countries. You can work from anywhere in the world, so long as your normal working day has 4 hours or more overlap with Chicago time (CST/UTC-6). Nomads welcome.

About the Job

The General Practice group at Basecamp works on a regular cadence of 6-week cycles in either Big Batch or Small Batch mode. Our feature teams are small. You’ll usually work with one designer, sometimes another programmer, and usually a tester as well.

That’s just a handful of people expected to regularly ship a big feature in 6 weeks or a small feature in a week or two. This is a fast pace, but it’s never frantic. We don’t have time for harried, hurried work. We value a calm company and deliberate, concerted effort. We work 40-hour weeks here (and less in the summer!). This is not a job for workaholic heroes who thrive on 80-hour+ marathons. NOPE!

Our formula: Capable people left to get great work done in a reasonable amount of time with minimal distractions.

And, of course, you’ll have the full support of some of the best Rails programmers in the business. We literally wrote the framework. Everyone here is keen to help and support newcomers to become part of the team and, ultimately, to do the best work of their career.

While creating new features for Basecamp 3 is mostly greenfield work, there are also a fair share of legacy obligations on our plate. We have the first Rails application ever created still running and serving happy customers. You may well work on the first version of Basecamp or any of the other products we no longer sell but still lovingly support. We cherish our legacy. Take heart when `git blame` reveal lines 12 years or older 😀.

You’ll help us support customers directly. Everyone at Basecamp participates in Everyone On Support every few months, and you’ll regularly help with escalated technical issues.

We’re also staunch supporters of the open source community. Not just through Rails, but plenty of smaller projects as well, including quite a few in JavaScript. Every programmer at Basecamp is encouraged to give back and share our tools.

About You

In broad strokes, Managers of One thrive at Basecamp. We’re committed generalists, eager learners, conscientious workers, and curators of what’s essential. We’re quick to trust. We see things through. We’re kind to each other, look up to each other, and support each other. We achieve together. We are colleagues, here to do our best work.

We’re all quite different people (and we stumble, fall, reach, and achieve just like anyone!) but these are fundamental attitudes we share. What floats your boat? What lights a fire in you? What keeps it burning?

We aren’t looking for ideological clones, but we are looking for people who share our basic values and beliefs about how to write good software. It helps if you can identify as a software writer. If you care about writing clean, concise code. If the thought of a majestic monolith appeals to you. If you seek the epicenter. If you say no.

As an experienced Rails developer, you should be intimately familiar with the framework, with Ruby, and with the stables of full-stack web development: HTTP, JavaScript, CSS, HTML, SQL. It’s a bonus if you’re broadly familiar with other languages as well — we write our iOS app in Swift, our Android app in Kotlin, and have tooling written in Go — but your main work will be Ruby through and through. We ❤️ Ruby, if wasn’t clear by now 😄.

Benefits & Compensation

Our pay is in the top 5% — or better! — of the industry for the matched role and experience, based in Chicago. No matter where you live. Plus, with two years under your belt, you’ll participate in our profit-growth sharing program.

Our benefits at Basecamp are all about helping you lead a healthy life away from work. While we have a lovely office in Chicago, it’s not where you’ll find foosball tables constantly spinning, paid lunches, or any of the other trappings that companies use to lure employees into staying ever longer at work.

Work can wait. Our benefits include 4-day Summer Weeks, a yearly paid vacation, a one-month sabbatical every three years, and allowances for CSA, fitness, massage, and continuing education. We have top-shelf health insurance and a retirement plan with a generous match. See the full list.

How to Apply

Please send an application tailored to this position that speaks to us. Introduce yourself as a colleague. Show us that future.

We value great writers, so please do take your time with the application. Forget that generic resume. There’s no prize for being the first to submit!

We’d like to see examples of software you’ve written. The actual code. We appreciate that it can be hard to share representative samples when you’ve been working on commercial software, so anything you can scrape together will be good. If you have open source contributions, those are great candidates, but you don’t have to be an open source contributor to apply.

You can share private repos on GitHub with @dhh, @packagethief, @sstephenson, and @jeremy. They will be your gentle and kind evaluators on the programming side of things.

Go for it!

We are accepting applications for this position until February 27, 2017. We’ll let you know that we’ve received your application. After that, you probably shouldn’t expect to hear back from us until after the application deadline has passed. We want to give everyone a fair chance to apply and be evaluated.

As mentioned in the introduction, we’re eager to assemble a more diverse team. In fact, we’re not afraid of putting extra weight on candidates from underrepresented groups at Basecamp.

We can’t wait to hear from you!

(And again, imposters: We are too. Take heart. Step up.)

Learning and mastering isn’t the same


When I first began making applications for the web, getting started was hard. Just figuring out which components to download, how to configure them, and getting Hello World through it all was a daunting affair. Frameworks like Ruby on Rails changed that, and now it really is possible to animate a complete database-backed web application in 15 minutes or less.

That means these days you can go from (almost) zero prerequisites to a (sorta) working software prototype in a bootcamp’s worth of introduction material. That’s amazing. Basic proficiency has never been more attainable or approachable.

Given this leap, it’s no wonder that people mistake the beginning for the end. That getting started is the same thing as knowing it all. But it remains a completely unrealistic expectation, and thus a mistake. Building a complete information system, like, say, your Basecamp or Shopify or GitHub or Zendesk remains real work that requires deep skill. It’s foolish to pretend otherwise.

And perhaps we have pretended otherwise at times. I’m certainly guilty of focusing on just how easy we made getting started that the conversation often didn’t extend to the work it takes to finish. Simply because that’s what felt like the main obstacle to getting more people onto the path of learning at the time.

Now that this obstacle is mostly cleared away, it’s time to focus on the latter part of the discussion: Becoming really good at anything takes time. Web development is no different, not even with Rails. We’ve changed the game from “hard to learn, hard to master” to “easy to learn, hard to master”. Yes, the second part remains the same.

I’m still learning. I’m still getting better. And I’ve been at this web development game for damn close to twenty years (if you count when I started dabbling with HTML/CSS). That doesn’t at all mean it’ll take you twenty years to become good at it, but it probably does mean that you should have realistic expectations about what you can learn in three or six months.

And it’s not so much about how long it’ll take you to learn your way around the framework or the language or the ecosystem. It’s as much as how long it’ll take you to become an expert. It’s one thing knowing there are 10 different ways to do a thing; it’s another to know which is a better fit and when.

This is part of why I like to compare writing software with writing prose. Most people in the developed world will have basic proficiency writing their native tongue by the time they finish high school. But how long does it take to become a great writer? Longer than that. Much longer, in most cases. Few find that surprising.

Yet plenty of people do seem to be genuinely surprised that a developer who just picked up Ruby on Rails, or any other extensive framework, language, or ecosystem, doesn’t make all the right choices the first time they’re faced with them. And that’s just plain silly.

Let’s continue to celebrate how easy we’ve made getting started, but let’s also set a realistic timeline for mastery. Not to scare anyone off the journey, but to prepare them for it. A glorious, years-long journey of learning. It’s a lot of fun if you know what you’re in for.

Let’s drop the unrealistic expectation of total transparency in open source

Running a large, long-running open source project like Ruby on Rails is very rewarding but can also be exhausting. The glimmers of glamour usually only sparkle around release time, but the grunt of the grind is daily.

The grind is an endless stream of bug reports, requests, demands, questions, and occasional inquisitions. To avoid getting stuck in the mud, you need to travel as a team, not solo on a lonely road. Without the backing of stable, friendly faces, you simply aren’t likely to go the distance. It’ll be thanks for the fish and adios muchachos!

A big part of this feeling is that co-chairing a popular open source project means you’re always ON in the public space. Every reply to every ticket, every comment to every discussion is fair game for dissection, scrutiny, applause, or ridicule.

Doing the work of justifying choices, presenting arguments, and collaborating on code in public is great for transparency, but also at the heart of why the work is so draining. Everyone needs a place and a time to retreat. To step out of the spotlight and loosen the guard.

We’ve embraced that need on the Ruby on Rails team through a series of contracting circles of intimacy and privacy. There’s the community at large, where all the interactions happen in public on GitHub or the mailing lists or wherever. But then there’s also a Rails Community Basecamp, a Rails Contributors Basecamp, and finally a Rails Core Basecamp.

I appreciate that the standard response from the open source gospel is that this is somehow sacrilegious. That total and complete transparency into all matters of an open source project is more important than the mental well-being of its long-term, key contributors.

I’m sympathetic to that ideal. Surely Rails would be worse off if everything happened behind closed doors, the community at-large wasn’t involved in anything, and releases just dropped from the sky. But there’s a nuanced world of grey beyond those extremes where healthy, happy people live and work.

We’ve long since accepted how pivotal our individual idiosyncrasies are to the art of programming. That much of the work in programming tools and languages reside in tickling the interface between code and our all-too human emotions. It’s well past due that we recognize the same fallibilities are present at the group-level of development, and that we find ways of working to accommodate these.

I’ve worked on Ruby on Rails for more than thirteen years now. The only way that’s been sustainable and enjoyable has been to protect my sanity and motivation in dealing with the encouragement and discouragement, judgment and praise from thousands of strangers over the years.

Letting smaller groups do some of the work and shoulder some of the exhaustion in private has been a key strategy. It’s a small trade-off to complete transparency for the well-being of the most active participants. I’m not going to feel bad about that.


When we started the Ruby on Rails core group back in 2004, it was just a private IRC channel. We then leveled-up to Campfire in 2006. Most recently we’ve leveled-up again to a full-fledged Basecamp 3 account that doesn’t trap us in chat. It’s been liberating!

Mainstream precludes cool


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

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

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

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

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

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

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

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

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

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

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

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

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

Provide sharp knives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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.

All my RailsConf keynotes

(Due to a scheduling conflict, I unfortunately wasn’t able to deliver my regular keynote at RailsConf 2016.)

RailsConf 2007: A peak at Rails 2.0

Unfortunately, I’ve been unable to find the video for this. You’ll have to make do with the slides alone, as I couldn’t even find the audio for this.


Bonus: If you’re really looking for some old school Rails fun, checkout the original 15-minute blog video. WHOOPS! If you want to see the application that gave birth to Ruby on Rails, checkout the all-new version 3 of Basecamp.