Ask HN: What programming design pattern book has had the biggest impact on you?
I own multiple well known design pattern books because I went on a buying-spree a while back (Gang of 4, Patterns of Enterprise Application Architecture, Clean Architecture, Head First Design Patterns). But as I look for advice on which are still worth reading, and which is likely to be the most impactful if I only read one, I find a lot of lists that are short on opinions.
I'm curious which of these or others have had the biggest impact on folks here, and which popular ones are worth skipping.
30 comments
[ 3.1 ms ] story [ 79.4 ms ] threadObjectiveSQL is an ORM framework in Java based on ActiveRecord pattern, which encourages rapid development and clean, codes with the least, and convention over configuration.
Features
1) With one annotation your Class has fully featured capabilities of SQL programming
2) Easy to relational(has_one, has_many, beglongs_to) querying and paged querying
3 Java expressions(arithmetic, comparison and logical) can be converted into SQL expression directly
Others are just implementations of abstract ideas about how things belong and communicate.
Long Answer : Design Patterns are useful only in an OO Setting, its utility is gone if you look at Functional Languages. In FP you would have to consider more fundamental things than trying to cosmetically map a classical model to a domain, and then write bunch of code to retrofit that model.
Logic and software are fundamentally complex. Djikstra said that software is “radical novelty.” It exists at a scale beyond anything the human race has ever built before, that’s fairly inarguable. He was also very fond of imperative programming, and was able to formally verify his imperative programs. Check out his book, A Discipline of Programming, where he goes over the mathematical theory of a simple imperative language.
There’s nothing more “mathematically correct” about the lambda calculus vs. Turing machines. Both are equivalent models. Whether or not state is implicit or explicit, state and time are a part of computation.
I like FP for the simplicity of it, the problem with OO is overemphasis on structural design and frequent indirections to name every entity as a noun with its own set of Data structures and state maintenance routines.
To answer your question if Industry is operating less efficiently? Maybe but there is no empirical evidence for it.
Considering all things equal software is inherently complex and OO is a real world abstraction to solve the complexity, but we end up introducing more complexity than we start out to solve, which is why i consider going back to roots and try a different approach as OO didnt actually deliver on the promise.
Also thanks for the Book suggestion.
Here's an anecdote. I have two friends who decided to take advantage of some COVID downtime to learn to code. I suggested they start by doing some HTDP, and they did. Now one is doing a bootcamp and the other is building his own apps. Both are doing Javascript, React, Ruby, a bunch of popular stuff.
I've interviewed and hired dozens of junior devs in my career, many of whom had already been on the job for a couple years. Most had only gone through a bootcamp. My two friends are far surpassing what any of those folks were capable of. They are able to understand these modern tools on a deeper level, not just copy-pasting or memorizing parts of an API.
I recommend it to anyone who wants to learn to code. Once you know fundamentally how to design functions, you can learn any of the trending technologies that might snag you a job. And you'll probably end up with higher quality, higher output, fewer bugs than your peers.
My question is, in your opinion what makes HTDP so good to make your friends learn unrelated things quicker than others? Do you think that is only a matter of designing functions or there's some other transferable skills too?
What I see from many people (especially coming out of bootcamps) is that they learn one tool. They make one or two apps with it, the apps work fine, and so they believe they can do anything. That works great until they come up against something they haven't seen before. Once they do, they have no framework in their mind as to how they can move forward in solving the problem. All they know are those one or two tools. So if they can't find a plugin or something to copy/paste into those tools, they become lost.
HTDP is genius because it shows you how simple the fundamental process really is. They literally call it a "design recipe". It's basically understanding the shape of your data, defining inputs and outputs, and writing tests. With those ideas and some practice with that methodology, you can handle any situation that comes your way, forever.
It's not the junior engineers' fault, though. A lot of people in the industry speak in terms of tools. "We're looking for React people", etc. The idea that your skills are defined solely by the tools you know is widely accepted in startup circles. It's no wonder that bootcamps operate the way they do.
From what I have seen, the mythical "10x" programmers really do exist, and they're the ones who are really great at keeping it simple. They're not necessarily FP-oriented, just focused on writing simple code to accomplish a goal (and very good at it). HTDP is a great way to start down that path.
That really motivated me to check HTDP out!
The way to create characters, plot, or get ideas. The plot is one problem and characters solve it. One thing and one thing only. The job to be done [of a movie] is to entertain an audience, don't get gradiose or too tied to it.
As a programmer, I watched the videos and with every video, there was a clear application to programming and design.
Advice on writing, in general, and observing good products evolutions lead me to increase my effectiveness: not building the wrong thing, better scoping, solving the right problem. This leads to a lot of code not written, and reduces unnecessary complexity.
I have of course read some of the books you mention, but I find that simplifying things delays the need to resort to some patterns. You often find code that does practically nothing but filled with observers and borgs and factories and whatnot. It's useless and doesn't solve a problem. If it were a display of patterns skills, maybe, but that's why I did Judo and not Aikido. I like things that work in real life against actual problems, not imaginary or compliant adversaries.
Screenwriting classics like "Save the Cat" and "The War of Art" contain very simple truths: there are rules to storytelling, honed over centuries of human experience and cultural evolution. Knowing when to follow the rules, and having the confidence to break them, is part of that journey, and can be applied to virtually any creative endeavor ;)
For the longest time I’ve been seeing the objects in my code as characters I. Stories, with messaging defining their relationships.
Will definitely check out the masterclass.
Which videos or Masterclass did you mean specifically?
This one:
>David Mamet's Masterclass on "Screenwriting"
I watched Aaron Sorkin's one, not the same feeling. Sorkin wants dialogue to be smart and fast and impressive. He wants characters who speak similarly to his perception of his smart friends' conversations.
Building product with David Mamet's advice will get you product market fit.
Building product with Aaron Sorkin's advice will get you funding, then put you in jail.
$200 is quite a steep commitment, but with this recommendation, I'll probably take it.
I have found over recent years not having to dip into those concepts much, there are a lot of these patterns built into libraries and frameworks these days.
I would recommend picking up a free chapter of the old one to see if you like the style of presentation.
Personally I just love the way they present information.
http://aka.ms/mspnp
Game Programming Patterns is another resource that is quite clear
https://gameprogrammingpatterns.com/