embedded software (2)

5 Tips for Expanding your Embedded Skills

As embedded systems engineers, we work in a field that is constantly changing. Not only does change come quickly, the amount of work and the skills we need in order to successfully do our jobs is constantly expanding. A firmware engineer used to need to know the microcontroller hardware and assembly language. Today, they need to know the hardware, several languages, machine learning, security, and dozen other topics. In today’s post, we are going to look at five ways to expand your skillset and stay ahead of the game.

Tip #1 – Take an online course

Taking an online course is a great way to enhance and add to your skillset. If anyone tries to tell you that you don’t need additional coursework don’t let them fool. I’ve often been called an expert in embedded systems, but just like everyone else, I need to take courses to learn and maintain my skillset. In fact, just this week I took a course on Test Driven Development taught by James Grenning, the expert in TDD. I’ve been playing with TDD on and off for several years but despite that familiarity, working with an expert in a subject matter will dramatically improve your skills. I was able to pick James’ brain on TDD, enhance my skills and walked away with several action items to work on over the next several months.

Start by identifying an area of your own skillset that is deficient, rusty or even an area that you want to just move to the next level in. Then find the expert on that topic and take an online, interactive or self-paced course with them. (I won’t mention my own courses that you can find here … ooopps!  )

Tip #2 – Read a book

Books can be a great way to enhance your skills. There are dozens of books on embedded system design that can easily be found at any bookstore or online. Some books are better than others. I’ve started to write-up reviews on the books that I’ve read in order to provide you with recommendations on books. This is just in its infancy and can be found at: https://www.beningo.com/?s=book (I’ll be adding a category in the near future to the blog).

You might also want to check out Jack Ganssles book reviews as well which you can find at: http://www.ganssle.com/bkreviews.htm

Books that I am currently working through myself that I’ve been finding to be fantastic so far include:

  • TinyML
  • Clean Code
  • The object-oriented thought process

Tip #3 – Watch a webinar

Webinars are a great way to get a high-level understanding of a new skill or topic. I don’t think a day goes by where I don’t get an advertisement for a webinar in my inbox. Unfortunately, all webinars are not created equal. I’ve come across many webinars that sound fantastic, only to later discover that they are totally marketing focused with little real technical information. I produced anywhere from 8 – 12 webinars per year and always try to include high-level theory, some low-level details and then a practical example through a demonstration. It doesn’t always work out that way and every now and then they undoubtedly flirt with being marketing versus technical, but I always try to make sure that developers get what they need and know where they need to go to dive deeper.

Over the coming months keep a close eye on webinars as a potential source to enhance your skills. I know that I’ll be attending several on Bluetooth Mesh networking (hoping they aren’t pure marketing pitches), and I will also be pulling together several of my own.

Tip #4 – Build something for fun

There is no better way to learn a new skill than to do something! I’ve always found that people who attend my webinars, courses, etc learn more if there are demonstrations and hands-on materials. It’s great to read about machine learning of continuous integration servers but unless you set one up, it’s just theory. We all know that the devil is in the details and applying the skill is what sharpens it.

I highly recommend that developers build something for fun. More than a decade ago when I wanted to learn how to design and layout PCB’s and work with USB firmware, I decided that I was going to develop a USB controlled light bar. I went through an accelerated development schedule and designed schematics and a PCB, had it fabricated and then hand soldered the parts. I wrote all the firmware and eventually had a working device. I learned so much building that simple light bar and even used it for as an example during interviews when I was looking for a new job (this was before I started my business).

Even today, I will still pick a project when I want to learn something. When I was evaluating MicroPython I built an internet connected weather station. It forced me to exercise many details and forced me to solve problems that I otherwise might not have considered if I hadn’t dived into the deep end.

Tip #5 – Find a mentor

The times that I’ve accelerated my understanding of something the most has usually been under the guidance of a mentor or coach. Someone who has mastered the skill you are trying to work with, has made every mistake and can share their wisdom. It’s certainly possible to learn and advance without a mentor but having feedback and the ability to answer a question and then get an educated response can dramatically accelerate the time involved. That’s one of the reasons why I often host interactive webinars and even have a coaching and trusted advisor offering for my clients. It’s just extremely helpful!

Conclusions

No matter how good you are at developing embedded software, hardware and systems, if you don’t take the time to update your skills then within just a few years you’ll find that everyone else is passing you by. You’ll be less efficient and find that you are struggling. Continuing education is critical to engineers to ensure that they are up to date on the latest and greatest practices and contribute their products success.

Originally posted here

Read more…

The Anti-Quality Movement

by Jack Ganssle

[email protected]

Recently our electric toothbrush started acting oddly – differently from before. I complained to Marybeth who said, “I think it’s in the wrong mode.”

Really? A toothbrush has modes?

We in the embedded industry have created a world that was unimaginable prior to the invention of the microprocessor. Firmware today controls practically everything, from avionics to medical equipment to cars to, well everything.

And toothbrushes.

But we’re working too hard at it. Too many of us use archaic development strategies that aren’t efficient. Too many of us ship code with too many errors. That's something that can, and must, change.

Long ago the teachings of Deming and Juran revolutionized manufacturing. One of Deming's essential insights was that fixing defects will never lead to quality. Quality comes from correct design rather than patches applied on the production line. And focusing on quality lowers costs.

The software industry never got that memo.

The average embedded software project devotes 50% of the schedule to debugging and testing the code. It's stunning that half of the team’s time is spent finding and fixing mistakes.

Test is hugely important. But, as Dijkstra observed, testing can only prove the presence of errors, not the absence of bugs.

Unsurprisingly, and mirroring Deming's tenets, it has repeatedly been shown that a focus on fixing bugs will never lead to a quality product - all that will do is extend the schedule and insure defective code goes out the door.

Focusing on quality has another benefit: the project gets done faster. Why? That 50% of the schedule used to deal with bugs gets dramatically shortened. We shorten the schedule by not putting the bugs in in the first place.

High quality code requires a disciplined approach to software engineering - the methodical use of techniques and approaches long known to work. These include inspection of work products, using standardized ways to create the software, seeding code with constructs that automatically catch errors, and using various tools that scan the code for defects. Nothing that is novel or unexpected, nothing that a little Googling won't reveal. All have a long pedigree of studies proving their efficacy.

Yet only one team out of 50 makes disciplined use of these techniques.

What about metrics? Walk a production line and you'll see the walls covered with charts showing efficiency, defect rates, inventory levels and more. Though a creative discipline like engineering can't be made as routine as manufacturing, there are a lot of measurements that can and must be used to understand the team's progress and the product's quality, and to drive the continuous improvement we need.

Errors are inevitable. We will ship bugs. But we need a laser-like focus on getting the code right. How right? We have metrics; we know how many bugs the best and mediocre teams ship. Defect Removal Efficiency is a well-known metric used to evaluate quality of shipped code; it's the percentage of the entire universe of bugs found in a product that were removed prior to shipping (it's measured until 90 days after release). The very best teams, representing just 0.4% of the industry, eliminates over 99% of bugs pre-shipment. Most embedded groups only removed 95%.

Where does your team stand on this scale? Can one control quality if it isn’t measured?

We have metrics about defect injection rates, about where in the lifecycle they are removed, about productivity vs. any number of parameters and much more. Yet few teams collect any numbers.

Engineering without numbers isn’t engineering. It’s art.

Want to know more about metrics and quality in software engineering? Read any of Capers Jones’ books. They are dense, packed with tables of numbers, and sometimes difficult as the narrative is not engaging, but they paint a picture of what we can measure and how differing development activities effect errors and productivity.

Want to understand where the sometimes-overhyped agile methods make sense? Read Agile! by Bertrand Meyer and Balancing Agility and Discipline by Barry Boehm and Richard Turner.

Want to learn better ways to schedule a project and manage requirements? Read any of Karl Wiegers’ books and articles.

The truth is that we know of better ways to get great software done more efficiently and with drastically reduced bug rates.

When will we start?

Jack Ganssle has written over 1000 articles and six books about embedded systems, as well as one about his sailing fiascos. He has started and sold three electronics companies. He welcomes dialog at [email protected] or at www.ganssle.com.

 

Read more…

Upcoming IoT Events

More IoT News

Arcadia makes supporting clean energy easier

Nowadays, it’s easier than ever to power your home with clean energy, and yet, many Americans don’t know how to make the switch. Luckily, you don’t have to install expensive solar panels or switch utility companies…

Continue

Answering your Huawei ban questions

A lot has happened since we uploaded our most recent video about the Huawei ban last month. Another reprieve has been issued, licenses have been granted and the FCC has officially barred Huawei equipment from U.S. networks. Our viewers had some… Continue

IoT Career Opportunities