I invited Professor McGuire to do this guest column after hearing some inspiring comments from him at our weekly Tuesday Science lunch today:<\/p>\n
Teach Process not Material <\/em>by Professor Morgan McGuire<\/p>\n I’ve been thinking lately that one cannot put enough emphasis on process, as opposed to material. In the sciences this means the methodology that we bring to solving problems. That methodology is usually mathematical or experimental. Moreover, I think process is a universal truth that applies equally well to the humanities, as well as outside academia in industry.<\/p>\n Workflow analysis (e.g., the time-motion study) is an industrial example of studying process. Reducing the number of physical motions that a factory worker makes can increase his or her efficiency. Something as simple as moving a lever from one side of a machine to the other, where it is easier to reach, can increase throughput for the factory. These ideas have historically been applied to kitchen design, craft work, and office layout. They’re even critically important for computer work. A student who keeps open all of the files he or she needs for a project rather than continuously opening and closing them has much less overhead to research and will likely finish a paper faster than a peer. \u00a0The natural extension of this is learning to use the time-saving features of computer tools, like desktop shortcuts, keyboard commands in Word, and macros in Excel to avoid slow or repetitive tasks.<\/p>\n In the educational context, learning how to approach any problem is more important than learning about specific problem domains. \u00a0Courses purport to teach, for example, Medieval History or Linear Algebra. \u00a0But they really teach a set of techniques for approaching problems, and use the subject matter as a concrete context for teaching those techniques.<\/p>\n What is interesting is that studying how to solve problems, rather than just solving them, might be new for bright students. \u00a0Those students might come to college accustomed to solving problems intuitively on inspection. Solving by inspection divides the world into trivial and impossible problems. There should be a smooth gradient, and thinking about how to solve a problem (instead of the problem itself) is the trick to climbing the gradient. It is the only way to approach problems that are too big to “get your head around.”<\/p>\n Some common approaches for solving any problem are:<\/p>\n 1. Abstract common operations.<\/p>\n 2. Divide it into subproblems (or distinct cases).<\/p>\n 3. Reduce it to an already solved problem.<\/p>\n 4. Translate it into a more familiar domain (which is really points 2 + 3).<\/p>\n We all know this, but it is easy to forget when actually faced with a challenge. \u00a0In research work I have to remind myself to step back from the work and ask whether I’m really approaching the problem the right way. \u00a0I know it is a challenge for some of my students as well. When I see them spending a long time on a problem where they know the material, I realize that I didn’t spend enough time explicitly teaching the techniques to apply to that material. In CS371: Computer Graphics and CS107: Creating Games, most of the class time is explicitly spent on process. \u00a0This squeezes out some topics I’d like to address, but allows students to learn and work very quickly by the end. I now feel that I should be teaching process even more in other courses I teach.<\/p>\n A final word about point 1: Abstraction. This is a really big idea. I’m partial to it because my entire discipline (computer science) can be seen as the study of abstraction in computation. Abstraction means making your own tools to avoid repetition, reduce the amount you have to think about at any point, and draw attention to important concepts. There are many ways of doing this. Two big ones are defining a new notation that hides boilerplate and transforming data into a visual form in which it is easier to observe relationships and anomalies. Some examples \u00a0combine both, e.g., chemical diagrams, Feynman diagrams, charts and graphs. \u00a0In fact, the other approaches listed above\u2014subproblems, reductions, and translations\u2014are all instances of abstraction. \u00a0So, perhaps my point is that studying details is a weak approach; we should instead think more about abstraction to avoid being overwhelmed by the details.<\/p>\n