Ask HN: How do I transition from full-stack web-dev to systems engineering? | Hacker News Reader

Ask HN: How do I transition from full-stack web-dev to systems engineering?

6 pointsvector_spaces4 comments

I'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 / 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.

I'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.

That said, I'm finding myself much more drawn to creating tools and languages than working on CRUD/business applications. It's a dream of mine to work on building runtimes and server infrastructure rather than the business software that sits on top of it.

I'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'll still have no idea what it's like to apply that knowledge in a production setting. The job postings for systems engineers I'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'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.

Questions/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'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?

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.

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.

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?

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

Reply on news.ycombinator.com