13 ms·

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 smil

by dakom 6y ago

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?

munificent 6y ago
> 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.
- dakom 6y ago
  Fantastic answer! Thanks for taking the time to respond here - looking forward to your next book :)
- dakom 6y ago
  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!

by dakom 6y ago

munificent 6y ago

> 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.

dakom 6y ago
Fantastic answer! Thanks for taking the time to respond here - looking forward to your next book :)
dakom 6y ago
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!