In her talk All The Little Things, Sandi Metz talks about teaching beginners about DRY:

The first rule we teach novices is don't repeat yourself - DRY. But have you ever thought about why we teach them that rule? It's because they can't understand anything else. They don't know anything, but by God, they can recognize duplication.

She goes on to describe the dangers of following DRY blindly, demonstrating that perhaps the rule is not quite as simple as it looks. So is it a problem that we teach this rule to beginners because it's easy to understand? When is it appropriate to teach someone about DRY?

Dave Thomas, the person who coined the phrase DRY, was asked this exact question in an interview on the CodeNewbie podcast. He answered with an analogy of a beginner learning how to drive stick. Experienced stick shift drivers often tend to give advice about things like double de-clutching and changing down gears going through corners. Dave Thomas says:

If you really want to drive effectively and efficiently, you know, that's the kind of stuff you'll do. But when you're first learning to drive, that is poison. That's the kind of stuff that causes you to kill yourself, because you're not thinking about the basics, like not hitting lampposts.

He goes on to recommend that DRY shouldn't be taught directly at all - it should be something that a new programmer discovers on their own. The same applies to design patterns, or any other best practices that come from experts:

It's the same with all of these rules. They have to be motivated by problems that you see, in order for you to actually, honestly believe in your heart that they're worthwhile. Otherwise it's just some expert standing up there pontificating.

As a teacher, it's tempting to teach best practices as a way to help beginners avoid writing bad code. But learning high level concepts doesn't happen by avoiding mistakes - it happens by experiencing mistakes and learning from them. And what's worse, teaching best practices takes the focus away from what a beginner should be focused on at their current stage in learning. If someone is still struggling with syntax, teaching them about high level design patterns is likely to do more harm than good.

If you teach a novice about DRY, one of two things will happen. One, they won't believe in its importance, and generally ignore the rule. Two, they will believe in it wholeheartedly, without fully understanding why it's valuable, and apply it to every situation imaginable. This is where you'll see a Chair class inheriting from a Cat class because both have four legs. The bottom line - it's not hard to teach a rule, but it's incredibly hard to teach when it is appropriate to apply it.

So what's the ideal solution? Instead of teaching best practices, try creating experiences for a student such that they can see the problem and discover a strategy on their own. The challenge is to create valid experiences and present it at an appropriate time in their learning. Unfortunately, this takes a lot longer than teaching best practices directly. But without the experiences to go with it, it's not teaching - it's pontificating. Good teaching takes patience.

Only after a student experiences the same problem in different contexts will they be able to discover both a strategy to address it and the contexts in which it is applicable. At that point, the only thing you need to do as a teacher is to introduce a name for that strategy. And now it's not some mystical rule, it's simply a name - a concise way to describe both the strategy and its appropriate application. Best practices aren't learned so much as they're earned, and an effective teacher knows when to guide rather than teach to make it happen.