Categories
Engineering Roles

Mulling over potential book chapters

All right, so if I’m to author a book about engineering careers (intended for high-schoolers and their non-engineer parents), I need some sort of rough outline to serve as a starting point. To that end I’m mulling over some potential chapters topics (all of which currently come to me in question form…):

  • What is engineering?
  • What do engineers do?
  • What aptitudes are found in engineers?
  • Which engineering sub-discipline should I choose?
  • Is engineering a good career choice?
  • What training do engineers require?
  • Will I need to be licensed to work as an engineer?
  • What earning power do engineers possess?
  • Are engineers happy?
  • What is the future of engineering?
  • How do I get into a good engineering school?
  • What are employers looking for in engineering candidates?
  • How do engineers think?
  • What are the downsides of an engineering career?
  • What are the social implications of being an engineer?
  • What will drive me crazy if I become an engineer?

There are a lot of existing references about engineering careers, but it turns out that few people have really investigated what engineers do in the workplace. Therefore, many descriptions of engineering responsibilities emphasize design and analysis, even though a small percentage of engineers participate in these activities on more than an occasional basis. (See “Are we accidentally misleading students about engineering practice?” [pdf] by Dr. James Trevelyan, 2011 Research in Engineering Education Symposium, Madrid.) I’d like to provide a more realistic view of engineering practice, and to emphasize the value of engineering problem solving in fields outside “traditional” engineering vocations.

Potential references:

  • Educating Engineers: A listing of engineering schools by state, as well as a description of various engineering career opportunities.
  • Discover Engineering: Site established by DiscoverE (formerly the National Engineers Week Foundation) “to sustain and grow a dynamic engineering profession through outreach, education, celebration, and volunteerism.”
  • A Career in Engineering: Description of an engineer’s professional responsibilities, written by the Wall Street Journal.
  • Engineering Careers: A long list of engineering sub-disciplines provided by Study.com.
  • Architecture and Engineering Occupations: Data on engineering employment and salaries provided by the U.S. Bureau of Labor Statistics.

Feel free to use the contact page to provide me with additional chapter topics and/or career planning resources!

Categories
Engineering Curriculum

Benefits of an abstract engineering education

My prior post was critical of the abstraction-based, mathematics-heavy, and computation-focused eduction served up to today’s engineering students. It has been my experience has been that the most successful engineers in industrial practice are very hands-on, with years of practical experience, and insights that have little to do with academic equations. That’s not to say that the academic abstractions are unimportant, for they provide the language of discussion. An intelligent conversation about, say, a motor drive system, requires participants to understand that additional motor horsepower is not necessarily needed to produce greater output torque. (An engineer friend recently shared with me his attempt to explain this to a non-engineer boss. In the end, the boss said, “This doesn’t make any sense to me, but if you say it’s so, it must be.”)

Despite possible shortcomings in the current methods of engineering education, today’s graduates continue to be hired, and paid well-above average salaries—so employers obviously benefit from bringing on students who survive the current curriculum. Whatever modifications I might advocate for improving engineering pedagogy, I would certainly hope not to abandon these beneficial characteristics of today’s engineering programs. So what does an engineer learn from dealing with high levels of abstraction?

  • Perseverance — It often takes hours, maybe even days, to work through a single homework assignment. One has to look at each problem statement and begin trying to match the available information with potential methods of solution. Often times, roadblocks in understanding are encountered. The instructional material needs to be re-read, and re-evaluated to build a more comprehensive understanding of the solution technique. If the solution is not already known (from prior semester homework files, or found online), then a student has to at least convince themself that their path of deduction and computation is logical and rational. Shortcuts in this process are rarely rewarded in the long run, and engineering students rarely make it past their sophomore year if they haven’t acquired a healthy dose of perseverance.
  • Emotional suppression — Solving math problems is not a matter of nuance, or persuasion. It doesn’t matter how mad you get, or how optimistic you may be. Either your solution works, or it doesn’t. A successful student learns to keep cranking away at a problem until the correct solution is found, regardless of their emotional state.
  • Delayed gratification — Not withstanding the time spent working individual problems, engineers have to spend several years working on fundamentals before they can begin to solve higher-order engineering problems. Want to study photography? Grab a camera and go take some pictures. Want to be a writer? Start a blog. Want to be a civil engineer? Then expect to take four semesters of prerequisite courses to get to the point where you can begin seriously talking about bridge construction. In fact, your four years in engineering school are just a warm-up for going into industry, where you have to learn how engineering is carried out in the real world.
  • Humility — Solving complex math problems leads one to be wary of false optimism. A dropped sign, a transposed notation, a forgotten property, a misunderstood application—all can lead to an incorrect solution, even though the methodology seems correct. This aspect of the engineering education has been well-stated by Vivek Haldar:

    To be a successful software engineer (or indeed, any engineer), one first needs to be utterly and completely broken by failure. One must be so humiliated by a complex system that they give up and realize that the only chance of moving forward comes from being a supplicant to the complexity, by approaching it with humility and caution, not with hubris. You have to listen to the system, coax it into behaving. Commanding it does not work.

  • Sub-problem identification — Getting the hang of breaking complex problems into solvable sub-problems is an important engineering skill. My understanding of how this could be accomplished came in the second half of my sophomore year. No longer did I have to look for an equation or method that solved an entire problem at once; I could break the problem into smaller parts and solve the sub-problems individually. This was my first inkling that I might actually be able to “think” like an engineer.

Any other benefits to a traditional engineering education that I’ve missed?

Categories
Engineering Roles

Engineering spectrum differences

In my prior post, I proposed that each engineering position requires a different level of abstraction. To a research engineer, almost everything is model-based, while the production engineer may be primarily focused on issues that are object-based. Although freshman and sophomore engineering students receive guidance as to the sub-discipline they should enter (electrical, mechanical, chemical, etc.), I’ve never seen any discussion about specializing in a particular level of abstraction. So I want to illustrate how skill sets vary according to one’s position along the engineering spectrum. The following abbreviations are used below: high abstraction (HA), moderate abstraction (MA), and low abstraction (LA).

Solution focus

HA: Primary focus is finding an optimal solution within a tightly controlled problem domain. Journal referees don’t want to read about yet another mediocre solution; they want to see mathematical, statistical, or experimental evidence that the proposed solution is in some manner better than previously discovered approaches. Only a single solution can be considered best.

MA: Central effort is placed in discovering a bounded solution. For instance, a bridge doesn’t have to be optimal in every respect, but it had better withstand the specified traffic loads. A bridge with too much strength is of far less concern than one with too little carrying capability. Any solution that meets the project constraints is potentially useable.

LA: Making sure that each component/batch/output is operating correctly often requires a rapid solution. If a manufacturing process is going out of tolerance, the first concern is getting product back within tolerance. Causes of the deviation can be examined later, or passed on for further study, but the key focus is on quickly finding a solution that works. For outputs of sufficient financial worth, almost any workable solution will be considered acceptable, at least on a temporary basis.

Solution domain

HA: Solutions are developed in the symbolic domain, where analytic tools of mathematics are most effective.

MA: Problems are solved in the spatial or schematic domains, where computer-aided-design (CAD) tools allow the consideration of multiple solution possibilities.

LA: Troubleshooting success is highly dependent upon prior exposure to similar problems, and thus the requisite skills are experiential in nature.

Social influence

HA: Symbolic solutions stand on their own, and require minimal social interaction to be presented and accepted.

MA: Gathering problem specifications, managing organizational expectations, and presenting solution proposals requires a moderate level of social interaction.

LA: Talents in motivating and managing others are quite valuable in bringing the right technical skills to bear on a problem, and in coordinating troubleshooting activities, especially in a high-pressure manufacturing environment.

Temporal effects

HA: Symbolic solutions do not care when a system is set into motion, as nature’s laws are assumed not to vary with the passage of time. Thus, problems of high abstraction accommodate everlasting solutions.

MA: Schematic solutions can remain valid over long periods of time. However, as types of components or methodologies change with time, moderate abstraction problems may need to be updated and improved.

LA: Corrective solutions may be specific to particular outputs, or a specific set of events acting on an output. Thus, actions associated with low abstraction problems are highly time dependent.

Summary

Individual engineers may have to move up and down the engineering spectrum over the course of a career, or a year, or even a single day. This post has attempted to point out that the skills needed to be a successful engineer necessarily vary with the abstraction level being utilized. In my next post, I’ll discuss why most engineering students are only exposed to high abstraction skills during their time in college.

Categories
Engineering Roles

What engineers have in common (part 3)

(Part 1 and part 2 of this series)

In my most recent post, I proposed the following definition (which I’ve slightly revised):

engineer: an individual who designs novel methods, devices, or systems that can be practically implemented to meet specified constraints, or analyzes existing methods, devices, or systems for their capacity to meet such constraints, while making judicious use of scientific models, mathematical analysis, and prior experience.

Engineers working in the physical realm (which I deem to be physineers) use theoretical models that capture how our universe behaves. Strong problem-solving and math skills are used to manipulate those models in a manner that leads to the creation of new physical embodiments.

I note here that working with “real world” objects, in and of itself, does not make one a physineer. A carpenter constructing wooden chairs operates in the physical realm, but we do not typically refer to such an individual as an engineer. If a chair leg were to break, a reasonable carpenter might attempt to replace the failed leg with a larger one, as simple observation of nature lends credence to the notion that bigger is often stronger. However, constructing chairs on a “trial-and-error” basis to find one that does not collapse, but does not waste material, is neither judicious, nor innovative, and is therefore not engineering. I interpret a “judicious” analysis to be a considered compromise among the various parameters influencing the work—including factors of size, weight, environment, material, maintenance, production, and cost. This often requires the development and manipulation of abstract models that permit a multitude of parameters to be evaluated. If such models have already been developed, and acquisition of a solution requires only that a predetermined sequence of computations be faithfully carried out, then the process is again not engineering, as it is not “novel.”

In contrast, a physineer might take the concept of a chair and create an abstract model that can be analyzed and manipulated. This abstraction might take the form of a free-body diagram, or a set of mathematical equations, or computer code. Important parameters could include the type of wood being used and the maximum weight that the chair is to support—as well as the equipment and methods available for fabricating a new leg. Most importantly, a physical engineer keeps in mind the eventual implementation of the modified design. There is little benefit to designing a replacement chair leg that uses an unavailable material (unobtanium), or has to be fabricated using an unreliable method, or incurs an unrealistic cost. By analyzing and modifying the model, a new design (or specific parameters to be incorporated into a design) can be established for a replacement chair leg. In this manner, physineers abstract reality, modify the abstraction, then implement the abstraction.

Key to my thinking is that engineers implement an abstraction. If there is no implementation, or at least a concern about implementation, then the effort is not engineering. However, implementations do not necessarily have to occur in the physical realm. Consider engineers who design database systems, or write system code. Instead of working in the physical realm, they may operate in an informational realm, as illustrated below. The STEM field assignments made in my previous post are still valid; however, the engineering concerns become distinctly different.

I propose that software engineers working in the informational realm be titled infoneers. To the extent they use models of informational behavior to design and implement new “methods, devices, or systems,” then they are as much engineers as physineers. They simply implement their work in a different realm, one that has its own set of entropic concerns. Rather than worrying about rust, or electrical noise, or structural fatigue, infoneers must deal with data integrity, network availability, and transactional states. So infoneers need less knowledge about physics than do physineers, but require a greater awareness of software and data theory. The function of infoneers, however, remains the same as other engineers–to implement an abstraction. If the work doesn’t lead to new code, or a new database, or a new application, then it’s not engineering.

I’ll even make the case, though it pains me to do so, that certain forms of “social engineering” can legitimately be considered engineering. If one uses models of human behavior to design a new means for altering social behavior, then that person seems to fall within my definition of an engineer. (Are marketers such individuals?) I’ll call engineers who work in the social realm to be socianeers. We can even start to match up fields of science with our new engineering descriptors. Physical scientists develop models that can be used by physineers, informational scientists create models used by infoneers, and social scientists advance models used by socianeers. However, each realm has distinct differences, and behavioral properties that are not easily mastered. Thus, crossing realms is difficult. Each has a different set of analytic tools, as well as different idioms to describe pertinent characteristics. However, though difficult, we’ll eventually see engineers starting to share approaches between realms.

Traditional engineering has already blurred the lines between physical realm sub-fields. We now have cross-discipline specialists in areas such as mechatronics, nanorobotics and bioprocessing. As technology advances, we will also begin to see cross-realm specializations. Perhaps an infostructural engineer will be concerned with how traffic and weather data is used to actively modify the structural properties of a bridge. Or a biovirtualization engineer will find ways to use time spent in a virtual environment to improve personal health. So I propose that we accept a wider definition of engineering, one that incorporates the possibility of realms beyond the traditional physical domain.

And what do all engineers have in common? They implement new things in a manner that finds an intelligent compromise between competing constraints in the realm of their expertise.

Of course, that’s just my opinion. What do you think?

Categories
Engineering Roles

The Marshmallow Challenge

Ever hear of the “Marshmallow Challenge?” Small teams of individuals are given the following assignment: use twenty sticks of uncooked spaghetti, one yard of masking tape, and one yard of string to construct the tallest possible free-standing structure that supports the weight of a marshmallow. Most people assume that since a marshmallow doesn’t weigh much, it shouldn’t significantly affect the support structure. Of course, even a small mass can produce structural failure when placed atop a long unsupported column.

So what profession does best at this task? According to Tom Wujec, a Fellow at software company Autodesk, the tallest structures are built by engineers and architects. They consistently outperform similar teams of lawyers, business school students, or corporate managers. This is not an unanticipated result, as we expect our engineers to know something about static structures. However, it is rather surprising to learn that youngsters, even kindergarten students, do far better than most adults—kids are simply not afraid to repeatedly fail as they search for an approach that works. (You may discover more about this learning exercise at MarshmallowChallenge.com).

Two insights come from this anecdotal report of group behavior. First, that engineers have been trained to think in a manner that is distinctly different from those in other professions. Second, that repeated rounds of prototyping and evaluation may be an effective means for dealing with the messy, unstructured, uncertain problems that engineers frequently encounter.

Categories
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!

Categories
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.