back
14 comments
I too have made the transition from "full stack" (well, backend mainly) dev to systems (& embedded) over the last decade or so. I generally present myself as a "software generalist with a systems focus" -- I'm by no means a systems eng expert, but it's become my sometimes fanatical interest and I love working on "harder" CS and lower level problems. But TBH I'm seriously considering doing a bit of a voyage back into the backend of web-facing stuff.

And only because the job selection -- especially locally, (and remote is getting harder to find) -- is far far better. Even if the type of work isn't usually as interesting. 9/10 of the jobs out there are some variant of this.

It can be scary to pigeon hole yourself into any specialist category with which it gives you less freedom of choice in the market place and be forced to make hard decisions on where you live and work. At least for me it's why I continually push towards being a generalist. That is, of course unless your talents in some specialist area are so fundamental to most companies that you'll be sought after for those skills and paid handsomely for the fact.
Backend engineer with sysadmin/OS knowledge is a powerful if not necessary combo. A great backend engineer will have a working knowledge of k8s/systemd/etc and their OS kernels. They won't be afraid to look at some lower-level C source code to debug something nasty.
What was your path into systems and embedded work? I'm familiar with embedded arm tool chains enough to build some interesting devices, but not knee deep enough to do something like say build medical or space devices.
I have worked on the "soft" side of embedded for some time, and by that I mean Linux on ARM SoC systems. That transition came about while I was at Google, and was able to transfer out of ads and onto various consumer hardware teams. And was concurrent with a personal interest in hobby electronics, microcontrollers, FPGAs, retro computing etc. I worked on the Nest Home Hub and some other similar things at Google.

These days I work on some systems for autonomous agriculture, which is mostly in Rust, and again Linux on ARM SBC type work.

Really, I wouldn't say I'm an expert in embeddedd; I'm no EE, and while I've played with board layout I'd never trust me to build hardware :-) And I've never been the person doing initial board bring-up, though that could be fun. So, again, generalist with a lower-level systems interest/focus.

Anyways the transition happened roughly on that path. With a zig-zag over to database internals for a bit which was also very cool. FWIW I've been a software developer in some form for about 25 years now. Maybe more depending on how you define it.

I'd say embedded is a bit of a trap and a mixed bag career wise though. Others here have made this observation before: EEs are in my opinion underpaid, and work adjacent to EE suffers from the same problem. It's a bit like gamedev, people like to do the work which I think increases competition for jobs? Something like that.

(That said I'm happy with my compensation right now)

(Also even the ads side at Google was a bit systems-y; realtime bidding, low latency, all in C++, a bit of mixture of high and low-level.)

Thanks for writing this! I'm not the one who asked the question, but I found it inspiring :)
I may be showing my age, but for me "full-stack" has always meant someone who can program from device drivers ans OS code all the way to the application, not a web developer who can do both the JS front-end and web app server backend.
There's some generational drift at place, for sure. I have heard "Full Stack" to mean JavaScript FE + service layer BE in a lot of the line-of-business world. I assume it is mostly a reflection of where widespread economic activity for software development takes place. The vast majority of companies aren't writing device drivers or kernel modules.

It's kind of like reading old (pre-XP) texts about testing that refer to testing a program in a family as "unit" testing. Not technically wrong because it all depends on how you define a unit, but definitely a sign of linguistic and economic drift.

I am old, too, but for me the term "full stack" only showed up during the last decade or so, in connection with web programming, meaning "frontend and backend". I never heard anyone using it your way. Actually I think I never met anyone coding devices drivers as well as GUIs :-)
It has a bit of infrastructure as code / drops implied, but ultimately it is a term to make "JavaScript programmer" sound more important.
Yeah from a distance it seems the thing that has happened that significantly changed things is that JavaScript became an acceptable backend language. So the split between people who wrote JS on the front side of things, and people who wrote Java/Ruby/Python/C# (or, err, PHP or... going back... Perl) on the backend has mostly vanished. And the new term became "fullstack" which, I dunno, it's kind of a funny term.

Having been out of web-facing things for a long time, I think I'd feel pretty alien being dropped into a TypeScript-on-Node codebase. I'd have no problem picking it up having played with it a bit over the years, but it still strikes me as a bit odd. And I find the JS frameworks out there like React etc absolutely terrifyingly overwrought.

The only way a bespoke component model framework works is if everyone adopts it. All the multitude of Java component-based web rendering systems failed.

Luckily for react everybody did basically adopt it so their component model did not fail.

It is always funny to watch people mock Java in the 1.0 version of their framework and some other thing and then come back and look 5 years later and their stack is easily or greater and complexity than the old Java stacks.

Well in general, I've noticed 'computer scientist', 'software engineer', etc has come to be synonymous with 'web dev'. I'm an AI compiler engineer, and when I introduce myself to people who I meet who themselves are web dev engineers (which is the majority), they'll ask me 'what framework' I use (obviously supposed to mean React, Vue, etc). No judgement.... just something I've noticed
"Beware of bugs in the above code. I have only proven it correct, I have not tested it." --Donald E. Knuth