Invert how to teach programming?

Question

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?

Answer 1

I don't think that you should do something like "error based teaching".

It would be enough, and most likely helpful, if, after explaining how to write a function let them remove the return statement, compile again and see what errors they get. So adding more details about the compiler used and the messages it generates to the normal flow of teaching that rightfully concentrates on the idea of getting things done.

This may be especially helpful with languages like C++, that have error messages and warnings that can be far more confusing than your example. Especially when starting to use STL containers and having a nice chance to see some 4k long error message for something as simple as a typo.

Or just let them remove a semicolon, so they see that the following error message has absolutely no connection to the actual problem.

Answer 2

I'd consider this to be dangerous if not worse. Would you want a chef to learn to cook by experiencing every possible kind of food poisoning so the chef knows how to not cook something in having all kinds of possible reactions? I know I wouldn't. If someone wants an odd case to consider look at how improperly prepared Fugu could be fatal.

Provide code to demonstrate all the ways this warning can appear.

How sure are you of being able to conclusively prove that every way is covered? That someone couldn't down the road find some other way to get some obscure case to occur?

Another point is how some of these could be hit rather early. Wouldn't a "control reaches end of non-void function" be covered as part of learning about functions as I'd imagine it would be in first seeing these that someone may experience this kind of message. Similarly, seeing a line of code like x = x + 1 may make sense to some people and be illogical to others.

Lastly, how many horrible ways are there to solve some problems? For example, how many inefficient sorting algorithms exist? Quite a few and I'm not sure how wise it is to teach most of them. A couple can be worth covering as part of an introduction to complexity but could you imagine seeing dozens of poor sorting algorithms? There would also be the idea that students could expect the real world to be like this where things are initially done at really low quality with the intent of great improvements coming quickly which may not always be the case.

Answer 3

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

Most? Really? Some, certainly, but some will go find the TA and ask what the error means, some will change the return type of the function, some will ignore the warning, and a few might even start changing all their other functions so that they, too, produce the same warning. After all, it's good to know that your functions are running all the way to the end.

All the compilers I can think of are capable of producing hundreds of warnings or errors, and the newer the newbie, the more likely they are to encounter a wide variety of same. Are you really going to assign problems intended to teach about each and every one of those? I can't think of a faster way to turn students off.

Instead, you might:

• Talk to students about the importance of understanding what they're doing and the problems that come from quick fixes and black magic debugging.

• Recognize that students are often in a hurry because they have a lot of other work that they need to get through.

• Build a case that understanding an error leads to a quicker fix than just trying things until they get it working.

• Ask them to keep a log of the warnings and errors they see and to explain what they mean and how to fix them. (Occasional "I have no idea" should be acceptable.) Using the script command to capture compiler output can make this much easier.

Answer 4

There is nothing like experience and good mentoring. How does one become an "expert" in their field. I would say that it took lots of hitting those brick walls, making their mistakes, and then finding their way out and making those adjustments for later reference. That is what we have here.

Those are definitely the kind of exercises that should be taught in school - things that can make a student not just learn a specific bug, but teach the mindset on how to find these things out and correct them for the long term.

However, most of the time, you will not be hit with this stuff until you hit the "real" world. This is where a good mentor and/or team lead can come alongside the young programmer and help them learn the abstracts of thinking in this logical manner and not repeating the habits of many young programmers. I think even posts like yours can help.

You've hit upon one of the differences between inexperienced programmers and those with some seasoning. Those with seasoning need to be ready to mentor and teach and those who are inexperienced need to be open for correction and learning.

Answer 5

Expert programmers can't come up with all the ways code can fail, so why should you stress out novice programmers with it?

Good design is more about making code that is easy to change and less about thinking of every contingency of how it could fail. If you lived in a vacuum and knew every requirement of a system, then it might be reasonable. You don't though.

It's going to fail and it's going to fail miserably. If you can fix it easily when your poor assumption is discovered, then you're in a much better position.