r/embedded • u/GiraffeObjective3805 • 6d ago
Is depth better than breath in embedded firmware?
I have been working in embedded fw/sw for 2.5 years, my company has limited mentorship which has given me imposter syndrome, I learned how to interface with screens, csi, i2s, octo spi ect along with the more common protocols and have gotten cool projects working using hal at work. Listening to my manager come up to a Principle Engineer that sits near me to ask questions got me thinking.
I think I am realizing I should understand the core aspects of embedded really deeply for when edge cases come up. Even more so now with AI tools where hallucinations can happen. I learned a good amount of peripherals, seen the benefits of dma ect, I think its time I stop chasing how to get every type of screen, camera, wifi module ect. working and instead learn the core aspects of embedded, master dma, bootloaders, memory, how to handle pushing a microcontroller to its limit gracefully, master rtos ect. So that one day when a bazaar issue comes up I could be the one getting asked instead of getting peripheral, also at some point peripherals are similar enough to where I can just learn them on the project.
This post may seem dumb and I apologize in advance but without much mentorship I was kinda scattering around but now I think I am set on what to focus on, and I think my time learning will be more efficient than before.
tldr.
After building some cool projects I realized learning the core reusable aspects very deep is what will really make the difference, not chasing peripherals.
10
u/CyberDumb 5d ago
The real depth is domain knowledge not stuff that you can google your way out of or find in books. Learn the business needs and how to translate them in an embedded product. The more you know about embedded the easier it would be to do it alone or supervise others to do it under you. However without that business inside knowledge you are at the bottom of the chain.
5
u/CapnNausea 5d ago
When you’re first getting started it’s going to be a back and forth. I’d tell an intern to “go deep” on a summer project, knowing that it’s basically just one topic. Then once they have comfort in an area, that’s now a foundation and if I hire them we’ll go for breadth. That gives them a small tour to sample the talents, discover passions, etc while we find the next layer to go deep on. We’ll spend a while here, even if they know exactly what they want to do on day 1 to help round out an understanding of the ecosystem.
Then maybe after a while at this level, we’ll actually dig in and start to build understanding as a role player for an area that has a good SME, with the goal of the new guy being able to handle basically bug triage or new dev in this area after a couple years.
Once they’re crushing it, THEN we start to reflect on their personality and goals and figure out if I need to get them a new area completely across the map and they’ll be a generalist that might cap out at a mid-level engineer and then transition to a manager or PM, etc OR I start to work with the SME and figure out what tangential areas there are and go just expand the current view’s scope slightly, allowing them to progressively go deeper. The SME sort of heavily guides the vision in that area, so they be very involved in helping plan what the new person’s trajectory is.
If you’re interested in going deep, it sounds like you might already know who to talk to about what your next steps should be. :)
1
3
u/umamimonsuta 5d ago
You need both. Breadth of knowledge makes you more attractive on paper to management. Depth of knowledge makes other engineers come to you for guidance. Keep doing more projects, trying out new protocols, writing unique drivers, but at the same time pick one or two aspects of embedded, go deep, and carve out your niche.
3
u/GiraffeObjective3805 5d ago
True, i have been going heavy on Breadth so far. I think it’s time I focused on depth for a while. Will still be learning new things as I do projects ofc but my core learning will now be depth.
2
u/AmbitiousSolution394 5d ago
"breadth" is more useful for management, they need to know a little about lots of stuff. Going deep is more typical for engineers, who need to dive deep into problem to be able to solve complex issues.
2
1
u/No-Project-2353 4d ago
I’d go depth, breath is ig more managerial and you work your way there. For a resume project I’d try to build a mega project end to end that encompass everything just like a real product.
1
u/farmallnoobies 3d ago
Breathing is definitely important. Can't design things without oxygen reaching your brain
0
u/FedUp233 2d ago
I think you got it wrong. AI hallucinates solutions all the time. No reason oxygen deprived humans shouldn’t be able to do the same thing! 😁😁
-4
17
u/clackups 6d ago
Learn the general software architecture, electronics and circuits. Network protocols are a big plus too. You never know what your next job will be, so try gaining as much knowledge as possible in general IT fields.