Engineers bring economic benefit to their employers. In this episode, we talk with Professor James Trevelyan about the value of engineers in the workplace.
While the word “value” has many meanings, Chris has an immediate desire to interpret it in terms of dollars and cents.
Engineers obviously provide some economic value, as employers continue handing out paychecks to their engineers.
Jeff has run across the Big Beacon Manifesto, which describes an idealized goal for engineering education.
Relatively few studies of engineering practice have been conducted, perhaps because such investigations require a merging of anthropological and technical skills.
Unlike medical students, most engineering students don’t get a chance to work “in the field” before receiving their degrees.
Tacit knowledge has been relegated to second-class status since the times of the Greek philosophers, with messy realities being considered less “pure” than Platonic forms embodied by explicit knowledge.
Engineering education moved from being practice-based to science-based around 1950, following World War II.
Since practical knowledge is no longer being handed down in large companies, much of the tacit knowledge of engineering is being lost.
Engineering students start leveraging useful skills, such as social networking, while still in school, but they consider the use of such talents as only “semi-legitimate.”
Jeff recalls an MIT study indicating engineers learn most of their day-to-day working skills in industry.
Regardless of experience or title, about 60% of an engineer’s time is spent in direct interactions with other people.
One explanation for why engineers exhibit such a high level of interaction may be that the engineering profession requires distributed cognition.
James references a book about constructing the Canal du Midi in Southern France, which required a collective effort.
Engineers largely succeed or fail on their ability to get individuals with needed skills and knowledge to contribute those assets at the right time, and in the proper manner.
James wrote a paper on engineering collaboration, titled “Technical Coordination in Engineering Practice” (pdf), in the July 2007 issue of the Journal of Engineering Education (vol. 96, no.3, pp. 191–204).
Engineers spend approximately 30% of their time coordinating the activities of others.
Engineers have shorthand methods of communicating technical ideas, as depicted in the book, Designing Engineers, authored by MIT professor Louis L. Bucciarelli.
James refers to a paper he recently presented at the Frontiers in Education 2012 Conference, held in Seattle, Washington. It is titled “Understandings of Value in Engineering Practice,” and should soon be available to those with a subscription to IEEE Xplore.
German philosopher Johann Wolfgang von Goethe identified that as we think about something, our ideas representing that thing shift and move. In his book Scientific Studies, Goethe writes, “How difficult it is…to refrain from replacing the thing with its sign, to keep the object alive before us instead of killing it with the word.”
We need to be aware that others, especially those from other disciplines, may assign entirely different meanings to words and phrases. Even across related engineering fields, similar words may elicit concepts that diverge in crucial respects.
Engineers are typically unaware of the economic value they bring to an enterprise.
Engineers produce significant value by reducing the project risk perceived by financial investors.
A framework for understanding why individual investors perceive similar conditions as presenting differing levels of risk is expectancy value theory.
Chris mentions Daniel Pink’s book Drive: The Surprising Truth About What Motivates Us, which suggests that people are strongly motivated by autonomy, purpose, and mastery, but not so much by economic gain.
Management skills are an important part of engineering work. However, most managerial training offers only an abstract introduction to the practical capabilities needed in industrial practice.
As we discover more about how individuals learn, we may need to rebuild the intellectual foundations of engineering, so as to allow a broader distribution of engineering knowledge, and a deeper understanding of engineering methods.
James Trevelyan can be reached via the email address listed on his website.
Thanks to peasap for the photo titled “George is Keeping an Eye On You!” Podcast theme music provided by Paul Stevenson
Is it possible to accurately perceive the world around us? Are engineers any more or less rational than the general public? Chris and Jeff discuss these issues with Jeff Ellis on this episode of The Engineering Commons.
It’s challenging to accurately perceive reality from within the confines of the human mind.
One approach to overcoming such limitations is called critical thinking.
Our guest for this episode is Jeff Ellis, who writes about critical thinking on his website, The Thinker Blog.
Critical thinking has been defined by Tim Van Gelder as “the art of being right.” This means adjusting one’s opinion willingly to the most defensible and rational viewpoint.
Jeff Ellis is an aerospace engineer who currently works at NASA’s Johnson Space Center. He became interested in critical thinking as a means for avoiding and mitigating project failures.
Our guest believes that critical thinking is “the most important skill a person can have.”
Overestimating one’s own abilities is a common cause for turning away valuable advice and information.
The principle of reciprocity states that we should respect the reasonableness and the goodwill of those with whom we disagree.
Critical thinking requires that we attempt to overcome the limitations of our human nature.
We have emotional attachments to our opinions, which makes it difficult for us to shift our viewpoint.
We still don’t know if some brains are pre-wired for engineering, or if engineering education develops what we recognize as stereotypical engineering attitudes.
Young engineers tend to transition too quickly from problem definition to solution generation, since creating things is the “fun” part of engineering.
Along a similar vein, young engineers can become too enamored with their first solution.
Some people take advice about critical thinking well, while others are offended that their opinion is being challenged.
Jeff Ellis wishes critical thinking skills were taught in college, as opposed to being left for workplace training. He also feels that the nation’s top liberal arts schools produce excellent critical thinkers.
Real world complexity means that there is rarely a single clear “textbook” answer. Thus, rational evaluation is needed.
Dealing with “alpha-geeks” can be a challenge, as Jeff Ellis outlined in his post, Castles and Tents.
Being able to handle disagreement in a congenial manner is an important skill when working in a team environment.
Civility is an important component of critical thinking.
Resources for learning more about critical thinking can be found at thinkerpedia.net
Jeff Ellis has the handle @twiticalthinker on Twitter, and an email address of jeffellis1 ..at.. gmail.com.
Thanks to Mary Harrsch for the photo of Rodin’s bronze, titled “The Thinker.” Podcast theme music provided by Paul Stevenson
Software is an important component in the toolkit of nearly every engineer. Chris and Jeff talk with Greg Wilson about how engineers and scientists can improve their programming skills.
Intended to encourage good programming practices, Pascal gained wider acceptance as the basis for Borlands’s Turbo Pascal.
Programming in the 1970’s was not carried out at a terminal, but required punching data cards on a keypunch machine, then feeding the cards into a card reader. Yes, that huge stack of spinning “magnetic disks” at the 1:14 mark is an early hard drive.
Our guest for this episode is Greg Wilson, who is the founder and director of Software Carpentry, an outreach and training program that helps scientists and engineers be more effective by teaching them “best-practices” for software programming.
Greg’s work with Software Carpentry is currently funded by the Sloan Foundation in the United States, and he is an employee of the Mozilla Foundation.
Software Carpentry seeks to reach the majority of researchers, scientists, and engineers who build “small” data projects, rather than the relatively few that work on “huge” data sets using supercomputers.
A typical Software Carpentry workshop consists of a two-day course, with blocks of instruction addressing the Unix shell, Python, version control, unit testing and SQL. The two-day workshop is often followed up with about six weeks of online instruction.
Greg says that if participants come away with nothing else, they should learn the value of version control, so that the provenance of scientific data can be tracked and analyzed.
The Software Carpentry team has found screencasts to be “a lousy way to teach,” as personal interaction is an important component of learning.
Greg has found engineers to have a bit more “hands-on” experience than scientists, and to be more MATLAB-oriented, but perceives relatively little difference in their understanding of software issues.
Considerable empirical research has been conducted about programming effectiveness, but little of this information is shared with students in college courses.
One of the most critical indicators of how well individuals can work together in a corporate programming project is not their geographical separation, or language differences, but how far apart they are in the company’s organization chart.
Pair programming is an effective method for reducing software errors, but it has an important caveat: it only keeps working if you keep shuffling the coding partners.
The single most effective way to find bugs is code review. Don’t compile the code, or run it, but have someone else read through the code. You’ll find 60-90% of the bugs in the first reading. Review Board is an open-source web-based tool designed to help in such efforts. A commercial product for this purpose is available from Smart Bear Software.
Mark Guzdial has been using “worked examples” to teach programming at Georgia Tech, and has found it to deliver more learning in less time.
A flipped classroom has students watch instructional videos for homework, and then spend class time working problems.
In a 2009 blog post, Greg talked about “real” engineers becoming more like software engineers, rather than the other way around.
Greg believes that higher quality software is possible, if the right incentives are offered to programming organizations.
Even if we can’t review code line-by-line, we can at least verify the methodology and processes used to create it.