Education & Training Channel

An engineering education does not end when you receive your degree. The world of embedded design undergoes noticeable shifts in what developers can do with the available processing resources approximately every three years. This series focuses on how education opportunities are and are not meeting the needs of the embedded design community.

Is College necessary for embedded developers?

Wednesday, January 11th, 2012 by Robert Cravotta

A bill was recently introduced to mandate that high school students apply to college before they can receive their high school diploma. This bill reminded me that I worked with a number of people on embedded projects that did not have any college experience. It also reminded me that when I started new projects, the front end of the project usually involved a significant amount of research to understand not just what the project requirements were but also what the technology options and capabilities were.

In fact, while reminiscing, I realized that most of what I learned to do embedded development was learned on the job. The college education did provide value, but it did not provide specific knowledge related to designing embedded systems. I even learned different programming languages on the job because the ones I used in college were not used in the industry. A concept I learned in college and have found useful over the years, big O notation, has not shown itself to be a topic taught to even half of the people I worked with while building embedded systems. Truth be told, my mentors played a much larger role in my ability to tackle embedded designs than college did.

But then I wonder, was all of this on-the-job learning the result of working in the early, dirty, and wild-west world of embedded systems? Has the college curriculum since adjusted to address the needs of today’s embedded developers? Maybe they have, based on a programing class my daughter recently took in college, because the professor spent some time exposing the class to embedded concepts, but the class was not able to go deeply into any topics as it was an introduction course.

Is a college education necessary to be become an embedded developer today? If so, does the current curriculum sufficiently prepare students for embedded work or is there something that is missing from the course work? If not, what skill sets have you found to be essential for someone to start working with an embedded design team?

What makes a conference worth attending?

Wednesday, October 26th, 2011 by Robert Cravotta

Travel and training budgets for engineers (and possibly every profession) have taken a beating over the past decade. Gone are the “grand-ole-days” of huge conferences for developers that would take up multiple halls and you felt like a salmon swimming upstream to spawn as you walked the exhibit areas. Instead, show and expo attendance for these conferences is decidedly lighter than it used to be. The change in attendance has been so profound that a few single-company developer conferences were delayed, cancelled, or transformed into smaller regional workshops a few years ago.

The hopeful news is that there is a sense that design activity is beginning to pick up again. Conferences targeting developers seem to be returning, attendance is up, but it seems that most of the attendance is by locals who can avoid most of the expenses of travel. I was having a conversation with an exhibitor at a recent conference; we were discussing whether there was something that the conference could offer that would justify a growing attendance that includes more attendees that had to travel to get there. The conference offered many announcements for new or upcoming components and tools that will help developers build their projects faster, cheaper, and better. There were numerous workshops and hands-on training offerings that were all well attended.

One of the most obvious things gone from today’s conferences from the past is the over-the-top parties at the end of the day. I can’t help but wonder – tongue-in-cheek – whether the excessive parties were a symptom of the huge attendance or a motivator for it. As developers, we are creating more complex systems in the same or shorter time frames, often with smaller design teams than a few years ago.

On a more serious observation, the time and complexity pressures on developers today probably raise the bar on what a conference will deliver to developers to justify spending their time travelling and attending the conference. What makes a conference worth attending? What features or events have you seen that you thought were particularly valuable? Is there something missing from today’s conferences that makes them less valuable than previously? Or maybe the contemporary conference is doing exactly what you need it to do, but there is no time to attend. Do you find the recordings of the proceedings worthwhile or perhaps even sufficient?

Question of the Week: How much ambiguity does your team permit when assigning a task to a team member?

Wednesday, June 2nd, 2010 by Robert Cravotta

I shared a story a few years back about how when I was a junior member of the technical staff. I learned the value of explicitly allowing some uncertainty in assignments to members of the team. An excerpt from that story illustrates the key point:

The instructions for my lab partner and me were to characterize the camera system and to make sure the automatic-gain-control algorithm appropriately adjusted the camera’s sensitivity. How to test the system remained unspecified. The system engineer had not expected us to try to simulate a single pixel signal. Because we were not influenced by his assumptions about the camera system, we uncovered an anomalous condition in the lab that would have caused the vision system to fail when it was deployed [in low-gravity space].

… A key defining element of engineering is to be able to create systems that can deliver consistent, repeatable, and reliable behavior despite uncertainty and variability over some range of environmental conditions. Dealing with uncertainty is fundamental to being an engineer, and there is usually a positive correlation between the seniority of an engineer and the amount of uncertainty he needs to deal with in his job. It is important to allow some uncertainty to exist in assignments for even the most junior engineers, as it can be a source of growth for them—and it might save a project from failure.

This personal experience made me realize how important it is to provide wiggle room in an assignment, especially to junior members of the team, because it provides a mechanism for them to practice dealing with uncertainty and making guesses. It enables them to practice dealing with increasingly larger amounts of uncertainty as their skill and experience increases. It also helps prepare them for the very real uncertainty that senior members have to deal with when directing new and path-finding projects.

Do you, or does your team lead, allow or make room for ambiguity when assigning a task to a member of your team? Does your team use other methods of encouraging the members to think “outside of the box”? How does your team grow and mentor your junior members?

If you would like to suggest questions for future posts, please contact me at Embedded Insights.

[Editor's Note: This was originally posted on the Embedded Master]