[karmajunkie]

I think that's good advice—great, even—for the person just learning to code. Its terrible advice for someone who is or wants to be a professional in a field in which continuous self-education is an imperative to stay employed. Patterns provide both a vocabulary and a toolbox to go to when you're solving a problem. If you don't learn the vocabulary and the tools that are available, you don't recognize problems when they arise, or you only recognize them because you're no longer able to constructively execute on new features.

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.

[rartichoke]

A beginner with a passion and goal to improve will eventually become a professional. You don't get to professional status by just research and reading, you have to actually do things and figure out first hand what works and what doesn't.

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.

[karmajunkie]

Yeah, look me up when you've been cleaning up Rails code from developers who didn't bother to understand solid design principles for several years... that whole "wait til its a problem" thing falls apart pretty quickly in non-trivial domains.

[rartichoke]

You can't ignore things until it's a huge problem, that would be a mistake no matter what.

Do you have a real code example from a non-trivial domain?