Engineering Revision

Rebooting Engineering Revision

Its been exactly three years since my last post on this blog, Engineering Revision. During that interval I finished up my PhD degree, and have spent a considerable amount of time sharing engineering knowledge in the college classroom. Teaching is a challenge that I truly enjoy, and I hope to continue improving my ability to share critical concepts in a concise and meaningful manner.

The podcast I started three years ago with Chris Gammell, The Engineering Commons, continues to chug along as well, although Chris is no longer co-hosting the show. However, I have three new co-hosts with whom to discuss the day-to-day joys and tribulations of an engineering career. It’s a thrill to share interesting conversations about the engineering profession with Adam, Brian, and Carmen, as well as our frequent guest experts.

My purpose in rebooting this blog is to start sorting out ideas for a book about the engineering profession. In particular, I want to provide practical advice for high school students (and their parents) who are considering engineering careers. I’m increasingly fascinated by the small incidents of happenstance that lead people into successful engineering careers, as well as the inability of most engineers to explain exactly how they add value to their respective organizations. I’m also concerned that the current emphasis on increasing the number STEM graduates is going to result in a boatload of unemployed engineers over the next five years. I’ll have to look it up, but I think the statistics are that 50% of engineering graduates are no longer working in engineering (or never worked in engineering) just five years after graduation. Will this only get worse with an increasing number of engineers in the workplace? And is an engineering degree to remain a job ticket, or will it become more of a philosophical degree; a lens through which to view and interpret the world?

So for a while, I want to make comments about books and articles that I’m reading (or more accurately, that I’ve been intending to read). I’ve accumulated a sizable collection of source material over the past three years; some of which I’ve actually read multiple times, but much that I have yet to crack open. As I’ve not yet found anyone summarizing such content, or attempting to pull these ideas together in a single location, I’m going to give it a shot.

My apologies if you’re shocked at seeing a new post from this site suddenly pop up in your feed reader after all this time. I’ll try to be more frequent in my future updates!

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.

Engineering Revision

Refocusing Engineering Revision

When I started this blog two years ago, I was convinced there had to be a better way for students to learn engineering concepts. Having professors talk monotonously at an overhead screen while showing page after page of convoluted equations offers, at best, a modicum of useful insight into how one would go about solving real-world engineering problems. Having spent twenty years in industry before returning to school for my doctorate, I’ve got a fair idea as to what skills engineers use outside of the university. And, Lord knows, as I conclude my seventh year in a PhD program, I’ve sat through my share of incredibly dry lectures.

Back in 2010, I thought that better presentations, maybe Khan Academy style, would provide a simple solution. I kept pointing out to my (very patient) friends the ridiculousness of having half the calculus students in the country learning from below-average instructors. Well-produced videos seemed to me a means for addressing this problem. But it appears that mere window dressing is not what learners need. There is evidence that active learning, social engagement and spaced repetition are critical components in effective learning. The relative important of these factors, however, and the precise role they play in enhancing the education of engineering students is as yet unknown (at least to me). For this reason, I’ve not written a lot of posts in the past year and a half; I’ve simply not been able to intelligently address the issue of how engineers can best be taught.

However, a recent stream of news articles related to STEM education seems to indicate that a lot of others think they know how the job should be done. To me, these approaches seem intent on doing more of what we’ve always done; and I must admit to being apprehensive of cranking up the rate at which engineers are being produced, without a considered modification of instructional methods or curriculum focus. Thus, my intent is to refocus this blog on asking questions about what engineers do, how they think, and what duties they perform. In doing so, it is my hope that answers about engineering education will arise. If I can’t offer solutions, then perhaps I can perform a useful service by asking the right questions.

Engineering Revision

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.

Engineering Revision

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!

Engineering Revision

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.

Engineering Revision

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.

Engineering Revision

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.