Category Archives: Engineering

Engineers Forget to “Stand on the Shoulders of Giants”

If I have seen further it is only by standing on the shoulders of giants.     – Sir Isaac Newton

All technical innovation has come from building on what came before, by using the building blocks provided by engineers who came before us. While its easy to recognize this is true for big innovations, engineers forget this principle way too often in their daily work.

[If you don’t have the time to read the rest of this post, then skip straight to this article about a disastrous example — Netscape v5.0 — of what happens when engineers and managers decide to build from scratch instead of building on what came before. I consider it required reading for all engineers working for me.]

A Shortcoming of Engineering Education?

Consider for a minute how engineering education teaches students to approach problems:

  • Professors always go back to first principles (and rightly so).
  • Problem sets force students to start their analysis from the ground up…and usually by themselves.
  • Copying others is considered cheating.
  • Students must finish all the coursework within one semester, which prevents them from building up a “toolkit” of solutions for solving more complex problems.
  • Project management and risk management are rarely taught.

Engineers are taught to reference the textbook when trying to solve a difficult problem; they are not taught where to look on the web for a pre-existing solution since that would be considered cheating. They’re definitely not taught the social skills necessary to cold-call a subject-matter expert to pick his brain. (To read more about this, see my post from last week on Emotional Intelligence.)

Fortunately, some professors are starting to change their teaching methods to account for the wealth of information on the web…and to teach students to solve problems as they would in the “real world.” This is easiest in computer science, where a solution can simply be copy-and-pasted, as opposed to disciplines that involve hardware.

For example, computer science Professor Adrien Treuille at Carnegie Mellon encourages his students to use code available for free online in solving their problem sets, as long as they cite the source. He explained to me, “This approach allows students to develop much more complex and interesting programs than they could if everything were coded from scratch, and they become familiar with the coding style…and the best sources for free code…that is typically used in industry.”

Information Asymmetry in Engineering

In addition to their academic training, “asymmetric information” also entices engineers to start from scratch, even when an existing solution is available. Let me explain what I mean by “asymmetric information” in this context…

There are usually several ways to solve a problem, each with its own advantages and disadvantages. Frequently the choice is between modifying an existing implementation versus building a new one from scratch.

The Existing Solution (warts and all): If an engineer has an existing solution in front of him (or her), all the hacks, bugs, and shortcomings are totally apparent. Documentation is frequently lacking, so reverse-engineering is necessary. If multiple people have worked on the project, the solution is frequently a messy mix of various coding and design styles.

Building It from Scratch: In contrast, when the engineer considers a new, fresh approach, the advantages are much more apparent than the disadvantages. The engineer sees the final solution in his mind’s eye as a gleaming, flawless example of engineering perfection. Of course, as the saying goes, “The devil is in the details.” Without the opportunity to work through the details on a new solution, the devil, Murphy’s Law, and shortcuts necessitated by project deadlines have not yet impacted the work.

For these reasons — the apparent shortcomings of an existing solution and the undiscovered shortcomings of a brand new implementation — engineers are tempted to scrap an existing solution in favor of doing it their (presumably better) way.

As I mentioned earlier, the best and most disastrous  example I’ve seen of this is the re-coding of the v5.0 Netscape browser. I consider this article REQUIRED READING for all engineers, regardless of their specialty. Please…think twice before you start rebuilding something from scratch!

On the Shoulders of Giants

There is a great scene in the movie Flash of Genius. Greg Kinnear plays Dr. Robert Kearns, the inventor of the intermittent windshield wiper. The scene shows him in a courtroom, cross-examining an expert witness called by the defendant, Ford Motor Company, which stole his invention. The expert had just testified that since Dr. Kearns did not invent the capacitor, the transistor, or the variable resistor and just bought them out of a catalog, that he did not create anything new.

Dr. Kearns starts his cross-examination by reading from A Tale of Two Cities by Charles Dickens: “It was the best of times, it was the worst of times. It was the age of wisdom, it was the age of foolishness.”

Kearns asks the expert witness,  “Did Charles Dickens create the word ‘it’?”

“No, he didn’t create that word,”replied the witness.

“Did he create the word ‘was’?”








Kearns continues, “I’ve got a dictionary here. I haven’t checked, but I would guess that every word that’s in this book can be found in this dictionary. Do you agree that there’s not, probably, a single new word in this book? All Charles Dickens did was arrange them into a new pattern, isn’t that right?”


“But Dickens did create something new, didn’t he? By using words. The only tools that were available to him. Just as almost all inventors in history have had to use the tools that were available to them. Telephones, space satellites all of these were made from parts that already existed, correct, Professor? Parts that you might buy out of a catalog.”

“Technically that’s true, yes, but that does…”

“No further questions, your honor.”

Don’t invent a new language and write a new dictionary before starting your work. Even though the English language is an imperfect work-in-progress, it is still used successfully every day to communicate, and sometimes even to create beauty and inspiration. Use the tools, resources, and existing solutions you have available to you, even if they’re not perfect…and build on the shoulders of giants.


Image credit: The original source and artist are unknown to me, otherwise I would provide credit. Link to Google search results for this image.

P.S. While people are listening, I want to publicly shame 😉 Mark Schultz for skipping out on the Hightstown Triathlon last weekend.  No excuses in 2012…start your swim training now so nobody has reason to worry about you drowning! 🙂

Emotional Intelligence – What Makes Star Engineers

In a college final exam, you’re on your own. If you can solve the problems fast enough and without help, you’ll pass.  If you’re caught copying from the smartest kid in the class, you’ll flunk…or be expelled.

Originally, I applied the same mentality to my professional development: in order to be a successful engineer, I reasoned, I had to know everything well enough to develop engineering solutions by myself. Big brain = success, or so I thought.

Frustrated Engineer

Most of my real-world engineering projects were larger and more complex than I could handle by myself, of course. Fortunately, I read a passage in the book “Emotional Intelligence” by Daniel Goleman that fundamentally changed the way I approach my work as an engineer:

Researchers Robert Kelley and Janet Caplan  studied star performers at Bell Labs, a renowned research lab near Princeton, New Jersey. The telecommunication systems the Bell Labs engineers developed were highly complex…more than any one person could understand…so everyone worked in teams, ranging from 5 to 150 people.

While everyone at the lab had a high IQ, only some stood out as stars. At the beginning of the study, managers and peers were asked to pick the top 10% of their colleagues.

The assumption was that those with the highest IQ or best academic performance would also excel in this highly technical environment. That assumption was wrong…by standard cognitive measures such as IQ, standardized tests, and academic performance, and even social measures such as personal inventories, there were no discernible differences between the stars and everyone else. The researchers had to dig deeper.

By performing detailed interviews, they discovered the critical difference was the stars’ interpersonal skills and how their professional relationships impacted their engineering work performance. The star performers put time into cultivating good relationships with people whose services might be needed in a crunch. When faced with a challenging problem, they were able to pick up the phone, call the right person, and get a quick answer that was usually correct. The average engineer, on the other hand, either struggled mightily to develop a solution on his own — and frequently an inferior one — or wasted his time with unreturned calls and unanswered emails.

The researchers summarized it this way: ‘The formal organization is set up to handle easily anticipated [and routine] problems. But when unexpected problems arise, the informal organization kicks in. Highly adaptive, informal networks move diagonally and eliptically, skipping entire functions to get things done.’

– Paraphrase of Daniel Goleman in Emotional Intelligence, p. 161-162

Image credit: / Bantam Books

An engineer I worked closely with for several years, Keith, embodied the lessons I took of the Bell Labs study. Keith wouldn’t initially strike you as a straight-A braniac student. I never saw his transcript, but I would guess that he enjoyed socializing as much as he enjoyed studying. But, man, he is one of the best engineers I’ve met. Whenever he’s faced with a challenging problem, he’s able to research it quickly and thoroughly enough to be able to ask the right questions. He then tracks down the best subject matter experts he can find, calls him them up, picks their brains, and, if necessary, visits them in person that same week. That’s usually enough to rapidly solve most challenging problems, but if not, he’ll contract them to see a solution through to completion. He repeats this day after day. The result is an ability to solve engineering problems that have vexed his entire industry for decades.

Based on the lessons from Goleman’s book and Keith’s example, I make a concerted effort each day to stay in touch with other bright people in my industry and pick their brains on a regular basis. I still code and design hardware, but it’s the continuous, informal expert input that allows me to incorporate best practices and lessons learned, and minimize the risk of the schedule delays and budget over-runs that typically kill projects.

In my post next week, I’ll write about what I see as the “corollary” to the emotional intelligence problem with engineers: what happens when engineers — including myself at the start of my career — undervalue outside feedback and ignore lessons learned. It’s a problem of “asymmetric information” that leads to costly efforts to re-invent the wheel. Stay tuned.

Special thanks to Mark Kasrel for teaching me about Emotional Intelligence and its importance.

Photo credit: iStockPhoto