[leoedin]

The embedded world is crying out for people experienced in modern software teams. A big chunk of it is one man bands who know C and maybe some C++. Most embedded projects could benefit from unit testing, automated build systems and modern memory safe languages.

If you're interested in a job in embedded you could learn it on the side. Buy a dev board (from one of the main vendors - ST, NXP or TI) and write an application for it. Learn the detail of developing for microcontrollers - setting up peripherals and clocks, debugging over JTAG, handling interrupts etc.

If you manage to get in front of a hiring manager with a couple of well executed open source low level projects along side experience in higher level languages, you'd have a good chance of getting the job.

[HeyLaughingBoy]

> A big chunk of it is one man bands who know C and maybe some C++

The parallel here to "enterprise development" is the small companies that have one guy who knows C# or VB. Pay's also about the same, as is the (non-existent) level of process automation.

I agree with your point, but I don't want compare apples to oranges. The "embedded world" that's "crying out for people experienced in modern software teams" is the one that's doing large projects with teams of 5-20 developers, not the ones with one or two. If you want to find those teams you'll need to look at the projects that require lots of people like Defense or complex medical devices, etc.

I've been doing embedded systems for my entire career and TBH, I don't much care if a candidate has ever seen a dev board or used a logic analyzer. It's a nice to have, don't get me wrong, but I care a lot more that they understand SOLID, version control, unit testing, can speak intelligently about why they love or hate TDD, etc. We typically already have people with enough low-level experience to build hardware abstractions that the "enterprise people" can program to.

These days, someone who understands software security on interconnected systems is a much more interesting candidate than one who can bit-twiddle on an 8051.

[unmole]

> The embedded world is crying out for people experienced in modern software teams.

The embedded world refuses to pay through.

[nalydmerc]

Hi, one man band here doing firmware at a small company. Could you elaborate on any particular skills, or tips for this sort of thing? Right now I'm trying to learn how to integrate unit tests into our newer/future projects, and setting up a Jenkins server for builds. I'm learning a lot, but it's difficult since I'm the only guy that understands firmware at my company, and these are fairly large projects to take on as a single person when there are other things I need to be managing.

[leoedin]

The things I've found are productivity and reliability multipliers are:

Unit testing - and the modularisation that it forces you to do. It's great to unit test C not just because it tests your code well before it runs on hardware, but also because it's basically impossible without embracing dependency injection and modular "object oriented" C. Personally, working with a bunch of higher level languages - Rust, C#, Scala, Python - and the tooling that they have gave me a much better understanding of how things can be done. I'm a big fan of Ceedling - http://www.throwtheswitch.org/#download-section

Writing firmware which can target a desktop environment. The hardware dependencies should be a small part of the project, and easily replaced with fakes or simulators.

Having a CI pipeline which runs tests/linters/builds for you.

Those aren't necessarily easy to insert into an existing project though. Honestly I think the most useful thing is just building projects using other languages, and taking the best parts back into the low level code. It depends a bit what kind of projects you're working on - if it's mostly just glue between peripherals then these approaches are a lot less useful than if you're doing complicated maths or json parsing or higher level stuff.

[HeyLaughingBoy]

Short answer, as someone who has BTDT (although as the tech. lead): you need to get management buy-in to upgrade your processes. Doing it yourself either leads to failure or resentment at working too hard for too little appreciation.

[bitwize]

> The embedded world is crying out for people experienced in modern software teams.

The embedded world requires VERY specialized skills, and pays significantly less than enterprise webshit (let alone FAANG webshit).

I'd LOVE to get into embedded, but I can't afford to make 2/3 to half of what I make now.