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

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

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 Curriculum

Along the engineering spectrum

My prior series of posts (part 1, part 2, and part 3) proposed that a common characteristic of all engineering activity was the use of abstract models to search a solution space before implementing a new method, device, or system. Engineers fill the gap between science, which seeks to generate accurate models, and manufacturing, which aims to accurately replicate a given embodiment. Some engineers are more “hands-on” than others, so we have a spectrum of engineering activities that range from mostly abstract to mostly physical. It is this spectrum of engineering skills that I want to discuss. (Since the traditional engineering fields focus on the physical realm, I’m addressing that particular domain. However, the same spectrum issues will exist for engineers operating in alternate realms. See my prior posts for a discussion of engineering realms.)

There are many different kinds of engineers, but I’m going to constrain the conversation by dealing with just three types of engineering professionals: research, design, and production engineers.

High Abstraction

Research engineers operate at a high level of abstraction. This necessitates that they be part scientist, and part applied mathematician, as well as an engineer with knowledge of the physical world. When striving to create models that more accurately represent physical world behavior, they take on the role of scientist. In creating such models, they tend to look for general behaviors that apply to all systems, or sets of systems, rather than the idiosyncratic behavior of individual implementations.

Researcher engineers do not normally need to extend the bounds of mathematics (although some do), but must have very strong mathematical skills to create and manipulate abstract models of physical behavior. A researcher in chemical engineering might, for instance, develop a new means for causing to plastics to decay in a ecological manner. The primary focus would likely be on a model that explains the decay mechanism, rather than how the method might someday be introduced into production.

Moderate Abstraction

Design engineers bridge the gap between high and low levels of abstraction. While they are free to consider a broad range of implementation methods, they must eventually deliver a design that will produce a desired result. They use existing models to examine possible solutions, rather than launching new experimental studies.

Rather than seeking a theoretically optimal result, as the researcher might, the design engineer must settle for a practical compromise between competing interests. Experience plays heavily into knowing how much weight to give to each design constraint. A thorough knowledge of manufacturing methods is also crucial to the design engineer, as the end design must allow for robust performance, whether for a single prototype, or for a product that will be reproduced millions of times.

Low Abstraction

A production engineer worries about keeping the manufacturing line operating in a smooth fashion. There is no need to worry about the theory of how the end product operates, or what it is going to look like–those decisions have been made upstream by the research and design engineers. Instead, the production engineer is mostly a troubleshooter, waiting for a production snag to arise, then resolving the issue in a manner that keep the problem from reoccurring.

While the research and design engineers can worry about more global issues, the production engineer has to be concerned about individual elements. Specific batches, machines, and output units each give indications as to the state of the manufacturing process. Coordination of corrective efforts, mixed in with the natural stress of high-volume manufacturing, requires that the production engineer be a strong communicator.

Summary

Just as there are differences between the various realms of engineering, each engineering job requires its own level of abstraction. In my next post, I’ll write more about the skill sets needed along the engineering spectrum, and their impact on engineering education.

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?