It’s axiomatic these days — The Customer Is Always Right. You’ll hear from all sorts of customer service gurus. But it isn’t true, and you need to realize that. What brought it home to me was recently re-hearing a radio interview from a decade ago.
Twelve Years As A Slave was a big movie, won some Oscars, including one for the screenwriter, John Ridley, jr. But this isn’t about him. It’s about his father.
His father was an ophthalmologist here in Milwaukee for several decades, retiring near the turn of the century.
He was told when the opportunity arose that Milwaukee was a good choice, “black looks good in Milwaukee,” his friends said. How good? Well, upon arrival his car was surrounded by white youths who told him to go back where he belonged. Maybe the idea was a little oversold, eh?
But even in the face of a welcome like that, the man persevered. He found a job working with Dr. Hinz, a highly respected ophthalmologist in the city. He’d work half the day in the office of Dr. Hinz, learning the practicalities of being a ophthalmologist: how an office worked, how to set up, etc. Because of his successful practice Dr. Hinz was a good example for him to follow. And for us all, as it turns out.
This is where the part about being right I mentioned comes in.
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.
Given the recent BritRuby brew-up and the associated wailing and gnashing of teeth, I think it’s appropriate to put my own thoughts forward on this topic. While I’ve not organized a technical conference (yet) I’ve been the sole organizer of chess events catering to areas spanning a single city up to a full hemisphere, and been part of groups organizing literary conferences, so perhaps I have a little to contribute to the public post-mortem currently going on.
Let me start out with a simple fact: I’m a dog-lover, and I prefer mongrels. Pure-bred dogs (and my first dog was a pure Collie, so I’m speaking from some experience) come with issues. They can be nervous, even neurotic. Quick to anger (or hide). Prone to various diseases and birth defects.
Most of these issues don’t show up in mongrels. The mongrels I’ve owned were stable, loving and useful pets. They weren’t nervy, rarely got sick. The hardiness comes from the genes of one breed canceling out the weaknesses in the genes of another. (It’s like metallurgy. You want the iron to be stronger, more useful, you mix in some other elements. Alloys are the mongrels of metallurgy.)
So it goes when it comes to conferences. The wider the experience and cultural base of the presenters, in general the more they have to offer that I haven’t yet seen or learned. Yum.
I wrote a little while ago about the advisability of teaching software patterns to beginning developers as well as experienced ones. But it occurs to me there’s reason for doing it that I may not have covered completely.
Iâ€™m going to take as my starting point Donald Knuthâ€™s idea that the main task in software development is to explain to other developers what we want the computer to do, that the primary audience of source code is a human, not a machine. That seems obvious enough to not need much supporting evidence. Nobody lives forever, no one stays in the same job forever; everybody gets replaced, either voluntarily or involuntarily.
While the syntax of the language makes this communication possible, we still need a common conceptual base to make it efficient. Even in English itâ€™s easy to come away from a single sentence with multiple meanings; development languages, with their near-total focus on what over why, can be even more adept at hiding meaning.
Or, In Defense Of Software Patterns.
I was listening to Ruby Rogues podcast episode #56 when the discussion turned to software patterns, and my teeth started grinding.
It wasn’t so much about what was said (though there were enough of those moments, to be sure) as about what was implied or left unsaid. With one exception (to come later) I’m going to leave names out of this, simply because I want the discussion to center on the ideas, not the personalities. Listen to the podcast, and you’ll be clear enough about who said what, if the who of it means that much to you. I’ll just say the guest and the rogues are all not short of accomplishments and as a group contain very good developers.
The implication that came out of it, and that was only halfheartedly challenged, was that software patterns weren’t useful things to teach beginning developers. The statement that made the show notes was “You need to feel the pain and understand the pattern before you begin to understand when and why to use it and when to deviate.” While the statement itself is defensible, it’s really irrelevant to the value of software patterns for either experienced or nascent developers. My own first reaction was, “So?, What’s your point?” Continue reading