Negative Feedback

Tag: teaching

  • My brain can’t do that!

    When I was teaching computer programming to chemical engineering students I categorically denied that “I’m just not good at programming” was a valid excuse for flunking my subject. Lately I have become less sure of my position. Let’s be clear: I am quite convinced that people have varying levels of aptitiude, it’s just that I had thought that certain skills were so similar that one automatically led to the other. Chemical engineering students in their second year have already passed many mathematics courses and have shown themselves to be intelligent and able to follow the steps required to do algebra and calculus in a relatively mechanical way. Programming has always seemed entirely analogous to math for me, so I made the mistake of generalising from my experience to theirs. As any good lecturer will tell you, this is a fatal mistake.

    I am constantly fascinated by how inaccessible our brains are to ourselves. The puzzle of exactly how my brain makes the connections between formulae and computer language syntax is probably better understood by some neuroscientist somewhere than by myself. This is, of course, entirely counter-intuitive. Many people would even deny it. But the thing that concreted it for me was listening to this episode of Radiolab (which if you haven’t listened to it yet, is an entirely awesome podcast covering a wonderful array of different subjects in a wonderfully cock-eyed way). Spoiler alert: the skill displayed here is a guy who is able to run multiple symphonies simultaneously in his head. Try it. Start playing a song you know well in your head. A couple of seconds later, try starting another one by a different band. Now tell me where you are in the two different songs. If you are remotely normal you will be unable to even conceive of how to do this. The feeling I get when I try to do this makes me wonder: if we have such a clear example of a person who can do something that seems totally unrelated to skill or practice, but which normal people cannot do, who am I to say that those people in my class just couldn’t “get” programming, ever?
    The problem is that it leads to an uncomfortable end point. I cannot assume that any student who struggles simply cannot do the stuff he’s trying with – that would invalidate the entire purpose of teaching! Well, unless you ascribe to the notion that teachers are only allowing their students to reach their potential, but that’s a whole different post. Like the conundrums of free will, it appears the argument ends in a place where assuming something we know to be wrong in general (that “any student can do this”) is both easier and less risky than correctly determining who has the ability in the first place and then only focusing our attention on them.
    One good thing has come from these musings though: I find myself being much more sympathetic to the struggles my students have. And I suppose a little empathy never hurt anyone.

  • The science of the general

    This is a draft of an upcoming comment hopefully to be published in Chemical Technology. Feel free to shoot with some comments, even if you’re not a chemical engineer.

    Chemical Engineering as a discipline by that name has been taught at universities since 1888. At this time it was seen as a small side-branch of Mechanical Engineering incorporating applied industrial chemistry, mainly serving the emerging chemical industries of the time. The curricula of these early courses would become more recognisable to modern Chemical Engineers when AD Little formalised the concept of unit operations in 1915, while the concept of material and energy balances had gained traction by 1935. Thermodynamics and process control had appeared by 1945, followed by chemical kinetics and process design by 1955 (see Origins of Chemical Engineering for a complete timeline). Henri Poincaré said “There is no science but the science of the general”, and one sees this instinct for generalisation at work as fundamental knowledge and general analysis supplanted a curriculum filled with specific examples from industry.

    During roughly the same time, computing devices were progressing from simple adding machines to fully programmable computers. Although computers had been used for process control on chemical plants since the late 1950s, the first personal computer was only released in 1974 and Chemical Engineering simulation software for the PC was released in 1981. In a recent Nature interview with Neil Turok from the African Institute for Mathematical Sciences, I was struck by his description of their curriculum design process. They had initially developed a “conventional syllabus involving math and physics”, but realised there wasn’t enough time to teach it. They then made a key observation: “… if you took a photograph of a scientist at work today, everyone looks the same … sitting at a computer and trying to make sense of what’s on the screen.” I think one could confidently replace scientist with engineer in that observation.

    The funny thing is that computers are often seen as a means to an end, something that can remain opaque to our understanding as long as the programs we use work. Although the same approach could arguably be applied to much of the equipment on our plants, we still teach Thermodynamics, Calculus and other subjects that are frequently described as not being used in the workplace. We do this because these subjects lead to a more fundamental, more general understanding of our plants. There is far greater likelihood of a particular Chemical Engineer using a computer in his day than any particular unit operation, but it is not common for us to teach the equivalent fundamentals behind computing as applied to the problems of Chemical Engineering. Instead, we focus on manual solution of sets of equations using methods that have very little in common with the computer techniques used by process simulators. A friend of mine summed it up well: “We’re teaching as though it were still the 70s, as though there is a reasonable chance of having to solve a problem on site without the benefit of a computer”.

    Perhaps a part of the problem lies in the demarcation of domains. The fact that computer science is a discipline in itself, or that there may be an electronic or computer engineering department in the same school as our Chemical Engineering departments may lead us to focus on the “real Chemical Engineering”, but the existence of an industrial chemistry course or a mechanical engineering course did not stop our predecessors from carving out the niche that would become Chemical Engineering. We would do well to remember that most of the simulators we use today were developed by Chemical Engineers rather than generic software houses.

    Another argument is that the principles don’t change much from manual calculation to computer implementation. However, the methods of solution and the fundamentals of computing have made such great strides in the last 100 years that understanding how to solve a set of mass balance equations by hand does not really enable one to reason about the algorithm being employed by a simulator. Not only that, but the algorithms and software that are available today enable the solution of whole different class of problems.

    We need to move beyond the simple treatment of computers as tools to solve our problems and appreciate that there is a general science underpinning their operation. As much as understanding Reaction Kinetics or Thermodynamics enables us to understand the design and
    failure modes of reactors, understanding the computational structure of our simulators, optimisation solvers and spreadsheets can help us to understand how to employ these new information unit operations more effectively. It may also enable us to develop the
    next set of tools for ourselves.