It was interesting to hear the different perspectives from a broad spectrum of embedded systems professionals.

Do you agree with the speakers? Please feel free to add a comment and let us know what you believe are some of the essentials skills that embedded systems engineers should have these days!

Wow what great collection of insights. Interesting to see how often non-technical skills come up and to hear how important the skill of learning is especially with the broad range of individual skills presented in total.

A lot of great insights were provided here, and this is a subject that has been on my mind a bit in recent times as I meet a lot of people coming through coding bootcamps that get into web development. I often have to explain that what I do is decidedly different and calls upon a quite different skill set.

To me, the big things that distinguish being an embedded software engineer from doing other software are having to know hardware on more than just a passing basis (since much code involves controlling/manipulating it) and operating systems concepts like memory management, multithreading, task management and inter-process communication. There is more, of course, because this is multi-faceted as many in this presentation convey, but those two stand out the most to me.

Two of the speakers made points which resonate with me.
Jean Labrosse's comments on documentation and source code readability: a friend of mine once told me source code has 2 functions:

1. Communicate to the computer what you want it to do
2. Communicate to other developers what you want the computer to do.

Function 1 is obvious, but function 2 is not seen as obvious but is just as important.

Jack Ganssle's comment on the problem with specialization and the need for life-long learning: One of my career philosophies has been to avoid specialization as much as possible, and be a "generalist" with the ability to specialize as-needed. This has not easy and has required continuous learning (including a recent trip to grad school), but has allowed me to continue to do what I want to do - be an engineer and solve problems.

I think all the speakers made great points.
I feel that a corollary question is: how do we get more people (graduates and non-technical managers) interested in and appreciative of this field, which is niche as well as vast and complex?

It was very informative. I was surprised how much personal skills were exposed here as an essential skill and how hight level stuff is becoming more important these days as hardware is getting powerful.

A great presentation by many good practitioners. Common themes throughout. Keep learning. Grow with your skill at software and at communicating with others. Allocate time in your day to try new things and understand the topics of the day in your field.

+1 for ensuring you have good requirements before starting writing any code, understanding the business and quality tradeoffs, ability to communicate well cross-discipline and writing maintainable code.

This is really fantastic piece of information! Thank you very much

Really agree with the skill of continual learning, and I would apply that to both technology side and the process side. Embedded development often leaves test, integration, and deployment as a second thought but is becoming ever more important with higher level and more capable embedded systems.

Great answers. A common topic I heard was the importance of security. Definitely not something typically taught in your undergrad courses.

I can really relate to the comments made by Jean Labrosse. Nobody thinks they have time to document things at the time they are developing them so the next guy will understand the system. Too many people thought Doxygen was the answer to this issue, but it's usually not. The take away I got from this session was the need to keep current and be willing to learn new ways of doing things as they come along.

Dave, I agree with your first statement, "Many of the skills are not taught in college and asking many questions" though I am torn on fixed bid versus per hour. If the job is a ?rinse and repeat? then a fixed bid makes sense, but you still will have many things out of your control, for example, supply chain as the COVID-19 market disruption has illustrated well. But if your customer is doing a first-time/prototype and is fuzzy on needed details, then per hour makes more sense. For example, I developed the firmware for avionics display, and I had no idea how long it would take and had never developed a product like that before. The customer did not even have a formal/detailed interface specification. That project started with a month of using a digital logic analyzer and a marketing spec to create a formal specification. A few years later, I was hired to do the next-generation display and add several new hardware features. We made major changes to the hardware and software architecture, but I was confident I could complete everything by the deadline they set. I still remember using dental floss in a hotel the night before the trade show to keep a cable from disconnecting, but we had a fully functional product to demonstrate. The great irony though in the above example, the first was a fixed bid and the second was per hour. The first nearly put me in the hospital and I literally slept under my desk for weeks and the second was one of my most enjoyable experience I had.

There are so many skills developers need today, it makes my head spin!

Great idea Stephane! The big idea I am hearing here is to always be learning and flexible. The speed of change is amazing and different industries move at different speeds. I designed a WiFi Router for a major commercial aircraft based largely on COTS technology about 15 years ago and the owner of the WiFi Radio IP changed hands 3 times before the aircraft made its first flight.

I agree with the common suggestions: learning all the time. In the last two years more than work the embedded systems in C language and FreeRTOS... I have learned many backend languages that process the information generated by the devices sending to the cloud over MQTT... I have learned Python, Node.js and many AWS serverless technologies that permits process the information received... Learn quickly and many different topics is the new skills nowadays

When it comes to essential skills (all relevant skills matter, but not all of them are essential) that today's embedded systems engineers need to have I totally agree with Jack Ganssle's words "Develop the skill of how to learn constantly".

Domain knowledge is the most important for me. You have to understand the system/product you are writing code for. This is a great way to ensure you understand the problem you are solving as engineer, hence making you write better code and avoiding problems in the future.