There are many different methods of teaching. One common method of teaching is the simple conveying of lots of information. A teacher can recite many facts and figures, statistics and anecdotes, methods and techniques. Students can listen, take notes, and attempt to comprehend the information being thrown at them.
Or, a teacher can explain concepts to the students in a way that enables students to just “get it.”
Photo by CloudSpotter.
When it comes to the subject of writing software (as well as many other subjects), I’ve found that many styles of teaching can be boiled down to two types. The first and more common one is what I call SolutionBased Teaching. This method consists of a teacher explaining solutions to problems that arise while coding software. The instructor explains all sorts of Design Patterns and architectural solutions that can be used in a variety of situations.
SolutionBased Teaching sounds effective, but it may not be of much value. Most of the time, when a teacher employs this method, the students only have a vague understanding of the solution because they don’t really understand the problem it is trying to solve.
To take this to an extreme, I had one professor who spent many classes teaching various Design Patterns, which are programming techniques that are used to solve common problems. He would first detail the technique, and only afterwards explain the problem it solves! After the problem was finally taught, I would think, “Okay, so what was the solution again?” It is virtually impossible to understand the Design Pattern in a vacuum, without understanding what it is trying to achieve.
However, even if the professor taught the problem first and the solution second, I feel that this is far from ideal. The reason for this is that many of the coding challenges aren’t really challenges to the students unless the students have actually experienced the problem. To simply be told by a professor, “Okay, here’s a problem that can arise,” doesn’t really make it a problem in the minds of the students, because they don’t really have a good grasp of the issues and drawbacks the problems create.
Enter ProblemBased Teaching. A teacher can really convey meaning and provide value when teaching Design Patterns if he or she can actually get the student to struggle with the problem. A problem cannot simply be explained. The teacher should have the student work on a handson project, in which the teacher intentionally sets up the project in a way that will lead the student to the problem. In ProblemBased Teaching, the student will “get” the problem, because she will have experienced the problem herself. Then, when the solution is taught, it will be an eyeopener to the student, and wellappreciated.
I believe that ProblemBased Teaching is many times more effective than SolutionBased Teaching. Unfortunately, not enough teachers use this method. ProblemBased Teaching is a teaching style that can be used for many subjects, but it is especially important when it comes to computer science. I wouldn’t be surprised if the dropoff rate of students who begin a computer science curriculum and later abandon it is largely due to the abundance of SolutionBased Teaching that is overused in the classroom. ProblemBased Teaching may take more creative effort, but the rewards truly pay off.
