Beginners Need Steps!
Beginners Need Steps!
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
A topic that came up repeatedly this week at Agile Development Practices was whether we should teach people steps or principles. Most, if not all, of the thought leaders and industry experts don't want to provide steps. We've all seen people take steps and follow them religiously. Leaders don't want to see steps abused. They've seen beginners take the steps and use them... but because they never learn the principles, they don't know why a given step is important.
Lee Copeland mentioned the "if-then" process principle. "If" this happens, "then" do that. All too frequently beginners see the "then" step but never learn the "if". The results, which are often disasterous, are that the prescriptive steps are followed when they don't apply and aren't needed. The "if" gets lost.
So of course, to avoid this, many people refuse to provide steps. They fight against people who provide steps. Steps have been abused, therefore they are always evil. Let's abolish steps!
Unfortunately this view forgets one vitally important fact. Beginners need steps.
Let's emphasize that. Beginners require steps. They can't learn without them. So when we teach without providing steps, they get lost, frustrated, and they quit.
This goes back to a topic I learned about from Andy Hunt, the Dreyfus Model of Skills Acquisition. When learning a new skill, we need (not want, need!) step by step directions. Levels one through three live and die by steps. It's the only way they can get work done. Levels four and five move into the realm of intuition... they "just know" how to do the right thing. They usually forget how to even express the steps! So they naturally try to teach via these very useful, high-level ideas. And that generally frustrates the new users.
Think back to your first progamming class. Did you discuss the ideas and prinicples on day one? No... you were given precise steps on how to type in a program and then run it.
10 print "Hello world!"
20 goto 10
How about cooking? Do the TV chefs measure out and level off teaspoons of ingredients? No... they just throw in a dash of this or a dash of that. Season to taste they say. That's how experts work... it comes naturally to them. But have you ever seen a cookbook that didn't specify teaspoons and cups?
The steps are how we find our footing. They get us started. When we deprive new users of prescriptive steps, we rob them of the ability to get started easily and quickly. They're robbed of the easy wins that get them rolling quickly. We tell them that until they understand the entire ecosystem, until they can grasp the advanced principles, they aren't worthy of playing in our club. This is so wrong.
We also need to warn people about the other extreme though... that's following steps blindly. Read Martin Fowler's article on the improvement ravine. He talks about following a process religiously ~at first~. Then, after you understand it, start changing the steps, tweak, eliminate... make it fit your shop. After you've followed the steps for a while.
I try hard to provide students, especially new ones, both steps and the motivations behind those steps. I tell them there is no gospel in our field. The steps are written by flawed humans and either wrong, or wrong for their shop. Be willing to throw the steps out after you've followed them for a while.
But if you're a teacher or leader, and you want to help people get started with a new topic, from programming to cooking to agile, provide them steps. Give them the "1, 2, 3". Also explain why each step matters. Then tell them to throw your steps out in a few months.
If you don't provide steps, don't be surprised when nobody adopts your ideas. People need steps.
The original posting can be found here.
Opinions expressed by DZone contributors are their own.