In a world increasingly shaped by technology, engineers have a moral obligation to consider the consequences of their choices.
Continuing education is vital for engineers. If you are surrounded by more experienced colleagues, you may be learning from them on a daily basis. Others keep up to date by reading books or journals like this one. Another way engineers learn is through professional training courses. These are available from independent trainers, such as myself, or from events like the Embedded Systems Conference. The important thing to remember when you're seeking out new knowledge is that not all forms of education are the same.
Some claim that educational institutions are failing industry by not producing graduates that are capable developers as soon as they leave university. I am not so sure that industry is entitled to a free lunch, with the taxpayer or the student footing the bill. In my final year of school, one of our lecturers wisely advised my fellow students and me to leave any company that spent less than ten days a year training us. For at least the first decade of an engineering career this is excellent advice.
While academia should provide students with the raw material to learn any particular set of software skills, it shouldn't fall into the trap of serving a narrow industry segment. In university, I did not learn about real-time operating systems (RTOSes), and neither did I learn about the Windows NT threads (not that Windows NT existed at that time). However, I did learn about the theoretical underpinnings of concurrency, which has allowed me to adapt to whatever type of parallelism I encounter.
Commercial training, on the other hand, is designed to provide the engineer with tools that can be used right away. Businesses are entitled to expect instant returns on their investment in the education of their employees. A business purchasing a course is not so concerned about whether the course they purchase is broad enough to help the student five years down the road. In fact, some businesses would prefer that employees do not use the training afforded to them to move on. While some businesses get stung, this sort of thing usually evens out in the end. A company might train an employee and lose him later, but the same company will hire an engineer who has benefited from training received in previous employment. An employer who skimps on training, on the grounds that some competitor might later receive the benefit, is doing the industry and himself a disservice.
One interesting-and commendable-quirk I have noticed in the training market during the recent downturn is that some companies will provide training to employees that they are laying off, to help improve their chances of reemployment.
Older and wiser
Years ago I presented courses on behalf of other training companies quite frequently. Those companies would sometimes be reluctant to send out a very young engineer (me) because they were afraid of giving the customer the impression that it was paying for someone who might not be long enough in the tooth to know the topic completely.
I took two measures to compensate for this. First, I grew a beard. Then I made sure I was well versed in the topic. I figured that if I knew every call in the API by rote, I would never get caught out by a technical question from the class. While the detailed technical knowledge was important, I was missing the point. What the more experienced trainers had to offer was not a better mental reproduction of the data sheets, but more war stories.
When instructing a class on real-time operating systems, it might be useful to be able to point out that a NULL value is valid as the third parameter to the createTask() call, but that's information you can find in the API documentation. It's more useful to talk about the design where you created a task every time a message arrived, and destroyed the task once the message was processed. Some profiling showed that the application spent more time creating and destroying tasks than it spent doing the useful work. Creating one task that processed a message and then stayed alive waiting for the next message proved a much better solution. Anecdotes like this one are likely to stick in the mind of the student.
Disaster stories are much more instructional than technical detail. It is always cheaper to learn from the mistakes of others. For the sake of the people I train now, I carry around a collection of my own mistakes. Some of these are so embarrassing that I express them as incidents that happened to a “friend.”
The ideal business model for a training company is to own a training course that leads to a kind of certification that's recognized within the industry and, therefore, sought after by students, as well as the managers who approve the training. However, I do not see this model leading to the highest-quality courses.
A course should be adopted to suit the level of the students, or the needs of the company. Certification encourages the trainers to apply the same standards and levels, regardless of individual needs. Education is about making students better than they were before, not about making them all the same.
The certification exams that I have encountered have all been based on multiple choice questionnaires. Engineers should be encouraged to think independently. They should not be restricted to a range of canned solutions. The desire to provide an exam in a format that can be quickly and automatically checked is sensible, but the benefits of studying for and passing such an exam will be limited when compared to exercises that involve actual design or programming.
While academic teaching can usually present material that's free from product bias, genuinely independent training is rare in the embedded world. Companies such as Feabhas, a UK-based training firm, provide embedded systems training that is independent of a product sponsor. They are the exception rather than the rule.
Apart from pure language training, most embedded training is either provided by, or sponsored by, companies selling tools or components, be they emulators, RTOSes, or processors. While this training is often of high quality, the students should understand that the opinions they hear are one-sided.
I have heard RTOS vendors provide copious amounts of excellent information on how to create tasks, avoid priority inversions, and tune resource definitions, but they rarely explain that sometimes an RTOS is not a good match for the design challenge at hand. (If you're interested in the roll-your-own RTOS question, you should take a look at Jack Crenshaw's March 2002 column, “Mea Culpa,” p. 13). I do not particularly blame the RTOS vendors, but by failing to provide comprehensive information, they lay the onus on the student to fill in the gaps left in this technically accurate, but less than universally applicable instruction. And if the student does not realize the gaps are there, how will he find out?
If you're attending product-specific training, keep a skeptical ear, and remember what Mark Twain said: “I have never let my schooling interfere with my education.”
Points about PowerPoint
A few years back, the keynote speaker at the Embedded Systems Conference, Cliff Stoll, gave an animated talk in which he raised a loud cheer for a few shots he took at PowerPoint. Slide shows were an easy target when you consider that the majority of the audience spent the day attending classes that were dominated by PowerPoint presentations. Amid the humor, the point Cliff was trying to make was that education is not about slick presentation, but the connection formed between the teacher and student.
Cliff Stoll has preached far and wide that the integration of computers into U.S. schools has been a bad thing, especially for the youngest students. He even wrote a book about it, High-Tech Heretic: Confessions of a Computer Contrarian (Anchorbooks, 2000). And I wholeheartedly agree with him. Early education should be more about acquiring a hunger for knowledge than about facts and figures-especially when so many kids spend their time away from the classroom in front of one screen or another.
In the context of the conference, however, Cliff was probably off the mark. In an hour-and-a-half-long presentation to dozens of people, it is very hard to form a real connection. Short presentations like those at the Embedded Systems Conference are about condensing lots of technical information into a short space, so that the student can leave knowing whether the technology discussed applies to the problems that he has to solve back at the office.
Of course, PowerPoint does have its down side. Flashy fonts, animated bitmaps, and slick style sheets allow an instructor to make even the most pointless information look professional, hiding the inadequacies of the material-or of the presenter. You should always let the presentation drive the choice of slides, rather than allowing PowerPoint to drive the show. PowerPoint also gets in the way of the war stories that I mentioned earlier. Such anecdotes often do not lend themselves to slide presentations. My advice is to turn off the projector for a few minutes and take the risk that the students might look at you instead of the screen.
A recent BBC radio show reported how rigidly some PowerPoint users stick to the templates provided by the Content Wizard. The users assumed that the set of templates provided by Microsoft was based on established formats. The Microsoft representative who spoke on the show admitted that the templates were put together on an ad hoc basis, and it was never intended that they be followed rigidly. This raises the issue of how much a productivity tool can influence the thinking of the presenter. While PowerPoint does not provide much in the way of templates for technical presentations, I noticed that the template for “Company Meetings” has a title of “Headcount” on one of the slides. I wonder how many agendas have had this topic added, simply because it was there in the template and the presenter allowed the tool to drive the development of his presentation, rather than the other way around.
The costs of training, and the desire to reduce travel lead to some interesting options. On-line training is one possibility.
Unfortunately, a small market like embedded systems has less opportunity to benefit in this area. It is estimated that to present one hour of training material requires ten hours of preparation, while one hour of on-line material requires one hundred hours of preparation. Because on-line material does not require the trainer to be present in person for that hour, the return for that extra investment can be handsome. However, achieving that return requires a large market. Markets of this size can be found in selling word processing courses or even C++ courses, but once you get into embedded systems training, there are few areas that have consistent demand.
Making on-line training interactive is the part that consumes the most effort. Bruce Eckel struck a good balance with his Thinking in C++ and Thinking in Java CDs, which present information in slide format, accompanied by his voice, which is probably a close simulation of being present at one of Bruce's personal lectures. It is a format I might be tempted to emulate if I were to immortalize some of my own training on CD.
Niall Murphy has been writing software for user interfaces and medical systems for ten years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy's training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at . Responses to this column can be found at .