A while ago, I saw someone on Quora say “real programmers don’t have programming language preferences” which I found absurd. I’m not saying you should use your favorite language for everything (mine is Lisp, and I don’t use it for anything), and some preferences are just snobbery masquerading as expertise.
But I wouldn’t trust any practitioners who have no opinions about their tools, be they doctors, dentists, chefs, painters, drivers, mechanics, artists, writers… I could wax on about how programming is a craft, there is an esthetic to code, a style in each language, which is not going to convince anyone who sees it as just a lump of ascii, so simply put: show me someone who doesn’t care about the tools they use every day to make their living, and I’ll show you someone who’s not interested in what they’re doing.
That Quora user (Quorer?) followed up with a declaration that programmers should instead be “fans” of algorithms and design patterns, which strikes me as inconsistent — even more than programming languages, algorithms and design patterns are right-tool-for-the-right job. I confess with algorithms I don’t have a favorite (OK, I have a fondness for alpha-beta search), and you’ll never see me trading design pattern playing cards (“I’ll give you two singletons for a visitor pattern”).
I think what the quorer was implicitly getting at is that in a perfect world we’d have no programming languages and just algorithms and for some reason design patterns (for a while it seemed design patterns were insinuating themselves into programming languages, but I think this trend is fading).
This is one of my longstanding complaints about design patterns, that people who don’t like programming latch onto them as a cookie-cutter substitute for programming (it is actually refreshing that this person mentioned algorithms in addition to design patterns — I agree, real programmers should know algorithms).
And they get really defensive about design patterns (it’s that real programmer thing). I wrote the following blog years and years ago, and someone got so incensed he went off to write his own blog complaining about how I and others unfairly maligned the classic Design Patterns book (but I’m not really attacking the book). Judge for yourself:
So I’m browsing back through Christer Ericson’s blog and see his article Design Patterns are from Hell, in which he states that the original/classic Design Patterns: Elements of Reusable Object-Oriented Software book from The Gang of Four is “one of the worst programming books ever”. It wouldn’t make my list (Beyond Java), but it’s nice to hear someone else say it’s not the greatest thing since sliced bread. I’ve complained about design patterns to a few (tolerantly-amused) coworkers, and touched on it in an old anti-Agile essay, but I didn’t want to digress into an unfocused grumpy old programmer mode.
I didn’t learn about design patterns until relatively late, near the end of the 90’s, but that’s probably because I started programming before 1990 and I started my career in Lisp. In my experience, you never see Lisp programmers hanging around talking about design patterns — they’re usually talking about something much more interesting. And, per Peter Norvig’s argument, design patterns don’t seem all that important when you’re programming in Lisp. If you need to apply a function through a list or tree, it’s a natural feature of the language — you don’t need to announce “I think I will apply a Visitor pattern”.
I first heard about design patterns when a new hire in my group asked me if he could expense the design patterns book, which had been taught in his college. Since I’d never heard about it, I said no, but when he purchased it on his own and I leafed through it, I regretted my rejection — the book didn’t bring any epiphanies, but it’s nice to recognize all these techniques you’ve been using with names attached.
And it turned out, I had heard of design patterns before — while taking breaks in the library of the Space Telescope Science Institute, reading Richard Gabriel’s columns in the Journal of Object Oriented Programming on applying pattern languages to software, inspired by architect Christopher Alexander’s attempt to create pattern languages for urban planning (next time you get an interview quiz on design patterns, ask your questioner about the relationship to Alexander’s work and to what extent Alexander’s design patterns are considered successful — so there!)
Design patterns started to seem important after I switched to Java — the libraries just ooze design patterns, and you’re going to learn them names whether you want to or not (Factory, anyone?) But at least the Java API’s are well designed (the greatest appeal of Java for me) Since then, design patterns have come up only in annoying situations, for example:
A VP of Engineering vigorously trying to convince I should have used the Flyweight pattern in one of my programs. It turns out I was using the flyweight pattern — I just didn’t know it was now a pattern and had that name, and even though I explained how my program worked, since I didn’t say “flyweight” he felt I was missing the boat.
A review of a coworker’s fix to my code — he delightedly said “Ah, that’s a singleton!”, and proceeded to apply the fix clearly without understanding the code (there were multiple instances of the same code that each needed the fix — ironically, he missed that “pattern”)
A coworker who called everything he did twice a pattern, even when it was terrible. Especially when it was terrible. With some exaggeration, it would be as if I deliberately had divide-by-zeros everywhere and called it a pattern, thereby justifying it as worthy code.
The same goes for refactoring — heard about, eventually read the classic book by (Martin Fowler), seemed somewhat interesting, useful insofar as support by tools like Eclipse, but now after listening to people talk about how they’re going to refactor today, when it should be a natural, ongoing, and unannounced part of programming (how would it go over in a scrum meeting if I said, “I’m going to type, today, maybe spend one hour backspacing, two man hours recompiling…”) — enough already!