
Ask HN: How do I transition from full-stack web-dev to systems engineering? - vector_spaces
I&#x27;ve been working for the past year as a software engineer. Half of that was for a consultancy, and half as a backend engineer writing business logic &#x2F; REST APIs, + some moonlighting for friends and family who need a site or app or data munging help. Before writing code professionally, I worked for about 10 years in product-adjacent and operations roles.<p>I&#x27;m self taught. I love to code and spend most of my free working on personal projects and trying to fill in the gaps in my CS knowledge.<p>That said, I&#x27;m finding myself much more drawn to creating tools and languages than working on CRUD&#x2F;business applications. It&#x27;s a dream of mine to work on building runtimes and server infrastructure rather than the business software that sits on top of it.<p>I&#x27;ve been learning C and Rust and PL implementation, working through operating systems books, and recently picking up assembly from that and GameBoy programming. That said, I feel like the amount I need to learn is crushing, and I&#x27;ll still have no idea what it&#x27;s like to apply that knowledge in a production setting. The job postings for systems engineers I&#x27;ve been seeing all seem to require several years of experience + experience managing systems with thousands of hits per second + contributions to the Linux kernel + a degree. I can&#x27;t go back to school at this point in my life and barely have time for the side projects and self studying that I do. So, feeling a bit defeated.<p>Questions&#x2F;tldr:
1. Is it realistic for someone to become a productive self-taught systems engineer? Are you or someone you know a self-taught systems engineer?
2. I get that systems engineering probably looks different at different companies, but if you are a systems engineer, what concepts do you find yourself calling upon on a daily basis to do the work that you do? I&#x27;m asking this with an eye to paring down the different subjects I feel I need to master to get where I would like to be.
3. If you were in my shoes, how would you proceed?
======
CyberFonic
The term, systems engineer, had different interpretations depending upon the
environment and context. In my experience, in IT the term could be better
described as systems integration, i.e. building systems out of sub-systems. I
have engineering degrees and decades of experience and yet I wouldn't claim to
know more than a fraction of what you allude to in your question.

Very loosely speaking there are there major areas of systems engineering,
mainframe based, large-scale Windows enterprise server based and Linux cloud
based. The technologies differ greatly across these so you probably should
choose a single area.

The common ground amongst these three areas is network engineering. Any large
scale environment comprises complex interconnection of nodes, switches, load-
balancers, etc.

If I were in your shoes, I would find a job with a medium sized systems
integrations consultancy and then develop my skills in one area at a time.
Over time you would end up with a comprehensive knowledge across the many
areas.

------
levimaes
fwiw, You might enjoy what golang has to offer in a systems programming
context. I think it's reliably offered it's users '95% right, 99% of the time'
comprehensiveness for all kinds of contexts -- what with how I think even
Dropbox might have switched over to Golang, from Rust, after conceding it's
greater overall compatibility (I'd imagine) to their product's improvement +
maintenance + growth/scale.

~~~
steveklabnik
Dropbox is using both Go and Rust; they’ve haven’t switched away from either.
They even use both together in some places.

Where did you get that idea?

------
rayvy
I too started w/ web dev (PHP and HTML (so funny to think about those first
days starting out)), but ended up moving to the backend (Apache Suite) for my
current job, and took up lower level programming from there, so here's my 2
cents.

#1 - throw out the "systems engineer" title. It's ambiguous, can't really be
_achieved_ , and I've seen guys out there who are actually Systems Engineers
(in job title) who are so good that it's almost sickening - makes me want to
quit. So first, get rid of the title.

#2 - Learn a low-level language. You seem to be already doing this (I'm a RUST
guy myself). Here you'll probably see (if you haven't already), that there's a
focus/efficiency that isn't _necessary_ for CRUD apps (e.g., passing
references, using as little memory/cpu as possible, etc). But that's kind of
what I like about lower languages, you get almost intimately close to the
machine and understand on a completely different level that a web dev.

#3 - And this is something I'm still dealing with: switch your dev mind from
higher-level web work, to lower level work. What do I mean? Well a lot of
times in web dev, you're building at the application level (e.g., CRUD apps).
However, I'm noticing for a lot of lower-level programming, you're building
_beneath_ the application level. I'm working on a load balancer at the moment,
which isn't really a part of the _application_ , but kinda sits underneath it.
The thing about lower-level dev work is that it's not really the show-boaty
type of thing that a React can be (oh look at my shiny UI). And in my opinion,
it doesn't get celebrated like it should have. I have SO much more respect for
lower-level guys, after jumping into that world.

TLDR; systems engineer title is ambiguous, learn a solid low-level language
and stick with it, reframe your thinking when it comes to designing/planning
what you build

