This is the best keynote he's ever given. It boils down to actually writing code and forget memorizing patterns.
That can't be more true.
That can't be more true.
While we're at it, let's get down to just cooking and forget food science. Never mind how a recipe should be adjusted at altitude. Or what to substitute when the person eating your minimally viable meal has a food allergy to an ingredient. Or what other things go well with your main entree. We're just cooking up things we got out of a can, after all.
Don't learn any patterns. Except the ones DHH wants you to—those are ok. All the rest of them just get in the way of writing software.
(readers may proceed to downvote now.)
Memorizing about 20 patterns for 3 months before you really write any code is way worse than just hacking together something and improving it because after enough time you know what's wrong.
The "you just know" thing is really powerful. I'm not a professional artist but I just know that if you had a yellow background and you drew something in the foreground with the same yellow code it wouldn't work because you couldn't see it.
When writing shitty code I just know it's bad because I find myself having to copy/paste something 8 times or maybe it's close enough to a copy/paste that it still feels wrong so then I fix it.
To take your example, yellow-on-yellow isn't an aesthetic assessment, its a functional one. You recognize that functional anti-pattern because you've experienced, at some point in your life, what happens with a lack of contrast. If you aren't colorblind, you probably don't (intuitively) recognize that red on green is also a functional anti-pattern. When you extrapolate to the world of software development, without having previously learned these patterns or something resembling them, you don't recognize the antipatterns when they occur.
I'm not saying "Don't write software until you know all the patterns, ever." I'm saying that DHH has a traditional antipathy for any pattern he hasn't deigned fit to include in Rails canon, and that when you're coding solutions that need to scale in both performance and complexity, you probably don't want to take advice from someone who thinks a formalization of the AR pattern is the height of domain modeling.
Then you eventually learn to see things on your own. I don't need to read a popular programming pattern book to know how to structure my code. I know how to structure it based on feedback of using it on a regular basis while having a solid base of information to work off of.
If something feels off, I fix it where the solution is it no longer feels off. Until it feels off I'll likely leave it as is because at this point I haven't experienced the problem.
If something isn't a problem to me then it's not a problem. It's only a problem when it causes me to react in a negative way or is causing the system to react in a way that is bad.
I wouldn't recognize first hand that red on green is a problem for color blind people because I'm not color blind. If this hypothetical app had to work for color blind people then I would open a ticket and flag it as a feature request and then get feedback from someone who is color blind.
That's a good example of it's not a problem until it's a problem.
You can still constantly learn and keep up with things while taking DHH's advice btw. I have been coding and working with his mentality for quite some time now despite working with rails for only a year.
Do you have a real code example from a non-trivial domain?