Michael Barr is a well-respected person in the embedded systems field. However, his recent editorial “Hands On” has numerous “bugs.” The first concerns his assertion that writing software for embedded systems is not easy. Well, the same assertion can be made by anyone about their chosen field! Hardware engineers, financial analysts, pilots, and homemakers — all can claim the same. But the problem is deeper. When experienced engineers and hiring managers believe that a job requires extraordinary skills, young aspiring engineers sense the contempt for them, and older people who have been laid off and searching for a job face discrimination when attempts are made to prove that they cannot learn new skills for the job.
The second issue he raises is about the education of computer engineers. I find it disconcerting that even highly trained and competent engineers believe that the primary purpose of a college or University is to produce graduates finely tuned to industry needs. The primary purpose of an educational institution is to provide education. The graduates can then go on to work for industry, academics, or the government. Embedded systems is not the only area of computer science or engineering.
Having been a teaching assistant for undergraduates in computer science for four years, and then having worked for 7 years in desktop and embedded environments, I have noticed that intensive project work in every course (with each professor convinced that his/her course is the most important) just serves to hassle the students, leaving them little time to absorb and reflect upon the subject. It is much better to produce engineers with strong analytical skills who can cope later with the changes in industry, which might in the future be about quantum computers and carbon nanotubes rather than the devices of today. Remember that pioneering inventors by definition did not do a “term project” on their invention! Industrial work is becoming more mathematical, more virtual, more cross disciplinary, and more science-oriented, rather than the other way around. As far as graduate studies go, they must focus more on abstract thinking, algorithms and mathematical methods, otherwise they would not be any different from undergraduate courses.
Institutions of higher learning are best left as they are — places of higher learning and research. For immediately useful skills, there exist numerous specialized training courses, such as those offered at ESC (and hopefully paid for by industries willing to train their employees). But those are not a substitute for a college education or vice versa. Each has its own role to play.
Theory and Practice
I couldn't agree with Mr. Barr more. I am a recent graduate from a private engineering school located in New Jersey. Although this school has a good reputation as an engineering school I did not feel that I got any practical experience for what goes on in an engineering environment. Don't get me wrong; the theory was there, but by the time I got to my senior year I (along with a small team) was expected to come up with some new and innovative project, which turned out to be impossible. This wasn't only due to the fact that we didn't have the experience but also because the school didn't back us up financially. We were expected to get our own sponsors and come up with our own money. I find that ridiculous.
I just thought I would let you know that you hit the nail right on the head with that editorial.
Dealing with GUIs
It is a major issue that graduates can leave school with little or no hands-on skills in the embedded field. We find EEs who come from a major university usually have no hands on, and those who come from a technical college have a lot of hands on. However, the EE from the technical college lacks discipline. So there is a trade off. It is no longer practical for an EE to be an embedded programmer and a hardware designer. More and more embedded applications have UIs and even GUIs. I find most EEs with the skills to debug all the low level code and hardware issues lack the ability to create a program intuitive to the end user.
We break up our projects among several groups. The Development group does all the low level code, such as bootloaders, PIC hardware, and I/O maps. The applications group does all the higher-level code, especially any GUI work. The applications group along with sales and marketing defines the product. This has really helped us pump product out with few bugs and great market success.