DISCLAIMER: This post is in no way meant to discourage Firmware/Embedded development. A lot of great consumer electronics, life-saving devices and commercial-grade equipment are made possible by C/C++ developers writing quality firmware. Rather, it is meant for developers looking for advice on how to accomplish this if they feel that firmware/embedded development has run its course for them for personal or other career reasons.

On waiting

You may have fallen in love with embedded development because of that mid-year real-time embedded systems course you took in college or final year project and then landed an internship leading to a full-time role building some exciting technology using your C programming skills. I have to admit that I found embedded development pretty exciting with the bit-twiddling, working with low-level hardware and building cutting-edge smart consumer electronics.

However, at some point in your career, you may start leaning toward other areas of software development for reasons unique to your circumstances. If you are an intermediate developer with 3-5 YOE in firmware development, don't wait to make the switch when you become a firmware developer with 8-11 YOE. It's not going to help. You may, inevitably be labelled; and, while doing personal projects (like building web/mobile apps) may help, the level of complexity expected of a senior developer may be hard to produce on personal projects in the new domain you are looking to break into.

In short, if you have the itch to switch, don't delay and start planning early.

On up-leveling and up-skilling

Due to your YOE, you may be reached out to by recruiters inviting you to apply for development roles, these may inevitably be application development roles. Resist the temptation to accept the invitation just because it is a Fortune 500 company (or FAANG).

If you make it to the interview, you will have a hard time convincing the hiring manager why you want to move from a Firmware developer role to an application developer role. Look at it as two variables: uplevel (moving from non-FAANG to FAANG) and upskill (moving from FW development to web/mobile/application development) and change only one variable at a time. If you want to accept the interview request, inform them that you are looking for Firmware developer roles. Turn down the request if they are not hiring for FW developers.

The upshot is to avoid changing two variables in one go.

On learning resources

Be honest with yourself when choosing what resources to use for up-skilling. If you feel you will not be able to exercise a lot of learning discipline then registering in boot camps may be for you. These boot camps will be pricey but will have a lot of students in the same boat as yourself, live sessions, lots of teaching support, deadlines and homework to ensure you keep learning on a regular schedule. If you are on a budget or you feel you can learn on your own then the other end of the spectrum is getting a good book and building projects yourself as a way to acquire new skills.

In short, don't spend a fortune on learning new skills unless you have to.

On choosing your next domain

In talking with recruiters, I found that the term 'Software Developer' or 'Software Engineer' seems to have become synonymous with roles that had to do with digital transformation (namely web, cloud, data, AI). So, my recommendation would be to explore this space for your next adventure. Try to find lateral commonalities in skill sets/tech-stack and then edge into them. E.g., as a firmware engineer if you have been programming in C for a while, try to move into a role where you use C++ so that you can get exposure to some higher-level constructs as many of these digital transformation roles use higher-level programming languages. Another example is that if your role is tied to writing firmware for a specific piece of hardware or silicon block (think DMA engine in an SoC or some other IP block in a microcontroller) try to move into a role or take on tasks that allow you to move away from the hardware and at a higher level up in the stack. For example, in a network router moving from developing firmware for a packet processing engine up into IP/MPLS protocol development.

On internal job postings

If you have been with your current employer for a while (say 5 years) and have been doing your job well then you can't go wrong with searching for job postings internally to see if there is a match. Your current employer may make concessions for your lack of experience or in your new domain like no external employer that you may be considering applying to will. Of all the points above in this post, this is, perhaps, the single most effective way to change domains even if it means a significant departure from your current tech stack. For example, if you switch internally (provided there are internal requisitions open) your employer may have no qualms about hiring you as a web developer even if you have been writing firmware for several years previously. One of the reasons is you belong to the same tribe i.e. you may not have the specific experience with the tech stack but you know the company's vision and product roadmap and, potentially, numerous internal references to vouch for you and your work.

In short, don't underestimate internal postings and how much your employer may value you as an internal hire even if it seems like a big jump from your current role. This is the best way to change domains.