Electronicdesign 9414 Whelm

Engineering Education: Fact and Fiction

May 29, 2015
I have taken a keen interest in the dialogue (that has been going on for many years) about the quality of engineering education in the U.S.

Education has always been an interesting subject for me.  When I entered college, my goal was to be a high-school teacher.  Later, I decided teaching college might be more to my liking, but that didn’t pan out the way I had intended.  I did do some teaching at various levels from elementary to college, and actually hold a community-college credential in California, which does me little good living in Colorado.

Another reason for my interest is that my work has often led to roles of mentoring and supervising electronic engineers and software developers, even sometimes in the recruiting and screening, and yes, occasionally firing of them. I have taken a keen interest in the dialogue (that has been going on for many years) about the quality of engineering education in the U.S.

My degree is in computer science. I was fortunate enough to take most of my classes from a very intelligent and practical instructor.  He just completed his undergraduate degree in physics, but he had a good grasp of concepts and taught us programming languages as tools to implement concepts, not as an end in and of themselves.  For example, we needed to learn recursion.  But we lacked access to any languages that supported recursion. Rather than throw up his hands, he showed us how to use a variable as a stack pointer and an array as the stack, and subsequently implement recursion in BASIC. 

By the time I graduated, he had moved on to industry and was replaced by an instructor who had a master’s in CS. The latter faced the same issue; however, he told his students that they would not be able to try recursion because we didn’t have a language that could do it. One of my classmates who took classes under the former instructor, and happened to be in this class, proceeded to show the instructor how to do it.  So much for a master’s degree in CS!  Your mileage may vary.

I recently read an article questioning the need for a college education. I have told people over the years that the degree you get in college is less important than the fact that you have a degree. There is still some truth to that, particularly when it comes to salary level and preference in hiring. However, in the computer field, the trend is to snap up bright applicants regardless of their (lack of) formal training.  Sometimes this works well, but it often leads to sloppy practices and poor documentation.  The CS degree may not be necessary to get the job done, but it may be valuable for writing quality code with minimal bugs that can be read by someone later on.

We all come into life with different strengths and different temperaments. One of my early dissolutions was the rigorousness of college-level math. I never cared much for the proofs of geometry in high school, and my initial goal of a math/physics double major in college rapidly vaporized in calculus class.  Fortunately, the college was putting together a CS degree about that time, and I found it much more interesting. 

Any kind of college degree, and especially a graduate degree, involves a fair amount of rigor. It also requires looking at oneself and ones work objectively, and not getting too emotionally attached to it.  For those who can maintain that ability, the results are very beneficial, but the process can often be rather ego-deflating.  This becomes an argument that’s both for and against a college education.  I sense a significant difference in the way a person with a college degree looks at life (and work), and find it frustrating to see the way those without that objectivity muddle through daily living.

Another aspect of college that brings mixed reactions is its wide scope. Those things called GE courses, which we all hated, give us a much broader perspective on the world and life. Engineering is a particularly good example of this concept when narrowed down to the workplace.

A good engineering curriculum includes a set of core courses that expose students to all branches of engineering. Why? Not so they can pick their field, but rather because an engineer in any field will quite likely have to interact professionally with others in other fields. The core courses teach them the vocabulary of each engineering field and the issues faced by practitioners in each field. That significantly improves their ability to understand each other and each other’s needs, as well as collaborate on solutions.

As an embedded programmer, my programs often control RF electronics. Sometimes they control mechanical systems with mass and inertia. Other times they control thermal systems. The things I learned in physics and chemistry have frequently been valuable. As an administrator, I always look at prospective programmers from the perspective of what they know about the subject domain of the company/project I am hiring them for—often RF. Do they know about power in dB? Do they understand basic modulation techniques?  Distortion?  Harmonics? Waveforms? Quadrature?  All of this is going to impact how quickly they come up to speed on a project.

Even more importantly, I’m seeking to determine whether they understand programming concepts or just mastered a list of reserved words and techniques. It is much easier to train someone in the specifics of a project, or even a language, than how to write quality code.

I once supervised a Vietnamese immigrant engineer. He was bright. He had to leave Vietnam part way through law school.  But U.S. law was different enough from Vietnamese law that he opted to switch to electrical engineering, graduating from a Cal State campus. Unfortunately he didn’t take to engineering as well.  Once I gave him a 3P4T wafer switch and a schematic of a circuit and asked him to build it.  Later in the day I walked by his work station and he was still examining the switch, trying to figure out which wire to solder to which terminal. Another day he was designing a circuit board and had cleverly let two resistors on the same net share the same pad (in several places) and could not understand why I didn’t think that was a good idea. 

I returned from vacation one day and he proudly announced he had fixed a broken system. He decided that the root cause was a fuse that had blown and that the blown fuse caused a circuit board to be damaged!  There simply was a disconnect between theory and practice. He eventually found his niche managing the company’s parts inventory.  One wonders how such a disconnect could lead to a BSEE from a respected university?

I also have to mention another immigrant BSEE (from the same university) who worked under my supervision. We would discuss a problem he was working on. I would ask leading questions to get him thinking along the right direction. He would respond by quoting whole paragraphs from his college textbook (from memory!) relevant to my question, but was no closer to a solution than before. His memorization was very good, but there was little comprehension. I learned that in his culture, saving face was extremely important—more important than learning.  It was common to take whatever measures necessary to get an A.

One day he asked if he could hire me to do his brother’s senior project for him (same university).  I never did learn who he got to do this, but I’m guessing it wasn’t him. Unfortunately he had to be let go. Saving face meant not telling me that he accidentally deleted a PCB CAD file I had asked him to edit, and rather than admit the mistake, he took the program and schematic home over the weekend and re-created it from scratch. If he had told me, I could have reviewed it carefully enough to find several mistakes that made the resulting board unusable—before we had fabricated and assembled 10 of them. Mistakes are allowed, but several similar incidents of lack of honesty convinced us not to continue to risk that lack of candor.

The hiring process is where trust should start. Certainly everyone wants to put their best foot forward and give themselves the best likelihood of being selected for the job, and both employers and employees engage in certain bargaining rituals to negotiate remuneration. But if one isn’t qualified for the job, there aren’t likely to be any winners by pretending otherwise. A cover letter I received with a job application stands out as the epitome of what not to do:

Dear Sir:

The reputation of software is legendary in the industry. I have researched the company on the internet and would be proud to add my skills to such a fine company.      . . . (this went on for a couple of paragraphs) The reality was that company was primarily a hardware company, although the position being filled was a software position. The company only had two developers. I wrote low-level embedded code for the hardware and the position in question was a GUI development position using Visual BASIC. The company had less than 50 employees total, and no one other than a handful of customers even knew we wrote software, let alone knowing about the software’s quality. In other words, there was 100% probability that the statements made in the cover letter were completely fabricated to impress someone. The applicant did a good job of representing his true character. The letter went into the circular file (aka missing bit bucket).  If I couldn’t trust what he said in a cover letter, do you think I could trust what he said as an employee?

This has been somewhat of a potpourri of ideas and anecdotes on the topic of education. I’m sure readers have interesting stories and ideas to contribute, and I look forward to reading them.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!