I was thinking about the responses to my thread on programming Program like a writer..? and most people agreed that you should have some structure and build from there instead of just typing away. New programmers, however, tend to just type, find mistakes, add code, and repeat unti it works.
To quote Richard Pattis:
“When debugging, novices insert corrective code; experts remove defective code.”
This is fine and all, but the problem is that people repeat their mistakes. After making a mistake enough times, they eventually learn to avoid it.
To give a practical example, consider
warning: control reaches end of non-void function. Most new programmers will see this, google it, figure out what's wrong, add in
return 0;, and they're good to go. They don't care about the error; they just want the solution
What if we invert this concept? Why not teach them how to mess up first? A possible assignment could be:
Consider the warning "control reaches end of non-void function" What causes this warning to occur? Provide code to demonstrate all the ways this warning can appear. Evaluate the following code samples and explain why the warning appears.
This way, the programmer learns that all non-void functions need to return something. They would have to write code to create this error (debugging/testing), and evaluate existing code to find the error (code review).
I'm not saying we teach this before fundamentals, because you should understand iteration/recursion, loops, assignment, equality, etc before writing significant code.
I'm saying that instead of solving errors as rookies make them, why not concentrate this knowledge in the beginning. What do you guys think of this idea? What are the shortcomings of this approach, and can it be feasibly implemented anywhere?