HackerNews Readings
40,000 HackerNews book recommendations identified using NLP and deep learning

Scroll down for comments...

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Martin Kleppmann

4.8 on Amazon

241 HN comments

Guns, Germs, and Steel: The Fates of Human Societies

Jared Diamond Ph.D.

4.5 on Amazon

239 HN comments

Deep Work: Rules for Focused Success in a Distracted World

Cal Newport

4.6 on Amazon

239 HN comments

Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin

4.7 on Amazon

232 HN comments

Getting Things Done: The Art of Stress-Free Productivity

David Allen and Simon & Schuster Audio

4.5 on Amazon

231 HN comments

The Three-Body Problem

Cixin Liu, Luke Daniels, et al.

4.3 on Amazon

225 HN comments


William Gibson, Robertson Dean, et al.

4.4 on Amazon

218 HN comments

Harry Potter: Hogwarts Hardcover Journal and Elder Wand Pen Set

Insight Editions

4.8 on Amazon

212 HN comments

Design Patterns: Elements of Reusable Object-Oriented Software

Erich Gamma , Richard Helm , et al.

4.7 on Amazon

208 HN comments

How to Read a Book: The Classic Guide to Intelligent Reading

Mortimer J. Adler and Charles Van Doren

4.5 on Amazon

193 HN comments

Sapiens: A Brief History of Humankind

Yuval Noah Harari, Derek Perkins, et al.

4.6 on Amazon

191 HN comments

The Intelligent Investor: The Definitive Book on Value Investing. A Book of Practical Counsel (Revised Edition)

Benjamin Graham , Jason Zweig , et al.

4.7 on Amazon

188 HN comments

Code: The Hidden Language of Computer Hardware and Software

Charles Petzold

4.6 on Amazon

186 HN comments

Seveneves: A Novel

Neal Stephenson, Mary Robinette Kowal, et al.

4.1 on Amazon

184 HN comments

Cracking the Coding Interview: 189 Programming Questions and Solutions

Gayle Laakmann McDowell

4.7 on Amazon

180 HN comments

Prev Page 2/180 Next
Sorted by relevance

qznconJune 22, 2015

The promise of Design Patterns (tm) is that you can systematically learn to organize your code. The article argues that only experience does.

ryanyoganonJuly 3, 2014

If you want an amazing book on Design Patterns for ruby, http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-...

cpetersoonMar 26, 2012

Christopher Alexander's A Pattern Language: Towns, Buildings, Construction is a candidate. It is cited as the inspiration of the Design Patterns book. But it is actually a very good (though long-winded) book.

konslonMar 4, 2008

I would think Design Patterns: Elements of Reusable Object-Oriented Software by the gang of four is the most famous -- I can't say I've read any books on programming that I felt were "memorable"

strlenonJune 18, 2008

Bruce Eckel's _Thinking in Java_ (available free online, just as are his C++, Design Patterns and .NET books) is excellent, combined with just API references.

mcvonJuly 21, 2021

Exactly. You can just as easily learn cargo cult programming from a book. Design Patterns anyone?

I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.

enterxonMay 18, 2014

Suggestion : Invert the order. :)

Read Refactoring first than read Design Patterns(GoF).

maxxxxxonFeb 5, 2019

Design Patterns by the Gang of Four and Power Negotiating by Roger Dawson. They both showed me that there are advanced levels to things that can be learned.

gitgudonJune 27, 2019

Surprised no ones mentioned these:

1. Design Patterns: Elements of Reusable Object-Oriented Software

2. Clean Code

3. The Pragmatic Programmer

They've helped immensely from working with small functions to the organisation of systems and systems of systems.

bltonFeb 3, 2013

What is your recommended introduction to design patterns? I've been meaning to read the original but I do get that old-school clunky Java feel from it. I'd be very interested in an updated Design Patterns for OO languages with mild functional capabilities like C++11, C#, Python.

pettinatoonDec 9, 2011

The System of the World by Neal Stephenson - for pleasure

Hadoop: The Definitive Guide - for fun

Design Patterns: Elements of Reusable Object-Oriented Software - for work

Effective C++ by Scott Meyers - for work

More Effective C++ by Scott Meyers - for work

kap7onJune 30, 2021

Just read:

- Clean Architecture
- Design Patterns: Elements of Reusable Object-Oriented Software
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- Clean Agile

and forget the rest. Life is short and those books are more than enough.

re_toddonJuly 24, 2016

Head First Design Patterns is awesome. I read a couple other Design Pattern books, but didn't really get it. I didn't want to buy a "Head First" book because it looked kind of silly, but this book has finally opened my eyes to what Design Patterns are about.

jsmartonlyonJan 1, 2012

Comparing to C++/Java, I felt that Design Patterns are more tightly integrated with Objective-C. So it is a very important subject to learn in Objective-C, imho.

And that is very good book for this important subject.

Good luck!

ahmedfarookionFeb 15, 2012

It's a matter of semantics, but I completely agree with you. I would have liked it if there was a book on Design Patterns in the list as well.

flavio81onOct 6, 2017

>By contrast, design patterns are about forcing a common solution onto a range of different problems.

This is one of the best criticisms of Design Patterns i've ever read. Great point.

TremendousJudgeonAug 29, 2017

You realize that Design Patterns:
Elements of Reusable Object-Oriented Software
was published in 1994 while Java 1.0 was published in 1996 right?

asdffdsaonMay 13, 2019

Books: Operating Systems/Database/Networking/Computer Security/Computer Architecture textbooks, Software Engineering textbooks (Clean Code, Design Patterns, Designing Data Intensive Applications, Domain Driven Design as a short list off the top of my head)

rusticoonMar 3, 2017

Too many books. I think with 'Node.js Design Patterns' and the 'You Don't Know JS' series is more than enough.

shwaonAug 29, 2011

Added the gang of four under OOP. Do developers still read this, or has head first superseded it?

Then again, a major pitfall of Design Patterns is that everything starts to look like the patterns you already know, which essentially boxes in your design process. Apply the knowledge at your own peril.

owenjonesonJuly 10, 2013

Although the aphorism sounds nice, Design Patterns were created to alleviate the complexity problem. Is the answer functional programming? The author offers no solutions.

gitgudonFeb 1, 2020

No one's mentioned this book [1], which is a great catalogue of concepts, useful in architecting codebases.

[1] "Design Patterns: Elements of Reusable Object-Oriented Software"

grabcocqueonFeb 8, 2017

Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since.

gnaritasonJuly 24, 2017

Smalltalk Best Practice Patterns by Kent Beck.
Refactoring by Martin Fowler. Design Patterns by the Gang of Four. Domain Driven Design by Eric Evans.

theteapotonAug 9, 2021

> I've purchased three OOP books (in the order I've read them): ...

If your gonna pick three books on OOP it should include Design Patterns at the top of the list. At least if you want to understand why OO is a thing people still use and talk about.

bryanrasmussenonApr 24, 2020

The first expression of a concept is not necessarily the best or most useful expression. As such the book can be the first expression of the concept of Design Patterns and be worthless as a lasting text.

mferonOct 21, 2019

"Design Patterns: Elements of Reusable Object-Oriented Software" by the Gang of Four. It has sold over 500k copies and has been translated to numerous languages.


rwmjonMay 22, 2018

Which programming books are actively harmful for developers? I'd put the "Gang of Four" Design Patterns book in this category.

rwillystyleonApr 5, 2012

Check out his Design Patterns book on Singletons. It's a little more thorough and has a different focus.

thornkinonDec 3, 2010

I found the first chapter of Design Patterns to be the most enlightening description of OO programming I have found.

azylmanonDec 7, 2011

I read Design Patterns and was unimpressed. Maybe it's because I'm used to large codebases that are already well designed, but all I got out of Design Patterns was formal names for patterns that I already used in my code because they're intuitively the correct thing to do.

munificentonMay 23, 2020

If you haven't read them yet, Design Patterns, The Pragmatic Programmer, and Code Complete, will all help you.

mwbrooksonApr 26, 2009

Nice summary of design patterns. Having a design pattern book on hand is a wise choice for any programmer.

Personally, I use 'Design Patterns: Elements of Reusable Object-Oriented Software.' However, Wikipedia or this website are fine.

Can anyone comment on sourcemaking.com's 'Design Patterns - Simply'?

robinphilip1989onJuly 25, 2017

Head First Design Patterns by Eric Freeman
Design patterns by GoF
Code Complete by Steve McConnel

rancuronOct 14, 2015

this is why I think it's great to start with C. I worked in it for 3 years and found myself creating and utilizing abstractions. I looked back and realized I was writing Design Patterns myself. Much easier to understand bottom up.

runakoonFeb 8, 2017

> "if someone were to write a "modern design patterns" book"

Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.

NitiononFeb 8, 2017

Having read Design Patterns in the past, I found http://gameprogrammingpatterns.com to be a really good modern follow-up, though it's targeted at game developers in particular.

zxvonApr 27, 2016

Anybody recall the InterViews[0] native C++ toolkit for X Windows, circa 1993?

At the time, it felt like a huge leap forward in ease of writing native GUI apps for X. The point being, C++ was a medium for lots of great ideas, including one of the early Design Patterns books [1].

[0] https://en.wikipedia.org/wiki/InterViews
[1] https://en.wikipedia.org/wiki/Design_Patterns

SamuelAdamsonJune 24, 2020

Yes exactly. I recommend reading the book Design Patterns [1] for some ideas on how early "modular" software was conceptualized. This book was published in 1994 and still has a lot of relevance today.

[1]: https://en.wikipedia.org/wiki/Design_Patterns

specialistonApr 24, 2020

Design Patterns gave us the vocabulary and opportunity to argue about design for a previously ignored level of abstraction.

Source: started design patterns study group, still active today.

DonaldFiskonFeb 8, 2017

That's very interesting. I haven't read Design Patterns. I have read A Pattern Language, and the Timeless Way of Building, by Christopher Alexander, and Patterns of Software by Richard Gabriel. It's been my understanding that Design Patterns had only a couple of dozen patterns (which turn up again and again in Java code) and prescribed their use generally, but if they're only examples of patterns, and programmers are encouraged to invent their own (which I do anyway), it might be worth a read.

detaroonAug 28, 2016

Design Patterns: Elements of Reusable Object-Oriented Software, whose four authors are sometimes called the Gang of Four (GoF). It established a vocabulary of common patterns.


jlaoonDec 6, 2011

I've seen so many lists like this and they always list the same books... Code Complete, Prag Prog, SICP, Design Patterns, Refactoring, etc...

specialistonDec 15, 2019

Cathedral & Bizarre has never made sense to me.

What do people think of Social Architecture, Pieter Hintjens' ideas for building successful open source software?

Collective Code Construction Contract





Hintjens' worldview appeals to me.

I've done a bit of activism, with (very) modest success. A Design Patterns book club I started 20 years ago continues today; we somehow stumbled on a sustainable format.

Not having any successful OSS projects of my own (yet), I can't say if Hintjens' ideas work. I hope to find out.

ThiagoBurgosonJune 4, 2011

I suggest you read the book from the Heads First series "Design Patterns". It opened my mind when I read it.

isaachieronMar 12, 2018

I completely disagree. I felt it was a modern followup to the classic Design Patterns (Gang of Four) book. The author is not trying to teach game programming as much as he is demonstrating how they are practical in his line of work.

JoeAltmaieronDec 11, 2019

Revisionist history? The seminal work in Design Patterns (coined the term) came out in 1995

Design Patterns (Elements of Reusable Object-Oriented Software), Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1995]

Same year Java was invented. Hard to imagine Java inspired it.

munificentonAug 5, 2020

More relevant to the HN crowd, he invented the general concept of a "pattern language" and described a set of patterns for architecture.

The Gang of Four took that concept, hunted down a set of patterns they found in software architecture, and wrote "Design Patterns: Elements of Reusable Object-Oriented Software" based on it, one of the most famous books in programming.

garethspriceonApr 18, 2017

The Art of Computer Programming by Donald Knuth is probably the closest to an actual bible for computer scientists - hardly anybody's read it all the way through, people quote bits of it out of context for their own ends and it mostly sits on shelves looking impressive while gathering dust.

The Mythical Man-Month by Fred Brooks for tech management.

Confessions of an Advertising Man by David Ogilvy for advertising/marketing industry.

Design Patterns: Elements of Reusable Object-Oriented Software by the "Gang of Four" for OOP software engineering.

tatterdemaliononOct 26, 2014

This is a wonderful video! Thankyou.

A lot of the comments remind me of patterns from A Pattern Language by Christopher Alexander. I'm sure many people on HN know this book from the preface to Design Patterns, but if you've never flipped through it you really should - any single pattern contains a great deal of insight into how we live in the world.

intrepidheroonJan 27, 2021

I've underutilized Python's OO system and I've certainly overutilized it. The light bulb moment for me was when I read: "prefer composition to inheritance". Which Wikipedia tells me comes from "Design Patterns" but I'm pretty sure I remember the argument from "Working Effectively with Legacy Code." Obviously it's not a hard rule to avoid inheritance, but once I started asking myself, "Is this relationship an is or a has?", my designs got a lot better. And by better I mean they quit making me angry when I revisited them months later.

PS. Highly recommend that book BTW. Especially (and somewhat ironically) for people designing new systems. Everything is eventually legacy. :-)

f2enderonJan 25, 2011

I have a CS degree so I have read the basic texts on Algorithms, Operating Systems, Compilers.

I recently got through the Design Patterns book. I was thinking of picking up either a new language (Go) or start the "Mastering Regular Expressions" book, not sure which.

douglaswlanceonDec 16, 2019

My top priority books:

    Software Requirements - Karl Wiegers

Programming TypeScript - Boris Cherny

Associate Cloud Engineer Study - Dan Sullivan

Design Patterns - Gang of Four

Refactoring - Kent Beck, Martin Fowler

Programming Pearls - Jon Bentley

Patterns of Enterprise Application Architecture - Martin Fowler

The Pragmatic Programmer - David Thomas, Andrew Hunt

CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl

Working Effectively with Legacy Code - Michael Feathers

Head First Design Patterns - Eric Freeman, Bert Bates

Code Complete - Steve McConnell

Peopleware - Tim Lister, Tom DeMarco

Clean Code - Robert C. Martin

The Clean Coder - Robert C. Martin

Clean Architecture - Robert C. Martin

Don't Make Me Think - Steve Krug

Functional Design Patterns for Express.js - Jonathan Lee Martin

The Surrender Experiment - Michael A. Singer

The best books I've ever read:

    Principles - Ray Dalio

The Power of Now - Eckhart Tolle

The Effective Executive - Peter F. Drucker

Think and Grow Rich - Napoleon Hill

Extreme Ownership - Jocko Willink, Leif Babin

Influence - Robert B. Cialdini

The Startup Way - Eric Ries

The Lean Startup - Eric Ries

12 Rules for Life - Jordan B. Peterson

Measure What Matters - John Doerr, Larry Page

The Fish That Ate the Whale - Rich Cohen

The E-Myth Revisited - Michael E. Gerber

The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh

Management - Peter F. Drucker

Thinking in Systems - Donella H. Meadows

Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne

cbm-vic-20onMar 18, 2019

I've enjoyed Christopher Alexanders' "A Pattern Language: Towns, Buildings, Construction"* as an interesting series of essays about designing spaces at a human scale. Computer / programming people rave about the book's structure (as an inspiration for the GoF "Design Patterns" book), but the content is also fascinating.

* https://en.wikipedia.org/wiki/A_Pattern_Language

BJaneckeonJuly 25, 2017

* Douglas Hofstadter - Gödel, Escher, Bach: an Eternal Golden Braid

* Fred Brooks - Design Of Design

* Fred Brooks - The Mythical Man month

* Eric J. Evans - Domain Driven Design

* Design Patterns: Elements of Reusable Object-Oriented Software

* Kent Beck - Extreme Programming Explained

* Kent Beck - Planning Extreme Programming

* Michael C. Feathers - Working Effectively with Legacy Code

* Daniel Kahneman - Thinking, Fast and Slow

[EDIT] Correct the author for legacy code

xliionNov 18, 2020

Tl;dr use strategy pattern where applicable.

One of the best programming books I read was UML Distilled (which introduced the idea of some pattern beside teaching UML) and Design Patterns (Shalloway, Trott).

The moment I started reading this post I thought “that’s a strategy pattern use case”. And that’s the conclusion.

A lot of people fret upon reinventing the wheel (use library instead!) but then they do so very often with the software design where a lot of problems are not only well researched but also peer reviewed and properly described with consequences that come with them.

If you enjoyed this article I would recommend picking up book on design patterns (any popular will do) as there are many more prefabricated solutions to choose from.

vram22onApr 2, 2017

Design Patterns (in software) are supposed to be derived or inspired (not the actual patterns, but the idea of patterns) by that book, BTW, or by Alexanders other thoughts or writings.

JTrilogyonNov 27, 2016

I'm a junior dev with ~2 years experience. Currently I'm primarily doing back-end web work on a massive spaghetti codebase written in Node, Python, and PHP.

My current reading list:

* Code Complete: A Practical Handbook of Software Construction - Steve McConnell

* Agile Software Development - Robert C. Martin

Upcoming reading list:

* Node.js Design Patterns - Mario Casciaro

* The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt

* Clean Code - Robert C. Martin

* Refactoring: Improving the Design of Existing Code - Martin Fowler

And maybe Working Effectively with Legacy Code by Michael Feathers.

If anyone has any comments or other suggested readings I'd love to hear them!

smyatkin_maximonJune 7, 2017

Excellent question btw. Language-agnostic books don't get out-dated that fast and I'd give them higher priority.

- Code complete

- Pragmatic programmer

- Design patterns

- Programming pearls

- If you're going for hardcore programming: the dragon book, something on modern hardware and something on OS internals.

orclevonJune 22, 2014

That isn't unique to functional programming. I've seen my fair share of Java and C# code bases that could best be describe as baroque monstrosities. It's like the authors read Design Patterns and then decided they absolutely had to use every single pattern at least once. The clean code book is also somewhat to blame here as people who go full retard on that tend to write stupidly complicated class hierarchies just so they can never have more than 1 line of code in any given method (effectively turning most classes into proxy wrappers for other classes providing some default values).

fusiongyroonJuly 24, 2017

A Mentoring Course in Smalltalk[0]. I was really surprised, after reading and really loving Design Patterns, that there was still so much to say about OO design.

I did love Design Patterns a lot though. Purely Functional Data Structures by Chris Okasaki was also really useful for Haskell, as was Real World Haskell.

Programming Prolog probably had a bigger influence on my Prolog than the other books, even though I read Art of Prolog and Prolog Programming in Depth first. Especially the latest edition, it's a really beautiful book.

[0]: http://www.lulu.com/us/en/shop/andres-valloud/a-mentoring-co...

Privacy846onDec 19, 2020

Design patterns are considered to be things that you can’t express directly in the language (that’s the Design Patterns book definition). Monads can definitely be expressed directly in Haskell. The only thing you can’t do is prove the Monad laws in Haskell (I think?).

Other languages, like e.g. Rust (because of lack of HKT), cannot express monads like Haskell can.

But yeah, you can definitely call it a design pattern if that’s what the culture around the language is like. But it would be like Java folks calling interfaces with default implementations for something goofy like “Interface with stateless implementations pattern”, and even they don’t go that far.

pumanoironNov 19, 2017

Completely disagree on the "Headfirst books" comment.
All the head first books I have read (Java, Design Patterns, Android, C, Ruby) have very high quality content. I have read great books on all these subjects along HFs. i.e. The Design Patterns Smalltalk Companion, K&R, etc. The HF books really help visualize and actually enjoy the subjects, they also have great exercises that help to cement the concepts one has just learned. If any of the HF authors read this, thanks for these books, they have help us a great deal.

ZababaonAug 10, 2021

I don't think those are the same "problems". "Design patterns" is about code, not solving business problems. To stay in the well known books in OOP, DDD would be about solving business problems.

TichyonApr 6, 2008

But most people who start out with "The C Programming Language" and never read "Design Patterns" will only ever use for loops and never think about iterators. How do you want to transmit certain concepts without giving them names?
I also had situations where "Design Patterns" helped me find a solution. Of course I also experienced the IT Manager who wanted to see Design Patterns everywhere, no matter if they were useful or not. But that is not the fault of the book.

stinosonSep 7, 2012

yep. When I just started I struggled through GoF's Design Patterns and even sorta tricked myself into believing I understood it. Well, I didn't. At all. 5 years later though it was one of the most insightful and useful reads ever.

ArzhonMay 19, 2016

This article makes way more sense when he says he never read the Design Patterns book. If he had, he would know that before he started. They explain that the book is a collection of patterns that they have compiled from a bunch of people and from years of experience. The patterns did come about organically, and they were never meant to be the way to design software. They were only trying to come up with a common lexicon for something that they were all already doing.

diego_moitaonDec 23, 2019

Pragmatic Programmer is still a good book, not as revealing as before but still has lots of good advice.

Code Complete is a problematic book. It has some good ideas but also has some very bad ones (cone of uncertainty, 10 times productivity in good programmers, etc).

Design Patterns is mostly obsolete. Functional programming techniques made a lot of Object Oriented techniques irrelevant (e.g.: observer pattern vs callbacks with lambdas).

Art of Computer Programming is the book everyone mentions but no one reads. A classic that people actually read is Structure and Interpretation of Computer Programs.

My recommendations: "Code" by Charles Petzold,"Don't make me think" by Steve Krug, Working Effectivelly with Legacy Code, by Robert Feathers, Clean Code by uncle Bob,..

flavio81onAug 29, 2017

I realize i made an anachronical mistake. However the Design Patterns book and the 'design patterns' mindset is most popular with Java developers.

Sorry but I do stand on my criticism of Design Patterns as applied today.

> The language most of the examples are written in, C++, does allow multiple inheritance and metaprogramming,

You're being very generous with C++ if you consider it does allow metaprogramming. It does not, if we compare it with the languages that make good use of metaprogramming: Lisp, Scheme, Racket, and now Julia.

caioconOct 11, 2015

Very specific to OOP : "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

jt2190onJuly 5, 2015

  > So their "best practices" end up being questionable at 
> best. Basically, who are you to claim that whatever
> you're doing is a "best practice"? It seems like a pretty
> bold claim, so I'd argue that it's not unreasonable to
> expect someone to back up their claims.

This is why IMHO the best advice comes with a list of pros and cons. It tells me that the author has thought deeply enough about the subject to understand not only the solution, but the contexts where the solution isn't a good fit. (Two books that spring to mind that do this: Patterns of Enterprise Applications by Fowler, and Design Patterns by Gemma et al.)

CodhisattvaonMar 13, 2015

"The C Programming Language" by the Dynamic Duo
"Structure and Interpretation of Computer Programs"
"Design Patterns" by the Gang of Four

InclinedPlaneonDec 22, 2012

Well, this brings up another problem. And that is that software development is not applied computer science. There are plenty of books which will teach you skills on dealing with real-world code (Refactoring and Working Effectively With Legacy Code being two of the biggies) and there are books that will teach you about other important aspects of development processes (such as Code Complete, Rapid Development, Design Patterns, The Pragmatic Programmer, etc. although those books are showing their age a bit these days) but none of those would be considered computer science textbooks.

CodeSheikhonJan 17, 2019

Nice list. Appreciate it. But I see there are a few amazing software books missing from the list such as:

- Clean Code (by "Uncle Bob")) [https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...]

- Design Patterns (by "Gang of 4") [https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...]

- Introduction to Algorithms (by "CLRS") [https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press...]

hodgesrmonFeb 1, 2019

Which design patterns are you thinking of and which languages had them? The original gang of four Design Patterns book is filled with C++ examples, most likely because almost nobody was using Java in 1995 outside of a few people at Sun.

More generally comparison and hashing methods seem like small potatoes compared to locking primitives, portability, and a large, well-documented class library that have made Java ideal for a very large fraction of business applications. There are many things to criticize in Java but the points you list don't seem to be especially important compared, say, to the relatively steep learning curve/complexity vs languages like modern Javascript.

ilakshonSep 14, 2016

Come up with an interesting project to work on in your favorite language. Keep adding more features until some functions have a lot of parameters. Then Google to see how you can group the variables together into objects so you don't have to pass so many variables around. Then just keep doing that in your new programs. After a few months or years you will get used to organizing code that way.

One thing you should not bother doing is to order giant piles of paper just so that you can say you read X famous author on OOP or Design Patterns or whatever. That is a waste of time and money now that we have Google and blogs/online articles etc. And anyway you are going to learn by doing it for X years or months, not by reading a book.

Also, be careful because people will to make it seem much more complicated than it is. The more complex or subtle aspects you are probably only going to remember or understand if you learn them through practice anyway.

wicknicksonJuly 30, 2013

That sucks so much. I read her Design Patterns book when I was doing my undergrad in Electronics. The lessons in that book are somewhat of a 'commandment set' for me. Its terrible what she has gone through. Feels like hearing about a good teacher who went through a bad time.

Glad she's back. Hope she continues. Very thoughtful and excellent article.

steveklabnikonNov 27, 2010

I might as well get all of the big names out of the way.

* Design Patterns: Elements of Reusable Object-Oriented Software

* Refactoring: Improving the Design of Existing Code

* Clean Code: A Handbook of Agile Software Craftsmanship

* Code Complete: A Practical Handbook of Software Construction

And some others:

* Working Effectively with Legacy Code

* Domain-Driven Design: Tackling Complexity in the Heart of Software

throwaway170805onAug 16, 2017

Current OMSCS student here. It's been a challenging, eye-opening experience, and I'm grateful to be a part of the program.

However, computer science and software development are not the same thing. If your primary goal is to up your game as a software developer, you might get more out of well-regarded software development books like "The Pragmatic Programmer," "Working Effectively with Legacy Code", or "Design Patterns."

Hope this helps.

anonsivalley652onMar 3, 2020

Hacker's Delight a zillion ways to do bit population count or over/underflow detection efficiently

Introduction to Algorithms MIT Press

Numerical Recipes algorithms for science




To Mock a Mockingbird combinators are good for you

Design Patterns

First Principles of Interaction Design (Revised & Expanded)

The Dragon book

Database Systems: Design, Implementation, & Management


Code Complete

Working Effectively with Legacy Code

Software Engineering at Google

Site Reliability Engineering

-- Also, learn these, at least to a novice level: --










x86 assembly

bash, JS, CSS, HTML, SQL, Python

and do Linux From Scratch & BLFS

munificentonSep 18, 2020

> how much easier it is to have dynamic behaviors without inheritance

I think you're getting at the idea that instead of having objects differ in their behavior by overriding methods, you have them differ by having fields bound to objects that implement different behavior.

Assuming I understand you right, that's an excellent insight, but it's just the classic principle:

Favor object composition over class inheritance.

There's nothing new in that idea or anything special to ECS. Do you know how I know? Because that sentence here is directly quoted from page 20 of "Design Patterns", which ECS and DoD are often claimed to be in direct opposition to. :)

ryanmaynardonApr 29, 2019

I can't speak for OP, but GOF (Gang of Four) is a reference to the four authors of a classic Design Patterns text. [1] This repo appears to be Python examples of some of the patterns referenced in the original text.

[1]: Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

mpweiheronJune 13, 2021

Yes, function composition is one kind of glue, and it's good that we have it. But it's only one kind of glue, and often not particularly useful (see the part of the post about algorithm DSLs).

As John Hughes put it in Why Functional Programming Matters, we need more kinds of glue.

See https://blog.metaobject.com/2019/02/why-architecture-oriente...

As to Design Patterns: the Smalltalk version of the Design Patterns book is a small booklet, most of the patterns just go away. As to the video: tried to watch, got to the "it's functions, functions functions and again functions" slide. For OO, it would be "it's objects, objects, objects and again, objects". Sadly, most FP-centered critiques of OO are at this level, or even worse. :-/

Overall, you're going to have more patterns in FP because its model of computation is less powerful. (See Concepts, Techniques, and Models of Computer Programming https://www.info.ucl.ac.be/~pvr/book.html for a definition of relative power ).

binarynateonApr 7, 2020

These three books helped me tremendously:

1. The Pragmatic Programmer by Andy Hunt and Dave Thomas

2. The Clean Coder by Robert Martin

3. Design Patterns: Elements of Reusable Object-Oriented Software (the "Gang of Four" book)

The first two contain a range of advice pertaining to working as a professional software engineer. The third one, although very dated, is still a great resource for understanding many of the design patterns used in OOP.

xtractoonJuly 18, 2019

I kind of disagree. A kind of hidden point I loved about Norvig's presentation is that there are design patterns useful and proper for Dynamic languages. The main problem is trying to use design patterns created for static languages, in dynamic languages.

I remember reading the Ruby book about design patterns. It was painful and the general motto of the book was "you don't need this and that static design pattern".

However, I think as a community we should be defining a collection of design patterns that are useful in dynamic languages. At the end of the day, the main idea behind Design Patterns was the definition of higher-level logic constructs that could be used to solve a problem when developing software.

It is like in the construction industry where bricks are the "code" and the 'best practices' (design patterns) of how to built houses with bricks do not apply when you are building a house using wood. Sure, brick design patterns do not work for wood, but that does not mean that wood building doesn't have their own patterns.

wonjunonMay 30, 2015

I'm giving away "Design Patterns: Elements of Reusable Object-Oriented Software" book for anyone who wants to pay shipping, http://www.shareprogrammingbooks.com/books/0201633612

beatonJune 17, 2015

If a book on software is truly obsolete anytime shortly after publication, then the tech itself isn't truly stable.

Read "The C Programming Language", by Kernighan and and Ritchie. Written decades ago, still accurate and relevant today. "The Mythical Man-Month", "The Pragmatic Programmer", "Design Patterns"... books like this will always be relevant.

Maybe a good rule is to stick to CS books that have been in continuous print for at least ten years.

ybluonDec 22, 2016

I read a few dozens each year. These are the top in my 2016 list.

* Zero to One: Notes on Startups, or How to Build the Future. If you can read only one book on startup this year, read this book.

* Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future.

* Running Lean: Iterate from Plan A to a Plan That Works.

* Alibaba's World: How a Remarkable Chinese Company is Changing the Face of Global Business.

* Start-up Nation: The Story of Israel's Economic Miracle.

* Disrupted: My Misadventure in the Start-Up Bubble. You will like or hate this book a lot, but it's surely an interesting read and perspective.

* Learned Optimism: How to Change Your Mind and Your Life. Good book that gives you a framework to become more optimistic.

* Sapiens: A Brief History of Humankind.

* The Three-Body Problem Trilogy. Great, great sci-fi.

* Understanding ECMAScript 6. Best ES6 reference book.

* Node.js Design Patterns. Best Node book for intermediate/advanced developers.

* CSS Secrets: Better Solutions to Everyday Web Design Problems. Great, great book on advanced CSS tips & tricks.

* Mastering Selenium WebDriver. This is probably the only good book on Selenium among so many bad books on this topic.

* Grokking Algorithms: An illustrated guide for programmers and other curious people. This is a good book but might be too basic for many people. Recommended for those who wants to quickly refresh their algorithms knowledge.

rurbanonOct 7, 2017

I call this bullshit.

> "Project Genie to educate Google about his proprietary ideas and techniques so they could develop a working proof of concept of his Engineered Architecture technology"

Parametric design and integration into AEC is industry standard since the 80-ies, and a long-time goal of virtually all design software manufacturers. Everybody had a take on this moonshot, and eventually it will get there.

It started with Christopher Alexanders "Design Patterns", when he won a city planning competition for the rebuilding of a destroyed Lima, Peru by offering simple recursive design patterns and not a grand master plan.
In the following decades this was being incooperated into various design tools. In the 90ies I based a university course on that ("Computer Assistet Planning"), and there were several others also worldwide.
City planning is obviously easiest, as there are almost no physics involved, AEC also easy but problematic because the heterogeneous SW used (needing API's, needing a strong partner), and construction being the hardest (Think of AutoCAD vs Revit). Allia thought of the Neufert standards as design patterns. Good goal, but by far not proprietary and revolutionary. Most of us working on that had far more than Allia.

Going to Google with this plan is also extremely naive. There's only AutoDESK to go to with such a project.

An earlier overview is that article https://www.theverge.com/2015/2/17/8048779/google-x-eli-atti...
A current take on city planning is the City Engine: http://www.esri.com/software/cityengine/free-trial

timronMar 26, 2012

I pretty much assume that anyone who claims to have read Introduction to Algorithms or TAOCP is using the claim colloquially. I've read parts (large parts, in the case of Introdcution to Algorithms), but neither is a book that I want to read cover-to-cover. They're best used as reference books.

That said, there's definitely a huge number of people who claim to have read Design Patterns, but actually have only read about Singletons and Factories in a Java book. It's a shame, because Design Patterns is one of the most formative books I've read as a programmer. Everyone should read it -- observing the way that patterns are (mis-)used in Java is a poor substitute for wrapping your head around the insights in GoF.

vickytnzonFeb 1, 2014

A pattern library is normally a collection of best UI practices: see the Yahoo UI pattern library http://developer.yahoo.com/ypatterns/ or http://ui-patterns.com/ for the two most well known examples. (It comes from Christopher Alexander's A Pattern Language and it being adapted to object orientated programming by the Gang of Four in 'Design Patterns: Elements of Reusable Object-Oriented Software'). The ALA version is a bit odd as it's more style-guide like (you normally have more options).

hinkleyonAug 3, 2019

There’s a lot of power in refactoring, but I’ll allow that some of it is counterintuitive. Anything counterintuitive requires state of mind and experience to line up and that’s quite hit or miss.

When that awful Design Patterns book was off the hype train but the new devs had heard about it and asked if they should read it, I would tell them No, read Refactoring twice instead, because it tells you why and when to use this stuff, which is much more valuable. Like feature work, if you know why you are doing something you can often reason out the gaps in the “what” on your own.

We sort of take a bunch of XP processes as a given and forget that this was Agile for most people at the time of the manifesto. Scrum pretends it’s separate but is essentially useless without half of XP.

x87678ronDec 18, 2020

I wish we had a new Design Patterns book in 2020.

GoF book is well obsolete, since then OO has faded, JS & Python are the the most common tools, even Java is unrecognizable with Lambdas and functional features everywhere. Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal. The GoF needs an update.

holygoatonSep 7, 2008

I think Design Patterns is mischaracterized as a "classic text of computer science". It's only 14 years old (which rules out some definitions of 'classic'), not nearly so profound as TAOCP and SICP (the other two books in your list), and it would be a stretch to say it's about computer science.

Computer Science != Software Engineering.

I would follow up by saying that, no matter how wonderful Road to Reality is, it's also not about CS, and GEB only overlaps the field.

An incorrectly titled post, perhaps?

pyreonSep 7, 2014

> I don't know that the parent comment makes a good case for relevance of this claim, though, since

The parent comment is responding to @tptacek's original comment:

> (It's actually of dubious relevance to programmers in general).

Where 'it' is the Design Patterns book. That's a more broad statement than just whether or not security researchers needs to read the book. The parent to your post replied to that:

> I agree that _Design Patterns_ has little to do with security, but I think you are being a bit hard on it from a programming perspective.

So, in summary:

  tptacek: Design Patterns has no relevance to security. It also
has dubious relevance to all other programming.

skue: It doesn't have relevance to security, but I feel that it
does have relevance to programming in general.

famousactressonDec 6, 2011

Man, still Code Complete? I dunno. Wasn't that big a fan, honestly. I think I got more out of the first three chapters than the sum of the rest of the book.

If we're talking about technical books, Refactoring is easily the most beneficial read I can remember having. I was pleased to see it (barely) trump Design Patterns... a book that I think (through no real fault of it's own) has spoiled more developer-years than it's benefitted.

kushtionJuly 7, 2014

The #1 book is "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma/ Helm / Johnson / Vlissides. It's about imperative programming though, functional/hybrid languages have other design patterns(but "Design Patterns" is #1 anyway).

+ Free Book "The Architecture of Open Source Applications" : http://hackershelf.com/book/54/the-architecture-of-open-sour...

threepipeproblmonJune 30, 2017

Lol I don't believe it's worth my time to argue this further, since you haven't made any actual arguments, and you come off as kind of a jerk with all the unsupported claims, not responding to my points, and demanding that I do work for you. Sorry you are blind to this. If you want to understand your deficiencies in this area I'd recommend reading A Pattern Language by Christopher Alexander, followed by Design Patterns by the 'Gang of Four', then thinking about the connection between architectural pattern languages and cutting edge software design. Perhaps think about why programmers have taken the time to assemble libraries of anti-pattern examples specifically, analogous to McMansion Hell's.

antocvonJuly 8, 2014

While I agree that many of the already given examples of books to read are really good books, nice reads.

I feel the best way to get into the mindset of good design, or design principals - even if it isnt "examples of good design" as the AOSA book - is to get immersed into an architecture formed from a design based mindset different than what you are used to.

Learn something engineered with design principles heavily visible in mind. What is the design principle of a modern GNU/Linux system? Its mosthly philosophical, you wont find the answer in several books, its spread out far and wide and requires that you actually use GNU/Linux for years, to have taken part in its history.

I suggest you pick up and learn JSF (Java Server Faces). Start reading JSF books, Java Enterprise things, start coding it, doing it. One good book is JSF in Action from Manning I believe.

When you begin reading about or trying to make a hello world site in JSF - youll be like "wtf is this, fuck" - thats right - thats you being exposed to a different design principles based mindset. Its not bad, its in fact very good (JSF and the experience).

Only once youve finished say a "community website, friends can befriend each other, send messages, write on wall, share pictures." in JSF, even though it looks as ugly as can be - then youve advanced more in passing those interviews with regards to design principles - than reading any of the books mentioned so far in this thread. But reading the other books wont dis-help you.

EDIT: From experience, the books flaunted around here, Code Complete, AOSA, Design Patterns here there and everywhere, are just bullshit for this task. What your interviewers were asking for is not if you can count and use Design Patterns. Or if you agree or dont agree on which method in a class should be refactored out and what it should be named. Dive deeper out of your comfort zone - go for JSF.

forintionApr 27, 2010

I read Design Patterns (GoF) and actually tried to write a text editor the way it describes it and found that it made selection really really difficult, so I had to find my own solution.

But I really grew fond of the Visitor Pattern, because you can do a lot with very little code.

Computer Graphics is the best school for Object Oriented thinking, I've found.

kirbman89onFeb 22, 2011

A book that I would recommend for refactoring object oriented code (Java in particular) is Refactoring-Improve the Design of Existing Code by Martin Fowler (a friend to the Go4). Written well and in a simliar format at Design Patterns-Elements of Reusable Object-Oriented Software by Go4 (Gang of Four).

krzykonMar 26, 2012

I didn't find Design Patterns as "dry", it was quite entertaining for me. Maybe because I didn't know anything about design patterns when I read it. On the other hand I reread it about 2 years after the first read and I still found it quite interesting.

Also, I've read the whole Code Complete and it was also interesting and I considered it one of the best books for programmers.

As for CLRS - boring as *%&^%#, I just can't manage to get past the sorting chapter. AFAIR there are not exercise answers so one is left alone when doing them, which mostly disqualifies every such book for anyone who is studying it on it's own, not in a class room.

Skiena's book is far, far better written, but unfortunately some of the exercises are to thought for me so when I'm reading my exercises are from 2-3 chapters behind. Although it's good that there is a wiki with (not always correct) answers.

Haven't read TAOCP.

osipovonJan 23, 2021

Erich is also one of the Gang of Four, the authors of the Design Patterns book. The fact that IBM did not recognize him as a Fellow and let him leave for Microsoft tell you a lot about why IBM's stock is in the gutter.

munificentonMay 18, 2020

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

weavieonSep 4, 2015

> it's getting from what needs to happen to how to decompose into classes/methods/libraries

Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience.

If you have to go OO, there have been plenty of people who have thought long and hard about how to make OO a suitable solution. Some classic books you may want to consider :

- Design patterns : elements of reusable object-oriented software (Gang of four) - there are people who swear by this and turn it into their hammer for which everything becomes a nail.

- Patterns of Enterprise Application Architecture (Martin Fowler)

- Refactoring: Improving the Design of Existing Code (Martin Fowler and Kent Beck)

- Growing Object-Oriented Software, Guided by Tests (Steve Freeman)

detaroonMar 2, 2021

"Design Patterns: Elements of Reusable Object-Oriented Software". also called the Gang-of-Four or GoF book for the four authors.

edroonNov 11, 2014

Speakers include:

Tom Chi (co-creator Google Glass)
- Grady Booch (creator the Unified Modeling Language)
- David Heinemeier Hansson (inventor of Ruby on Rails)
- Brian Fox (invented the GNU Bash shell)
- Rebecca Parsons (CTO, Thoughtworks)
- Hakon Wium Lie (inventor of CSS)
- Alex Gaynor (Director, Python Software Foundation, and core committer to Django)
- Sarah Allen (Presidential Innovation Fellow, led development for many Adobe products)
- Gilad Bracha (co-author of the Java Language Specification)
- Kent Beck (creator of Extreme Programming, created Test Driven Development, co-created Agile, author of 9 books)
- Ward Cunningham (inventor of the wiki, contributed to Extreme Programming, co-author of Design Patterns)
- Bram Cohen (inventor of Bittorrent)
- Hampton Catlin (creator of Sass, Haml, m.wikipedia.org, book author)
- Matei Zaharia (creator of Apache Spark)
- Melody Meckfessel (Google Director of Engineering)
- Jon Skeet (the top answerer on StackOverflow)
- Scott Hanselman (author of multiple books)
- Jeff Haynie (founder of Appcelerator)
- Ryan Bubinski (founder of Codecademy)
- Aaron Skonnard (founder of Pluralsight)
- Floyd Marinescu (founder of InfoQ)
- Steve Newcomb (founder of Famo.us)
- Orion Henry (founder of Heroku)
- Janet Wiener (Engineering at Facebook, big data expert)
- Scott Chacon (CIO, Github)
- Chad Fowler (CTO, Wunderlist, well-known programming educator and blogger)
- Salil Deshpande (open source investor titan)
- Hadi Partovi (founder of Code.org, was in charge of Internet Explorer, advisor to Dropbox and Facebook)
- Qi Lu (EVP, Microsoft)

andrewriceonNov 11, 2014

Easier to read:

  - Tom Chi (co-creator Google Glass) 
- Grady Booch (creator the Unified Modeling Language)
- David Heinemeier Hansson (inventor of Ruby on Rails)
- Brian Fox (invented the GNU Bash shell)
- Rebecca Parsons (CTO, Thoughtworks)
- Hakon Wium Lie (inventor of CSS)
- Alex Gaynor (Director, Python Software Foundation, and core committer to Django)
- Sarah Allen (Presidential Innovation Fellow, led development for many Adobe products)
- Gilad Bracha (co-author of the Java Language Specification)
- Kent Beck (creator of Extreme Programming, created Test Driven Development, co-created Agile, author of 9 books)
- Ward Cunningham (inventor of the wiki, contributed to Extreme Programming, co-author of Design Patterns)
- Bram Cohen (inventor of Bittorrent)
- Hampton Catlin (creator of Sass, Haml, m.wikipedia.org, book author)
- Matei Zaharia (creator of Apache Spark)
- Melody Meckfessel (Google Director of Engineering)
- Jon Skeet (the top answerer on StackOverflow)
- Scott Hanselman (author of multiple books)
- Jeff Haynie (founder of Appcelerator)
- Ryan Bubinski (founder of Codecademy)
- Aaron Skonnard (founder of Pluralsight)
- Floyd Marinescu (founder of InfoQ)
- Steve Newcomb (founder of Famo.us)
- Orion Henry (founder of Heroku)
- Janet Wiener (Engineering at Facebook, big data expert)
- Scott Chacon (CIO, Github)
- Chad Fowler (CTO, Wunderlist, well-known programming educator and blogger)
- Salil Deshpande (open source investor titan)
- Hadi Partovi (founder of Code.org, was in charge of Internet Explorer, advisor to Dropbox and Facebook)
- Qi Lu (EVP, Microsoft)

50shadeonNov 11, 2014

-Tom Chi (co-creator Google Glass)

-Grady Booch (creator the Unified Modeling Language)

-David Heinemeier Hansson (inventor of Ruby on Rails)

-Brian Fox (invented the GNU Bash shell)

-Hakon Wium Lie (inventor of CSS)

-Alex Gaynor (Director, Python Software Foundation, and core committer to Django)

-Sarah Allen (Presidential Innovation Fellow, led development for many Adobe products)

-Gilad Bracha (co-author of the Java Language Specification)

-Kent Beck (creator of Extreme Programming, created Test Driven Development, co-created Agile, author of 9 books)

-Ward Cunningham (inventor of the wiki, contributed to Extreme Programming, co-author of Design Patterns)

-Hampton Catlin (creator of Sass, Haml, m.wikipedia.org, book author)

-Matei Zaharia (creator of Apache Spark)

-Melody Meckfessel (Google Director of Engineering)

-Jon Skeet (the top answerer on StackOverflow)

-Scott Hanselman (author of multiple books)

-Jeff Haynie (founder of Appcelerator)

-Ryan Bubinski (founder of Codecademy)

-Aaron Skonnard (founder of Pluralsight)

-Floyd Marinescu (founder of InfoQ)

-Steve Newcomb (founder of Famo.us)

-Orion Henry (founder of Heroku)

-Janet Wiener (Engineering at Facebook, big data expert)

-Scott Chacon (CIO, Github)

-Chad Fowler (CTO, Wunderlist, well-known programming educator and blogger)

-Salil Deshpande (open source investor titan)

-Hadi Partovi (founder of Code.org, was in charge of Internet Explorer, advisor to Dropbox and Facebook)

-Rebecca Parsons (CTO at Thoughtworks)

-Qi Lu (Executive vice president of Microsoft’s Applications and Services Group)

-Chris Richardson (Java Champion, book author, founder of CloudFoundry)

-Bram Cohen (Inventor of Bittorrent)

loumfonNov 28, 2010

A lot of people misunderstand that book. Design Patterns reduce complexity when used correctly. A good book to understand that is Refactoring to Patterns http://industriallogic.com/xp/refactoring/.

If you need your code to construct objects without knowing the type, then you need a factory (or other creation pattern). If you don't -- it's overkill. They are using a solution to a problem they don't have.

seregineonJuly 7, 2014

The book that inspired software patterns. I found it more interesting than GoF's "Design Patterns", and it feels less dated these days:
The Timeless Way of Building by Christopher Alexander

The C2 wiki has interesting entries on software patterns and related ideas:

Stanford CS 240 has a great list of papers on system design:

One paper that's no longer on that list, but I remember from when I took the class:
End-to-end arguments in system design

trilinearnzonMar 19, 2020

Too many =P But seriously, there are certain volumes I would never part with. For example: The Pragmatic Programmer, SICP, Design Patterns, The C Programming Language. Tomes which are definitive and timeless.

I also have a few for purely nostalgic value, representative of key moments in my past. Notably: the OpenGL Red Book and C++ The Complete Reference.

MachaonMay 27, 2019

In the past, students read the books in the college library, as it was the best way to find information about the topics they studied. Having their own copy was prohibitively expensive for anything more than the textbooks and maybe one or two books of required reading (this may be an experience in countries with free education, when you're borrowing several thousand a semester, another thousand for textbooks is probably less significant, but it was true in Ireland), and the only other source of information was the college's journal archive which was definitely not aimed at beginners.

Nowadays, most students have a library of pirated PDFs, meaning they have the information on hand where they need it and with no need to return it or find it already borrowed in the college library. Most colleges will give you access to online databases of journals, so they aren't a draw either.

The other problem encountered was that of QC. At least in my institution more substantial books were always in short supply, as they'd never have more than 5-6 copies of a single book, so you'd arrive at the computing section and find... "Java 2 for Dummies". Or "Teach yourself C++ in 24 hours". Books that might have been fine to self-learners (when they were not significantly outdated), but nothing that wouldn't be covered in a textbook and nothing more substantial.

Probably this is a disconnect between the people running the library and the lecturers, but the attitude of the library was "Yes, we have software development books. What do you mean 15 years is out of date? The psychology books have been there since the 70s. And our figures show that more students have taken out 'Java 2 for Dummies' than 'Design Patterns' or 'The Pragmatic Programmer', so we don't need more copies."

But those two factors, the greater accessibility of pirated PDFs and blogs (and for some of the slightly more recent students, Stack Overflow), and the lacking quality of what was probably available on the shelves at any given point you chose to look meant that the library was definitely way more useful as a study space than for the contents of the shelves for the other students and myself during my degree.

dragonwriteronFeb 8, 2017

> >, the good old Design Patterns book, responsible for more atrocious over-abstracted,

> This is a misunderstanding of the DP book.

It is discussing an effect of the book, not the intent.

> It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies.

Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.

qwertyuiop924onJuly 21, 2016

Seeing as I have the freedom to code in lisp, etc., much of Design Patterns may be of questionable value. However, knowing my own weaknesses writing code (every piece of code I have written is terrible), and my relative newness to programming (I've been doing this on and off for 7 years, but rarely seriously), Refactoring seems like it may be of value.

mattfrommarsonJune 29, 2018

Does anyone know a good time in one's career to take time out and spend it on going through SICP and videos lectures with it?

I have a STEM (non-CS) degree but very recently, started working as a programmer. Doing my first internship at a 'techy' corporate company. One of the things I'd be doing on the side is to go through https://mitpress.mit.edu/books/elements-computing-systems. The video introduction to it just gives me goosebumps to this day. I don't know why. It's fascinating.

Than there is other paradigm books such as "pragmatic programmer", "Thinking Like A Programmer", "Design Patterns: Elements of Reusable Object-Oriented Software", etc.

So far, I've done plenty of reading on Algorithm & Design Structure and leetcode here and there. In the past, I didn't qualify for internship at Google, Amazon or M$ as a software developer/engineer. I feel the reason why I didn't was because I didn't have a "computer science" keyword mentioned anywhere on my resume. Hence, my hope is after getting through "Element of Computing System" & Design Pattern, I'll be able to shove in "computer science" keyword one way or another on my resume.

munificentonAug 14, 2012

From Design Patterns (first edition):

> Delegation is a way of making composition as powerful for reuse as inheritance [Lie86,JZ91]. In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate. This is analogous to subclasses deferring requests to superclasses. But with inheritance, an inherited operation can always refer to the receiving object through the "this" member variable in C++ and "self" in Smalltalk. To achieve the same effect without delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver.

Sounds like they're perfectly clear and correct to me. As the author of the post points out the GoF don't actually show examples of delegation in the book and I don't recall them using the term much, so I don't see how they're perpetrating any misinformation here.

> In JS we can assign a prototype: the equvalent of the parent slot in Self.

No, .prototype is not equivalent to a parent slot in Self. It's closer to a traits object, I think. The unstandardized __proto__ property is equivalent to a parent slot in JS.

> Yeah, Design Patterns showed examples in Java. And Java can’t do delegation. So is that a valid argument for rewriting the meaning of a term?

Design Patterns is older than Java. Maybe later editions use it, but the original version used C++ and Smalltalk.

Otherwise, good troll post, original author. I'm sure you'll get lots of traffic and people noticing your book. Well played!

cottonseedonJuly 25, 2017

Tough question. I'm not aware of any books that are substitutes for reading and writing large projects, some books I've found useful: TCP/IP Illustrated: The Implementation (goes through the implementation of the 4.4BSD-Lite network stack), Lion's Commentary on UNIX (or xv6 book), Network Algorithmics (amazing book), Linux Kernel Development by Love, Large Scale C++ Software Design, Design Patterns. A lot of people like the Architecture of Open Source Applications books. I also think learning more computer architecture as the beginning of computer systems engineering is good for everyone, but that's just me.

Lampson's classic on hints for computer system design:


Here is a previous HN post on the subject: https://news.ycombinator.com/item?id=8000811

The Clean Code author has a Clean Architecture book but I don't think it is out yet.

aaron-santosonSep 13, 2017

Christopher Alexander, an architect who wrote among others A Pattern Language: Towns, Buildings, Construction. A Pattern Language later inspired Gamma et al to write Design Patterns: Elements of Reusable Object-Oriented Software.

muzanionJuly 2, 2021

I thing the big difference is that software is gradually becoming more declarative. It's less about coding how it does things, more about coding what it is doing. This has been the flow for many decades, but it's more common now than 5 years ago.

Something like React is the norm now. It's not necessarily any simpler or faster, but it's more efficient past N hours, which is the case for many larger companies.

It's also why functional programming has regained popularity, or at least writing functions the way you would for functional (immutable, output of one is the input of another).

However, we're still using a lot of old techniques. The best book on Design Patterns was written in 1997. Pragmatic Programmer was written in 1999 (though revisited a few years ago). The best TDD book is still from 2002; a lot of modern takes on TDD gets the philosophy completely wrong. TDD was meant to reduce fear, not improve test coverage.

ChuckMcMonSep 9, 2018

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE.

My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time.

Right now, on your first job experience, even a kid who never went to college is better at programming than you are because they've been experiencing all the pitfalls that can happen and have built up a knowledge from that which is perhaps more intuitive than formal but serves them well. What you have over that person is that you've trained yourself to consume, classify, organize, and distill massive amounts of information in a short amount of time.

Use that training to consume everything you can on the art of writing programs. Read "Test Driven Development" read "Code Complete", read "Design Patterns", read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1", and a book or two on databases. With your training you should be able to skim through those to identify the various "tricky bits" and get a feel for what is and what is not important in this new field of yours.

Soak in as much as you can and ask a lot of questions. Pretty soon no one will know you haven't been doing this your whole life.

xueyonggonMay 12, 2020

Keep writing!! I've personally started my journey into content creation as a software engineer just this year! To be more focused, I found a growing passion for Design Patterns and started writing my learning about them. Hope to share the same passion with you! Keep going pal! Would love to hear some tips from you! Here's my site, and hope it encourages you all!


scarface74onAug 24, 2019

I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.

shubhamjainonMar 6, 2015

I read "The Pragmatic Programmer" about two years back and back then I felt inspired and excited about all the wonderful ideas shown in the book. Fast forward to today, it seems that stuff was kinda obvious - automate things, read, take responsibility, care for the craft, be patient and the other forty tips.

I kind of believe that, have I not read the book, I would have stumbled upon the ideas later anyhow, by reading blogs, tinkering, and making mistakes. Albeit, it is wrong to expect any magical words that can shift your direction completely, but still I am not sure how much value do printed ideas provide vs learning them by experience. I am not implying that books like it are futile but I don't buy that they are "career-changing".

Same goes for reading about Design Patterns. I believe it is better to learn "Design Patterns" by building and reading code and finding a certain code organization better for your use-case, rather than enforcing a kung-fu-singleton-ninja pattern where it might be simply an over-engineering.

pjmorrisonJuly 27, 2016

I'm a huge fan of Stewart Brand, starting with the 'Next Whole Earth Catalog', which is where I learned how big a fan Brand is of Christopher Alexander and his 'A Pattern Language'. Alexander's work in patterns inspired the 'Gang of Four' to write 'Design Patterns'... so I think your best-seller prediction is not only correct, but empirically validated :)

vogonJuly 14, 2016

> inheritance & mixin bad / composition good

This wisdom is at least as old as the classic GoF book [1] which was published in 1994. Many of their patterns can be summarized as: "Favor 'object composition' over 'class inheritance'."

They also give a pretty simple, compelling reason for that: It is just a direct consequence of the even more fundamental principle:

"Program to an interface, not an implementation."

[1] Gang of Four (Erich Gamma,
Richard Helm,
Ralph Johnson,
John Vlissides): "Design Patterns: Elements of Reusable Object-Oriented Software" https://en.wikipedia.org/wiki/Design_Patterns

slowmovintargetonApr 27, 2021

It actually was a problem.

From the article:

> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.

I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)

It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.

Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)

voicedYodaonApr 24, 2020

Design Patterns by Gamma, Helm, Johnson, and Vlissides (aka GoF)

StormbringeronMar 29, 2011

I think that Guido probably has his plate full with the open revolt over the transition to version 3.

Javascript is much closer to a halfway point to Lisp than Java. I don't really see Java as being at all similar to Lisp... witness the 3-4 year (possibly longer) debacle trying to get closures into the language. Talk about banging a square rhinoceros into a round hole.

Java's point of greatest similarity to C++ is undoubtedly Generics, which has all the syntactic disadvantages of C++ templates, but none of the meta-programming advantages.

But one of the ways of seeing that C++ and Java are quite dissimilar is to first grok Java Interfaces, and then read through the smalltalk/C++ version of the GoF book Design Patterns, with a view to how many of the Patterns don't even make sense in Java or are obsolete in Java because of Interfaces.

tobinharrisonJuly 27, 2014

I think this pattern was popularised in the Design Patterns book (Gama et al).

But my guess it's a natural progression from a standard Factory; Factories allow instantiation without specifying any type, and FactoryFactories afford the same flexibility, but just for instantiating a Factory without knowing it's type.

This was probably reenforced by the fact that life was easier if you built to interfaces rather than implementations, so factories were good for this.

I actually love the design patterns book, but I sometimes curse it - especially when stumbling upon things like the AbstractSingletonProxyFactoryBean. WTF!


munificentonFeb 8, 2017

> which turn up again and again in Java code

This is true, but it's an effect, not a cause of the book. "Design Patterns" is older than Java. They wrote it based on patterns they saw mainly in Smalltalk and C++.

> prescribed their use generally

Like "A Pattern Language", "Design Patterns" reads more descriptively than prescriptively. It's, "Here's a thing we saw people do. Here's what problem they were solving with it. Here's the context of their problem. Here's the positive and negative consequences."

smprkonApr 19, 2014

I would recommend very simple things really -

1. For Data Structures and Algorithms.

- Join this site where active job seekers hang around and share interview questions - http://www.careercup.com

- Solve a question a day and post your solutions, read through that of others and comment.

- This is an active community so you would get up and running with the basics quite fast.

2. For Design Patterns.

- Do a "light reading" of this book - http://www.uml.org.cn/c%2B%2B/pdf/DesignPatterns.pdf

- Explore opensource projects and see if you can identify patterns.

shaileshonJuly 25, 2013

Assuming that you've found an interesting business problem to solve:

1. Write a list of desired features. Next, prioritize those features.

2. Write brief functional specifications for features of highest priority.

3. Decide on how you want to use the software stacks for different tiers, e.g.

   Browser - Bootstrap or Zurb, AngularJS

Server stack - node.js, Ruby, Python

Database - MySQL, Postgres

These examples are sketchy, just to give a feel of things.

4. Research any libraries that automatically handle common functional units, such as authentication and authorization, analytics et al.

5. Some functional units might be implemented more easily by gluing together services. E.g. using New Relic for deep application monitoring, Twilio for cloud communications.

6. Design and implement all functional units.

7. Profit!

8. Write a Thank you HN note, :)

One should do this exercise for a "toy" application like "To Do List" first. It helps remarkably when we go about building serious stuff.

1. Code Complete by Steve McConnell - worth at least skimming it.

2. Design Patterns by Erich Gamma et al

Also, definitely have a look at Peter Norvig's slides:

3. About Face 3: The Essentials of Interaction Design by Alan Cooper

4. Writing Effective Use Cases by Alistair Cockburn

1. Obviously, HN, :)

2. http://highscalability.com/

It may look like a huge undertaking, but it really isn't. A quote from Michael Abrash seems appropriate here, "Winning a hard race prepares us for the next harder one."

This is just top of the mind; hope this helps.

Good luck.

Edit: formatting.

JareonJuly 8, 2013

It's what the book /says/, but in practice it's not what the book /encourages/: a bit like alcohol or sports car TV ads, which all say "drink/drive responsibly". Your own introduction suggests patterns as a cure for bad design and architecture:

"I started trying to find books about how to organize programs. Fast-forward several years and a friend hands me a new book: Design Patterns: Elements of Reusable Object-Oriented Software. Finally! The book I’d been looking for since I was a teenager."

"But the architecture that this brilliant code hung from was often an afterthought. [...] if they ever cracked open Design Patterns at all, never got past Singleton."

I'm sure most cases of badly architected code you have ran into were caused by insufficient time and/or attention devoted to design and architecture. Now the question is, do you think if these coders had the same time/attention but knew patterns, the result would be better? How would it compare to these same coders without patterns but with more time/attention?

In that sense, metaphor alert a book of design patterns is to programming what a dictionary is to writing: useful, but mostly orthogonal to the quality of the output.

jrochkind1onJune 22, 2015

Design Patterns: Elements of Reusable Object-Oriented Software http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...

Practical Object-Oriented Design in Ruby by Sandi Metz. http://www.poodr.com/

mynegationonFeb 25, 2011

First of all, do not ever call yourself "slow" or "not very smart". This is just not true. I haven't realized that English is your primary language until you mentioned it Granted, English is not my native language either, but the point is: if you could get this far with the natural language you're definitely have anything but the learning disability. And having a stable job after dropping out of college is no small feat either.

Algorithms and Data structures. I have CS and Applied Math degrees, but honestly - very rarely I have to recall the inner workings of specific algorithms and data structures. It is useful to know how it all works, but not as important as you may think. You can certainly follow "fake it till you make it" approach: you need to remember memory and time complexities of the data structures and some implications, e.g. "hash tables have asymptotically O(1) search time but may consume more memory than red-black trees that provide O(log(n)) search time but have guaranteed memory and search time constraints". And so on and so forth. So go ahead and read Cormen with that in mind.

Also, my guess is that you need only as much CS as you need to become a better software developer. I don't think you want to be a theoretical computer scientist, do you?

In your situation I would also recommend reading following books:

"Structure and Interpretation of Computer Programs". Honestly, to CS graduate it reads like a book for preschoolers but it is very beautifully written and is almost zen-like. And it will definitely help you understand what programming is about if you did not get proper formal training.

"Design Patterns". It is not a CS, but Software Engineering book. It provides a framework for your software design skills. You can be a great programmer without reading that book, but then you have to be exposed to a lot of beautifully designed code, and that book will save you a lot of time.

Find a popular and stable open source project that is closest to what you are doing now or what you want to do and read the code, look at the build infrastructure, documentation, try to get involved and maybe even fix some bugs, starting from simplest ones and moving up to features. You'll get a lot of brutally honest peer reviews, just don't abuse it.

Hope that helps.

ratwwonMar 9, 2021

I agree with you and the TFA. I also think that naming the book "Design Patterns" and calling the techniques "Patterns" is unfortunate and misleading.

But I think calling them like that is what made the book as famous and as is it. If the book were called "OOP Programming Techniques" it wouldn't have the same popularity. Of course that doesn't make it right.

As a book it has served its purpose at the time, but by portraying what are basically "band aids" to limited programming languages (Norvig 1996) as foundational CS knowledge, it ossified the development of OOP and CS itself by a few years IMO.

wheelsonMar 3, 2008

- Introduction to Algorithms (MIT Press). This is the only one of my computer science textbooks that I consistently refer back to. It's elegant and timeless and covers a lot of ground.

- Design Patterns. Dry, boring, useful. You can skim it and get most of the ideas. The best part about it is building up a vocabulary for discussing common patterns with other software engineers.

- Programming Perl. Ah, the camel book. It's possibly the only written-by-the-language-designer reference that's fun to read. Regardless of what your favorite scripting language is, you have to love Larry Wall.

- The Mythical Man Month. Another classic. Easy to read. Stuff people should know, but don't.

- The Design of Everyday Things. Not really a programming book strictly, but a nice introduction to the principles of usability. If you can get over the slight smugness, it can shake up the way you think a bit.

q845712onMar 7, 2021

That's interesting - thanks!

I think "catalogers" as I'm thinking of them are by nature not quite pioneers, since the fundamental move of cataloging is to describe and categorize what already exists, but might often be settlers, in the sense that a good career move for a cataloger is to be the first to apply a new process to gain insight into new distinctions or categories. In that sense I would see GoF themselves acting as "settlers" in their Design Patterns book, which I tend to view as a catalog project.

However books like "Refactoring", and "Working effectively With Legacy Code" also turn into partial cataloging projects, but those might overlap more with "town planner" in that they're really leveraging some mature technologies and looking for system-level economic savings of readability/changeability/maintainability.

So I guess I'd continue to argue that it's a "mindset" as much as "a type of person"; "Working Effectively With Legacy Code" isn't _only_ a catalog, but there's parts of it that come from a catalog mindset.

Regardless, I hadn't seen the above mapping you linked and I appreciate it!

SilhouetteonApr 20, 2018

Short answer: No, but your best bet might be to read old, substantial books, and find other work by the kind of people who read and wrote those books before they were old.

Longer answer: Basically, you need to get away from the world of front-end web development, and from the echo chamber blog posts and conference talks by people who have only ever worked in that area. No-one is writing anything large, high-performance, high-reliability or long-lived there yet, so you need to look for experience from people who have had to do those things in other contexts instead.

Classic books like Code Complete and The Pragmatic Programmer, early "serious OO" books like Design Patterns, and practical advice books of a similar generation in the Effective <programming language> style all contain a wealth of knowledge and insightful commentary. Of course some of the technical details are quite dated today and some of the specific techniques discussed might no longer be considered good practice a decade or two later, but many of the underlying principles and the discussions around them are as relevant as ever. A bit more recently, there were interesting discussions about a broad range of programming issues in Beautiful Code and the related titles, and there have been some interesting case studies based on open source software too.

If you want to read some shorter pieces online, I recommend finding a few authors who work in fields like games or embedded software, where there are often significant performance and reliability constraints to deal with, not to mention hard deadlines that force difficult decisions and compromises. There are some healthy doses of reality in there that you won't find in less demanding environments.

Enterprise applications, while often considered bland, can also be large and some of the longest-lived software we develop, and much has been written about organising and maintaining them, including real-world pressures like changing operating environments and large development teams whose members come and go. Perhaps a little ironically, this now includes a fair bit of back-end web development. Some of the writing around this is well worth a read as well, but beware that this part of the industry is plagued by consultants who talk a good talk but don't have much of a track record or other evidence to back up their advice. Approach with caution, particularly anyone who uses words like "agile", "lean", "craftsmanship" and anything else on the buzzword scale.

sg0onApr 4, 2018

These are the ones right next to me now:

1. Design Patterns (GoF) - This book is all about design, someday I aim to really understand all the patterns.

2. High Performance Parallelism Pearls Volume 2 (Reinders/Jeffers) - There are couple of other books similar to this one. But, if you want to know how myriad HPC applications make use of parallel programming models such as MPI and OpenMP, this provides a good introduction.

3. The Annotated C++ Reference Manual April 1995 hardbound edition (Ellis/Stroustrup) -- What a fantastic little book, also got it for $4.95 at Powell's bookstore in Portland :) IMO this books provides a gentle introduction to C++, you can flip to any page and just start reading.

4. Numerical Recipes in C (Press, Teukolsky, et al.) - If I need to quickly prototype some scientific computation kernel, this is my go-to book.

5. Effective C++ 3rd edition (Meyers) - I like to approach this book from the back (i.e., indices), pick up a topic, and then read the contents one by one. Repeat.

6. Discovering Modern C++: An Intensive Course for Scientists, Engineers, and Programmers (Gottschling) - I like and dislike certain portions of the book. It definitely contains a lot of code explanations of C++ idioms, which helps a beginner like me.

mujocoonOct 1, 2018

I read a few Head First books when I was first learning to program (Java, SQL, and Design Patterns), and I know what you mean about the books trying too hard to be funny, with lots of silly stock photos, word search puzzles, and the like.

Even so, Head First Java in particular is a good introduction to object-oriented programming for someone with no prior background in it. I feel like any beginner who can look past the silliness of the Head First style could learn efficiently from this series. I wouldn't use a Head First book now, but they are good for people without much background to build on who want an easy learning curve.

bendee983onDec 4, 2020

For me, nothing will replace the original GoF book:
"Design Patterns: Elements of Reusable Object-Oriented Software"
It's still worth reading. But I also recommend "Object-Oriented Analysis and Design with Applications" by Grady Booch. It's not strictly design patterns, but it's a classic that explores a lot of the fundamental concepts you'll need for DP.

dragonwriteronAug 5, 2015

All languages need design patterns; they are about designing how to implement certain functionality.

Languages differ in which design patterns have a native expression in the language, which can be reduced to simple reusable library code, and which require type-it-in-each-time fill-in-the-blanks code recipes.

The fact that Design Patterns were popularized in software development by the GoF book which, among other things, included code recipes to illustrate its patterns, and that the patterns in it tended to be ones for which the popular languages of the day required code recipes (lacking native implementations or the ability to provide general implementations as library code), has unfortunately associated the term with the code recipes, which aren't really the central point of understanding and using patterns.

sjclemmyonJan 4, 2013

I did the same; taught myself css, php, javascript and quit my FTJ last Christmas. Best thing I ever did.

I also sent the following as advice to someone wanting to get into web dev:

"I was just thinking of 'easy ins' to the world of web development and a good source of information is http://news.ycombinator.com/ there's a lot of information from people who work in the world of tech startups and it's good information.

Also - if you are wanting to do php dev the key things to learn are:
Software engineering techniques and practice - object oriented development and abstract patterns are key to how to think about good development.
Database design and development (1st normal form, third normal form etc) Learn SQL. (SQL for dummies or similar is good for the basic commands and syntax etc.)
Stackoverflow.com - it's the best source of help for software development on the internet.
read books, the ones that come up again and again when people talk about learning to program:


also - look at github.com - that's where programmers keep their source code.

Learn about Object Oriented Programming, Design Patterns, MVC (which is a design pattern) is specifcally useful for web development.

Also - demand for javascript programmers will increase over the coming years because of things like jQuery and Ajax.

That's my starter for ten - if you are interested in a career as a web programmer.

If you want to focus more on the html/css design side you could do worse than focusing on one CMS - such as wordpress and learning it inside out - you could then offer that to clients and it's a good way to provide web sites cheaply with very little effort."

dllthomasonSep 6, 2014

Did you just want to voice your opinion and find my comment relevant enough to serve as a place to hang it, or did you mean that as a response to what I wrote? I don't think I substantively disagree, although I think Norvig's claim is often read (not sure if intended) slightly stronger than is merited. I would also note that the list does not seem to be restricted to "security professionals", but to all those interested in learning about the topics in the list I quoted above. I broadly agree with the thesis that Design Patterns doesn't fit that mold particularly well.

(In general, I find it a recurring problem on HN - and to some degree similar fora - that I am not sure what conversational role a poster intended their comment to serve; I wonder if there is a good way to address that...)

mark_l_watsononOct 6, 2018

Looking on my bookshelf I see that Design Patterns for Smalltalk is only about 40% of the length of Design Patterns for Java. Design patterns are not much required for reasonable dynamic languages. Interestingly, they don't seem to be needed for functional languages like Haskell either.

All that said, when I did a lot of Java programming over about a 15 year period, I found the Java Design Patterns to be useful.

shadowmintonMar 13, 2018

> I felt it was a modern followup to the classic Design Patterns...

If you’re going to recommend a book, then why not just recommend Design Patterns?

That’s actually a good book; and, if you read it, you will extract exactly zero value from this one, which gives only the most trivial coverage of a handful of the patterns from the former.


I feel like people who 5 star review this on amazon didn’t read Design Patterns becuase it looked to scary, and liked it because this was cute and simple and easy.

...unfortunately, the reality is that cute simple explanations are usually trivialising the content (as this book does; seriously go read a few game programming gems if you think game programming is as trivial as a singleton...), so given a choice of a universally acclaimed coverage of the topic, and some hand drawn pictures, why the heck would you recommend the latter to anyone other than a student?

I don’t get it, and I see no value in the content of this book ...but, I guess different things for different people.

brnstzonJan 31, 2013

> That's orthogonal to OOP, isn't it?

Sure, you can do upfront design in any language. But you need to have experience to do upfront design. If you're new to programming, you should just hack around.

The other option is to read a Design Patterns book and treat it like religion. This is what happens to many new programmers who start with C++ or Java. You learn the patterns and you apply them everywhere, because that's what you were told to do. Some people like this, but many are turned off right away. I understand the point of things like Java. They make it possible for dozens of programmers to collaborate on a large project without stepping on each other's toes. But all of that abstraction makes no sense to a new programmer (at least one who is not a super intelligent space alien).

I don't see that risk in other programming paradigms, mostly because they are not as popular. But I also think something like functional programming carries a lot less baggage than OOP. It's easier to get the main concept.

Dynamic typing is easier on a newbie. They're just trying to put the parenthesis in the right place. There's plenty of yelling going on already. That said, something like Haskell which is less verbose probably wouldn't be so bad.

saturnflyeronAug 14, 2012

I'm the author. I'm not redefining delegation. I'm pointing out that the Gang of Four, who cited Henry Lieberman who created the term, described it incorrectly. You can read the citations in the Design Patterns book and see exactly what they got wrong. Here's a link to Lieberman's work http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...

strlenonJan 11, 2011

It's not that Scala is Effective Java, it's that "Effective Java" (the book) is a good set of patterns of software developments in many other object oriented languages. You'll note much of the same discussed in Design Patterns (unfortunately, in a more rigid and less accessible form) and visible in well written pieces of software in Java, C++ and many other languages. That's why I highly suggest reading Effective Java even if you hate Java the language / Java the culture, the latter symbolized by horridly designed and implemented frameworks like Spring which have turned design patterns into a set of buzzwords to liberally sprinkle.

throughonJan 8, 2019

Perhaps your or another’s understanding changed. Avoid the cargo cult of millennial software design. It’s generally polluted.

It does no harm to reference the GoF that perhaps the same G. Booch is associated with:

Design Patterns:
Elements of Reusable

Replace word first thinking with thought first thinking and you’ll be fine.

AsookaonOct 26, 2017

To expand slightly, a single read from memory that's not cached and actually has to go to RAM can take 100 cycles. That's 100 cycles during which your CPU does nothing but wait for electrical signals to travel to and from RAM. Well written data processing programs (game engines, physics simulations &c) strive to structure their data so they have as few of those as possible. If you just read "Design Patterns" and wrote a beautiful 10-level deep class hierarchy in Java, where every object access can be behind something like 3 levels of indirection via pointers.

This is not a critique against either Design Patterns or Java, both of them are important and useful. And really, quite often you don't care about waiting 100 cycles, you have ten million times 100 cycles in every second. It's when you start crunching numbers in large quantities that it can get problematic. Modern CPUs are very fast, but only if you feed them data in the right order. Otherwise you're basically running on a machine from 20 years ago, just with 32GB of RAM. Best program design right now is to yes, do write your deep class hierarchies and whatnot, but also know how to identify the parts of your program doing heavy computation and how to restructure those so you can unleash the full power of a modern processor.

neiljohnsononAug 22, 2010

Without more specifics it's hard to give practical advice. Daniel Pink's book 'Drive' and the video that has been doing the rounds in response http://www.youtube.com/watch?v=u6XAPnuFjJc make an awful lot of sense.

Essentially to get the best from people you need to give them
* Autonomy
* Mastery
* Purpose

I suspect from your question that you are most interested in
focusing on Mastery, specifically how to help them make progress towards it.

I found Pragmatic Programer to be a pretty good general resource. http://www.pragprog.com/the-pragmatic-programmer

Outside of that I'd second the other comment here taking about Design Patterns - I think that the Head First book http://oreilly.com/catalog/9780596007126 is a great introduction

Day to day, finding ways to give to really quick feedback is important, code review and general collaboration with the others will really help.

dboydonDec 14, 2010

The Pragmatic Programmer: http://pragprog.com/titles/tpp/the-pragmatic-programmer

Code Complete: http://cc2e.com/

Introduction to Algorithms (google that one, it's hard to find a good link)

Domain Driven Design: http://domaindrivendesign.org/books/evans_2003

Design Patterns: Elements of Reusable Object-Oriented Software

The term "web development" doesn't mean much. There is web design. There is application development. When the two mix, there is web application development. Any kind of application development is hard, and simply knowing a language or two isn't going to make you a good application developer any more than knowing english will make you Stephen King. (IMO)

specialistonApr 24, 2020

The value of Design Patterns is the shared vocabulary. Abuse of words, grammar drives me nuts too.

But older me now understands every generation goes thru a phase where they think they newly discovered sex.

When I asked my then teenaged son the difference between "emo" and "goth", he informed me that "goth" is for old people.

themulletonSep 4, 2015

Design Patterns! As you said your problem is "how to decompose into classes/methods/libraries"

Book wise, I learnt them from "Head first design patterns" which is useful and fun or for a quicker overview - http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/in... .

Also remember if you have other people around you delegate / meet them / bounce ideas together.

vram22onAug 12, 2017

>One of the main points of design patterns is composition over inheritance.

One of the opening pages of the Design Patterns book (the GoF book) has "Prefer composition over inheritance" (or words to that effect) as the only sentence on that page, right in the middle of it. My guess is that the GoF authors did that to emphasize the importance of that advice, maybe due to having seen too many brittle inheritance-laden hierarchies.

I mentioned this to a client I was consulting to, a couple of years ago, after I saw that he seemed to be using inheritance too liberally, and maybe without thinking if it was needed and the right thing to use for his specific needs. He did get the point, and changed his code from then on.

kazinatoronOct 15, 2016

From the first list, I've only read (3) The C Programming Language and only partially (5) Mythical Man-Month.

From the second: (1) Intro to Algorithms, absolutely cover to cover once, and selected readings additional times; based the Kazlib "dict" module closely on the Red Black tree algorithm (with a slight improvement); (2) Compilers: Principles, Techniques and Tools: Ditto, and in recent years, implemented a regex compiler based on the graph-based descriptions in that book; (3) TAOCP: selected readings only, too huge; (4) Design Patterns: cover to cover, when OOP was fashionable in the 90's; (5) nope, but I read the Stroustrup and Ellis Annotated C++ Reference Manual cover to cover (weekend before starting first C++ gig). That counts as a 1:1 substitute, more or less.

sramsayonDec 27, 2012

"I just wish I never become that guy."

But hopefully you will, and I can tell you why.

After a long and painful apprenticeship, you finally realize that being a great programmer has nothing to do with the language or its features. You get to the point where you're completely done learning this or that new technique (which, by the way, is nearly always an old thing for someone else). Your "profound enlightenment experience" with Lisp is ten years old; your copy of Design Patterns looks like an old Bible; you've had dozens of dirty weekends with stack-based languages, declarative languages, experimental languages, etc. You've been all of those places and done all of that. Many, many times.

At that point, the pros on cons have fully evened out, and what you want is a tool that you can completely and totally master. You've stopped searching for tools without warts, edge cases, and gotchas, because you know those do not exist. What matters is community, ancestral memory, stability, maturity, docs. Above all, you just want to build something really great.

It is at that point that you become that guy. You might well turn to C, as many before you have. Maybe, maybe not. Lots of us have.

We aren't crusty old neanderthals, though. We're just at the logical end of the process.

westurneronNov 25, 2017

"The Architecture of Open Source Applications" Volumes I & II http://aosabook.org/en/

"Manifesto for Agile Software Development" https://en.wikipedia.org/wiki/Agile_software_development#The...

"Catalog of Patterns of Enterprise Application Architecture"

Fowler > Publications ("Refactoring ",)

"Design Patterns: Elements of Reusable Object-Oriented Software" (GoF book)


UNIX Philosophy

Plan 9

## Distributed Systems

CORBA > Problems and Criticism (monolithic standards, oversimplification,):

Bulk Synchronous Parallel: https://en.wikipedia.org/wiki/Bulk_synchronous_parallel

Paxos: https://en.wikipedia.org/wiki/Paxos_(computer_science)

Raft: https://en.wikipedia.org/wiki/Raft_(computer_science) #Safety

CAP theorem: https://en.wikipedia.org/wiki/CAP_theorem

munificentonJuly 8, 2013

This is one of my concerns too. I've seen patterns be overused almost as much as underused. It's a shame too, because the original Design Patterns book actually goes out of its way to tell you not to use patterns unless they are really a good fit. Unfortunately, remarkably few people have actually read the original book.

If you look at the chapter outline, I'm planning to have an introductory section on "How to Use Patterns (and How Not to Abuse Them)" where I'll try to mitigate this. Also, each chapter has a "Keep in Mind" section that focuses on telling you when a pattern might not be a good fit.

andyjohnson0onMar 26, 2012

From the article:

The problem with Design Patterns is that much of the information in the book (but not enough of it) is accessible elsewhere.

Maybe now, but I don't think this was true when the GoF book was published in 1995. My recollection is that there weren't a lot of books on software architecture (code- or system-level) back then because it wasn't so much of an issue. Most of us were writing monolithic C code or trying to get reuse of C++ libraries. The whole "architecture astronaut" thing hadn't got started.

That is was so ahead of its time is what makes it an important book.

struppionJan 13, 2016

Inheritance is a tool that makes a lot of sense in some situations, but that always comes at a cost. And often, the cost does not outweigh the benefit.

So, inheritance is not always bad, and you should not avoid it at any cost. But you should avoid it where you can. AFAIR, the original quote from the GoF book ("Design Patterns") was something like: "Favour composition over inheritance", not "Stop using inheritance alltogether".

The biggest cost of inheritance (that is, inheritance of concrete methods and state) is tight coupling. You couple two classes together in a way that makes them really hard to test, change and evolve in isolation. Everything becomes worse if you have mutable state in one of the two classes.

This can cause ripple effects in your code: You try to fix one little defect, and in fact you end up changing several classes and unit tests because everything is so tightly coupled and because everything has side effects.

There are several techniques to reuse code that give you better decoupling: You can extract pure functions from your code - They are really easy and painless to reuse when you get the abstractions right. You can compose objects instead of inheriting from them. You can use callbacks or lambda expressions instead of abstract methods.

To recap: Inheritance always comes at a cost. And you can often find solutions that are just as easy or easier to understand, and that will better decouple and isolate parts of your code.

js8onNov 29, 2015

I used to think the same thing.. but then I read http://www.haskellforall.com/2012/06/you-could-have-invented... and my jaw dropped.

This is a formal way to do homoiconicity, and frankly much better than codewalkers and CPS-conversions and similar tricks.

I now think that everything you can do with macros in CL, you can do in Haskell too and it will be cleaner. Another good example are lens and traversals, they are generalizations of generic references such that CL can only envy.

Someone should really rewrite On Lisp and Paradigms of AI in Haskell.. (and also Design Patterns from GoF) I think it would prove this point.

ryanisnanonNov 1, 2016

I'm somewhat familiar with the GoF book and Alexander's A Pattern Language book and I must say, I don't really understand this post.

I wish I had the latter in my hands now for reference (it's at home), but from what I can recall, the book goes into great detail about how to solve specific problems using generalizable solutions. For example, to establish a connection between the space inside of a building with the space outside of the building, consider adding awnings with open archways to the perimeter.

The Design Patterns book, though wildly specific (possibly only because it can be), also deals with solving specific problems with generalizable solutions. For example, creating and ensuring only one instance of an object exists (Singleton - p. 127). The book outlines the motivation for this (e.g. the problem), and defines an abstract for the solution.

Also, the fact that more modern languages can more easily solve some the problems discussed in Design Patterns is, while true, seems like a bit of a red herring. Undoubtedly the patterns themselves have a lifetime of usefulness, and will evolve as we discover new ways of solving new (and old) problems.

wwwestononJuly 18, 2019

Key takeaway point: "Dynamic Languages have fewer language limitations, less need for bookkeeping objects and classes, less need to get around class-restricted design. Study of the Design Patterns book: 16 of 23 patterns have qualitatively simpler implementation."

Or as someone else once put it, "design patterns" might more accurately be called something like "palliative idioms for pain points in static manifestly typed class-oriented languages."

That's a little bit unfair, given Smalltalk's place in all this, but one of the wastes of time over the last 20 years has been the ways in which some dynamic languages cargo-culted practices from, say, the Java world because Design Patterns™ were The Mark of A Professional™.

The fact this happened in JavaScript with Angular is particularly atrocious.

SomeCallMeTimonJuly 20, 2016

>code with Java Syndrome

You might find that most of the Design Patterns and even some of the Refactoring book are focused on working around limitations in Java/C++-style languages.

>Although, I should probably get around to reading Refactoring, and Design Patterns

I'd been programming for 20 years before reading either.

Both were...entirely unsurprising. Design Patterns at least defined a useful vocabulary for talking about different patterns, so I found it useful in that respect, and at least some of the patterns are useful outside of a Java/C++ language. Refactoring had some good wisdom on OO design, but it was pretty much all stuff I'd picked up elsewhere or come up with on my own.

Wouldn't hurt to read through both at least once to see if there are any surprises for you. Might be safe to just check them out of the library, though. I kept Design Patterns around but gave away my Refactoring copy.

OsmoseonDec 5, 2009

If it's Head First Design Patterns, then yes. :P

In all seriousness, I highly recommend the Head First series of books. They read so much smoother than other large reference/learning books.

As for Design Patterns, the value in that was not that I learned any specific patterns, but rather that it got me to analyze software design in a systematic way rather than a "I like this" way.

JoerionDec 18, 2018

    The Pragmatic Programmer
Clean Code
The Clean Coder
Domain-Driven Design
Growing Object-Oriented Software, Guided by Tests
Continuous Delivery

I have a confession to make: I haven't read any of those books, and I'm not really planning to.

I have read some other broad-spectrum programming books (Mythical Man-Month, Code Complete, Design Patterns, Peopleware, some lesser known ones). I've read a summary of DDD. I've read many blog posts linked to from HN relating aspects of those books. But I've never read that specific set of books.

I wonder if I'm really missing out much by not having read them, but I'm not motivated enough to find out by reading them, because there's other books I have on my reading list first (e.g. currently re-reading DDIA, after that I have Tufte lined up). Also, I never get signals from my surroundings that there are gaps in my skill set that those books would fill. Besides, having read some books is already a leg up, since many (most?) programmers don't read books.

timronDec 6, 2011

The ranking of this list is extremely suspect.

Code Complete is a fine book. The Pragmatic Programmer is okay. But neither book holds a candle to Introduction to Algorithms for career-long usefulness. For that matter, neither one holds a candle to Design Patterns for the ability to expand your mind and improve your ability to think about code (I read both at the same time, and Design Patterns is the only one whose lessons I remember distinctly, years later).

I think the main problem here is that the easy, mechanical reads get more votes than books that are harder, but more valuable. It's the technical equivalent of a lolcat photo.

eruonMay 11, 2010

The following comment from Matthias Felleisen at the page is especially interesting: (http://projectfortress.sun.com/Projects/Community/blog/Objec...)

>> Thank you, Guy, for emphasizing the importance of proper tail-call implementation (let's call it PITCH here) for software design and refactoring. When I delivered my | ECOOP keynote in 2004, I made the PITCH point slightly differently using the | Design Patterns book. I developed some code using the patterns from the book in Java. I requested and received confirmation that the code was truly OO oriented and truly according to Their Book. Then I tested it and it worked fine. Then I stress-tested it (on a not so large input), and it failed with stack overflow.

>> The next step was to demo the same code in the | PLT Scheme class system, which looked very similar to the Java code. And it ran great on those stress tests and even larger ones. So I asked the 300-400 people in the audience what the problem was and why this slow, interpreted language Scheme did it right and Java, C#, Eiffel, Python, etc got it wrong.

>> Not one person had any insight so after a minute of playing with them, I told them about the story of "Smalltalk to Actors to Scheme and how PITCH had 'come along for the ride'" (you may recall our email exchange in the spring of 2004 to confirm the story of 'apply'). And I did reinforce how much knowledge the OO research community has forgotten over the years.

>> Sadly, the reaction was surprisingly hostile from some corners in the room. One person was especially outspoken in arguing that we all know that we just need three or four special constructs -- and they may have to be map or for-each or such -- and we'd be in business. Given that it was a public exchange, it was difficult to point out to him how messed up his argument was.

>> While I have received many positive emails about the talk (my slides are on-line and people find them time and again), this message about PITCH deserves to be repeated and repeated and repeated for OO audiences. Let's keep going at it.

hota_mazionAug 14, 2016

I feel you haven't taken a look at Java in the enterprise in a long time.

Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean with plenty of very capable specifications and implementations (JPA, CDI, etc...).

And FYI, the Design Patterns book came out before Java (1994 vs/ 1995) so I think you have your timelines confused. The early editions of Design Patterns didn't contain a single line of Java, they were mostly C++ (and some Smalltalk).

Java is twenty years old, and for such an old geezer, it's adapted remarkably well (and between Java 8 and Kotlin picking momentum, its legacy seems to be well assured).

daniellmbonMar 28, 2011

Great start! Here are a few other books I've read recently and marked the crap out of because there is so much good information in them.

  - JavaScript Patterns by Stoyan Stefanov
- High Performance JavaScript by Nicholas C. Zakas
- High Performance Web Sites by Steve Souders
- Even Faster Web Sites by Steve Souders

Here are a few I haven't read yet but are on my to read list.

  - Object-Oriented JavaScript by Stoyan Stefanov
- Pro JavaScript Design Patterns by Dustin Diaz, Ross Harmes

munificentonJune 25, 2015

> And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.

The Gang of Four didn't give us that. An army of OOP novices who were overwhelmed by all of the new choices and only skimmed Design Patterns gave us that.

If you actually read the book (which surprisingly few people have, given the number of people who have strong opinions about it), you'll see the Gang of Four are actually quite clear on the limitations or and ways to abuse the patterns.

afandianonFeb 5, 2019

"Difficult Conversations: How to discuss what matters most". I bought this on the strength of an HN suggestion.

It's like Design Patterns for human conversations: the result of studying how people interact, common patterns that work, and how things break down. Really crystallised a lot of insights I'd perceived but never thought about systematically. I highly recommend it.

Word of warning - there are a few books with this title. Look for the one by Douglas Stone, Bruce Patton, Sheila Heen.

Also Thinking Fast and Slow, recommended elsewhere in this thread.

jasodeonFeb 8, 2017

>, the good old Design Patterns book, responsible for more atrocious over-abstracted,

This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation.

The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription.

Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary.

One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

jasodeonAug 29, 2017

>I'd argue that Design Patterns mostly appeared because of Java. [...] And such workarounds were collected, tagged, and proposed as Design Patterns

Fyi... "Design Patterns" in 1994 predates Java 1995.

Design patterns in some form have been around as long as computers have been around. Independent teams of programmers notice a repetition of code or a higher-level idea and they make it a convention. E.g. the "observer" pattern was something Smalltalk and Objective-C programmers did more than a decade before Java. Before "Design Patterns" became a meme/book, different teams used different vocabulary. Maybe they'd call it the "event watcher code convention" instead of "observer pattern". DP was a book of past practices gathered from the real world and it got everyone to converge on the same vocabulary to label what they were already doing.

phaedrusonApr 6, 2008

I modded you up even though I disagree with you.

Using design patterns really helped me in a large project I did in C# two years ago - although I must admit I used the friendlier Head First Design Patterns as my reference rather than the original Design Patterns book.

I honestly think I would not have been able to do the project without the aid of design patterns. The project's architect was living too high in the clouds to grasp why his architectures were unimplementable, yet tried to micromanage the implementation as well. He continually specified implementation details which violated basic constraints of the language syntax and the static type system (like asking for multiple inheritance in C#). So I would use design patterns to get around a language limitation to do something close to what he wanted. Since he didn't understand design patterns, he found my explanation of how the design pattern accomplished the trick impenetrable enough to just leave it alone.

It backfired on me when he learned the Singleton pattern (which he kept mistakenly referring to as the "Simpleton" pattern), and started insisting that every object should be a "Simpleton".

Anyhow so the reason I didn't downmod you, is that I do think design patterns are useful, but they fix a problem which is partly that the language is broken, and partly a people problem.

AvalaxyonMar 3, 2013

I usually read books when I'm trying to learn something new and complex, such as a new programming language. I have a few reasons for that:

- The information in books is complete. Tutorials on the web usually cover only a tiny fraction of everything there is to know about a specific technology. Tutorials often go deep into a specific part of the technology, or try to cover everything in a very shallow way. Books provide a thorough explanation of everything, nut just a tiny fraction.

- Books (if you make the right selection, I usually type "best [some technology] book" in google and read the suggestions on stackoverflow or other programming sites) are usually written by authoritative people in the industry. Very often by the author of the programming language that you're trying to learn. Not by some amateur who has some spare time and wants to write a blog post.

- It's much more pleasant to read long texts on paper than on a bright computer screen where you have to scroll all the time and cant place physical bookmarks.

As for your last question (what I read and can recommend):


- Design patterns : elements of reusable object-oriented software

- Patterns of Enterprise Application Architecture

- Code Complete 2

- Clean Code

- Pro ASP.NET MVC (if you're into MS stuff like me)

- Scrum and XP from the trenches


- Business model generation

- Purple Cow

- Permission marketing

- Rework

(how to do these line breaks correct?)

I didn't like SICP. I can handle boring books, but this one is pretty extreme.

edwinnathanielonDec 26, 2012

I'd say software is becoming more 'specialized'.

My alma-mater (UBC.ca), the CS Dept touches a few subjects:

- Design Patterns (still using GoF, which is probably not the right fit for 3rd year students)

- Refactoring (we do refer to Martin Fowler's book albeit we don't dig that deep)

- Barbara Liskov book (touches a few thing regarding type-systems and its relation with OOP, IN-OUT contract/verification, a bit more academic/formal but most of us saw her work in C# contracts, the L in SOLID principles, some of the OOP best practices probably).

hinkleyonMar 5, 2018

Whenever anyone asks me if they should read Design Patterns by Gamma et al, I tell them to go read Refactoring. If they say they've already read it I tell them to read it again.

The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.

wglbonSep 10, 2011

I remember how we all waited with bated breath for Design Patterns to come out. It was a bit of a disappointment, I recall. Seemed kind of complicated. So now for some of our patterns we need four C++ files per object? Heck with that.

I would disagree that there are tons of Smalltalk examples there. There are in fact a few examples, and they actually don't weigh very much, because they are pretty small, and you don't really need the whole Design Patterns concept if you are a Smalltalk dude. I have a friend who first picked up the book after programming for 17 years in Smalltalk. He put it down after scanning through the first few chapters because it was very self-evident to him.

For young up-and-coming programmers, I recommend setting aside Design Patterns and reading everything you can find written by Peter Norvig. Start with his design patterns essay. The short version of which is that if you need design patterns, (in the sense of the book) then there is something lacking in your language. They are an unnecessarily.

I would never recommend Uncle Bob to anyone looking to improve programmming chops. Read Norvig instead. Uncle Bob came down on the wrong side of TDD and the fellow who failed to TDD his way into a sudoko solution. Peter Norvig comes up with a different notation, not a methodology, not a design pattern, and produced a very elegant solution.

So to improve your programming skills, avoid Uncle Bob, read Norvig, go easy on the methodology.

MachaonAug 7, 2011

Part of the reason why there are so few low level programmers is that it's quite complicated to actually find information on it:

* Lots of college courses, especially of the Java school variety simply do not cover anything remotely near low level code.

* For people looking to learn themselves, there are far fewer books and websites with resources than for other subjects. If I walk into my local book shop, there are books on Java, C++, C#, PHP (lots of PHP), Flash and Python. Then a few language agnostic books like Code Complete and Design Patterns (Stuff like this is lacking in quantity, but at least it's there). None on anything low level. There isn't even a x86 assembly for dummies type book there. The internet has free books for other languages too (Dive Into Python, Why's Poignant Guide to Ruby, etc..) and plenty of free resources on good functional programming or good OOP. For assembly, all I keep running into is a wikibook, which I'm rather skeptical about as they tend to pretty poor in my experience.

And then, once you've gone through the initial learning phase, how are you going to get any experience? For 95%+ of projects, it's a case of YAGNI. There aren't any interesting open source projects coded in assembly today. Maybe a few Linux drivers, but that's something that would need a lot of domain knowledge on top of low level knowledge to understand.

threepipeproblmonJune 30, 2017

I guess you can't be bothered to look for yourself, so here is a recent post about architecture concepts.


There are many such posts (explicitly theoretical/academic) in the site's history. More importantly, the day to day "McMansion" posts actually back up the theoretical concepts expressed in such posts. Much the way we programmers use both positive and negative examples of Design Patterns.

If you are not aware -- and it seems like you aren't -- the Design Patterns movement in software was inspired by an architecture book that did much the same thing -- showing patterns and anti-patterns -- just with less hipsterism, and more examples than counterexamples.

ScottWhighamonAug 31, 2009

Couple of things:

1) You'll likely get better/more response if you prefix your post with "Ask HN: " (lots of folks have triggers for that type of thing)

2) You don't have to be a mathematician to be a good programmer. Tons of great programmers were not comp-sci majors so don't let that sort of thing get you down. If you've done "some basic noodling here and there... in a few languages" and you want to improve as a programmer, I'd advise you to:

   - Pick a language
- Pick a pet project
- Buy a few books or take a few online classes that are on your chosen language
- Begin reading the book
- Implement your project while reading the book
- Find some sample apps written in your language and review how they did things differently
- Finish your book and buy another book/class that is specific to your language
- Pick a new pet project and implement it
- Review some open source apps written in your language
- Contribute to some open source apps

At this point you're likely ready to spend a bunch of time reading non-domain specific books but, up until this point, the value you would receive from reading books not directly related to a specific language/task is debatable. Now that you've had some experience, I think this is a great time for books like:

   * The Pragmatic Programmer
* Code Complete
* Head First Design Patterns
* The Mythical Man-Month
* Design Patterns: Elements of Reusable Object-Oriented Software

(Those are all titles of books BTW)

Next up: build a startup!

Notice there are no math books in my list. This is different from what others would propose but, given the scant description you wrote, I don't see any need for math except to satisfy a possible desire to learn.

wistyonJuly 25, 2011

There's a quote, that goes something like: "For each rule of thumb, there is an equal and opposite rule of thumb. Both are wrong".

I'd like to see a lot more context with those principles. I'd like two examples - one which demonstrates why the principle is useful, and one that shows it going just a little too far.

Otherwise, these principles just create what artsy types call a "lens". It might help you reach an epiphany ("doh, I should have abstracted that bit - that's the word, abstraction, where did I hear that?"), but it also leads to the "Journeyman Programmer who just read Design Patterns and wants to make everything a Stratergy" phenomena (is that a Joel misquote?).

wheelsonAug 3, 2008

Yeah. It's boring. Here's really all that you need to say about it: It's a vocabulary trainer.

That's mostly what reading Design Patterns is good for. You learn names for things that you'll see over and over again that you can refer to them as when talking to other programmers and you learn to implement them more or less the standard way not because that's novel, but just because it then makes it easier for other people to understand what you've done.

On the other hand, it's easy to read -- like one day, and at that it's definitely worth it.

kenonMay 27, 2008

"The problem is, about 1/3 to 1/2 of them were basically cover-ups for deficiencies in C++ that don't exist in other languages. Although I'm not a huge Perl fan anymore, I have to admit the Perl community caught on to this first (or at least funniest). They pointed out that many of these so-called patterns were actually an implementation of Functional Programming in C++."

Compare Norvig (1998): "Design Patterns in Dylan or Lisp: 16 of 23 patterns are either invisible or simpler". http://norvig.com/design-patterns/

beatonDec 30, 2016

Well, actually...

Antipatterns are on rather firmer academic ground than the guy at the airport barstool. Antipatterns are simply a negative version of design patterns. Design patterns in software started with the book Design Patterns: Elements of Reusable Object Oriented Software (aka Gang of Four or GoF), one of the greatest classic works in software engineering. GoF was itself based on the book A Pattern Language, by Christopher Alexander, a classic of the architectural field.

Alexander came up with the idea of a "pattern language" to describe patterns in architecture, a formal structure for observable phenomena. The GoF reused pattern language in a formal way to describe software patterns. Part of the pattern language describes how to implement the pattern. Antipatterns first appeared in the book Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. Again, pattern language was used, including patterns for solving the problems caused by the antipattern.

So yes, this is rigorous. Not math-rigorous, but rigorous.

hwjonJuly 3, 2019

These are his books on "Programming Languages" and "Programming" (in the bottom right corner of the image):

* APL: The Language and its Usage

* The Design an Evolution of C++

* The annotated C++ Reference Manual

* The Joy of Clojure

* Eiffel the Language

* Programming Erlang

* Forth (Salman et al.)

* Thinking Forth

* Introduction to Fortran

* The Little Schemer

* The Seasoned Schemer

* The Reasoned Schemer

* The Little MLer

* Programming in Lua

* Lucid, the Dataflow Programming Language

* Functional Programming in Scala

* Clause and Eiffel

* Scatchpad

* Smalltalk-80, The Interactive Programming Environment

* Smalltalk-80, Bits of History, Words of Advice

* The TeXbook

* The METAFONTbook

* TeX: The Program

* METAFONT: The program

* Viewpoint: Toward a computer for visual thinkers

* Visual Grammars for Visual Languages

* How to design programs (Felleisen et al.)

* Design Patterns (Gamma et al.)

* The art of the Metaobject Protocol

* Elements of Programming

* Concepts, techniques and models of computer programming

* Structure and Interpretation of Computer Programs

* Types and Programming Languages

* Essentials of Programming Languages

* Advanced compiler design and implementation (Muchnick)

* Introduction to Algorithms (Cormen et al.)

* Hacker's Delight

* Programming Pearls

* Coders at Work

* Computation: finite and infinite machines

* Purely functional data structures

* The space and motion of communication Agents

* Superdistribution

* A small matter of programming

* Basic Theory for Computer Scientists

saturnflyeronAug 14, 2012

Thanks for clarifying. I had most of it written before posting and had forgotten the code samples. My copy of Design Patterns is packed up for a move. I've update it to refer to C++.

Actually, people have visited, but few have stayed to read. My goal is to clarify the concept. I did plenty of research before writing this including asking Lieberman and others about it. I first wondered how everyone's notion could be wrong and doubted that my understanding was correct.

This is a term that others have attempted to clarify as well http://javalab.cs.uni-bonn.de/research/darwin/delegation.htm...

tptacekonMar 27, 2010

You're playing semantic games. If we accept your terms, we're adopting the GoF patterns any time we use "method_missing". You're also arguing with a straw man.

The original idea behind the "Design Patterns movement" was to provide a common language for describing recurring concepts in software design. It's the same idea behind Alexander's "A Pattern Language", which is something else you should read.

Nobody is arguing that describing things a little more rigorously is bad. But a lot of people have problems with the way "engineers" and "architects" abuse the pattern concept.

Alexander did not write a book that claimed you could build an entire city by picking out a "44. Local Town Hall" and mixing it with a "69. Public Outdoor Room". He had an idea, that the cart was dragging the horse in architecture, and attempted to use vocabulary to reframe the discussion about why specific choices were being made.

The Gang of Four introduced a minor corruption in that approach --- they had no fundamental thesis about how software should be designed, only a notion that there was folkloric knowledge that should be captured and named --- but their followers completed the corruption wholeheartedly. Instead of a language describing software, the GoF patterns became a perscription for building it.

And so we have Ruby code that includes a "singleton" module into classes, and SOAP4R code that includes "factory" classes (note again how ruby already transparently supports the abstract factory concept), and people argung that we should start "doing a little engineering" by pulling these clumsy ideas back off the shelf.

I can't argue this any better than Norvig can. In fact, I'll invoke him again by suggesting that you don't want to end up like Norvig's "opponent" in the sudoku-solving contet.

alaricsponAug 29, 2009

I think it's a knee-jerk reaction to how the more zealotous members of the design patterns community have had knee-jerk reactions to people questioning the scripture status of the Design Patterns book.

Once a bunch of people get religious, another bunch of people will crop up to get religious against them in turn.

I think design patterns are useful and valid; but I think they should be evaluated individually within the context of a given programming language, not necessarily considered global.

ajrossonAug 28, 2008

Indeed. FTA:

"First and foremost, by being the best damned Java or C++ programmer their management had ever seen. In 1996, I took three Java books on my honeymoon, and read them. [...] Every single night after work on my C++ contracts, I would read something from Design Patterns and Stroustrup."

Truly, the author is a paragon of development expertise. He reads books (books!) on Java and DP. He's even read the manual of his programming language! That's one 133+ h4x0r there, I tell you. I'm in awe.

kazinatoronJuly 24, 2017

Design Patterns is about typing out boilerplate code by hand to solve a problem, because the language doesn't have the expressivity to encode the same solution directly.

When it does have the expressivity, the underlying rendering of the pattern hasn't gone away; just the manual boiler-plate for producing it.

For instance, if you're working in assembly language, then you might sometimes benefit from a "while loop design pattern" to keep your code clean. The while loop design pattern calls for some test code before a block which jumps past the block when the test is negative, and an unconditional backward branch at the end of the block back to that test expression.

The while loop doesn't go away when you use a higher level language. You just indicate that you would like that pattern, and the compiler spits it out for you, invisibly.

> Every time you pass a lambda to a higher order function you're using a strategy pattern.

Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you.

aw9994onMar 21, 2011

Learn about Design Patterns, they will force you to really use Java's features such as Interfaces and Abstract Classes, accessibility modifiers (public, private, protected) and others. That is the method I use when tutoring individuals in similar situations as yours that want to get back into Java specifically.

I recommend the Head First Design Patterns book if you're not turned off by the less-than serious nature of it. I really did not like the book at first glance, but after actually working through some of it as instructed I enjoyed it and really developed a solid understanding. Simple examples like Vending Machines and Washers really helped me, I still use them in my head when thinking about problems.
Design Patterns are not always the best solution and forcing them on problems can make things worse, but as far as teaching Java I really recommend it.

I also recommend learning about Test Driven Development as previously suggested, we use JUnit4 to teach our undergrads at my university. There are also other methods of testing besides TDD, but I feel it was the easiest to help students.

sha90onMar 27, 2010

"GoF patterns exist primarily to make up for the fact that you're not in Ruby"- this is the epitome of ignorance and the exact denial referred to in the article. I must have missed that part in Design Patterns that said "if you use Ruby you should not use this book".

But hey, I guess the Ruby stdlib includes the "Singleton" pattern for fun right? Not because you'd use it, or anything. Same with delegates. And I guess Rails didn't actually implement Martin Fowler's Active Record, Action Controller and MVC patterns? You just dreamed those.

Wake up. Your comment is painful and a little embarrassing. Design patterns are language independent. They are not implementation, they are descriptions. They can be used in any language, and they are used in Ruby.

mirekrusinonAug 19, 2016

Paul Graham's quote in "Design Patterns" section actually says nothing or the opposite of what the author is trying to say - Paul says that when he's seeing in the code things (shapes <<of code>>) that repeat themselves, it's an indication to him that he's missing some macro definition that would build this shape for him so he doesn't need to repeat himself by manually creating it all the time - that he can reuse it (as macro).

How does it relate to design patterns? Does it say not to use them? Absolutely not. It says the opposite, if anything - to recognise patterns in your code. "Design patterns" is just an idea that if you see your patterns repeating themselves (some of your macros tend to be very similar in different projects) then you should give it a name. This way when you explain system to your colleagues it's easier to communicate.

kevasonJuly 13, 2018

For me...

1. Technical Analysis of the Financial Markets by John Murphy

2. Options as a Strategic Investment by Lawrence G. McMillan

3. [just finished] The Checklist Manifesto: How to Get Things Right By Atul Gawande

4. [finished last week] Dealers of Lightning by Michael A. Hiltzik

5. [currently working on] Design Patterns: Elements of Reusable Object-Oriented Software By GOF

6. [currently working on] Dan Appleman's Visual Basic Programmer's Guide to the Win32 API by Dan Appleman

7. [next on the list] Skunk Works: A Personal Memoir of My Years at Lockheed by Ben Rich, Leo Janos

raganwaldonDec 23, 2007

What anti-design patterns meme?

I write programs with Design Patterns, I catalogue new ones from my work, I use them to teach and communicate. "A Pattern Language" is one of my favourite books.

What did I say? Well, I quoted someone else telling a story about their experience:


I thought it was a good story because it illustrated two different mind sets when it comes to writing programs and what happens when they come into contact with each other. There's no preachy conclusion, it's a human interest story.

I also talked about a particular cultural approach in this post:


There, I expressed opposition to the idea of a fixed set of standard patterns.

So, now you know what I was saying.

duweaseonNov 11, 2013

The Enterprise code brings back awful memories of working with a framework architected by someone who had obviously read the Design Patterns book and had the take-away of "Use these as often as they can be wedged in to have a better system."

God forbid I needed to add a single boolean field to a single screen. By the time I submitted the DB change request, then changed the abstract factory interface, then the abstract factory class, then the factory interface that generated, then the factory class, then the abstract DAO interface that generated, then the abstract DAO class, then the parent DAO interface, then the parent DAO class... pauses to catch breath ...then the child DAO interface, then the child DAO class, then the controller object interface, then the controller class, then the actual page, then the unit test, it was 4AM and time to go to sleep.

Let this be a cautionary tale to any future architects out there.. remember that flexibility is a MEANS, with the ends being less time and money spent coding and maintaining code. It's not an ends to itself, and can even be a hindrance to the ends.

bigtunacanonJuly 8, 2014

I've seen multiple people mention the GoF's Design Patterns book. This is well known and worth several reads through; it will take multiple passes to grok all of it.

There are several other books that have tried to explain the GoF's Design Patterns in either an easier to approach manner, or in the context of a specific language they have tried to explain where new design patterns have emerged or the original patterns had mutated.

A couple of those worth checking out are

"Head First Design Patterns"


"Design Patterns In Ruby"


"Learning JavaScript Design Patterns"


scott_sonAug 22, 2009

This article made me realize the relationship between structural pattern matching and polymorphism. How I would solve the problem in C++ (with constructors and error checking omitted for brevity):

  class Tree {
virtual int depth() = 0;

class Empty: public Tree {
virtual int depth() { return 0; }

class Leaf: public Tree {
int n;
virtual int depth() { return 1; }

class Node: public Tree {
Tree* l;
Tree* r;
virtual int depth()
return 1 + max(l->depth(), r->depth());

Since I've never programmed in a language with structural pattern matching, I welcome others to compare my solution to what was presented. Clearly, structural pattern matching requires less code. Also, I've never actually read the Design Patterns book, but I think what I have above is different from the Interpreter and Visitor pattern he described in the article - for one, I don't have any mutation. But, again, please correct me if I'm wrong.

adolgertonNov 27, 2010

K&R's _C Programming Language_, because my father saw me start to write Schrodinger's equation in BASIC and said I should take a look.

Stroustrup's _The C++ Programming Language_, twice in a row, because I didn't want to be left out for not having taken Computer Science.

Butelhof's _Programming with Posix Threads_, because another book referenced its explanation of why Win32 threading had a bug because it could not, at the time, signal and wait on a mutex in an atomic way. There was something deep to find in those rowboats and bucket stories.

GoF's _Design Patterns: Elements of Reusable Object-Oriented Software_, because when I complained to a mentor that I was struggling to organize a dozen scientist programmers, he handed it to me, laughing.

John Robbins, _Debugging Applications_, first edition, because it was the first time for me that code didn't have the disclaimer, "of course you should insert error-handling code here." Basic x86 assembly in one chapter!

nimchimpskyonDec 15, 2016

"co-author of the influential software engineering textbook, Design Patterns: Elements of Reusable Object-Oriented Software. He co-wrote the JUnit software testing framework with Kent Beck and led the design of the Eclipse platform's Java Development Tools (JDT)"

And here's me writing code that creates csv files, that get copied from one server to another server (on another continent) - without anyone reading them.

Built withby tracyhenry


Follow me on