For almost 3 years now, I have had the LinkedIn headline of “Hardware Engineer, Aspiring Firmware Engineer”. That latter title remains, and feels like it might for my whole career.
As I tend to do, I have procrastinated this article for almost a year. In doing so, I get to include some learnings from the rise of LLM coding agets in the firmware space.
What was the initial interest in firmware?
As I described in the last full post on this site (in 2021, oof), hardware design is ‘choppy’. The amount of time spent in deep design cycles is minimized when things go well: either a product is simple enough to be captured in a short timespan and/or the resulting hardware has few enough errors that the debugging is minimized. Said another way: “if things are going right, you’re not spending a ton of time on hardware”.
As a service provider and someone doing board bringup, the capabilities of just about every chip is dependent on firmware. I wanted to develop some self determination in building products and more broadly, solving problems.
I have tried courses, books, and tutoring around firmware, all of which have helped. But it’s the hands-on struggle that continues to be the thing that focuses me in on weak spots.
The fear is still there
Some writers talk about the blank page. Some runners talk about the first step. I think for me, it’s firing up the debugger.
If I can get past that first step and get into code, I am fine. That first run is a big barrier for me. Why? Probably impostor syndrome mixed in with some fear and a proclivity for good ol’ fashioned procrastination. In short: I don’t think I can do the task in front of me.
This article started after I watched Laura Kampf’s video celebrating her 500th video.
She descrices how people that I view as the top of their field are feeling the same things I am. Sure, I have “20 years” of experience under my belt. With firmware? Much less.
That video is fantastic because she shares a lot of the methods for getting in the right headspace for building things. Laura does it on a regular schedule and that is a hard thing to do. Building the right habits and understanding how to build forward momentum are crucial.
For me, it’s important to open up my code editor with a cup of coffee and a reminder to myself that the best coders in the world take problems one step at a time. If you’ve seen problems, even completely unknown scenarios, and pushed through them before…you can push through them again.
Skills I’m working on
I am currently interested in the following, many things subject to change
- Zephyr RTOS and its various quirks
- Debugging
- GDB tooling
- Utilizing design patterns
- Architecting code
These are in addition to the growing list of hardware things I want to develop, especially in the low power and RF space.
Skill building? In THIS economy?
I mean, yeah, you’ll probably notice that many of my ’thoughts’ on this blog (my new shortform / microblogging style posts on the homepage) includes musings on the impacts of LLMs. I feel them in my uptake of firmware work, and they’re creeping into the periphery of my hardware work too. I am trying to stay positive, especially about the posibility of the lowered barrier to entry bringing more people into the fold (I referred to myself as “The Walmart Greeter of Electronics”). But as I have procrastinated this article, I have seen my own opinions change, quite rapidly.
12 months ago on the topic of LLMs and firmware I wrote:
I don’t trust LLMs / coding tools for firmware work. I won’t be using them. Too often I have run into Claude or Gemini trying Zephyr projects and I need to repeat over and over again “I need you to use the latest version of Zephyr, not the one you indexed 6 months ago…this version now longer works!” All of the training data was on the legacy versions of Zephyr. Luckily if I should something like “read the code!” or “read the !@$(&@) docs!” into the air enough times, I usually think, “oh yea, I should do that too” and the problem resolves itself.
6 months ago on the topic of LLMs and firmware I wrote:
I recently saw LLMs referred to as a lazy person’s documentation manual. I like that description, both from highlighting its strong suit but also in describing how I think it’s best to lean on code assistance. I am happy to let it check out my pointer notation and even suggest different elements. I am a bit further from releasing an agent to do everything and present its work back towards me. In fact, I think understanding the ingredients of the code are still key to the most important skill of hardware/firwmare co-development.
Today on the topic of LLMs and firmware I write:
I am not sure I ever need to write firmware again. It is incredibly fast now to point it at a repository or just the Zephyr docs and … away it goes. But if I really step back and think about it, that means I am going to have to fight my better nature more now than ever to really take time to study how to do these things. If i just let go of the wheel, I will let the brain rot set in and I’ll never understand how any of the things work. The LLM will output code, I’ll check the output and shrug and say “yah whatever” and when things break…it will go poorly.
Troubleshooting is the skill
Even back in 2024 as we started seeing the rise of LLM assisted tools, Dave and I discussed how “troubleshooting is the (critical) skill”. If you let a coding assistant take the wheel, you need to understand that what you’re working on and what is going wrong. Simply saying something like “try harder” to a coding tool will be a recipe for inducing madness (ask me how I know). There are many thought pieces on how this is a ticking time bomb for code. I’m not so sure. I think the next generation of model is better than the last and the fixer of early-generation LLM code is probably later generational code. I instead worry that we’ll have nothing to add and soon will be out of the loop entirely. If you’ll pardon to the comparison, the hardware industry of the US and Europe in the 90s migrated to the China-based hardware ecosystem of the 2000s and beyond. Manufacturing–and eventually design–was once a task that corporations gleefully handed off. Then the bright young minds in Shenzhen and Shanghai built their own skills and now possess a corpus of knowledge not available in many other parts of the world. I could see code going in the same direction. We are what we repeatedly do, and if we hand off all tasks to different parts of the world or to intelligent systems…the knowledge base will wither on the vine.
Where do we go from here?
For me, it’s about building practice. Finding roles and projects that require me to stretch my skills and have a timeline that allows me to put in the work. The impetus to just hand it off to an agent will be strong, so it will need to be a deliberate practice. Otherwise, I’ll be an aspiring firmware engineer the rest of my career.