Too Many Tools. Not Enough Time.
In the fast-moving world of embedded systems, staying current often feels like trying to drink from a firehose. Every few weeks, there’s a new RTOS, toolchain, board, protocol, or abstraction layer claiming to make development “easier” or “faster.”
You’re probably juggling deadlines while also asking yourself:
- “Should I switch to Zephyr or stick with FreeRTOS?”
- “Is PlatformIO worth it over Make and CMake?”
- “Do I really need Rust right now, or is C still fine?”
This is the paradox of embedded development today: more options create more complexity. It’s not a shortage of tools: it’s an overabundance of them, and not all of them serve your goals right now. That constant pressure to keep up can quickly turn curiosity into burnout.
The truth is, there’s no shortage of powerful tools, but not all of them are right for your project, right now.
This is the paradox of modern tech: information abundance breeds decision fatigue. With so many options, tutorials, and opinions, it’s easy to fall into the trap of constantly exploring instead of actually building. Worse, the fear of “missing out” or picking the “wrong” tool can paralyze progress altogether.
Focus Only on What You Need Next
So, how do you stay updated without getting overwhelmed?
The answer is simple, but not always easy: focus only on what’s relevant to what you’re building or where you want to go next.
You don’t need to understand every embedded language, framework, and architecture. You need the one that works well on your hardware, integrates cleanly with your development flow, and is proven in your type of application. That’s it. The rest can wait. You need the ones that:
- Run well on your target hardware
- Fit your workflow (and your team’s)
- Are stable and proven for your application domain
This kind of intentional filtering, what some call “just-in-time learning”, isn’t lazy or shortsighted. It’s strategic. In a world where tech changes every quarter, depth matters more than breadth. Mastering a few tools deeply, based on your immediate and upcoming needs, will always beat skimming everything superficially.
A Simple Framework for Choosing Embedded Tools
When evaluating a new tool or framework, ask:
- Hardware Support – Will this work with your MCU or board? Whether you’re using an STM32, ESP32, NRF52, or a custom SoC, compatibility is non-negotiable.
- Toolchain Fit – Does it integrate well with your compiler, debugger, and build system? If it breaks your CI/CD flow or adds layers of unnecessary glue code, think twice.
- Ecosystem and Docs – Are other engineers using this in similar projects? Is the documentation up-to-date? Can you find working examples? A healthy ecosystem reduces guesswork.
- Workflow Simplicity – Does it simplify your job or add friction? If it takes 10 steps to flash firmware or debug a peripheral, it might not be worth it.
- Longevity – In many cases (especially in the embedded world), you need a tool or framework to be around for 10 years. Does the framework in question have a history of support and updates, backing by industry partners, used by others in the community? Or is it a one-off student or hobby project that might lose support in 6 months?
Asking these questions will help you eliminate tools that don’t fit your current project, so you can spend more time building and less time yak-shaving.
Depth Over Breadth = Confidence Over Chaos
We often see engineers spin their wheels chasing every new tool, hoping one will “solve everything.” But more tools often mean more complexity unless you’re clear on your needs. The most productive developers aren’t necessarily the ones who know every acronym or chase the latest GitHub stars. They’re the ones who ask:
- “What problem does this tool solve?”
- “Does it actually solve my problem better than what I’m using now?”
- “What’s the cost of switching or integrating it?”
If the answer isn’t clear (or you’re adding complexity just to keep up with a trend) walk away. The goal isn’t to know everything. It’s to know what matters for your stack and your product (or project).
Build Smarter with Purpose-Driven Learning
The pace of technological change isn’t slowing down. But your stress level doesn’t have to scale with it. If you want to build resilient, forward-thinking products, and stay sane doing it, adopt a new mindset: learn less, but learn it better.
When it comes to finding what frameworks and tools to teach, I personally go through the same process I outlined above. Keeping up with the sheer amount of tools, languages, and processes out there is frankly overwhelming. By going to industry events, chatting with fellow engineers, and watching social media and news, I keep an eye on trends (like Zephyr, Rust, etc.), but I won’t spend my time learning them until I believe they’ve reached a critical mass of following and demand in the embedded space.
I try to employ the principles of “just-in-time learning,” and I’ve seen it work well for other developers.👉 If you’re ready to start learning, check out my courses at https://shawnhymel.com/courses/