Tag: curriculum

Categories
Engineering Revision

Bait and switch in engineering education

It seems that many children have never considered the possibility of an engineering career. Well-meaning programs therefore attempt to nudge students toward engineering through exposure to engineering-like projects. These activities most often involve the manipulation of physical objects, such as constructing toothpick bridges, building LEGO models, preparing for an egg drop, or working with robots. Youngsters may alternatively be presented with a simulation of working with physical objects. As I’ve stated before, the role of an engineer is to implement new methods, devices, or systems. For an engineer working in the physical realm (a physineer), this means constructing something novel in the material world. So I have no problem with these introductory programs attempting to capture the imagination of students with physical-realm activities. My concern is the abrupt switch to purely abstract thinking that we impose on those who have expressed a desire to pursue an engineering career.

When students are sent off to college, they are immediately thrown into a series of math and physics courses that can seem wholly irrelevant to the activities that enticed them to enter the engineering curriculum. Although my undergrad experience took place more than thirty years ago, I remember struggling to rationalize how my knowledge of integration techniques was going to help me design production machinery. I had seen industrial equipment being built in a local machine shop, and I was fascinated with the banks of electrical relays that automated mechanical movement. (This was prior to the time that PLCs came into wide usage.) I wanted to learn how to design such machinery, and so I enrolled in my state’s largest engineering school, taking both mechanical and electrical engineering courses. Although I’m not sorry that I learned calculus along the way, I can safely state that knowing how to integrate by parts was never of benefit in my industrial career. In fact, over the two decades I spent in industry as a design engineer, I never found myself needing to solve an integral equation.

Given that several decades passed before I returned to my alma mater for a PhD, I presumed that the situation had improved. But my conversations with students currently in the middle of their undergraduate studies suggest that things are marginally better, at best. They are learning techniques of solution, but have little engineering insight. Children of my college buddies are now enrolled in various engineering schools around the country. When I talk with them I hear similar stories of being led blindly through math-heavy courses that appear to have little relevance to what they’ve heard at home about real-world engineering duties.

Is it any surprise that students are dropping out of this type of curriculum? Some claim the subject material is simply too hard. However, I think that Robert Talbert correctly identifies the problem:

Students aren’t put off by hard work. They are merely put off by any kind of work that doesn’t appear to be worth the effort.

I’d go further and say that engineering students can’t see the connection between the abstract and physical realms. This confusion is reflected in the following illustration, which has been floating around the internet. (Click on the image to see full size graphic.)

[The upper graphic seems to be from Valve’s Team Fortress 2. If someone knows which textbook the lower derivation is from, I’d be happy to give appropriate credit.]

The sad part is that this graphic is wrong. While research engineers may work in high-level abstractions, a great many engineering activities do not need such advanced mathematical acumen. In fact, many engineering problems are solved with spatial or experiential skills that require little mathematical prowess. So while I see nothing wrong in teaching abstract thinking, I think that engineering studies should advance from the physical realm toward the abstract realm, rather than the other way around. Otherwise, we’re promising to teach students one set of skills (to entice their enrollment), and delivering something else entirely. It strikes me that we’re teaching them how to be graduate students, rather than employable engineers. I suspect that this misalignment has real costs for students, employers, and the nation.

Categories
Engineering Roles

What do engineers have in common?

While I see many articles concerning new initiatives in STEM education, relatively little is said about the types of duties that engineers perform in the workplace. Any design process has to begin with certain constraints on the finished product, and it seems to me that an informed choice of curriculum and educational methods should begin with an understanding of the skills needed by newly graduated engineers. We live in a rapidly changing world, but are relying on an educational system that is rather dated. Simply doing more of what we’ve always done seems rather inefficient. It is also strikes me as unfair to students to make them endure an education process that is misaligned with their career interests. So I am curious if we can determine the overarching commonalities that exist in the career category we call “engineering.”

Operators of railroad trains, broadcasting equipment, boilers, and aircraft systems have long been given the title of  “engineer.” However, these duties are different from the math-intensive skills that are taught in most engineering classes. Further, just about any activity that involves planning or scheming is now described as “engineering.” I cringe each time I come across the term “social engineer” being used to describe someone who manipulates the emotions and trust of others. Alas, my discomfort with the nomenclature does little to remove it from the common vernacular. So let me be more specific in describing a particular set of engineering functions.  I’m going to identify those who graduate from traditional engineering programs (mechanical, electrical, chemical, nuclear, civil, etc.) as “physical” engineers, or physineers. Central to their skill set is a knowledge of how the physical world behaves.

A story that received a lot of attention at the beginning of last month was Facebook’s plan to open an engineering office in New York City. I have previously expressed some concern over software professionals being called “engineers.” As recently as last week, I was prepared to write a post to argue that the “engineer” moniker has been co-opted to the point of becoming meaningless. It’s not that I don’t appreciate the skills of these software experts, but rather that I believe they solve a different type of problem than do physineers. However, after giving it some thought, I’m of a less dogmatic mindset. Efforts of software engineers, financial engineers, and social engineers do, in fact, share some commonalities with those who work in traditional engineering fields. We just need better naming conventions to describe the duties that each group of engineers perform for society.

The whole naming issue is important because of the disconnect that exists between the skill sets that employers are asking for, that universities are providing, and that students are expecting to learn. A recent article on the Forbe’s website heralded the strong demand for engineering talent, but neglected to point out that most of the job openings are for software engineers. Think that becoming a computer hardware engineer is a closely related safe bet? Sorry, while the Bureau of Labor Statistics predicts that software engineering employment will grow at a mean rate of 2.1% per year, the forecast is that jobs for computer hardware engineers will grow at only one-fifth that rate. Additionally, the forecast is for 1.2 million software engineers in 2018, but only seventy-seven thousand computer hardware engineers. Employment opportunities will not be evenly distributed across the engineering terrain. We need to be far more specific in the skill sets we ask young engineers to attain. So I want to look more closely at what engineers (of all stripes) actually do, and how we might better distinguish between their various responsibilities and activities. I’ll proceed with this discussion in my next post.

Categories
Engineering Curriculum

Career, Teaming, and Entrepreneurial Methods

Well, now that the fall semester has started at Purdue, I’m going to make an effort to post more regularly. Of course, just one post a month would be more regular than my recent performance. 🙂 Anyhow, today’s e-mail brought a brochure for a course (IE 590 & ChE 597) titled, “Career, Teaming & Entrepreneurial Methods for Engineers.” It promises to teach engineers how to:

  • Be proactive in career development
  • Develop interpresonal and professional communications skills
  • Understand large technical project management
  • Develop an awareness of the technical marketplace and the supply of technology
  • Learn entrepreneurial methods

It sounds interesting. Why isn’t this type of class required for all engineering students?

I might be tempted to take it if I could afford more time away from my dissertation. However, I can’t graduate without defending, and I can’t defend without a dissertation. And it’s difficult to teach at a leading engineering school without a PhD. So more of my future blog entries may be more related to my research (and less devoted to engineering education in general). At least until I clear the hurdle of completing my final defense.

Categories
Instruction Methods

A Mother Lode of Engineering Education Information

Happened across Dr. Richard Felder’s website today. Wow! What a treasure trove of information. It’s going to take me a while to digest this information, but I’m thrilled to see that the research exists. You can view an hour-long presentation Dr. Felder recently made at Penn State University, titled “Engineering Education in Five Years (or sooner).” Too bad we can’t see his slides most of the time, but an interesting talk nonetheless. My take away quote: “The power of the interactive tutorial is huge.”

Thanks to Teaching College Math for leading me to Prof. Felder’s site!

Categories
Engineering Curriculum

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.

Categories
Engineering Curriculum

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.