[hinkley]

It's entirely possible that the anecdote I mentioned in a sibling reply is just an early Uncle Bob comment from ages ago.

The Pattern Language approach to code didn't have to turn into naming everything after patterns (and then arguing endlessly about the ones that are ambiguously differentiated). It could have just been a field guide to spotting them. I recall reading a few good papers about how 75% of that book is just idiomatic functional programming code. I am blissfully unaware of anyone in the FP space getting suckered into actually naming anything after the official names.

I attended a workshop a couple years back, run by a person who was 1 degree of separation away from the Gang Of Four and he asserted that book was a Masters or PhD thesis for the youngest author and the other people were essentially editors. This was all news to me. I suspect if I had known this I would have pushed back a lot sooner, instead of getting sucked in too. A decade of OOAD ruined by someone's college project...

[poulsbohemian]

While the GoF book has perhaps not aged well and led to a lot of misguided ideas, it also did something that was a good idea and could have been developed further: a common nomenclature for things we’d all seen and needed to be able to describe to peers. To my thinking, the reuse of patterns to solve specific problems is along the path to turning programming into a discipline of software engineering

[hinkley]

I told my last mentee to “read ‘Refactoring’ twice instead”.

GoF tells you What. ‘Refactoring’ tells you Why, and gives some pointers on How. In any field, if you know the why and the how of something, and the what doesn’t work itself out? Then you’re in the wrong field.

(He’s gotten promoted twice since we parted ways. He’ll be just fine.)