I did do web work for a long time, but I grew tired of it, so these days I just do contract work on legacy systems and platform modernizations. Some of those systems may have a web UX, some do not. But the work is more about refactoring architectures to get off brittle tech that nobody knows anymore, and move on to tech stacks where you can actually find talent to run it.
It is a different experience to be sure - I work on stuff that nobody likes and where most people are surprised it still exists. And my goals tend to be about shutting down, not growing. I succeed with every server we kill, every product we turn off, every customer we get rid of.
I don’t work on web apps at all. Most of my time goes into security tooling and analysis pipelines.
A lot of it is closer to systems work than application development: parsing large datasets, automating analysis, dealing with flaky inputs, and building things that are mostly run headless.
The feedback loop is slower than web work, but the problems tend to be deeper and longer-lived. You spend less time on UX and more time thinking about correctness, edge cases, and failure modes.
I suspect there are many people here doing similar non-web work, it’s just less visible because there’s no UI to screenshot or product to demo.
I haven't made a website of any kind since a C&C: Red Alert fan site somewhere on GeoCities in the late 90s.
I work on graphics drivers. They're hard write and even harder to debug. You have to be a huge nerd about graphics to get very far. It's a relatively rare skill set, but new, younger, nerdier people keep on coming. Most people in graphics are quiet and are just keeping the industry functioning (me). It's applied computer architecture in a combination of continuous learning and intuition from experience.
Hardware bugs can be found during chip bring-up within the first couple of months back from the fab, but since I've worked in this area I've never actually seen a bug that couldn't be worked around. They happen, but they're rare and I've never experienced a chip needing a respin because of a bug.
There is documentation, but it's not as well organized as you might imagine. Documentation is usually only necessary when implementing new features, and the resulting code doesn't change often. There are also multiple instruction sets as there are a bunch of little processors you need to control.
Vulkan/DX12 aren't really "low-level" APIs. They're "low overhead", and honestly, no. Their code base is just as large and complicated, if not more so, than OpenGL/DX11.
I build audio software engines mostly. This is highly enjoyable to me, because I get to create new sounds and new audio effects with results being near instant. Upgrading old Amiga ProTracker .MOD file playback to not sound so 8-bit and low samplerate is a fun challenge too.
Compressing Lamport Signatures is a side-project of mine too.
We write mostly Java, some Kotlin, targeting the JVM.
Most commonly our software runs on premises on server-class hardware (or what passes for server-class depending on the industry...), sometimes hosted in the cloud, sometimes on "edge" hardware (think Raspberry Pi class power/spec wise).
One component of the software actually is a web frontend (and a Jetty backend) to go with it, but it's not your typical "web-app" and it's not SaaS. But there's much more to it than that.
It is a different experience to be sure - I work on stuff that nobody likes and where most people are surprised it still exists. And my goals tend to be about shutting down, not growing. I succeed with every server we kill, every product we turn off, every customer we get rid of.
I work on graphics drivers. They're hard write and even harder to debug. You have to be a huge nerd about graphics to get very far. It's a relatively rare skill set, but new, younger, nerdier people keep on coming. Most people in graphics are quiet and are just keeping the industry functioning (me). It's applied computer architecture in a combination of continuous learning and intuition from experience.
Is there some big spec document or ISA that you follow when implementing the driver?
Also I'm curious is it easier to write a driver for the modern "lower level" APIs like vulkan/dx12?
There is documentation, but it's not as well organized as you might imagine. Documentation is usually only necessary when implementing new features, and the resulting code doesn't change often. There are also multiple instruction sets as there are a bunch of little processors you need to control.
Vulkan/DX12 aren't really "low-level" APIs. They're "low overhead", and honestly, no. Their code base is just as large and complicated, if not more so, than OpenGL/DX11.
I'm building a better primitive for infrastructure via microvm's (think virtual machine but fast and easy to use).
I am about to launch a complete rewrite of this: https://github.com/BinSquare/ERA
Compressing Lamport Signatures is a side-project of mine too.
Most commonly our software runs on premises on server-class hardware (or what passes for server-class depending on the industry...), sometimes hosted in the cloud, sometimes on "edge" hardware (think Raspberry Pi class power/spec wise).
One component of the software actually is a web frontend (and a Jetty backend) to go with it, but it's not your typical "web-app" and it's not SaaS. But there's much more to it than that.