> "Why do you still want to learn low level code/hardware/ways of doing things? It seems the industry keeps moving towards higher level frameworks/hardware/products."

> ... someone has to build the world that the easier to understand, higher level pieces live in."

Ah I love reading that! Some people really enjoy watching other people use or get use out of something they built or helped build. Some people just like knowing that the things they built or worked on are useful to folks and make their days / lives a bit easier. Then there are folks like you who are content to know that exactly because nobody knows your work exists or knows that you worked on that work specifically pretty much means you've done a great job. I'm sure that's an entirely different type of good feeling of knowing the things you worked on were useful.

IMO the reason to do embedded is it's super cool. You can actually hold something up and say "I made this". I don't really care for web because it's so ephemeral. I want to be like the previous generation that could point up at the sky at Hubble and say "My code is running on that".

Unless you really love doing low-level stuff, I'd still probably recommend you don't though. As a career, it just doesn't give you the same opportunities.

Yes, there are jobs, but I doubt you'll find the scope for advancement, and mobility that being a skilled dev (with good bit manipulation/low level skills) would give you.

An SRE role at Google might be a good example of a position that would involve a good deal of low-level debugging, but is still paid well, looks great on a CV and could advance you to other (and equally interesting positions) easily.

I actually find the opposite to be true. I can spin up containers, write ruby backends and do frontend design like anyone else. Moving up the stack is easy, especially when you know a little something about the performance impact of doing this vs that. I've seen a lot of people try and fail to move down though. It's a very complicated world that requires a lot of time to get comfortable in. Yea, driving peripherals is "just" writing to a particular memory address but where do you start? How do you find all the relevant documentation? What are the unwritten conventions of how that's done? Big endian/little endian? How long can I make this Interrupt Service Routine before things start to break?

I agree with this. Did embedded for years. Actually started out doing device drivers—as far as I know my name is still on a little driver .c file in the Linux kernel, my one meager claim to fame in life LOL. I eventually left the field partially because of the nonexistent career growth curve. Kind of sad that you can make 2-3X what a typical embedded programmer makes by barely holding some front end JS together, but that’s the reality of supply and demand.

Yeah that is not true at all. I've been doing embedded work for about 8 years and regularly get recruiting messages from/interviews with Apple, Amazon, and Google along with a bunch of smaller companies from around the US. I am currently at a startup working on autonomous quad-copters and we basically can't find really talented embedded engineers. Between IoT and autonomous systems the market for embedded developers is great right now.

Depends on location perhaps? But personally I've not seen that. Google etc. will always be looking for all kinds of people. But are they looking for as many embedded devs? Are they senior positions? If you want to progress within those companies will you need to move out of embedded dev? Those are the questions I'd ask I guess.

Unless you love doing X stuff, I'd recommend that you don't do X stuff because people should ideally do what they love and avoid doing what they don't love.

What I mean is there are aspects of embedded work that can be found in other jobs which are potentially more lucrative and may make your life easier later in your career. So, unless there's something in embedded work in particular, that you can't find elsewhere, it might be considering those jobs.

An example might be, if you like bit twiddling, digging into hard often hardware related problem, you might consider something like an SRE role.

I say turned, when more specifically I'm just a jack of all trades at a small software shop that does custom work across all three domains. I do truly love it, and I'm using it to segue into some EE experience as well, but the majority of my work is still in the mobile side, albeit interacting with the firmware dev I do (lots of BLE stuff).

That sounds like a really nice mix of work. Personally that sounds like great fun. It's also giving you a skill set that you could transition into starting your own thing (building your own product prototypes if you get enough EE stuff). Which sounds great!

I was in this space for a while, working on Airport sensors and then Elevator controllers.

Every job I found was short term or contract. I really enjoyed the work but I did not enjoy the ever-present need to be looking for a job.

Was I just looking in the wrong place or is it mostly short term/ contract work?