I'm a full-stack software engineer, but I'm feeling burned out by building similar CRUD applications and I'm especially unsure how my work fits into the industry now that AI tools are becoming more capable. In college, I enjoyed learning how computers work under the hood—compilers, operating systems, assembly, and related topics—and I'd like to move toward a more technically deep career path.
I've considered areas such as systems programming, infrastructure, networking, cybersecurity, robotics, hardware, and specialized backend engineering, but the number of options feels overwhelming. I'm comfortable with C and have been looking at learning paths involving C, Linux, systems programming, and backend development.
Ideally, I'd like a direction that:
- Involves lower-level concepts such as operating systems, hardware, performance, or networking
- Builds on my existing software and web-development experience rather than requiring me to start over
- Has realistic remote-work opportunities, at least for the time being
Robotics and hardware interest me, but many of those roles appear to be onsite. I'm also curious about cybersecurity, although I'm unsure how much of my current background would transfer.
For anyone who has made a similar transition, what area did you choose, what did you learn, and how did you get your first role? Are there practical paths from full-stack development into deeper, lower-level, and still reasonably remote-friendly work?
5 Answers
Before changing specialties, consider whether the problem is the kind of work or the way you’re approaching your current role. Maintaining a real product can involve reliability, scalability, architecture, observability, deployments, and supporting millions of users. A backend or full-stack role at a more technically demanding company might provide the depth you want without throwing away your existing experience.
Try taking ownership beyond finishing tickets: measure performance, improve reliability, understand production incidents, work with infrastructure teams, and think about how the system evolves over time. Those responsibilities can make application development much more technically challenging.
Cybersecurity and computationally focused areas are worth exploring as hobbies first, especially if you’re worried about starting from scratch. Your programming background can transfer into application security, security tooling, cloud security, vulnerability research, or secure infrastructure, but each area has its own fundamentals.
Whatever path you choose, keep your current experience as an advantage rather than treating it as baggage. Build on it with focused learning, a relevant project, and conversations with practitioners. A gradual transition is usually more realistic than quitting full-stack work and trying to become a completely different specialist overnight.
You don’t necessarily need to commit to a new field immediately. Pick one area that genuinely interests you—systems, networking, security, robotics, or something similar—and explore it through a serious side project or open-source contribution. For example, you could build a Linux service in C or Go, write a small compiler or interpreter, investigate performance with profiling tools, or contribute to an existing systems project.
That will tell you much more than reading broad career roadmaps. You can also attend a conference, local meetup, or technical event and speak with people who actually do the work. If the interest holds up after several months of hands-on practice, then start targeting roles in that area.
Good point. I think I need to experiment before making a major move instead of treating every interesting field as a potential full career change.
Go is another reasonable direction if you want lower-level ideas without abandoning productive backend work. It’s useful for services, command-line tools, agents, daemons, networking software, and infrastructure tooling. Learning Go won’t automatically make the work deeper, but using it to build something that deals with concurrency, networking, memory behavior, profiling, or operating-system interfaces can help you develop the right experience.
The important part is the project and the concepts behind it, not simply switching languages. C, Rust, Go, or C++ can all lead to deeper work if you study systems fundamentals and build software where performance, resource usage, and reliability matter.
A new language by itself won’t solve the problem. The depth comes from understanding the constraints and taking responsibility for how the software behaves in production.
Infrastructure and platform engineering could be a strong bridge from full-stack development. You’d use your existing programming and service experience while learning Linux, networking, containers, CI/CD, observability, cloud infrastructure, and reliability engineering. These roles can involve substantial systems thinking and are often more remote-friendly than hardware or robotics.
A practical progression would be to learn Linux administration, networking fundamentals, processes and memory, containers, infrastructure-as-code, and production monitoring. Then improve the deployment and operational side of a project you already understand, or build a small platform that runs and observes several services. That gives you concrete evidence of systems experience when applying for platform, infrastructure, or backend-performance roles.
That’s fair. I may have decided too quickly that I need a completely different career, so I’m going to look more closely at the kind of responsibility I’m taking on now.