I'm thinking of buying: Design Patterns
Elements of Reusable Object-Oriented Software

Those who read it do you recommend it? If no what are other software design/arch do you recommend?

Title seems fishy and vague.

That is the book written by the GoF and has become kind of a bible for OO at that point.

It's definitely worth a read, especially if you work with OO codebases. You will however find that it is not an entertaining read. It's overall more useful as a reference.

Highly recommend. And agree it is used more as a reference. But it is good to do a deep skim of it to understand what's in it so that you know what is there and when they can be used. It's not made to solve every problem and honestly rarely use the patterns verbatim, usually put my own spin on them.

Also I've found a few times that other devs will respect you more if they realize you have read it since they feel you are putting effort into your field of expertise.

@Makenshi I see, but for a person who has been in the industry for 7 years, do you recommend it? Or I am already familiar with it's content?

@BobbyTables nice feedback, I'm guessing even after those years it's still good to have a look at it as it's helpful

@gitpush Yes, it's still useful. Personally I wouldn't read it from cover to cover. Maybe give yourself an overview of the more uncommon patterns and solidify your knowledge about the commonly used ones like command, strategy, flyweight and so on.

Afterwards it's mostly great as a reference.

I'd like to add two things to @BobbyTables great comment.

> other devs will respect you more

True, and additionally it greatly improves communication. "The Visitor pattern solves this elegantly" - "agreed" is way more productive than discussing the raw structure.

> honestly rarely use the patterns verbatim, usually put my own spin on them

You're doing it right, that's exactly their intended use. A pattern isn't a finished solution, it's like a signpost. You have problem X, so this general direction should work. Your specifics, especially domain-wise rather than technical, decide the actual path you take.