I had a bit of difficulty with this book. Loved reading it in every way (style, content, clarity, etc.) - but in parts[0] of every section I found myself thinking, "wait - of course that's what I'd do... but that's just, like, the thing to do... why is it a pattern? Does it really matter if I call it that pattern or if I don't know the pattern name?"
Maybe it's because I didn't learn coding in university, or because most of my career has been spent in very small teams with little need to use pre-established jargon, but I get slightly annoyed when I see discussions about this pattern or that pattern and I have no clue what they're doing, even if I've myself used that "pattern" dozens of times without knowing the accepted name for it. YMMV
[0] the other parts would be when it got into the nitty gritty of solving a specific problem instead of the generic pattern. For example, propagating transforms using the |= trick. That stuff was great for me.
I totally agree with you, but I think you're understating the value of the pattern language. Of course any good practitioner will have internalized these "patterns" to the point that they're second nature, in the same way a good carpenter will know all the uses for his tools. The problem with carpentry though is that you require (for the most part) a mentor to pass on this first-hand experience. Programmers benefit from being able to describe our craft with this design pattern language, so that other practitioners can understand very quickly what our implementations look like, and more importantly (IMO), neophytes can quickly and independently familiarize themselves with the patterns to more quickly become experts.
But I don't just think this book is for beginner programmers or people who don't understand the idea behind the patterns. Even competent designers like yourself ought to know the names for these concepts purely for discursive purposes, maybe teaching new engineers or writing blog posts, or designing with other engineers at the same level. The pattern language is just an efficiency layer on human-human communication, which for many of us is one of the most challenging parts of our jobs.
> I get slightly annoyed when I see discussions about this pattern or that pattern and I have no clue what they're doing, even if I've myself used that "pattern" dozens of times without knowing the accepted name for it.
Having an agreed-on name for it is how you avoid that frustration.
Hehe - I wasn't sure which person to reply to... then I realized, it's YOU!
First of all - I want to say thank you. I really really did enjoy the book and smiled at the picture with your dog (as well as all the programming stuff ;)). Honestly, I've recommended it to others enthusiastically and got a lot out of it. Thanks!
I totally agree with what you and others said. I get it - and the only way I've been able to get away with not knowing the names of some of these patterns is precisely because I've only worked in very small teams and had a lot of autonomy. Also, for async/internet discussions I often have enough time to look it up if someone uses the jargon, and because I've encountered the names/concepts before (like in your book) it doesn't take long to catch up to the conversation.
That said - I'd like to explore one more avenue... is it possible that not seeing things as patterns allows for a more intuitive grasp? e.g. if I want to do things based on some current state, yeah I could reach for "statecharts" or "finite state machines"... but thinking of things as enums with switching based on the enum value might lead to a more intimate grasp of what's going on, and clearer insight into the different ways to hack around the problem? That might not be the best example (I've basically described a state machine and then said "how about not using a state machine") - feel free to substitute a better one if the question makes sense.
I guess I'm wondering if maybe there's an advantage to solving these things over and over but not seeing them as patterns? Not saying I'd recommend it.. just, if there's a silver lining to a bit of ignorance?
> is it possible that not seeing things as patterns allows for a more intuitive grasp?
Yes! I think about this often. There is sort of a Zen or Bruce Lee aspect where thinking of things strictly in terms of named categories can lead to overly rigid thinking and cause you to avoid better solutions simply because they don't have a name and don't seem as "real".
There is a balancing act, though. When we write code on a team, there is a real value to shared understanding of the codebase. Sticking to familiar categories, even at some minor expense of fitness to the task, is probably a net gain if it makes it easier to the entire team to understand what the code is doing and why.
It's also important to remember that the primary reason the Gang of Four wrote Design Patterns and called them patterns after Christopher Alexander's A Pattern Language is because they are not rigid copy/paste structures. If they were, we'd just call them data structures or algorithms.
The fundamental premise of why we call these patterns is that each manifestation of a pattern will appear slightly different, shaped by the context in which it is applied. That's why you don't often see resuable "pattern implementation libraries".
Good literature on patterns stresses this flexibility. Less good literature tends to just say "here's the thing that solves all your problems" and discourages readers from thinking deeply.
Btw, I think this exact concept might have been dealt with a bit in Zen and the Art of Motorcycle Maintenance. I just can't figure out which viewpoint falls into the "classical/analytical" and which falls into the "romantic/intuitive"... an argument could be made on either side, and as you said it's best to master both and find the balance. Food for thought!
Maybe it's because I didn't learn coding in university, or because most of my career has been spent in very small teams with little need to use pre-established jargon, but I get slightly annoyed when I see discussions about this pattern or that pattern and I have no clue what they're doing, even if I've myself used that "pattern" dozens of times without knowing the accepted name for it. YMMV
[0] the other parts would be when it got into the nitty gritty of solving a specific problem instead of the generic pattern. For example, propagating transforms using the |= trick. That stuff was great for me.