Tag Archives: communication

Episode 80 — Spatial Reasoning

spatialDuring this episode, we chat with researcher Jonathan Wai about the strong spatial skills exhibited by many engineers. We also discuss why standardized tests don’t measure spatial abilities, the manner in which highway clover leafs are designed, and how one particular co-host would go about reconfiguring his local deli counter.

Thanks to James Lumb for use of the image titled “Silver Balls.” Podcast theme music by Paul Stevenson.

Episode 57 — What Engineers Do

DraftingIn this episode of The Engineering Commons, we discuss engineering skills and duties learned in the workplace, rather than from a textbook.

  • Brian tells young engineers that an engineering degree is a “learner’s permit.” Once in the workplace, engineers have to teach themselves to solve an entirely new class of problems.
  • A gold-fish shaped retention pond, first mentioned by Adam in our episode on engineering pranks, is referenced once again, although your dutiful scribe is still looking for hard evidence of such a structure.
  • An extended discussion related to beer production and consumption breaks out amongst the discussion panel.
  • Jeff describes how the bricks that once covered the entire racing surface at the Indianapolis Motor Speedway are now found only at the start/finish line, in what is known as the Yard of Bricks.
  • Lateral loading on racing surfaces, due to the massive grip exerted by race car tires, requires the use of specialized asphalt mixtures.
  • Drivers in the Indianapolis 500 automobile race pull more than 3 lateral g’s while going through the turns.
  • Quotes about the engineering profession:

    “Engineering is the art of organizing and directing men, and of controlling the forces and materials of nature for the benefit of the human race.” — Henry Gordon Stott (1907)

    “”The ideal engineer is a composite … He is not a scientist, he is not a mathematician, he is not a sociologist or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems.” — N. W. Dougherty (1955)

    “Engineering is not merely knowing and being knowledgeable, like a walking encyclopedia; engineering is not merely analysis; engineering is not merely the possession of the capacity to get elegant solutions to non-existent engineering problems; engineering is practicing the art of the organized forcing of technological change… Engineers operate at the interface between science and society…” — Gordon Stanley Brown (1962)

    “Scientists study the world as it is, engineers create the world that never has been.” — Theodore von Kármán

  • Engineers break complex problems into smaller solvable pieces. The “art” of engineering is knowing how big those pieces can be.
  • Whereas textbook problems usually have a definite answer, problems from the workplace are often ill-defined, and may sometimes offer no practicable solution.
  • Problem constraints in industry may seem at times arbitrary, being controlled by economic, political, and organizational powers beyond the engineer’s realm of influence. Additionally, these constraints are not fixed, but vary with time.
  • We reveal our high-tech method of aligning audio tracks in Audacity, the audio editing software used to create this podcast.
  • Obsolescence issues are increasingly important for design engineers as commercially-available components are being manufactured for shorter periods of time.
  • Engineers must avoid the natural urge to over-design products, even when dealing with complex constraints.
  • Making a prototype work once in the lab is far different than making thousands of mass-produced products work reliably in the field.
  • An important part of an engineer’s job is prioritizing where one’s time should be spent.
  • Many times it’s more important to be on the “proper” side of the equation than to be right; that is, one has to make certain assumptions that may be incorrect, but those assumptions need to be made such that the product or service will not fail, even if the assumptions are not perfectly accurate.
  • Jeff’s example of a 500 ksi stress load would have been more realistic at 50 ksi or 500 MPa, at least for steel parts.
  • In examining the meltdown of nuclear reactors at Japan’s Fukushima Nuclear Power Plant, recent reports have suggested that a contributing factor was the lowering of a seawall back in 1967.
  • Jeff references a scene from The Big Bang Theory television show where Stuart and Sheldon argue about gradations of being wrong.
  • It’s important for engineers to keep track of the small details, even though the process of doing so may be quite tedious.
  • In his autobiography, test pilot Chuck Yeager recalls the tragic outcome of a line worker’s decision to install bolts “right side up” while assembling a jet plane aileron, even thought the blueprints indicated otherwise.
  • Engineering designs need to account for human factors, as well as technical constraints and specifications.
  • Jeff makes selective use of geometric dimensioning and tolerancing standards, as sometimes a simple callout works better in the prototype machine shop.
  • As an engineer, skepticism is prudent in evaluating information and methods. However, too much skepticism can lead to one being labeled “not a team player.”
  • Engineers are often asked to be “fortune tellers,” predicting future outcomes for processes and designs that have never before been realized.
  • Adam emphasizes the importance of understanding safety factors, and their proper application in the design process.
  • Production and maintenance costs are crucial factors in industry, while such cost issues are often overlooked in textbook problems.

Thanks to Seattle Municipal Archives for the photograph titled “Drafter working in Engineering Department, 1959.” Podcast theme music by Paul Stevenson.

Episode 48 — Troubleshooting


We talk with electrical engineer Bob Schmidt about troubleshooting in this episode of The Engineering Commons podcast.

  • Please help us improve the podcast by filling out our 2014 Listener Survey!
  • Adam, Brian and Jeff agree that troubleshooting computer software problems can be a frustrating process.
  • Our guest for this episode is Bob Schmidt, an electrical engineer with 40+ years of experience dealing with software, hardware, and system design.
  • Bob obtained an FCC first-class radiotelephone operator license at the age of eighteen.
  • A Motorola 6800 microprocessor provided the computational power for Bob’s first computer, which had 512 bytes of memory.
  • Bob got interested in troubleshooting when he realized he was being specifically paid to deal with problems.
  • We often learn useful lessons through “parables of problem solving.”
  • The Dog Barks When the Phone Rings: An Engineer’s Guide to Solving Problems” is Bob’s new book about troubleshooting. Look for the second edition of the book, which will be published any day now!
  • Another troubleshooting reference is David Agans’ book, “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.”
  • Bob Pease’s book, “Troubleshooting Analog Circuits,” is a problem-solving guide related specifically to electronics.
  • The “five questions” approach that Bob advocates for problem-solving involves asking:
    1. What do you know?
    2. What are the rules?
    3. What don’t you know?
    4. How can you find out the stuff you don’t know?
    5. How do you know when you are ready to solve; or have you already solved the problem?
  • It’s important to write down what you know when beginning to troubleshoot a problem.
  • Our guest feels that clear communication is an important element of the problem-solving process.
  • Carmen references one of Bob’s blog posts, “What Customers Don’t Understand.”
  • We must be attentive to the constraints of people, time, money and results when addressing the customer’s problems.
  • Henry Petroski’s book, “To Engineer Is Human: The Role of Failure in Successful Design,” discusses what can go wrong in engineering projects.
  • In a 2010 presentation for the National Book Festival, Dr. Petroski talked about how the sciences and engineering are treated when successes and failures occur.
  • Our guest feels that studying the designs of other engineers is a great way to get an intuitive feel for potential problems.
  • Carmen references a Jim Williams tale about design titled “The Zoo Circuit: History, Mistakes, and Some Monkeys Design a Circuit.” This case study is told as a chapter in the book “Analog Circuit Design: Art, Science and Personalities.”
  • Not all information on the internet is reliable, as Bob discussed in his recent blog post, “The C.R.A.P. Test.”
  • It makes sense to ask experts for help in problem-solving, but one has to be cognizant of other demands on the expert’s time and attention.
  • An engineer’s physical senses can be quite useful in troubleshooting problems.
  • “Debug by division,” or “divide and conquer,” is a useful methodology for solving problems.
  • Adam discusses how the debug process is applied in road building.
  • Watching others apply the “debug by division” process is useful means for learning the methodology.
  • Bob’s book offers a few “warnings” that should be heeded if you think you’ve successfully solved a problem:
    1. Correlation is not causation.
    2. Your theory of causation had better show good correlation in your experiments.
    3. There might be more than one correct answer.
    4. Undo your fix and check to see if the problem returns.
    5. There can be multiple paths to good solutions. Your way is not the only way.
    6. Never allow a defect or problem report to go by without documenting and fixing that problem.
  • Additional “challenge” questions that one might ask about a possible solution include:
    1. How did other people solve problems similar to this problem in the past?
    2. Good writers of design are good readers of other people’s designs. Are you a good reader?
    3. Could it ever have worked that way?
    4. Does it work that way now?
    5. Are you suffering from optimism bias?
    6. How complete are your checklists?
    7. Are you doing big debug or little debug?
  • Our guest feels that engineering schools should emphasize troubleshooting as an integral element of the design process.
  • Bob can be found on the web at PrettyGoodProblemSolver.com.

Thanks to César Astudillo for the photograph titled “Troubleshooting.” Podcast theme music provided by Paul Stevenson.