Slideshow: 5 Things I Wish I'd Learned at University

The university I attended offered a great engineering programme, but there are a few subjects I wish had been covered in a little more detail.

Hello there, and welcome to my new blog here on EE Times. You may have come across some of my ramblings before over on All Programmable Planet (APP) or in the Xilinx Xcell Journal. If so, you will know that (in my "day job") I have the privilege of being the head of electronic design for Astrium Products Payloads in the UK.

My first thought on being asked to write this blog was: "On what topics can I focus that will be of interest to a wide audience?" And, after giving this literally seconds of thought, I decided I would base this inaugural offering on the numerous books and folders that I have carried around in my briefcase over the years, and which now litter my study, as illustrated below:

Just a few of the books and folders on hand in my study.

What kind of books are these? They are quite simply a collection of notebooks that -- over the years -- I have filled with circuits, comments, and interesting engineering issues I have run across in my career. Flicking through these pages made me notice a number of things and caused me to think "(a) I have messy handwriting, (b) why did I not write down more detail, and (c) many of these topics could be gathered into just a few categories."

With this in mind, I set about grouping things together. This got me thinking how lucky I had been with regard to the university I attended -- Sheffield Hallam University (the same as Max, but I attended much later because I'm so much younger than he) -- since they offered such a good engineering programme. Having said this, looking through my list of topics, I did come across a few subjects that I wish had been covered in a little more detail.

These topics can be summarized as follows (click the image below to start the slideshow):

No. 1: Design reliability -- We did, of course, cover reliability as part of my university course; however, it was at a very academic and abstract level. It would have been great to have had someone explain about failure rates; redundancy architectures (hot spared, cold spared, triple modular redundancy, and so on); fault propagation, etc., in a little more detail and with real-world examples. If a system has a MTBF (mean time between failures) of one year, does that mean it will work fault free for the year? And just how much will be the product recall cost (financial and reputational) if you do not consider reliability?

Of course, I suspect that everyone who has ever attended university has -- on occasion -- wished they had devoted more time to different aspects of the course, and also that the course itself had devoted more time to certain topics. Unfortunately, real-world time limitations often come into play. But who knows, maybe one of my old lecturers will read this blog and I will be invited back to give a guest lecture or two. If something similar were to happen to you, what would you focus your lecture on?

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.