how to program in something other than Fortran. Okay, I know that I am dating myself, but I wish that I had had more options then, and that once I graduated from school I kept that particular skill set up. Knowing engineers who know C, for example, I'm impressed by how it is their go-to tool for many different things.
I would add some experience in production of electronic equipment. Many graduates can design a circuit, but do they understand how to manufacture it? Have engineers learn how a production line works and the problems production engineers have. People have noted design for manufacturing, but education should include packaging, package materials, mounting problems, heat-sink requirements, etc...
I'd add a course on technical writing. You might be a good engineer, but if you can't communicate clearly, your ideas will go nowhere. In my experience, only a few engineers know how to write well.
Someone ought to teach engineers how to document code, too. Most of the code I see lacks comments and the included comments rarely provide information about what code does.
In the 1950's when I was in engineering school, calculus was emphasized heavily but linear algebra was ignored, and in modern times it seems to me that LinAlg is quite important. Also, all labs seemed to focus on one factor at a time, while in industry multi-factor DOE is routine. We could have used some Stats and DOE and Linear Algebra in place of some calculus and dumbed-down labs. Just my opinion.
We did have one great prophetic lecture which featured Herb Simon, who wrote chess playing games for ancient IBM machines amongst his other insights. He pointed out that much of EE would be automated, and that the last jobs to be fully automated would be those that require hand-eye-brain coordination, like racing or bulldozer operation. We needed more visionaries in many technical universities.
The university lab courses back in my day involved building circuits on solderless breadboards with very standard parts. Perhaps that was fine for undergrads, but the practical hands-on experience I got in my first 6 months of working was invaluable -- designing circuits to tough specs, choosing which devices would best meet the requirements, designing the PCB, building the circuit with a soldering iron, then testing it and reporting the results.
That's asking far too much for a university curriculum (or is it?), and perhaps even asking too much of most employers to invest that much in a fresh graduate.
I think people after spending more than 10 years in industry should be allowed to go back to academic sector and help in brinign the academics and practical world closer. Like I would like to let students work few hours in some electronics companies or software companies or electromechanical sectors as part of curriculum. It doesnt matter if they spend time with Design, supply chain, production or quality. But it will definitely help the students to widen their learnings.
You raise a very good point many engineers spend a lont time writing documents and it is important these are completed acurrately and correctly for example requirements, design anaylsis, business cases and so on.
Maybe I should add a 6th one of how to write good requirements, that really is important.
Unfortunately, students can get a very clear idea what life will be like at most employers (especially large ones) by reading Dilbert.
For those companies that aren't Dilbert-like, probably the biggest rude awakening for new grads will be how much writing is required for good engineering. While it's been a while since I was in the "ed biz", I expect that engineering education still emphasizes solving math and logic problems in various forms, which gives students the idea that it's a great field for those who hate writing. But when you enter the real world, good engineering requires writing good specifications and descriptions of product and module functionality.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...