Categories
Engineering Roles

Why is engineering so hard to explain?

As a young engineer, I had no doubt in my mind that engineers designed things, and fixed things, and analyzed things. I never thought for a moment about the difference between engineering and science… or the difference between engineering and anything else for that matter. Yet as I set about explaining the engineering profession to non-engineers (and young non-engineers at that), there grows a great mysteriousness about engineering duties.

Koen [1] notes that engineers are known by the products over which they toil:

Because the connection of the engineer with his completed design is so enduring and the connection with his use of method so fleeting, a person insists he is an engineer based on what he produces, irrespective of how he goes about it, instead of insisting that he is an engineer based on how he goes about it, irrespective of what he produces. In a similar fashion, the historian uses the existence of dams on the Nile, irrigation canals in various parts of the ancient world, gunpowder, and pottery to infer the existence of engineers and craftspersons in past civilizations. But behind each chemical, each road, each pot hides the common activity that brought it into being. It is to this unity of method that we must look to see the engineer in every man.

So while Koen would have us see each person as an engineer, Petroski [2] tells us that there are distinct differences between engineer and scientist:

Although there may be commonalities in principle and similarities in method, neither science nor engineering can completely subsume the other. This is not to say the self-declared or designated scientists cannot do engineering, or that engineers cannot do science, In fact, it may be precisely because they each can and do participate in each other’s defining activities that scientists and engineers—and hence science and engineering—are so commonly confused.

And perhaps most disheartening, is the assessment of Williams [3] that:

… the establishment of an autonomous engineering profession oriented toward ideals of broad social responsibility … has not happened and is not going to happen.”

At the very least, engineering is a “niche-y” profession. My experience has been that no two engineers carry out the same duties, even if they work for the same company. So my quest continues; I’ll keep reading, and attempting to sift out commonalities among the world’s multitude of engineering roles!

Footnotes

1. Koen, B. V. (2003). Discussion of the method: Conducting the engineer’s approach to problem solving (Vol. 198). New York: Oxford University Press, p 8.
2. Petroski, H. (2011). The essential engineer: Why science alone will not solve our global problems. Vintage Books USA, p 26.
3. Williams, R. (2002). Retooling: A historian confronts technological change. MIT Press, p 80.

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 Roles

A Quote from Freeman Dyson

Somewhere along the way, during the past six months or so, I saw a quote about engineers attributed to a 1979 book written by Freeman Dyson, titled Disturbing the Universe. As I am too frequently apt to do, I found a used copy listed on Amazon and had it shipped my direction. This particular book managed to escape the piles of books I am hoarding in my office, and found its way to my bedside stand. As a result, I have been working my way through it for the past week or so.

Dr. Dyson is perhaps best-known for showing that two competing descriptions of quantum electrodynamics were equivalent. In particular, he matched the diagrams of Richard Feynman with the mathematical methods of Julian Schwinger and Sin-Itiro Tomonaga. His description of how the solution came to him sounds like something from a Hollywood script:

For two weeks I had not thought about physics, and now it came bursting into my consciousness like an explosion. Feynman’s pictures and Schwinger’s equations began sorting themselves out in my head with a clarity they never had before. For the first time I was able put them all together. For an hour or two I arranged and rearranged the pieces. Then I knew that they all fitted. I had no pencil or paper, but everything was so clear I did not need to write it down.

I’ve had an insight or two in my time, but never anything quite this substantial. And I can’t tell you how many good ideas (or at least what seemed to be good ideas at the time) slipped away because I failed to immediately write them down. But it appears Dr. Dyson’s memory is a good deal sharper than mine. Alas!

Between 1957 and 1961, Dr. Dyson worked on a project to use nuclear pulse propulsion for space flight. During this interval, he worked with engineers in designing spaceships, aiming for “Saturn by 1970.” In describing this period of his career, he notes (on page 114) that:

I particularly enjoyed being immersed in the ethos of engineering, which is very different from the ethos of science. A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering.

It’s not yet clear to me where such a quote might fit into a book about engineering, but I love that final sentence: “There are no prima donnas in engineering.”

Categories
Engineering Roles

New Podcast with Chris Gammell

[Update: The podcast has a new home at The Engineering Commons!]

Chris Gammell, co-host of The Amp Hour podcast, kindly allowed me to join him in creating a podcast dedicated to engineering’s more philosophical issues. You can listen to our first session below:

[Update: You can download the mp3 file directly, if you prefer not using the SoundCloud widget above.]

In this episode we discuss jumping off into a new design effort. What do you do when you don’t know where to start?

  • We discuss the need for engineers to take a greater leadership role in society. (See the Forbes’ opinion piece: Engineers: Our Government Needs You. While we did not discuss this article, as it had not yet been published when we recorded the episode, it seems somewhat apropos.)
  • The “messy” nature of design is covered, and we laugh about the neat, linear nature of the engineering process, as portrayed in textbooks.
  • Jeff shows his advanced age by referencing an Opel GT, which was produced between 1968 and 1973, and featured a bump where the carburetor stuck up into the hood.
  • A TED talk by Tim Harford is cited as Jeff and Chris talk about having to work through design problems via trial-and-error.
  • A happiness curve for the design client is painted in words, with the associated moral that frequent communications are vital to a successful design effort.
  • Jeff addresses why pi is the “magic” multiplier for time and effort estimates.
  • A hot-selling book in the start-up field is Eric Ries’ tome, The Lean Start-Up. Projects are encouraged to try out a “minimal viable product,” or MVP, as quickly as possible.

Chris and I would be quite interested to learn of your reaction to the podcast, and to learn where you think we should take future episodes. Thanks for your input!

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

What engineers have in common (part 2)

(Part 1 of this series can be found here)

In my last post, I suggested the term physineer be used to describe engineers who deal with the physical realm. These are individuals employed in the traditional engineering fields, such as chemical, electrical, civil, and mechanical engineering. To see how the responsibilities of such engineers are similar to those employed in non-traditional engineering fields, say software or financial engineering, I want to take a closer look at what we consider to be “engineering” activities. In doing so, I’m going to wax philosophical for a bit—but only for a short while, I promise.

We live in a physical world. To survive in this realm we must eat sufficiently well, avoid facing extreme weather conditions without shelter, and protect ourselves from oncoming traffic. Thinking about how a mythical super-hero might catch a bullet in his or her teeth is a fairly harmless mental exercise, but attempting to replicate the feat in real life will lead (most likely) to a life-ending result. We cannot escape many of the consequences that result from our actions (and inactions) in this physical existence.

Despite our inability to escape the material realm, we humans have a natural proclivity for creating mental notions of how and why things work. These abstractions have no material embodiment; they exist only as a result of a particular pattern of brain waves. We can perceive a model to exist in our minds; but we are unable to separate it from our consciousness. I can explain to you the properties of my model, and suggest relevant analogies, but I cannot directly hand you my concept, nor can you hand me yours.

In contrast to our human traits, the physical world has no need for abstractions. (Okay, some of the quantum mechanics stuff is kind of freaky, so feel free to tell me that I’m wrong.) The apple that fell in front of Isaac Newton did not need to compute the gravitational force acting on it; it simply fell. Electrons passing through a wire do not know the wire’s resistance or the voltage drop across the wire; they simply jump from atom to atom. Force and voltage and resistance are human abstractions; models that allow us to comprehend how the world around us behaves. As we learn more about the universe, we update our models. I’m not aware of any evidence that the universe changes to accommodate our conception of how it should properly function.

So I propose a logical separation between the abstract and physical realms (with apologies to the true philosophers among you, who will accurately identify my lack of knowledge about metaphysical concepts such as Idealism and Platonic Realism.) This separation is illustrated in the figure above. The arrows represent our ability to move (mentally, not physically) between the two worlds. As mentioned above, we have a tendency to generate theories about how our universe operates. If our models (abstractions) are sufficiently accurate, then they can be used to “explain” physical phenomena. In some cases, they can potentially be used to predict events and interactions that have not yet been witnessed. Even more powerfully, our abstractions can be used to create new devices or methods that cause the physical world to behave in a manner that is more to our liking. (Think central air conditioning on a hot August afternoon in central Kansas, when the ever-present west wind has inexplicably died down for an entire week, and shimmering black tar bubbles have popped up along every inch of sealed crack in the dull, sun-baked asphalt.)

To further our discussion, I’ve added the names of certain disciplines to the diagram. These are the STEM subjects; science, technology, engineering, and mathematics. It seems to me that we can assign one of the STEM fields, in a somewhat meaningful manner, to each side of this figure. Associated with the upward arrow are scientists who observe the real world and try to explain its behavior through the creation of theoretical models. Their model development is guided by the rules of logic and analysis that mathematicians advance while working in the abstract realm, represented here by the upper box. In association with the downward arrow, traditional engineers (physineers) use models to assist in safely modifying physical behaviors, and in creating new physical embodiments. Finally, technologists utilize and operate mankind’s tools and creations while working in the physical realm, which is identified by the lower box.

As with all models, my diagram is an incomplete representation of reality (a notion better stated by Howard Skipper). One obvious flaw is that very few individuals employed in the STEM fields have the luxury (or curse, depending on your perspective) of limiting themselves to a single discipline. In addition to creating new methods and mechanisms, engineers must be able to develop new models, and should be adept in applied math. Scientists must, at times, design their own equipment and develop mathematical tools. Today’s mathematicians may interact with computer hardware or gather physical data, while technologists occasionally have to model physical phenomena or solve obtuse logic problems. But this diagram gives context to my proposed definition of an engineer:

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 use of models and mathematics.

Physineers clearly fit into my definition of an engineer. But since those engaged in software, financial or social engineering do not design objects that can be physically embodied, can they really be engineers? Up until a few weeks ago, I would have said, “no.” However, note that my definition says nothing about the resulting designs being limited to the material world. In my next post, I will discuss the activities of engineers working in alternate realms.

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 Roles

Building Sandcastles

As a life-long Midwesterner, I haven’t spent a lot of time on the beach. However, I managed to build enough sandcastles during my youth to know that hours of effort can quickly disappear underneath the waves of a rising tide. No matter how beautiful the structure, how perfect its lines and curves, it stands no chance against a powerful sea that seeks to level everything it can touch. If the sandcastle is to be admired for more than a few hours, it has to be rebuilt. Time and time again, one must construct the sculpture, fully aware that it will erode as high tide sweeps in. Of course, the joy of construction disappears after a few days. But the destructive nature of the tides is unrelenting, so one must build the sandcastle once more.

Although I’ve long since forgotten where I picked up this sandcastle metaphor, I often use it when thinking about the life cycle of engineering projects. It is deceptively easy to believe that the job is finished once a device, or system, or methodology has been designed. However, as soon as that design is released into the real world, it will begin to erode. Surfaces idealized as perfectly smooth by the designer acquire minute ripples during the machining process. Electronic signals pick up noise, hydraulic pumps leak, bearings seize, and chemical solutions degrade. As a result, maintenance is a large portion of the engineering workload. Many engineers spend their careers doing nothing but keeping industrial processes operating smoothly. And anyone responsible for maintaining a house built more than twenty-five years ago knows that there is a significant cost, both in time and currency, associated with keeping a once-pristine structure in proper working order.

Although nature can do significant damage to an engineered system, the most severe problems are often people-related. Managers forget the caveats placed on equipment specifications, and begin demanding unrealistic production rates. Operators forget rules about proper usage, and begin to utilize machinery in applications for which it was not intended. Engineers fail to ask enough questions when integrating equipment into larger systems. And so the erosion accelerates. Devices, systems, and methodologies, once so lovingly designed to serve a particular purpose, begin to break down as they are misused, misapplied, or misappropriated.

System failure is not always a bad thing, as it may lead to knowledge of how the scheme might be improved. But it is usually a unwanted outcome, and keeping a system running smoothly requires diligent observation. A supervision style known as Management By Wandering Around involves checking in with employees, in a casual and unstructured manner, and asking questions about how things are going—so as to discover how processes and procedures might be improved. This methodology emphasizes identification of unexpected complications, as it focuses on newly-arisen issues, and is not intended as a replacement for standard performance reports. In a similar manner, frequent inspections are required to keep engineered systems operating on a reliable basis.

Although failures can be reduced via analysis during the conceptual and design phases, the most difficult problems are usually unanticipated. Thus, one can never assume that a system is “done.” I regard as cruel any engineer who tosses a design “over the wall” and walks away without regard for others who must subsequently maintain system functionality. All physical processes have to be observed, analyzed, maintained, and tweaked to offset the unrelenting tendency of nature to maximize randomness. Steel will rust, capacitors will short circuit, and out-of-spec materials will find their way into the process.

Likewise, interpersonal understandings may have to be reconstructed on a regular basis. Managers may need to be reminded as to their original agreements about specified performance. (Keeping a contemporaneous notebook is quite useful in this regard.) Operators may require a bit of nudging to return to proper operating procedures—although this should be done with an open mind, as they may be ready and able to show why the procedures should be revised. Colleagues may benefit from a better understanding of how a prior-generation system was intended to operate. But none of this can happen if an engineer holes up in a cubicle, and refuses to interact with others. There has to be a willingness to walk the beach, just to see how the sandcastle is fairing.

When engineering students are asked to carry out design projects in a period of a few weeks, just getting their design to function properly is a sufficient challenge. However, during semester-long activities, such as a senior design project, young engineers need to be made aware of the multitude of forces that may cause their designs to decay. Where possible, designs should account for the eventualities of repair, maintenance, and disposal. These issues are certainly of less immediate importance when one is thrashing about, trying to get a new design to simply work. However, as a design is refined and improved, the life cycle of the system deserves serious consideration.

Engineering graduates should also understand that, during the course of their careers, they will likely run into financially-focused managers who will tell them to put off maintenance, or goal-driven managers who may ask them to run systems outside of specification. There are sometimes quite legitimate reasons for doing such things, and the political clout to countermand such decisions is frequently beyond the engineer’s reach. But they should attempt, to the best of their abilities, to reconstruct the agreements and understandings that constrained the original design work. In a perfect world, this should not have to be done. But it usually falls to an engineer to deal with the physical consequences that result from such managerial decisions. So engineers should learn early on that, sooner or later, someone will have to go out and rebuild the sandcastle.

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.