Rich Nass of embedded-computing.com interviewed me about my thoughts on engineering education. Now, first, it’s important to note that the university experience is not an engineering education; it’s merely the start of that process. Too many of us practitioners figure we can stop learning after graduation. It’s disturbing that the average firmware person reads just one technical book per year; this in a field where change is the very foundation of our profession.
When I went to college, a very long time ago, I felt the University of Maryland had a great engineering program. But it did suffer from an over-emphasis on theory. We were not allowed to solder, as the school feared we’d burn ourselves!
The school offered too little guidance. I got caught up in too many math classes, finding the subject interesting. But most of those classes, like abstract algebra, were a waste of time. Calculus was worth learning as it is the basis for most of science. I’m glad to have learned it, though it’s surprising how infrequently I have used it in my career. When my son told me he needed help in his high school calculus class I had to re-study the subject to stay a step or two ahead of him. It was humbling to find my skills so degraded.
Circuit design classes were awful. There were only two: one on circuits, and another on transistor theory. Both were highly theoretical, and neither covered much about actual circuits. There was a lot of difficult math, like impulse response, which hasn’t been useful at all over the last 40 years. There wasn’t a peep about Darlington pairs, op amps, push-pull, classes of amplifiers, hetrodyning, and all of the rest that has been so important over the decades.
Looking over syllabuses today it appears EE requirements are more realistic, though it’s hard to know how practical a class is by the descriptions. But more electronics appears to be taught than in the early 70s. The University of MD still requires two electromagnetics courses, and I’ll bet those are just as incomprehensible as of yore. That material is more important than ever in this world of high-speed communications links, but it should be more accessible to students who will go on to design systems, not practice arcane mathematics. Today only one chemistry class is required, which is a good thing. I thought the second class we needed, organic chemistry, was mere memorization.
Today the U of MD requires one English class, on technical writing. Back in my day a composition course was mandated, though one could test out of it. We also had to take a literature class.
Engineering curricula are packed with too many classes in too short a period of time. Few manage to get out in four years, and that fifth, at an astronomical cost per year, can be financially devastating. But I sure wish we could wave a magic wand to squeeze in some much-needed additional classes.
Number one on my wish list: Written and spoken communications. I think students need a number of classes on the subject. They simply must learn to write, and to write well. This is the communications age, yet too many techies have no communications skills.
There’s a growing gulf between the technically-competent and those, our customers, who don’t understand the difference between a zero and a one. We need to bridge that divide. Unless we can explain what our creations do, how to use them, and their benefits, no one will buy the products. When we’re gathering requirements, negotiating with customers and suppliers, or doing the give and take that characterizes a lot of engineering work, we’ll be communicating in speech and the written word with others who don’t understand the basics of our field. Those who can do this effectively will succeed; the others will be left in a sort of limbo, buried in pure technical roles with no prospects of advancement.
In developed countries engineering is in decline. That means developers will increasingly be working with engineers in other, lower-cost, countries. English may be a barrier; toss in an inability to use it effectively and development will stall as both sides spend more time scratching their heads in puzzlement over the latest email or report essentially encrypted by poor exposition.
Engineering students should be writing every semester. The only way to master this is the same way one learns to differentiate equations: constant practice. Calculus is easier than writing in that there is a single correct answer; prose is much more qualitative. That’s actually a good thing, because in the real world most of our problems involve decisions that are based on a lot of complex factors. There often isn’t a right answer; there’s the least worst. Or there’s an answer that satisfies no one, but that causes the fewest objections. Looking over the EE requirements at the University of MD there’s only one class, “Social & Ethical Dimensions of ECE Technology,” that deals with non-quantitative results.
I well remember at age 20 talking to my dad, a mechanical engineer, about the purity of engineering, at how the results are so clear. He laughed. And he was right.
Public speaking should be required as well. Most of us hate it. But it’s an essential part of our profession. We all know the developer who is afraid to speak up in a meeting. That means the team loses the benefits of that person’s knowledge and experience.
We have to learn to be comfortable giving short presentations in front of a group. Team up with PowerPoint and get your point across, with clarity and forcefulness. (Many condemn PowerPoint, but the problem is the poor use of that application, not the application itself).
People object that they may not be natural public speakers, but who is? Demosthenes suffered from a speech impediment, so practiced speaking with pebbles in his mouth. He went on to become one of history’s great orators. Winston Churchill had a stutter, when younger, that was called “agonizing.” Ralph Waldo Emerson put it well: “All the great speakers were bad speakers at first.”
On another subject, I’m giving my Better Firmware Faster seminar in Baltimore (Nov 7) and Santa Clara (Nov 14). More details here .
Jack G. Ganssle is a lecturer and consultant on embedded developmentissues. He conducts seminars on embedded systems and helps companieswith their embedded challenges, and works as an expert witness onembedded issues. Contact him at . His website is.