7 More Things Colleges Should Teach EEs

RSS

Suggestions for what EEs should be taught in college.

Again my thanks to all of you who responded to my blog of July 22nd: What should colleges be teaching EEs?  http://electronicdesign.com/blog/what-should-colleges-be-teaching-ee-sHere is what I discovered from a second reading of all the comments and the separate emails: A list of topics that many agree should be taught.  I wouldn’t call it a complete consensus, but these topics showed up repeatedly.

First, most of you agree that the math/science/engineering fundamentals are essential and they should remain a strong part of the program.  Second, you want to minimize the amount of new technology taught as it changes rapidly over time.  I mostly agree with this but I still think you need to teach some of the current technology so as to create an employable engineer who does not look like an idiot the first day on the job.  You know what I mean.

Anyway here are some suggestions you made:

  1. Communications - More than a few of you mentioned how important writing and speaking was to your career.  I definitely agree with this.  Engineers are constantly blamed for their poor writing and speaking ability and they deserve the criticism as it is true.  The better you communicate the faster you will progress on the job.  A couple of English courses in most BSEE curricula is not enough.
  2. Project management – All engineers will run a project, even if it is their own small part in a larger project.  You need to learn planning, timing, costing, budgeting, and all that related stuff to be effective.  Some team playing and personal interaction should be a part of this.
  3. Problem solving – What engineers do is solve problems.  They apply their engineering talent to coming up with solutions including products that meet needs.  And problem solving is also the essence of troubleshooting.  What engineer does not do that?  Reader Bob Schmidt sent me a note and a copy of his book The Dog Barks When the Phone Rings:  An Engineer’s Guide to Solving Problems (Kokomo Press, 2013) that I wish every engineer could read.  I don’t like the title but the book is full of problem solving basics and wisdom every engineer should know.
  4. Statistics - More than a few of you said that some knowledge of statistics and probability is essential today.  Here is another one I agree with.  I took a stat course in my Master’s degree work and wondered why at the time.  As it turns out, I used it more than I realized. Still do. It is a big part of decision-making and testing these days.  A great math elective if you can work it in.
  5. More software – Engineering is all about software today, not only for embedded systems but in the tools we use to design.  Programming languages and design tools are the soldering irons of today.  How about adding DSP to that.  DSP seems to be in everything today and its all math algorithms and software.
  6. Test and Measurement – Isn’t this a major part of what most engineers do?  Test, measure and troubleshoot?  Yet rarely do modern students learn the basics of using a scope or spectrum analyzer or even simpler gear.  Or finding really serious EMI that plagues us all today.  Whatever happened to the lab work?  Most T&M is to ensure the meeting of standards.  Everything you design today has some standard associated with it.  Something else they never tell you.
  7. PCB Layout – Here is a real practical skill that really involves deep engineering knowledge.  With today’s high speed digital interfaces and gigabit RF circuits, it is ever more critical to most designs.  This requires knowledge, skill and even some black magic to get it right.

I doubt that any of these things will develop into real courses as there is just no space left in most programs, but at least these topics should be incorporated into other courses.  I do believe these will help produce a more “rounded” graduate.

I would like to add one more thing.  Learning how to learn.  Maybe most EEs do learn how they learn or they would never make it through an EE program.  But this is a key skill that is essential to surviving as an EE or in any career.  Any EE has to learn continuously all the stuff never taught in school as well as things needed for the immediate job.  Some form of continuing education is critical to an EE career.  All of us need to do as much as possible like read the magazines, join the IEEE, take webinars, read the latest white papers and app notes and try out the MOOCs (massive open online courses).  Reader David Archer sent me a link to his website where he offers a wide range of continuing education online short courses for EEs.  Check it out at www.learningmeasure.com.

If only we could get the professors to read this blog.

Discuss this Blog Entry 17

on Aug 28, 2013

This is interesting. I graduated from an accredited Canadian University in 1990 and all points but the 7th were covered in the undergraduate program (Electrical Engineering). Why the resistance in US universities? If this information is not being taught, what is?

on Aug 28, 2013

Very well put. I can't agree more. I'm glad communication is #1 on the list. I'm lucky to have faired well there, and it has helped me tremendously.

One minor added detail. While software is agreeably important, and I'm glad it is in the list, the software community has wandered way out into the weeds (my degree is in CS and most of my work is software develoopment and management). A lot of emphasis has been placed on abstraction. Some woudl argue that it results in fewer bugs (possible, but debatable) and it also results in less develoopment time.

However, it has created a generation of programmers who have almost no contact with the hardware. Time and time again, I've see code that was 50% 10% sometimes 1% as efficient as it could be, simply because the author didn't realize what they were asking the CPU to do. Often minor refactoring of the problem presents it to the compiler in a manner that can generate much more efficient code.

I routinely tell the developers I work with that any decent programmer can tell you the exact assembly language code the compiler will emit for a given construct. No I don't advocate writing in assembly, or even studying every line of assembly code the compiler generates. But if a programmer is clueless what code is actually generated from some STL template, they may be spending a long time trying to figure out why it takes too long to run on a 3 GHz quad core processor!

I frequently generate disassembly listings of portions of my code and look at how certain lines are compiled. The insight is invaluable.

on Aug 28, 2013

Not enough lab work in today's EE curriculum? oooo, not good. I wonder what made the staff of these universities think that it wasn't important.
Statistics - extremely important. Even if the grad forgets the exact equations, the experience from a statistics course gives you a "gut feeling" of why tolerance and temperature drifts are important.
Layout and programs: Most CAD programs I've been able to pick up in a few weeks, self taught with help from the guys who use it at each company. I don't know if a whole semester course should be devoted to each one.

on Aug 28, 2013

Unfortunately, colleges and universities are more interested in tuition money than in creating good engineers now. Quality of teaching is plummeting.
I have been teaching for a while and found out that 2-year "students" could not multiply two regular fractions.

on Aug 28, 2013

I originally majored in ME, and we had a course called "Materials and Methods" which was basically a grizzled old manufacturing engineer telling stories about how the real world gets the job done. This was probably one of the most informative courses I ever took! If there were an equivalent in the EE world, it would go a long way to answering your items #1, 2, 3, and 6.

on Aug 28, 2013

I AM a grizzled old EE telling those war stories to my students :)

on Aug 28, 2013

Here are my thoughts after over 40 years in the field.
1. When all is said and done, documentation is the only product of value that engineers actually produce. Without proper documentation a product's design cannot be verified and the product cannot be properly manufactured, tested, used and maintained. What good is an incredible working prototype if it cannot be produced?
2. Project management can be a fatal trap when it comes to design and development. It is most important to realize that early iteration is far less costly that a redesign later on. In fact early iteration must be encouraged to avoid major project disasters, which everyone actually saw coming but didn't want to disrupt the project schedule.
3. Problem Solving - whatever happened to elegant solutions? Bloatware seems to be everywhere in software and hardware. See also iteration above.
4. Statistics - I've only ever seen statistics used to make performance look better than it actually was and thus hide system defects.
5. Software - most software I've had to maintain has been poorly written, bloated and poorly documented. Realistic testing of software is virtually non-existent. "It seems to work - let's try it out in the field."
I've used spreadsheets to generate waveforms to be converted to system inputs, testing all possible values and then brought the system outputs back into the spreadsheet to evaluate performance. Every system I've tested this way showed up major bugs. It's similar to testing an amplifier with waveforms and a 'scope. Works very well for me.
6. Test and Measurement - Inadequate testing of designs is rampant. I spend more time building test equipment for my designs that on the design proper to be able to test it in all possible operating conditions. This includes all input values including overloads and transients and all environmental conditions including temperature, humidity, vibration and EMI. And don't forget to encourage a few characters who think it takes great talent to break something.
Most importantly, involve users throughout - especially important when doing iterations - see 2. above.
7. PCB layout. If in real estate it's location, location, location, in electronics it's layout layout layout: grounding, power rails, keeping digital and high power conductors away from sensitive inputs and just minimizing conductor lengths. I've seen Auto-routing used as a crutch with disastrous consequences. If you do a well thought out component layout, auto-routing will do its job in a couple of seconds. But you always have to check out what it's done. And have
I mentioned, test, test, test?

on Aug 28, 2013

Here in the Design Lab at Rensselaer we specifically cover these topics.

The course is for EE, Computer System Engineering, Mech E, Materials Engineering, Biomedical Engineers, and Industrial System Engineers! It's a multidisciplinary senior design course, so ALL of these majors may be represented on a single team!

We work with industrial project sponsors and developed the program with their inputs.

on Aug 28, 2013

NC State did most of that in the mid 1990s, except no PCB layout and the SPICE interfaces were awful. They tried to teach the software but it was in no fit state for human use in 1996, and they did a crap job teaching what was available. Problem is there is now far too MUCH software. You can't know all the schematic, sim, and PCB software. But I guess even learning free stuff like pcbartist shows you the fundamentals, like knowing Photoshop would help to learn GIMP. But still, the fragmented EDA market puts up a lot of unfortunate learning curves that just waste engineers' time.

on Aug 28, 2013

I'd like to add a number 8: Techniques to designing for energy efficiency.
While designing for low power consumption is obvious for battery powered devices, a lot more energy can be saved in high power systems. There are many techniques from lower supply voltages, duty cycling, lower power devices and a major one we seem to forget, code efficiency. By simply recoding more efficiently I was able to reduce the clock by 80% and together with some minor circuit efficiencies, I was able to extend the battery life by nearly two orders on a 500 channel data acquisition system.
We all have to pay more attention to power efficiency. What's your excuse for wasting power and consequently reducing reliability on any system?

on Aug 29, 2013

I would add "configuration management," or "product life-cycle management (PLM)". I have seen too many disasters because companies have no knowledge or respect for document control. I worked at a billion-dollar semiconductor machinery outfit that only figured out the schematic of the machine when the had an EE and tech trace the circuits with a DVM. The goof-ball "scientists" aka process engineers, that designed the thing would just wire a harness as they stood around a machine, and then send the harness to a wire shop with instructions to "Make 10 of these." They didn't treat the mechanical engineers much better.

As a consultant, I would get calls every month from some dork company that had lost the PCB design files and either wanted me to work backwards from a set of Gerbers, or just had a (usually down-rev) PCB they wanted to bring over and have me copy.

on Aug 29, 2013

Engineers at large have an abysmal ignorance of history, little knowledge of government and, indeed, write poorly. However, my college experience with the English Department was much less positive than it could have been. The instructor in the first term of English Composition was excellent, but the professor in the second term was a bizarre individual who gave me a "D" on a composition because it lacked emotion, not because it was written poorly. My time with that individual was wasted. My wife's experience at another university was similar. Engineers do need to be able to write, but paradoxically, college English faculties don't appear to be competent or even genuinely interested in assisting in this aspect of the educational process. By the way, in the second term of Western Civilization, I had the high score in the class, even though there was a considerable load of writing assignments as part of the class.

on Aug 30, 2013

Great topic. Regarding dynamics (original blog), EE's working on motion control systems who don't know dynamics are limited. But the real value of cross-discipline courses is for your #3 - problem solving. Applying the same principles and tools to problems in different disciplines creates an appreciation for the process. at least for me.

on Aug 31, 2013

I've been thinking of developing a course to help EEs learn more about test and measurement. Maybe I'll purse that more aggressively.

on Aug 31, 2013

The engineering educational deficiencies start well before college. Primary and secondary schools do a poor job of teaching the basics; kids graduate from high school not knowing much of anything but they "feel good about themselves".

In the past, kids had hobbies like amateur radio which allowed them to get "hands-on" experience in electronics and to learn some basic DC, AC, & RF electronics. Now kids only learn software and get no real hardware experience.

I think it is a mistake to try to be an engineering "Jack-of-All Trades". While some broad education is helpful, it is far more useful to concentrate on one niche. Long ago I decided that I could be a mediocre digital engineer or a good analog engineer so I learned just enough digital to get by-- there are far better digital designers than I am-- I cheerfully cede the field to them; ditto for programmers.
You cannot be a decent engineer without hardware experience so a college's minimizing labs is unfortunate. I have met new graduates that have no idea of what components are practical or how to use a scope. The simple act of troubleshooting a circuit speaks volumes about the persons basic skills and their reasoning ability.

on Sep 3, 2013

Sounds like a BSEE/MSCpE/MBA, accompanied with $200k in student loan indebtedness.

on Sep 4, 2013

Well, I'm one of those old timers that predated many of these courses discussed above. During my college years, we were taught FUNDAMENTALS of each topic. It was left to the student to delve into the fine points & to SOLVE problems. That's how one forms an engineering mind. P.C. Board design was non-existent then. While good p.c. board design IS a must, especially today w/ rf ckts in the gigaHertz range, I do not believe that this should be part of an engineering core curriculum. It may be better represented as an electromechanical elective for those who desire such knowledge, and it SHOULD be almost entirely a lab course, since it is mostly a "doing" thing.
While Probability & Statistics are very important, for me it was a purely theoretical exercise covered in two semesters. In my 50 year career, I've used it very little, although the understanding of the concepts has been MORE of a factor than any derivations.
Communication, whether oral OR verbal would be at the top of my list of importance to an engineering/science/math discipline. The first semester of freshman year, we were given several topics. We had to write short papers (longhand writing was OK!) on these topics. The topics were general in theme, having virtually nothing to do w/ our technical majors. They were sponsored by the English Dept. which did the grading. At the end of the semester, those students who completed all the assignments were slotted into two groups, Pass/Fail. Those passing went on to their studies; failing were required to take a one semester course in Writing Composition, which stressed good sentence structure, spelling & punctuation. (p.s. I passed w/ flying colors!)

Newsletter Signup

Please or Register to post comments.

What's Communiqué?

Blogs on topics such as wired and wireless networking.

Contributors

Lou Frenzel

Lou Frenzel is the Communications Technology Editor for Electronic Design Magazine where he writes articles, columns, blogs, technology reports, and online material on the wireless, communications...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×