So, my guest shot on Ruby Rogues is now in the can. I didn’t do as well as I would have liked. Was it nerves, or the 100-degree fever I was running at the time? More than likely it was that I simply prepared for the wrong discussion.

It’s nobody’s fault but my own; it’s a wide topic and the narrow bit I wanted to talk about soon was left behind as wider topics aired, and the discussion ranged farther afield than I had prepared data for. Mea Culpa. I did a bad job of preparing myself to guest. It happens. It will be neither the first nor the last mistake I make. (At least I hope it’s not my last; the day I make my last mistake will be the day I die.) You learn from it and move on.

As this whole thing started with me shooting my mouth off, I’ll bring it back here, in a format I’m comfortable with and with a head not so encumbered with medication.

There’s a problem in our industry that we all have horror stories about, but we seem to be treating it as if it’s incurable. And I find that puzzling. Most developers I know got into the field because they loved solving problems. And here’s a problem. Yet we’re acting as if it weren’t possible to solve it?

I can’t accept that. And that’s where I was coming from. We have loads of people who come into our field on their own. They start learning on their own. They code, and they repeat the mistakes that have been made (and solved) decades ago. And there’s a very real and very strong faction in the industry that claims this is As It Should Be.

Bollocks. That is a large steaming pile of male bovine excrement. That is nothing more than the return of the “priesthood” mentality I fought to get away from in the 70’s and 80’s, the idea that programming is a form of magic, and you must endure your initiation rituals through the Hazings of Non-Scalability and Tight Coupling (et al.) before you are worthy to enter into the Holy Hall Of Patterns. It isn’t worthy of us.

I might have sounded a bit flippant there, but I was serious. If we know something is a problem, and we know ways of thinking that can avoid it, and we hold that information back because the developer in training hasn’t “felt the pain” yet, aren’t we doing a form of hazing — intentionally making someone suffer before deigning to let them join our ranks? The road to advancement is hard enough, there’s no need to artificially increase the difficulty.

First, we need to put to a final bloody death the damaging notion that one “cannot begin to understand” a concept until one has “personally experienced the pain” of doing without it. We all have learned far more from the vicarious experience of others than from our own. If I started up a table saw in front of you, I daresay the vast majority of you who did not stick your hand in the blade had never done so in the past. Yet you still learned not to. How about electricity? I suspect far more of you would work very hard to avoid being in a house without electricity for a week of a Wisconsin winter than actually have experienced it. You know it’s something to avoid, even though you haven’t personally experienced it.

No other field of human endeavor seems to suffer from this sort of hubris, that we start as tabula rasa and may only write what we directly experience. A bricklayer doesn’t demand his apprentices lay brick badly before showing them the right way to do it. A plumber teaches her apprentice the right way to do it first, and then checks their work to ensure they did it the way she taught them.

So if other fields don’t work this way, obviously the problem isn’t either incurable nor inevitable. It’s cheap and easy to say programmers all have this or that personality quirk; I just don’t think it’s either valid or useful. I’ve spent 45 years hearing the same drivel spouted about science fiction fans, and I know first hand it isn’t true there, either. Pull the other one.

So how do other fields allow self-starters and self-learners to “get up to speed” in their fields? By preserving, not ignoring, the past. Craftsmen through the ages looked at the work of those that went before them, saw what they did good, and what they didn’t. And passed those judgements on. And we don’t.

I joked the primary function of a junior developer is to write bad code. That isn’t to say the senior developer never writes bad code, but rather that along the road from junior to senior you (hopefully) learn to write less bad code.

It would not surprise me if it were true that every system of any significance ever written contains bad code. But what would absolutely astonish me would be if no system of any significance ever written contains good code. There are plenty of examples, I am sure, of cute ideas coded clearly and used well.

Where we (I include myself in this) have failed is we haven’t called them out. In every other field of literature there are known established examples of excellence that the neophyte can study to learn how to practice their craft better. Writers get not only books about writing, but they get reading lists of great examples of How It Is Done. We leave it up to the beginners to make their choices about what code to read; how can we claim to be surprised by what comes of that?

It’s the same in chess. We have a saying in chess education: “Study The Classics.” Not only are there treatises on the game, or specific phases of it. There are game collections. Beyond that, there are acknowledged masterpieces. You could show a top player today a position from a significant game of a century ago, and they could quote the rest of the game to you, and probably show you two or three similar examples.

But in the world of software development, we have treatises that can be considered “classics” (often with names like Robert Martin, Kent Beck, Martin Fowler or Michael Feathers attached) but we haven’t compiled (you should excuse the pun) the accompanying library of classic code. Where is our “reader’s library” to go with the “teaching library?”

I fear that until such a library gets widely disseminated, we’re doomed to forever repeat the mistakes of the past.