A Narrower Focus

As I enjoyed lunch with a friend today, he described a teenager that he has been counseling. The young man that my friend has been advising wants to be engineer. When asked why, the teen replied that he wants “to build things.” That’s certainly why I wanted to be an engineer. It’s also why I was so frustrated in my first two years of college. I didn’t understand what possible connection all of the math and physics I was “learning” had to do with making things. My father ran a machine shop, so I knew what making things looked like. It usually didn’t involve a lot of calculus. In fact, I worked in industry as an engineer for twenty years without ever having to solve a single integral.

This doesn’t mean that I didn’t need to understand math and physics. On many occasions I approximated an integral using Riemann sums, because I understood the integration concept. However, the connection between my engineering studies and the shop floor certainly escaped me for my first couple of years in school. I know many talented young people who got frustrated with engineering and quit because they couldn’t see the relevance of the engineering curriculum. Their youthful passions “to build things” were quashed for a lack of clear and direct communication about what engineers do and how they complete their assigned duties.

As I think about the future of engineering education, it’s easy to get caught up in interesting conversations about college costs, classroom technologies, and alternative certification. However, the problem I need to focus on is that of curriculum relevance. What does an engineer need to know in order to go “make things?” How do you make that knowledge relevant to an eighteen year old student? What are the key points that every engineer should remember and understand a decade after graduation? All in all, I need to narrow my focus and concentrate on these issues.

Oh yeah, it wouldn’t hurt to get my dissertation finished, either.

Posted in Engineering Curriculum | Tagged , | Comments closed

Teaching Students to Learn in 3 Easy Steps

This past week I had the opportunity to attend an excellent workshop presented by Jeffrey Karpicke, who heads up the Memory and Cognition Lab at Purdue University. He makes the case that students don’t know how to study effectively. As a result, they spend hours and hours “laboring in vain”—performing tasks that produce absolutely no learning. This is understandable, he says, as the only guideline that most college students are given is that they should spend 2 to 3 hours “studying” for every hour they spend in class. Without additional guidance, they tend to confuse comprehension with actual learning.

What constitutes studying in the minds of college students? More than 80% of the students that Dr. Karpicke and his colleagues surveyed listed “rereading notes or textbook” as a study method, and more than half identified it as their preferred strategy (see Karpicke, Butler & Roediger, Memory, 2009). Unfortunately, rereading has absolutely no benefit; time spent rereading material is wasted (see Callender & McDaniel, Contemporary Ed Psych, 2009). So students are losing precious time on ineffective study methods. Dr. Karpicke tells his students that they can substantially improve their learning by spending 45 minutes each week performing three easy steps:

Step 1: Collect and Organize — Encourage students to organize their grasp on a subject by creating their own outlines or self-study guides. This is something I have always done in my studies, but only 24% of students surveyed by Dr. Karpicke carry out this process.

Step 2: Assess Comprehension — Students often confuse familiarity with comprehension. To get beyond this, students should try explaining concepts in the absence of notes or textbooks. When presented with central topics or keywords, they should examine what comes to mind. If they are unable to produce an accurate response, or are unsure of an answer, then this is an area where they need to “study.” This step is carried out by only 13% of the students surveyed by Dr. Karpicke.

Step 3: Practice Retrieval — Long term learning requires more than comprehension; repeated retrievals of the material are required to ensure that the information is not forgotten. Have students pull out a blank sheet of paper and write down everything they can remember about the topic. Encourage students to use flash cards. Knowledge retrieval is often seen as “neutral,” a process that does not modify or alter the learning process. But Dr. Karpicke claims that the act of retrieval itself produces learning. (see Roediger & Karpicke, Psychological Science, 2006) What percentage of students carry out self-testing? Less than 11%.

Most scary is that students who utilize rereading as a study strategy are over-confident about their learning, while those that practice active retrieval are under-confident. Making a rough estimate from the graphs that Dr. Karpicke displayed, it appeared that rereaders are about 20% more confident in their “judgment of learning” than are self-testers, but perform about 35% worse when tested. Thus, it may be quite useful to discuss potential test questions during lectures, so that students begin to assess their comprehension, and have appropriate lines of thought for self-testing. One of the workshop participants stated that he has students submit potential test questions as part of their homework; this forces them into the beginning stages of self-assessment.

How much do we really remember from our college days? Some big concepts, for sure, but many of the small details are quickly lost. For a humorous look at this topic, watch Father Guido Sarducci’s Five Minute University.

 

Posted in Instruction Methods | Tagged , | Comments closed

Lessons Lost to Time

Since I live more than an hour’s drive off of campus, most of my research takes place from my spare bedroom. Internet access is a wonderful thing, as I can search through vast libraries of knowledge without leaving my computer. One downside to this comfort, however, is that most of the databases I use on a regular basis do not house articles published before about 1990. In most cases, any journal issued before then has to be tracked down at the library. Of course, for me, that’s not a simple walk across campus.

My adviser noted one day that the situation isn’t much different for the grad students who live closer to the university. After commenting that nobody wants to spend time digging through the library stacks to pull out old articles, he said, “We’re going to spend the next twenty years rediscovering what was published forty years ago.”

Posted in Grad Student Life | Tagged , | Comments closed

Adding to the Curriculum

While trying to get more informed on how engineering education can be improved, I thought I’d post my “newbie” perspective on what subject material needs to be added to the core engineering curriculum. As illustrated above, there are at least six areas that I think deserve greater attention. These are, in no particular order:

  • Software Skills: As I mentioned in Programming the Physical World, I think that software skills are going to become exponentially more important in coming years. I’m not talking about knowing a particular language syntax, per se, but rather an awareness of issues such as code storage (revision control), quality assurance (unit testing), and complexity reduction (refactoring). It’s far too easy to create software that gets the job done, but leaves gaping holes with regard to access, usability, and security. Just look at the constant stream of code updates from big players like Microsoft, Apple, and Adobe—these companies have access to world-class programmers, yet there remains an unending flow of corrections to fix previously undetected errors. Just this week, Microsoft admitted to a security bug that’s been in their code for 17 years! As we start programming the physical world, it won’t just be bits and bytes that are compromised. It could conceivably be bridges and electrical stations and chemical plants that are compromised as the result of poor programming practices. As with so many things related to engineering, a small mistake can lead to disastrous results. It seems to me that an instructional program like Software Carpentry would go far in helping engineers improve their software skills.
  • Individual and Group Behavior: We train engineers to be great problem solvers, yet much of the difficulty in implementing solutions is not technical, but rather social. Further, we want engineers to operate devoid of emotion, and to think in a purely rational manner. Yet a quick glance at popular books like Predictably Irrational and Sway: The Irresistible Pull of Irrational Behavior indicates that most people operate in anything but a rational manner.  At the very least engineers should be aware of:
    1. Their own limitations in perceiving and evaluating the world around them.
    2. Human tendencies to respond in certain ways to external inputs; for example, our innate tendency to want to reciprocate favors, to be part of the majority, to be consistent in our actions, etc.
    3. Methods used by marketers and politicians to sway both personal and group decision-making.

    If engineers are going to be effective in advising society about our increasingly complex world, they need to be aware of human tendencies in evaluating information, and in responding to requests for action. I’d like to see a semester-long program like Software Carpentry address these issues. Primary texts for this class would be Influence by Robert Cialdini, and Yes!, 50 Scientifically Proven Ways to Be Persuasive by Noah Goldstein, Steve Martin, and Robert Cialdini. A text on negotiation skills might also be appropriate here.

  • Technical Communications: If the preceding class on human behavior provides the strategy for effectively communicating an engineering perspective, then this class would be focused on the technique of delivering a targeted message. Engineers need to have a sense of how non-engineering audiences process information if they are going to counter the emotional appeal of most marketing campaigns. An investigation of information graphics would include texts ranging from Tufte’s classic book, The Visual Display of Quantitative Information, to the more casual Back of the Napkin. The Challenger Incident could serve as a case study in the importance of clearly deliniating the important engineering issues at hand.

    Methods for presenting a clear, concise message would be covered, referencing texts such as Presentation Zen and slide:ology. Also included would be a discussion of presentation styles such as the Lessig and Takahashi methods, as well as the Pecha Chua and Ignite formats. An introduction to LaTeX may be appropriate as well, as few things are uglier than presentation slides showing equations that have been typeset using Microsoft products (IMHO).

  • Risk Management: It is rare in most industrial settings to find individuals who can keep up with the mathematical skills of a fresh engineering graduate. So when an engineer is asked to make a calculation, the boss rarely wants to know how the calculation is performed. Rather, the boss wants to know if a particular product or process will operate in a desired manner. However, given the variability in all materials and methods, there is never an exact answer to such a question.

    For some engineering problems, such as elevator construction, there will be a safety factor that is specified by code. However, no particular safety factor is given for most industrial tasks; an engineer must determine the appropriate safety factor for each situation. To do so effectively, an engineer must be cognizant of the risks that are inherent with his or her assumptions, and know how to convey the risk of those assumptions to others, who will likely possess less technical knowledge. This is especially critical given that all of us usually make poor estimates of inherent risk. It appears that Virginia University’s Center for Risk Management of Engineering Systems is attempting to address some of these issues.

    Update: A possible text for this material is Judgment under Uncertainty: Heuristics and Biases. Referenced in this post by John Cook.

  • Physical Problem Solving: Engineering problems would take forever to solve if each engineer had to develop their own theory of calculus. Yet we leave engineers to come up with new designs without giving them any hint as to how the work of prior generations could help them solve their problems. If the engineer doesn’t stumble upon the connection to prior work by happenstance, then each new design effort is simply an educated guess.

    Inventor Genrich Altshuller and his colleagues studied the trends found in Russian patent filings starting in 1946. They developed a theory known as TRIZ, which translates from Russian as an acronym for “the theory of solving inventor’s problems.” The TRIZ methodology offers users a means for examining “new” problems in terms of existing solutions, thus often leading to quicker results. Although much of the TRIZ theory has been extended by private firms that keep their methods close to the vest, there do exist some open-source resources for learning this approach. There are also numerous books on this subject, including one by TRIZ developer Genrich Altshuller himself. Instruction in the TRIZ method could be enormously beneficial in improving the effectiveness of tomorrow’s engineers.

  • Design Thinking: If the prior class defines how to produce a technical solution, this topic seeks to identify how to successfully implement a human solution. There is usually a large disparity between what people say they want or need, and what they actually use, do, or buy. Thus design thinking, in essence, is a focus on identifying human needs. As noted in a recent post by Stanford professor Bob Sutton, design thinking was developed by engineers. It is now being incorporated into other areas of study, including medical schools and MBA programs. However, many engineering schools fail to introduce their students to even the basics of design thinking. In addition to instructional material available from Stanford’s d.school website, there a lot of information available from the website of design leader IDEO. Perhaps books like The Art of Innovation and Change by Design could serve as reference texts.

So what is going to be thrown out of the core engineering curriculum to permit these courses to be taught? My current thought is that there must be a way to more quickly bring students up-to-speed. Perhaps the “lecture, study, homework, test” cycle of traditional education can be improved upon. If so, I bet the solution will rely heavily on the six skills areas outlined above.

Posted in Engineering Curriculum | Tagged , , , , | Comments closed

Just a Newbie

Despite the fact that I’ve not posted anything in over a week, it’s not that I haven’t been thinking about engineering education. Over the past two weeks I’ve read a lot about the problems that higher education will face in the coming years. There are those who think academia will collapse due to lower-cost alternatives, poor educational results, or structural disaggregation. And if the universities don’t do it to themselves, state funding for public institutions may disappear as the states go broke due to the current economic crisis.

I’m just starting to get a faint grasp on the issue at hand. So I feel pretty useless right now; I don’t have anything very intelligent to say about anything. However, I still think that engineering concepts can be conveyed to students more quickly and more efficiently. I’m happy to remain a newbie for now. I’ll keep reading and studying and thinking—and I’ll keep reporting on what I find along the way to a more informed opinion.

Posted in Engineering Revision | Comments closed

Engineering Role Research

In scanning the internet for information on engineering roles, I stumbled across an the web page of James Trevelyan, a professor at the University of Western Australia. He is leading research into Engineering Learning and Practice. An interesting eleven-minute introduction from 2008 can be viewed online. It appears that Dr. Trevelyan is of the opinion that universities teach relatively few of the skills required in engineering practice.

A recorded web conference conducted in conjunction with the University of Wisconsin indicates that studies of engineering practice here in the United States are also being conducted. A quick sampling of this conference provided several insights, one of which is that incoming engineering students are unaware of their future duties; nobody wants to think that they will be responsible for production or maintenance—they mostly anticipate being designers and researchers. There is a lot of information is available on Prof. Trevelyan’s site; it will take me a while to try and digest it all. Better too much data than too little!

Posted in Engineering Roles | Tagged , | Comments closed

Sorting Out the Lines of Thought

It is my hope that, by making frequent blog entries, I will slowly sort out the tangle of thoughts that go through my head each day. These ideas and notions are often related to the engineering profession or engineering curriculum—and they all seem tangentially related to one another in some way as they pass through my consciousness. Without stopping to write them down, however, all I retain is an emotional agitation that comes from knowing that things are changing, but not being sure what to do about it. It is somewhat akin, I must confess, to the way that I felt about my stock investments throughout most of last spring.

So, as a first pass, I see these issues as needing resolution to put my tiny brain at ease:

Role: Are engineers to continue as problem solvers, or should they (could they?) become advisers to society? In a Talk of the Nation interview on NPR, former marine biologist Randy Olson talks about why scientists need to involved in presenting their findings to the general public, and how they might do so effectively. It seems to me that as the world becomes more complex, we need engineers to speak up about the inevitable compromises that are part of any sufficiently robust system. The concept of relying on facts, rather than anecdotes, is only now starting to get due attention in management circles. Courtesy of Stanford professors Bob Sutton and Jeffrey Pfeffer, the notion of evidence-based management reached the readers of the Harvard Business Review in 2006. If not evidence, on just what have managers been basing their decisions up to now? Could engineers really do any better, or are they so lacking in charisma and social skills that they could barely stay afloat in the choppy waters of corporate politics?

Skills: Are the skills that students learn in college in any way related to the skills they need to be productive in society? It seems to me that engineering curriculum is too often subject to the tyranny of technique. Yes, students can calculate the maximum stress in a beam, but do they know what to do with the number they generate? They may be able to produce a Bode plot for a feedback system, but can they use that information to reduce system error? It is undoubtedly easier to teach and grade technique, but is this ultimately a disservice to students, and to society? Further, a majority of the engineers that I graduated with become project engineers, rather than designers or researchers. Would their classroom time not have been better spent learning more about project management, and less about the intricacies of partial differential equations? This is not to say that we could ever abandon mathematical rigor in the engineering sciences. However, with college costs climbing without bound, perhaps a more judicial use of students’ time and money is prudent; not every engineering student want to pursue an academic career. For those who want to proceed to grad school, the current arrangement may be fine. However, are the remaining students receiving an education that will allow them to acheive rapid proficiency throughout their working careers?

Education: Based on the roles and skills needed by engineers, it is possible to start addressing the education of engineering students. This topic is vast, and I might start by breaking it down into four subheadings:

  • Topics: What skills should we be teaching? More software programming? More interpersonal skills? More hardcore engineering?
  • Methods: By what method should we present these topics? Screencasts? Online lectures? One-on-one tutoring?
  • Style: How might the material be best presented to allow students to quickly comprehend key concepts?
  • Structure: What is the structure by which this education is best delivered? Are universities still the right venue for delivering an engineering education? Will new organizations, either ad-hoc or private enterprise, sprout up to deliver an education at a lower cost, and in less time?

I’ll try to work through these issues in future posts. If blogging fails to help me sort out these thoughts, then perhaps the “Preparing Future Faculty” program I enrolled in today will get me moving down the right path. By completing the course I am supposed to be able to:

  • Explore and reflect on my assumptions about academic roles, positions, practices, missions, and institutions.
  • Construct an institutional profile and relate my career goals and faculty skill sets with institutional missions and departmental goals.
  • Construct a career strategic plan for enhancing and maintaining faculty skill sets and competencies.
  • Develop a portfolio including curriculum vita, cover letter, research statement, and teaching philosophy.

Sounds like a good start to me!

Posted in Engineering Revision | Tagged , , , , | Comments closed

Instructional Training

When I returned to school more than two decades after getting my master’s degree in mechanical engineering, it was with the intent of teaching at the university level. I had previously taught engineering technology classes, early in my career, at one of Purdue’s extension campuses, and I enjoyed the experience. But I had studied to be an practicing engineer, and I left academia to begin my industrial career soon after. Following twenty years in the private sector, though, I felt that I had accumulated enough useful insights to be of benefit to young engineering students. Teaching at the university level requires a doctorate, however; so, at an age that was twice the norm, I began work on my PhD.

As I wrap up my degree (hopefully defending yet this semester), I must admit to having nagging doubts about an academic career. Its not so much the hard work associated with beginning at the bottom of the academic ladder, or the drudgery of grading tests and homework, or even the murky waters of academic politics. Rather, as I will detail in future posts, I think that universities face some serious challenges in the near future. Further, I believe that much of the coming revolution in education will be driven by private enterprise, and not academic institutions. I would much prefer leading the change, rather than resisting it.

Granted, this may be making some unfair assumptions about today’s universities. I know that many schools are working hard to modernize their curriculum and instructional methods. And my experiences in higher education may not be typical. So I’ve decided to give the academic path one final look during the course of this semester. I’m signing up for the “Preparing Future Faculty” course being offered this semester. Perhaps, given further additional exposure to the academic system, I will feel more comfortable about making positive changes from within a university position. If not, well then I can say I gave it an honest evaluation.

In addition to the PFF course, I plan on attending a series of workshops given by Purdue’s Center for Instructional Excellence (CIE). I’m told by friends who have previously attended these seminars that the material is more suited for the humanities than for engineering coursework. However, I’ll try to report on the ideas and methods that seem the most appropriate for the engineering classroom.

Posted in Engineering Revision | Tagged , , | Comments closed

Programming the Physical World

One of the first articles that inspired me to start this blog was an article by Greg Wilson stating

Instead of software design becoming more like “real” engineering, we’re about to see the latter become more like the former.

To see what he considers “real” engineering, we need only reference his post of two weeks later, Without the Hot Air, in which he notes that

…almost none of what we call “software engineering” is actually engineering. I’ve worked with enough civil, mechanical, and electrical engineers to know how important back-of-the-envelope reality checks are to their disciplines. Other than figuring out how many servers you need to meet a service level agreement, I don’t know if such reality checks are even possible for software construction.

Having identified a fundamental difference between software and engineering design, Mr. Wilson correctly predicts (IMHO) that “real” engineers will inevitably become more like software designers in the future, rather than visa-versa. This will occur, he surmises, because new manufacturing methods, such as rapid prototyping and desktop manufacturing, can be manipulated via easily modified code. In comparison, traditional manufacturing methods require slow and costly changes to molds and tooling. As a result, future engineers looking to optimize mechanisms and processes (beyond the level possible with mass production) will increasingly turn to these newer technologies. In turn, they will need much stronger software skills, and will therefore turn to their software-centric colleagues for advice.

Five years from now, I predict that software designers who’ve been griping about never being given enough time or enough respect will be on the lecture circuit teaching their ID and IE counterparts how to be agile, live with chaos, and cope with design cycles measured in hours rather than months.

From what I’ve seen as a (rather elderly) grad student over the past five years, the programming skills of many engineering students are sorely lacking. I’d venture to say that the majority of mechanical engineering grad students with whom I’ve worked have no idea of how to use version control, or how to write a unit test. I am acutely aware of how easily a small programming error can alter the results of my research, and I suspect that a great many published articles unknowingly rely on faulty code.

Since I am studying in the area of feedback control, much of my programming work is in Matlab. Not a difficult language, and a heck of a lot easier to get started with than Java or C++. Still, while grading homework for an introductory grad-level controls class, I’ve come across some truly awful programming practices. This is not the fault of my fellow students. Engineering is not an easy discipline, and there never seems to be enough time to adequately cover the existing curriculum. As a result, engineering students are often never been exposed to the finer points of software construction. In many cases, programming skills are assumed but never taught—students are simply given a handout or two and expected to come up to speed on their own.

It would appear that Mr. Wilson has already recognized many of these same problems. He champions the Software Carpentry program, an effort to improve the software literacy of scientists and engineers. It is based on Python, rather than Matlab, but could probably be ported to a new language with few technical difficulties. (Finding the time to prepare for twenty-five hours of instruction is likely to be a much larger problem.) In any case, courses like this need to be a part of every engineering curriculum. Much of the physical world is going to be programmed, rather than fabricated, in the coming years.

Posted in Engineering Revision | Tagged , , | Comments closed

Welcome to Engineering Revision

More than a decade ago I started a blog titled ZopeNewbies, utilizing (then hard-to-come-by) web space kindly donated by blogging pioneer Dave Winer. It was my intention at the time to assist those interested in the Zope web framework as I investigated the software myself. Although I wrote a few well-received tutorials along the way, I quickly discovered that the hours spent summarizing Zope news devoured any and all time I had available for learning the software. And after almost two years of blogging, I decided the two to three hours I was spending on the ZopeNewbies site each morning could be put to better use. So I placed the site in the capable hands of Luke Tymowski, and moved on to other things. Since then I’ve had a great appreciation for bloggers who can generate insightful material on a regular basis — but I’ve had no desire to return to blogging myself. Until now.

Although I don’t consider myself a hardcore geek, I do love technology. I am fascinated by how things work, and I enjoy thinking about how devices and processes might better function. To that end, I’ve gone just about as far as I can go in trying to train myself to be an effective engineer. At the age of (almost) fifty, I am finishing up a mechanical engineering doctorate at Purdue University. A licensed professional engineer since 1986, I’ve worked for small machine shops, medium-sized companies, and large mega-corporations. And for the past fifteen years I’ve run my own consulting business. Throughout my career, I’ve been surprised by the apparent disconnect between what is taught in engineering classes, and what passes for engineering in industry. While I’ve seen encouraging steps taken to close that gap, I don’t believe that change is coming fast enough. So this blog is going to talk about how the responsibilities, skills, and training of engineers will necessarily change as we plunge deeper into the twenty-first century.

As I hope to point out in future posts, the role of engineers must evolve as technology marches forward at an ever increasing rate. It is unlikely that a larger percentage of the population will ever want to study engineering, but modern technology is rapidly allowing more and more people to leverage the power of applied science. As both society and the infrastructure upon which it relies become more complex, engineers must transform from isolated problem-solvers to socially adept guides who can direct the technical endeavors of others. While still in my twenties, I spent a couple of years teaching engineering technology classes; I know that it can be challenging to motivate students to absorb difficult mathematical concepts. Trying to interest them in the psychology of group dynamics may be near impossible. But the need for a new style of engineer has never been greater, and the tools available for revolutionizing engineering instruction have never been more readily available.

So welcome to Engineering Revision. If you have an opinion on this topic, please feel free to leave a comment.

Posted in Engineering Revision | Tagged , , , , | Comments closed