I think you are being unfair towards GoF. GoF came out when Object Orientation was the rage and it provided a useful compendium of solution archetypes that can be used in response to (solved, recurring) problems. That is not to cast aspersions on your personal experience. It sounds like you had an encounter with an Architecture Astronaut and ended up in a bad place, but the fact that you are writing about it is a good thing, isn't it?

I also agree that "changed my x" is a bit of a stretch; perhaps it's hyperbole and should be taken as such. There are very few "things" that change one's life. Perhaps being in a war, or a natural disaster or some such, having an encounter with death but averting it or some such event could singlehandedly change one's life, but I doubt that reading a book or a set of books is one of them.

It's not a judgment of GoF per se, although I have some critique on the book as well, but of the impact it had. Unfortunately, a lot of people (mis)took it to heart, and GoF became just another book to learn by rote when interviewing.

Somehow related, Google right now demands interviewees to prepare using the Cracking the Coding Interview book. Pretty much it's like someone sells you a door and hands you a set of lockpicking tools instead of you using the key to enter.

> One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.

This is a sign, that in order to solve the problem, you must move on to a job that isn't the problem.

I learned many things from that experience, but later, when I actually got smarter about career and interviews; being introverted didn't help much either. But I'm glad I didn't make this mistake on my end, when I was at the other end of the table; I was able to hire and help grow people who would have been put down because they didn't read a recipes book.

I actually really appreciate the GoF book. I don’t use their patterns every day, but it’s definitely driven home the message of carefully thinking about which parts of the system should depend on which other parts, and examples of how you can achieve that. I also find it useful as a reference because many of the more common patterns do show up in people’s code and in libraries and understanding what a singleton/adapter/factory/builder is, does help me in my day to day.

I think the problem are the people who can’t abstract the message of the book and instead use it as their reference for absolutely everything, over-engineering the hell out of things. When I’m asked the sort of questions you describe, I also just ask if they could instead explain the problem, because being able to solve problems is all design patterns are about. If they can’t, I would respectfully ask how their knowledge of the design pattern will then help them in their job.

I cannot second this enough. Uncle Bob et all have done imeasurable bad to a lot past and future devs generations.

Advocating for a perverted cloudy way of overengineered sw that builds cvs and horrible enterprise sw.

There are much better ppl to read out there. Anyone actually writing long lived sw. Linus, sam neal, anyone actually DOING it rather than living off self indulgent books.

I agree and hope that no one will come here commenting in favour of the uncle&co, what relevant software have they actually written? And how much time has been lost refactoring code from people that mindlessly followed their extremely simplified recommendations and toy examples? Let's forget them please.

> what relevant software have they actually written

I think Fitnesse [1] is quite relevant. That said, not a lot of FOSS work from someone like him, to put the things he preaches in large and complex projects that we can look at the source and learn from.

[1]: https://github.com/unclebob/fitnesse

Would you mind linking to something written by Sam Neal? Not familiar with the name.

> One such people screwed my career development for 7 years

The problem was with this person, not so much with the GoF book. In present days this person might have become an FP fundamentalist and come up with some exotic category theory quiz question that he was very fond of himself. The GoF book is now of course outdated but the idea of categorizing best practices from the industry was a good one. Unfortunately many good ideas will be abused by people who lack the common sense to know how and where to apply them. A similar thing has happened to the agile software development movement, to microservices architecture (every service is a microservice?!), unit testing (people trying to reach 100% coverage).

>Or books on fundamentals…

Abelson, Sussman's Structure Interpretation of Computer Programs also good recommend - helps show that whilst it's not magic, fact everything still works is magical

This has sat on my shelf for my ten year career and I've never read it. Are there any up-to-date resources to help approach the text?

That is the beauty of this book, there is no need for any extra resources. Install SICP package in Dr. Racket [1] and start reading the book. Try your best to solve the exercises, and don't give up easily on the exercises. Thinking over the exercises and solving them is the best way to assimilate learning from SICP. I read only the first 3 chapters, and relied on notes from Eli Bendersky [2] to check when stuck with exercises.

1. https://stackoverflow.com/questions/19546115/which-lang-pack... 2. https://eli.thegreenplace.net/2007/06/19/introducing-the-sic...

The videos from a class the authors gave in 1986 are available online (https://m.youtube.com/watch?v=2Op3QLzMgSY). I highly recommend those, if reading the text is not your style.

This is a gem!!

Just install Dr. Racket and write #lang sicp at the top. What kind of resources to help you approach the text you’re looking for?

Incidentally, I just installed Racket today so I can work through SICP. I was kind of confused by the choices of what to run.

What the hell is GoF

“Gang of Four”. It’s how the book * Design Patterns: Elements of Reusable Object-Oriented Software* is often referenced. The “four” being the four authors.

> It's not only because it tries to codify coding as a sum of recipes

It doesn't do anything of the sort. It may try to codify some specific solutions to SOME specific types of problems, in a very narrow OOP'y context, but if "codifying coding as a sum or recipes" is what you took from it there's little wonder it has colored your view, so.

agree. I’ve inherited codebases from new “architects” who seemingly have just read GoF.

I've met such newly appointed architects myself - judging by the commit history, they were OK writing unmantainable spaghetti for 10 years, then they read a few books on patterns, got promoted to architects and started applying those patterns everywhere (ending up with unmaintainable overengineered abstractions). When arguing during architecture reviews, you'd often hear "but in book X it's written that..." like they don't have their own opinion. Fortunately, they all outgrew this phase and eventually became proper architects.

Haha I remember my first designs as a Jr Engineer after I had crammed the book into my brain before starting. I’m pretty sure the other devs just threw those classes into the trash when I wasn’t looking. For about a year I thought everything had to be a design pattern and making a vanilla class was a faux pas. 14 years later I don’t think I use any of the patterns anymore. Maybe facade if I’m refactoring a complete mess of a project

My thought about this is that patterns are something I recognize in the completed code, not something I bake into my code. A useful tool for refactoring at best. But re-factoring, not factoring. :)

Or SICP…