An excerpt from my new online book, The Developer’s Code: 50 lessons, observations, & unadulterated opinions on web developer life through the eyes of one of them. Follow me on Twitter @developerscode.
Teach the “rules” in the beginning as if they were set by law: Death by a thousand cuts if broken. It provides a structured starting point for a novice. And, it’s probably not a bad thing to instill a little fear…
This is also what the Dreyfus model of skill acquisiton preaches for novices as well. The rules part of it, not the punishment part. The Dreyfus model is, put simply, a model of how students learn. It was proposed in 1980 by a couple of PhD brothers (Stuart and Hubert Dreyfus) in their research at UC Berkeley.
According to the Dreyfuses, at the novice level, students follow rules without context. There’s no questioning. Why do you want to normalize a relational database? Why do you want complete separation of structure and presentation in your HTML markup? Why do you want to adhere to the DRY principle in software development? Because that’s what you’ve been taught, son.
But, when they start heading toward the expert level, those stone-etched laws are meant to be broken. A proficient coder treats those rules as guidelines — the orange plastic cones on the highway. For instance, there actually is a time and place to denormalize a database (e.g. when the database is a “read mostly” one, like an OLAP cube). But, a novice shouldn’t know about the benefits of denormalization in the beginning until she’s fully grasped the benefits of normalization. In order to understand the cracks in the foundation, you need to intimately understand the foundation itself.
When you begin to master a subject like programming, you stop using rules to guide your work. That thing that just comes naturally, takes over. There is no more recipe, there’s just intuition.
And, that is what your student needs to know. One day, on the road to becoming as good as you, your student has to cross that intersection where he questions the rules that you taught him in the first place. One day, some of those beginner rules won’t fit with, what your student thinks is a better approach to the problem. Encourage that type of autonomous thought.
In Arthur J Riel’s Object-Oriented Design Heuristics, a book of metrics for good object-oriented design, he states:
I refer to these 60 guidelines as “heuristics,” or rules of thumb. They are not hard and fast rules that must be followed under penalty of heresy. Instead, they should be thought of as a series of warning bells that will ring when violated. The warning should be examined, and if warranted, a change should be enacted to remove the violation of the heuristic. It is perfectly valid to datte that the heuristic does not apply in a given example for one reason or another. In fact, in many cases, two heruistics will be at odds with one another in a particular area of an object-oriented design. The developer is required to decide which heuristic plays the more important role.
In other words, break the rules when it makes sense to. That’s the big leap from novice to expert.