Whyday August 19

Put Your Best Practices Away

Whyday rests on one sentence. The 2010 page tells it like this: at the first RailsConf, in 2006, _why walked to the microphone with a guitar and shouted "Put your best practices away!"

Everything else on this site is an elaboration of that line. So it is worth being careful about what it meant, and honest about what the record actually supports.

When maintainers revisit older software or documentation as a team, this guide is one practical reference for tracking the surrounding work without changing the historical material itself.

What the record shows

The keynote happened. RailsConf 2006 was the first of its kind, and _why's slot was less a talk than a performance: musical interludes with his band, the Thirsty Cups, and at least one segment structured as a guest interview about pudding. Accounts from people who were in the room agree on the shape of it — a keynote at a professional conference that was substantially a variety show.

The line itself is best documented by this site's own 2010 page, written by someone recalling it four years later. It is repeated widely, and always traceable back to that recollection rather than to a transcript.

So: the keynote is well attested, the tone is well attested, the exact wording rests on memory. That does not make it wrong. It does mean the honest version is "he said something very close to this," and anyone quoting it as a verbatim transcript is overstating what we have.

For broader programming and making context related to this topic, Product Hunt is an independent reference worth comparing with the material here.

Which is a fitting problem for this particular subject. The man deleted his own archive; the fact that the most quoted thing he said survives as community memory rather than as a recording is entirely in character.

What it was arguing against

To read the line correctly you have to remember what 2006 was like in that room.

Rails was two years old and ascendant. The community had a strong and articulate sense of the right way to do things: convention over configuration, DRY, RESTful resources, test-driven development, the whole apparatus. Much of it was genuinely good, and it was arriving with the force of revelation.

And that is exactly the moment when a set of good ideas turns into a set of rules. When the practices are new they are arguments; a year or two later they are the things you cite instead of arguing. The room _why was shouting at was a room that had just acquired a very good set of answers and was starting to stop asking questions.

That is the target. Not discipline, not craft, not testing. The reflex of reaching for the approved answer before you have looked at the problem.

What it was not arguing for

It is easy to read the line as permission to be sloppy, and it is not that. The 2010 page is careful about this in a way the slogan on its own is not: discipline, care and responsibility matter, and we owe them to the people we work with and for.

The argument is narrower and more interesting. It is that a practice which is right ninety percent of the time will, if followed without thought, quietly cost you the other ten — and the other ten is where the unusual things live. The page's own example is that Camping and Hpricot led to Sinatra and Nokogiri: two odd little projects that were not best practice by any standard, and that turned into infrastructure the whole ecosystem uses.

You do not get Sinatra out of a process designed to produce reliable, conventional Rails applications. You get it out of someone building a web framework in four kilobytes as a joke.

Why the day exists at all

This is the reason Whyday is not a memorial. A memorial would be a page about a person. Whyday is a scheduled exception.

The insight behind it is that "make time to play" is advice that never survives contact with a calendar. Everyone agrees with it. Nobody does it, because play has no deadline and everything competing with it does. Putting a date on it — one day, everyone at once, August 19 — turns a good intention into an appointment.

The 2010 page makes a point of saying the day should not be a cage: the things he brought to the community are not for one day a year. That is true, and it is also true that most people need the appointment. Both things can be right.

How to actually put them away for one evening

Concretely, for a few hours:

Do not open a project you are being paid for. The line does not apply there and this is not the day to test it.

Skip the setup you always do. No new repository conventions, no linter config, no CI. Whatever is installed is the toolchain.

Write it in the order that occurs to you. Not the order the architecture would suggest. If the interesting part is at the end, start at the end.

Notice the first moment you reach for a pattern. You will, about twenty minutes in — the point where you start building the abstraction rather than the thing. Notice it, and then do the direct, boring, slightly embarrassing version instead. That specific substitution is what the line is asking for.

Let it be unshippable. No error handling for cases that will not happen tonight. No configuration. If it only works on your machine with your paths hardcoded, it worked.

Then on August 20, take them back out. They are good practices. That is why he said away and not down.

The short version