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?

About these ads


  1. Yes, yes, yes, And this is why I argue to anyone who will listen that computer science is not a science at all, but is an engineering field. The things you list as important for engineers to learn are exactly the things that that computer science majors need to learn too.

    Comment by Bonnie — 2013 January 30 @ 05:23 | Reply

    • It’s not too surprising that my view of what engineers need to learn matches what you feel computer scientists need to learn. My PhD is in computer science, and I spent 15 years in computer engineering before moving into bioinformatics. So I have a rather computer-science view of engineering. But a lot of this musing is based more on my much earlier training by my Dad, who started out calling himself a physicist, and later changed his title to research engineer, to more accurately reflect what he did and how he thought. He is the one who trained me to think like an engineer, not my math professors or computer science professors (the three EE courses I took in grad school may have influenced me a little).

      Comment by gasstationwithoutpumps — 2013 January 30 @ 09:12 | Reply

  2. Excellent thoughts, Kevin. I practice in an engineering field far different from circuits, but agree with your assertion that engineering is a behavior that applies to all disciplines. From that perspective, let me offer these observations:

    In my 25 years of practice I rarely have encountered peers who think like the archetypical Engineers you describe. Most practicing engineers have little interest in solving unique problems, trying empirical solutions that are not guaranteed to succeed, wracking their brains to develop analogies to other disciplines and import new analytical techniques. Great, good, or even competent Engineers, as you’ve defined them, are quite rare. My industry is overwhelmingly filled with practitioners intimidated by uncertainty and unable to think independently. It’s almost like the prevailing “technician” skill set has co-opted the word “engineer” and left us without a word to describe the attitude and abilities that you describe as true problem-solving Engineering. Huge organizations, successful ones, NASA and General Motors and Apple, have organized their engineering departments consistent with the reality that very few of the people working on solving problems will have strong Engineering skills. The resulting culture tends to be very conservative, to a degree that a person who behaves like an Engineer, as you describe it, doesn’t feel comfortable or is not welcome and ends up developing their game-changing engineering advance from outside the large organizations. The folklore of “2 guys in a shed” grows from a kernel of truth. Real Engineering often is impossible in large engineering organizations because a the prevailing culture is geared toward technicians and senior managers (also technicians) are unable to recognize and accommodate real Engineering.

    So this comment grows long, and I’ll try to come to the point: The limitation you observe in your students is not, in my experience, caused by failure of prior teachers to inculcate the correct skills. I have devoted significant thought to the question of from where, then, does real Engineering skill come, and have no good answers. What I can offer that may be helpful for the circuits class is that you are likely observing actual American engineering skills. Most of your students will be well matched to the requirements and expectations of jobs in industry, that have been molded over time by the available candidates having the word “engineering” on their diploma but able to work only as technicians. Your students will get jobs that require them to follow procedures in a manual, conform to established thinking, and limit their ideas to what is readily understood by others with a similarly mundane approach to engineering. Real Engineering is frustrating and difficult, and you should not expect to change them so that they embrace the requirements of archetypical Engineering. I encourage you to help them as best you can, whittle away at the worst of the passivity, try to make problem solving fun and not overwhelming, within the context that they still will need to be led to the “correct” answer so they can earn a grade. I think that you could call that success, within the context of industry expectations

    And if you do, however, have one or a few real energetic problem solvers in the class, see if you can’t devote what resources you have left to creating a capstone experience for them, without intimidating the whole class with expectations that all engineering students have the potential, or the desire, to tackle difficult and poorly defined problems like Engineers. Recognize that these students may actually be the ones who are ill-suited to working in industry, who may get frustrated (after a couple of years trying, typically) working even at the best engineering shops. If these students have time, see if you can’t steer them toward a course in basic entrepreneurialism, which may get them to the “2 guys in a shed” phase faster and with less frustration.

    Good thoughts, Kevin. I appreciate the forum that you’ve created here.

    Comment by Doug — 2013 January 30 @ 06:35 | Reply

    • I’m not sure whether to be encouraged or discouraged by your comment. Basically, you seem to be saying that I should be content if I can get the students to learn some rote skills, and apply them to familiar problems, and that I should give up on getting them to think, because industry doesn’t really expect them to. I suppose I would be happier if I embraced that attitude, but right now it feels too much like giving up as a teacher.

      I may have to be content with smaller improvements in their engineering thinking than I’d like, but what I need are ways that I as a teacher and course designer can maximize those gains, rather than hearing that it is a hopeless task. I have nearly ideal conditions here: a small class of smart, hard-working students who want to learn the material and all have very similar prior training, a free hand to design the course any way I can imagine, only one course to teach this quarter, lab facilities that are much more than adequate for the level of course, an experienced lab instructor who earns teaching awards from the engineering students every year as a mentor, and an undergrad group tutor to help students out in the lab with me.

      The only things working against me are time—we have 34 class meetings and 10 lab meetings and have already used up a third of them (9 and 3)—and any blind spots in my thinking about how to teach them.

      Students are definitely out of their comfort zone, but I can’t tell whether I’ve pushed them too far (beyond the realm of proximal growth) or not far enough.

      I don’t have the appetite for risk and thrills that being an entrepreneur requires, so it is difficult for me to advise other students to go that route. Not that I think you’re wrong—just that I’m naturally very risk-averse, and so have trouble recommending that others gamble where I would not.

      Comment by gasstationwithoutpumps — 2013 January 30 @ 09:35 | Reply

  3. The caveat I’d add is that a fair amount of doing good experimental science includes the concepts you’ve assigned to engineering and that effective experimental scientists have to have them, in addition to “questioning dogma and challenging ideas.” I’m also guessing that engineers have to do that sometimes, too, in order to find solutions to new problems (rather than applying old solutions to problems).

    In an experimental science lab, people ask “Is this right?” a lot, too, and the answer is also often “Try it and see!”

    Comment by zb — 2013 January 30 @ 09:39 | Reply

    • I agree that a fair amount of what experimental scientists do is engineering. A very large part of experimental physics is engineering (designing and building experimental equipment). Designing a new wet-lab protocol and debugging it is most definitely engineering.

      The difference I see in biological fields is in the importance assigned to different parts of the process. The “scientists” ask questions about biology and the details of the experiments are often an afterthought—the journals put “methods” in small fonts at the end of the articles. As often as possible, the methods are standardized protocols purchased as kits or looked up in books of protocols. The “engineers” focus on developing reusable methods that can be used for many different experiments—creating the kits and protocols that the scientists use.

      The same individual may take on both roles at different times, just as one person may be a musician, a scientist, and a teacher, but the thinking process is different in the different roles.

      Comment by gasstationwithoutpumps — 2013 January 30 @ 10:01 | Reply

  4. Interesting comment by Doug — I too wonder what percent of students need to be taught to be “Engineers” (or, in the words above, people who have the potential and desire to tackle difficult and poorly defined problems). Those problems clearly exist outside of engineering, so, we don’t really just mean engineers, but any student (including students who will be teachers).

    I don’t know the answer — I have a vague feeling that most interesting jobs will require it, but also find that there are students who don’t seem like tackling ill-defined, complex problems is their strong suit, but who are quite good a tackling well defined problems. How much do we train everyone to have the most extreme skills or how much should we select a subset of students to have those skills?

    In my mind, the questions isn’t that you shouldn’t be trying to teach “Engineering” but to whom you should be teaching it.

    Comment by zb — 2013 January 30 @ 09:48 | Reply

  5. Good point, Kevin. In no way did I mean to encourage hopelessness. Setting reasonable expectations, though, might help replenish your optimism. Very few people are temperamentally suited to attacking difficult problems using innovative thinking, and so you are likely so see fewer of them than you might want even in a group of high-performing students.

    So you asked for suggestions for the class already in progress, and my comment didn’t offer much except for maybe allow for a couple of kids, the ones who already “get it,” to thrive. Let me try again, though I have low expectations that any of my thoughts will be helpful.

    1. I believe that your practical approach has pushed the students beyond the realm of proximal growth. You can probably ask one or two of them to confirm for you.

    2. Are they concerned about expectations, performance, and grading? Maybe something as simple as a 10-minute discourse explaining your expectations and how you’re aware that this course is different than other courses. Do they need assurances that grading is not keyed entirely to success? I imagine that these kids are used to getting good grades in exchange for correct answers, and you’ve given them problems that don’t necessarily have a clear path to a good grade.

    3. Would it help for them to do some of the work in groups? Can you introduce a brainstorming and prototyping component to the class that takes advantage of a few good ideas and spreads them around the class? Are some of the students just perplexed about how to attack a problem at the beginning? And can they learn from having it modeled?

    4. Do they have sound fundamentals? Sometimes I struggle to implement solutions because my math is rusty, so I confuse an error with a fundamental failure. This might be the difference between debugging and basic design errors. Just guessing here, but when I’m on unfamiliar technical turf I get tentative, and then I start to doubt even well-designed solutions.

    That’s what I have this morning. Again, excellent topic.

    Comment by Doug — 2013 January 30 @ 09:54 | Reply

      1. I’m not sure the students can tell when they are in their realm of proximal growth any better than I can. They are out of their comfort zone, but that would be the case for proximal growth as well as for way over their heads—it can be hard to gauge how much you are learning when you are uncomfortable. I do get feedback from the students frequently, and I welcome more. I’ve made some changes already based on feedback, and I expect to make more.
      2. Some students are definitely concerned about grading and about workload. The class is down to 11 students (stable now that the add/drop deadline has passed). Students who are left have been getting grades in the B- to B+ range on their lab reports, and some have been asking about what it would take to get As instead. I’ve been trying to provide that information both as individual feedback and to the class as a whole. Part of the problem is that I am requiring good, literate design reports every week, which most of them are not used to providing, not just answers to questions.
      3. They do their lab work in pairs (rotating who they are paired with, though the class is small enough now that I’ll have to allow repetition of partners by the last couple of labs). The paired work for the labs is helping. So far the design problems have been small (choosing one or two parameter values), so brainstorming would be rather pointless. Next week they have a slightly bigger problem (designing a low-power audio amplifier using an op amp), so there may be some point to an in-class design exercise in groups.
      4. They are very rusty on both math and physics, which is a real problem for a circuits course. I’ve been refreshing them as we go over the do-now problems, and I think we can bring back enough of their skills here for them to be comfortable with the problems they need to solve.

      Comment by gasstationwithoutpumps — 2013 January 30 @ 10:25 | Reply

  6. [...] post last night on teaching engineering thinking had a coincidental resonance with another blog post that came out yesterday: Calculus and formal [...]

    Pingback by Formal reasoning in intro physics « Gas station without pumps — 2013 January 30 @ 19:46 | Reply

  7. You’re in a situation here where reassessment is likely cheaper (in time and resources) than in your other courses. Is it time to consider standards-based grading? I’m imagining standards that involve justifying a choice between two technically correct solutions, or explaining which principles support which answers. I’ve had some success with questions in a form something like this: “All of the following statements are true. Which ones are supported by Kirchoff’s voltage law?”

    What success I’ve had helping students learn to analyze heuristics, debug something, pay attention to details, and use sanity checks have come from making students use those skills on their learning process, not just their circuit-buidling process. It helps with “empiricism rules,” too, since it frequently forces students to confront the discrepancy between what they “feel” like they know and what they can actually do. I helps me move the pace of the course forward, as well — I can give the quiz before students are ready, knowing that some will use it as a summative assessment and some will use it as pre-assessment before they decide whether they need to practice/study.

    Comment by Mylène — 2013 January 30 @ 20:14 | Reply

    • Creating assessments is the time-consuming part for me—I expect to spend several hours this weekend trying to come up with a handful of questions for Monday’s quiz. So reassessment is still expensive, even in a small class.

      So far, I’ve been assessing them strictly on their lab write-ups, though I have said that we might need a midterm and final if I don’t get the information I need from the write-ups. I did add the quiz next Monday (which doesn’t have the weight of mid-term exam), since I need to know who has actually gotten the ideas of impedance and voltage dividers—they’re going to need them to do amplifier design with op amps, which is the next lab. I’m thinking of trying to do some in-class design work in groups next Wednesday the day before the lab.

      I do allow students to redo any lab report (except the last one of the quarter) if they are not happy with the grade I assign, and I give a grade of “REDO” for anything lower than a C. So I am doing reassessment on the 10 lab reports.

      Comment by gasstationwithoutpumps — 2013 January 30 @ 21:09 | Reply

      • Interesting. What criteria do you use to grade the reports?

        Comment by Mylène — 2013 January 30 @ 21:32 | Reply

        • I have guidelines that I wrote up at

          Basically, I’m looking for reports that would explain what was done, what design decisions were made (and why), and what it all means to someone who has not read the lab assignment. I’m not looking for a “written-to-the-teacher” report to prove that they followed some cookbook procedure. I want a professional (or near-professional) engineering report, such as would be required of a paid consultant. They’re not quite there yet (B- to B+ range), but I have hopes that one of the students who has gotten 2 B+ grades will get up to A- by lab 3 or lab 4, and that a couple of others with a B and a B+ will be there by lab 4 or lab 5. I don’t have any students left in the class who got “REDO” on both the first two labs (drop deadline was last week), and there is only one student with one lab that got a “REDO” that hasn’t been redone.

          Because of FERPA and how Univ. of California interprets it, I can’t share the student work with my blog readers—at least, not without explicit individual permission for the specific work I want to share, so I can’t show you the current level. Suffice it to say that just about any faculty member in the country would be happy to get the reports that I regard as A- quality, even in a grad course. I don’t know whether anyone will get to A quality this quarter—it’s possible, but I’m not as hopeful of that as I am of seeing multiple A-s.

          Comment by gasstationwithoutpumps — 2013 January 30 @ 21:48 | Reply

          • Thanks. I’ve mostly avoided lab reports because of the likelihood that I would get “high-school chem-lab style proof that you successfully followed a cookbook procedure.” Any thoughts on the use of the passive voice? I’ve always found it stilted, and I don’t see the advantage.

            Comment by Mylène — 2013 January 31 @ 03:00

          • I strongly discourage passive voice, because students overuse it, thinking it is somehow more formal.

            Correct use of passive voice in technical writing is generally to invert a sentence to improve the flow. The old information⇒new information flow heuristic is a good one for determining what should come first in a sentence. Occasionally passive is used to hide agency (that is, to obscure who actually did something), but that is generally bad style in technical writing.

            Comment by gasstationwithoutpumps — 2013 January 31 @ 08:30

          • I didn’t know that about the correct use of passive voice. Count me as one of those people who was forced to write in passive voice and told that active voice was inappropriate for a formal report.

            Comment by Mylène — 2013 January 31 @ 12:11

  8. There are efforts like the Engineering is Elementary ( that, while aimed at younger children, are attempting to define what engineering thinking is for a wider audience.

    Comment by Mark Guzdial — 2013 February 5 @ 18:10 | Reply

    • I think it’s key to define how it is exactly that engineers should think. Those random thoughts in your post can apply to many different fields of study, and not just engineering. I believe those skills can be developed in a number of different fields, and frankly, some are born to be more analytical and detail-oriented than others.

      Thinking like an engineer is not much different from thinking like a scientist as the case for biomedical engineers.

      Comment by Petroleum Engineer — 2014 January 11 @ 09:16 | Reply

      • There are many times that scientists have to think like engineers and engineers have to think like scientists, but they are (I think) distinctly different modes. Part of the confusion comes from mislabeling some professions—for example, something like 90% of experimental physicists are really doing engineering, designing and debugging lab equipment. Only a relatively small number are coming up with questions to ask about physics—the rest are asking engineering questions: how do I build a machine to do that?

        The distinction is clearer in bioengineering, though the recent emphasis on “translational research” has been an attempt by funding agencies to turn scientists into engineers. The results have not been very successful—basic research has gotten less funding and novice engineers (who were once good scientists) have been favored over good engineers, so that both science and engineering research has suffered.

        Comment by gasstationwithoutpumps — 2014 January 11 @ 09:50 | Reply

  9. [...] find a link to Engineering is Elementary recommended by Mark Guzdial in response to the post “Teaching Engineering Thinking” at Gas Station Without Pumps.  The contexts are smaller (design an alarm circuit, design a [...]

    Pingback by K-12 Engineering: Engineering is Elementary « Shifting Phases — 2013 February 5 @ 19:05 | Reply

  10. [...] me because I’m trying to teach the bioengineering students in my circuits courses to “think like engineers“, but I had not thought of the problem in quite the way that Dr. Hanson put it.  My goal is [...]

    Pingback by Becoming engineers « Gas station without pumps — 2013 February 9 @ 20:23 | Reply

  11. […] On the first day of the design course, I had students fill out an intake survey listing what skills they brought to the class and what they wanted out of the class.  I also talked a bit about the difference between science and engineering and why I saw a need for teaching engineering thinking. […]

    Pingback by First day of freshman design seminar | Gas station without pumps — 2014 January 8 @ 10:28 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme Blog at


Get every new post delivered to your Inbox.

Join 250 other followers

%d bloggers like this: