Gas station without pumps

2013 January 30

Teaching engineering thinking

Yesterday I wrote

Maybe I should recommend some generic problem-solving books, like Polya’s How to Solve It, since it seems that the class has not been taught many problem-solving skills. I keep feeling that I’m teaching stuff that they should have had much earlier, but clearly haven’t, as if every teacher they’ve ever had has pushed off teaching the important stuff in order to cram in more factoids. There are times when I’m tempted to kick the can down the road myself, but these are all seniors, and it seems almost criminal to let them graduate as engineers without ever having been taught to think like engineers. I’m going to end up working them pretty hard, trying to get them up to speed in circuits, writing design reports, and how-to-think-like-an-engineer in just 7 more weeks.

I’ve been trying to pin down just what I mean by “how to think like an engineer”—something I’ll need to have at least some handle on before I can teach students how to do it.  I have a few vague ideas of what it means, but not anything crisp and clear enough to serve as a design guideline for planning my teaching.  Here are a few random thoughts:

  • Engineers pay attention to details.  It isn’t enough to have the right general idea—the execution has to be right also.
  • Engineering is about solving new problems, not memorizing solutions to old ones. It is better to have a few general principles that can be used over and over in different contexts than an encyclopedia full of formulas and protocols for every known situation.  If the problem has already been solved, it isn’t really an engineering problem.
  • Design is often about a tradeoff between conflicting goals, or between goals and constraints that limit what can be done.
  • Sanity checks are essential.  Every schematic, every wiring connection, every computation should be subjected to quick checks for consistency.  Some of the checks are easy: Does every 2-terminal component on the schematic have two connections to it? Is every pin on the chip accounted for—either wired up or labeled as not connected? Do the units for the computation match (ΩF=seconds, not Hz)? Does replacing the ammeter with a short-circuit change the expected behavior of the circuit?  …
  • Design is not a process of randomly trying things until something happens to work, but of carefully planning how things should behave.
    Don’t get me wrong—I’m not denying the role that chance and luck can play in engineering. There are occasional serendipitous events, where something works despite mistaken thinking, but that is rare. My first patent, the plucked-string algorithm that Alex Strong and I developed, resulted from just such a serendipity—Alex had been attempting to implement something and had mistakenly added an averaging of two adjacent samples. My main contribution was to figure out why that mistake produced much more interesting results than what he had originally set out to do.  But even with that initial serendipity, we spent a couple of years doing careful design—coming up with different software and hardware implementations for the plucked-string algorithm (which we called the Digitar algorithm, but is now more commonly called the Karplus-Strong algorithm).  I even took a  VLSI design course so that we could implement the algorithm as a custom chip—a course that shaped my career for the next 15 years.
  • Debugging is a process of thinking carefully about why the circuit, program, device, system, … is not doing what you want, and what modifications to it should change it in the desired manner. It is even less random than design—one has to build useful mental models of the failing system that explain the cause of the failure, then determine modifications that would fix that mental model, before trying fixes in the real world.
  • There are no right models, just useful models and useless ones.  (Even that’s wrong: there are more useful and less useful models, where the usefulness depends on what questions you need to ask of the model.)
  • Quick estimates from rules of thumb and extreme cases are handy.  A capacitor is an open circuit at DC and a short circuit at ∞ Hz, so low-frequency and high-frequency behavior of RC circuits is easy to estimate without much computation.
  • Empiricism rules: the answer to the question “Is this right?” is almost always “Try it and see!”

How can you tell if someone thinks like an engineer (or will learn to think like one)?

Some people point to kids who like to take things apart to see how they work, and say that they are budding engineers.  While taking things apart to see how they work is sometimes done by engineers, it isn’t the normal mode (they even call it “reverse engineering”, because it is backwards from what engineers usually do).  Scientists take things apart to see how they work—engineers put things together to make them work.

I posted about science vs. engineering 2½ years ago. In looking over that post, I see that even then I was thinking about the differences in training:

There is a distinct difference in the training one should give a student who is planning to be a scientist and one who is planning to be an engineer.  Sure, the basics are the same at the beginning (basic science, math, lab technique, computer programming, statistics, and so forth), but the engineer has to be taught how to design and debug, while the scientist has to be taught how to question dogma and discover new ideas.  These are not the same skills at all and both need substantial practice before people are competent at them.

For scientists, the tradition has been to devote the undergraduate years to acquiring basic knowledge, but not to practice being a scientist at all.  As a result it takes 5–7 years of grad school (and often several years of post doctoral training) to turn science undergrads into scientists. For engineers, the tradition has been to do 2–3 years of basic training, followed by 2–3 years of project work of gradually increasing complexity, culminating in either a B.S. or an M.S. degree.

The shorter training time for engineers means that it must be much more focused—you can’t hope that the students will pick up skills they need gradually as a by-product of years of doing something else (the way that scientists are trained). Instead, the specific design skills and group management skills need to be explicitly taught and practiced while the students are still undergrads.  This has a lot of consequences for curriculum design, as almost all junior and senior courses have to include design practice, and there needs to be at least one big project (preferably one too big for a single engineer to handle).  Explaining these curricular needs to faculty trained as scientists can be difficult—they want to leave all that to the grad curriculum or one-on-one training of postdocs.

I’m afraid that the bioengineering students in my circuits class have all been trained like scientists, with a huge number of courses in basic scientific knowledge, but almost no training in debugging or design practice. Hmm, that’s not quite fair.  Several of them have worked pretty intensively on debugging wet-lab protocols, though mostly in senior thesis projects, not in regular courses.

I can’t teach everything about “thinking like an engineer” in one course, even if I could articulate exacly what I meant by it.  I will try to give them problems that are puzzles, rather than rote application of formulas, and that emphasize design goals rather than analysis of what is already designed.  Since the traditional circuits course is almost all analysis with very little design, this makes the crafting of this course into an engineering design challenge: I need to create something new, not just copy exercises and lesson plans from elsewhere.

Unfortunately, I’m still wrestling with the precise design goals of the course and the constraints imposed by the time available and the prior training of the students. I had taken “thinking like an engineer” for granted earlier, for example, and not thought of it as a pedagogical goal for the course.  Now I need to rethink how I present material and how I get students to wrestle with it so that their lifelong habits of thought are shifted.  I was thinking I would be adding a couple of new tools (from circuit design) to their toolbox of mental models, rather than having them build a whole new toolbox.

Having to debug a course design is a lot like other engineering design challenges, except that I need to debug the course while it is running—I can’t turn it off, restructure it, and turn it back on again.  The problem I have right now is that my mental model of the material and how the students would interact with it is not quite right (I get too many surprises), and I’m trying to decide if it is a good enough model to continue with, or whether I need to find a substantially different mental model in order to debug the course.

Perhaps my new view of needing to teach “thinking like an engineer” is wrong—maybe the problems I’m seeing are not that fundamental, but are just unfamiliarity with the material, and that a little more practice to get comfortable with it is all they need.  The pedagogical interventions I’d need to do are quite different in these two views of the problem, and I’m not sure how to tell which mental model is more useful.

Does anyone who got this far in my post-midnight rambling have any suggestions for me?

%d bloggers like this: