[clarry]

On the other hand, life is short, time is finite, and there's more to read and do and learn than any one person can do in a lifetime.

Time and time again I read things only to regret it later because I didn't get my time's worth out of it and probably could've spent that time on something more useful.

It's less a question of style and more a question of content. Do I feel like I'm learning something insightful or important? If not, I start to get bored. If it's a book people recommend a lot, I force myself to keep reading, and tend to get more and more bored. I might or might finish, but in the end I usually regret it. It's very rare for a book that doesn't start out well to do a U-turn and get good towards the end.

[Silhouette]

You make a valid point, and if you're reading fiction for pleasure then your own judgement of the experience is really the only thing that matters. However, if you're reading technical material with the aim of improving your skills, how can you tell whether you are learning something insightful or important?

A classic problem, and the reason that some questionable authors with unreliable content are nevertheless among the most popular in their field, is that the student of a technical subject is by definition never going to be qualified to evaluate tutorial material aimed at their current level. We all rely on the opinions of those more skilled or experienced than ourselves to guide us, at least until we reach a level where there are no more tutorials and instead we're learning from our own experiences including original research and discussions with peers.

In the case of Design Patterns specifically, if you're not into the kind of OOP where those patterns apply then it will have much less value to you. However, I'd say anyone who is working in a language like Java, C++ or C# should have at least passing familiarity with the patterns within and their names, if only to recognise the concepts and key details when they come up in discussion with fellow developers or get mentioned in code or documentation. Some of the ideas behind those patterns are relevant in non-OOP contexts as well, but in other programming styles they are often expressed very differently, which is why I say the book would have much less (but not necessarily zero) value to someone whose interests lie away from class-based OOP.