4 ms·

You may also look into Kernel Programming for a lucrative systems programming career. It is more C and low-level oriented though.

anonymousDan 4y ago
Interesting, what types of companies pay well for kernel programming?
- caskstrength 4y ago
  Significant portion of kernel code is written by FAANG, for example. There are other companies that also pay reasonably well. You can check some statistics of contributions to Linux kernel here https://lwn.net/Articles/909625/ https://lwn.net/Articles/909625/
- synergy20 4y ago
  not many, I did it, jobs are scarce, most of the time you port a new version of CPU to the kernel, or add a few device drivers, the industry does not need a lot of those engineers, and per my experience, not compensated that well either. these days many kernel programmers work for big companies.
- antegamisou 4y ago
  I remember Apple having a lot of related listings so I'd assume companies that are somehow involved in OS development (Microsoft, Google, maybe RedHat/IBM and Intel).
- maldev 4y ago
  Alot of government and security researcher jobs pay google tier for kernel skills with strong knowledge of the OS.
- 0x0203 4y ago
  Defense industry has a few such jobs, working a lot with RTOS's, network devices, sometimes even embedded for signal processing/control systems, etc... The big defense contractors probably pay better than working directly for the govt depending on where you live.
deaddabe 4y ago
> You may also look into Kernel Programming for a lucrative systems programming career. This is the road I have taken since I started to work professionally, but I yet have to find a lucrative job. I know that I am paid more than microcontroller devs, but less than web devs. The market for kernel developers is not that big either.
- boredtofears 4y ago
  That's insane to me... getting into systems programming recently I am well aware of how much harder it is than web dev.
  - DeathArrow 4y ago
    I did embedded and now I do backend. I wouldn't say one is harder than other. Things are very different.
  - yxhuvud 4y ago
    Payment is not based on hardness, it is based on demand and supply.
    - AndriyKunitsyn 4y ago
      Not only on hardness, but hardness influences how much of supply of competent workers the market has.
  - avidphantasm 4y ago
    Harder yes, but at least you don’t have to keep up with “flavor of the month” frameworks and toolkits that frequently change.
  - larve 4y ago
    I’ve been in both web and embedded for the last 20 years, and to me web dev “done right” is just as much if not more complicated than embedded, and very similar. In both cases, you have a distributed systems (everything action you take, system wise, is asynchronous, and very uncertain). Debugging is a pain in both cases, because you have only limited access to the system under test (especially in the field), and things like minification / optimizing compilers make it hard to necessarily track bugs. Embedded has the advantage that you can usually trust your peripherals more (they’re not a user that randomly presses CTRL-R), there is less framework and thirdparty stuff in your way, and the timing constraints are usually better understood. Webdev also suffers from a ton of UX and UI (animations, wizards, complicated workflows, error handling that needs to be error handled that needs to be error handled), which often results in very complex state machines. In both cases, observability is key, especially for debugging purposes. I use the same patterns in both cases: a lot of state machines and event driven design, because I get “debugging” for free (I just need to log state + events and I can reproduce any scenario). The big advantage of web, and one that I always have to adjust to when I come back from a period of time in embedded, is that you can YOLO a lot. YOLO to prod, you can always easily revert. YOLO the UI, because you can trust the user to refresh their page or workaround it (your hardware peripheral won’t). YOLO everything because you’ll never really brick stuff. YOLO timing because you usually don’t have hard or even squishy-hard realtime requirements. YOLO behaviour because you can have realtime feedback on how your system is doing, and pushing a new version is only minutes away. But “web dev” done right, and I really like having something fast, robust, repeatable and observable, is quite the challenge too.

anonymousDan 4y ago

Interesting, what types of companies pay well for kernel programming?

caskstrength 4y ago
Significant portion of kernel code is written by FAANG, for example. There are other companies that also pay reasonably well. You can check some statistics of contributions to Linux kernel here https://lwn.net/Articles/909625/ https://lwn.net/Articles/909625/
synergy20 4y ago
not many, I did it, jobs are scarce, most of the time you port a new version of CPU to the kernel, or add a few device drivers, the industry does not need a lot of those engineers, and per my experience, not compensated that well either. these days many kernel programmers work for big companies.
antegamisou 4y ago
I remember Apple having a lot of related listings so I'd assume companies that are somehow involved in OS development (Microsoft, Google, maybe RedHat/IBM and Intel).
maldev 4y ago
Alot of government and security researcher jobs pay google tier for kernel skills with strong knowledge of the OS.
0x0203 4y ago
Defense industry has a few such jobs, working a lot with RTOS's, network devices, sometimes even embedded for signal processing/control systems, etc... The big defense contractors probably pay better than working directly for the govt depending on where you live.

deaddabe 4y ago

> You may also look into Kernel Programming for a lucrative systems programming career. This is the road I have taken since I started to work professionally, but I yet have to find a lucrative job. I know that I am paid more than microcontroller devs, but less than web devs. The market for kernel developers is not that big either.

boredtofears 4y ago
That's insane to me... getting into systems programming recently I am well aware of how much harder it is than web dev.
- DeathArrow 4y ago
  I did embedded and now I do backend. I wouldn't say one is harder than other. Things are very different.
- yxhuvud 4y ago
  Payment is not based on hardness, it is based on demand and supply.
  - AndriyKunitsyn 4y ago
    Not only on hardness, but hardness influences how much of supply of competent workers the market has.
- avidphantasm 4y ago
  Harder yes, but at least you don’t have to keep up with “flavor of the month” frameworks and toolkits that frequently change.
- larve 4y ago
  I’ve been in both web and embedded for the last 20 years, and to me web dev “done right” is just as much if not more complicated than embedded, and very similar. In both cases, you have a distributed systems (everything action you take, system wise, is asynchronous, and very uncertain). Debugging is a pain in both cases, because you have only limited access to the system under test (especially in the field), and things like minification / optimizing compilers make it hard to necessarily track bugs. Embedded has the advantage that you can usually trust your peripherals more (they’re not a user that randomly presses CTRL-R), there is less framework and thirdparty stuff in your way, and the timing constraints are usually better understood. Webdev also suffers from a ton of UX and UI (animations, wizards, complicated workflows, error handling that needs to be error handled that needs to be error handled), which often results in very complex state machines. In both cases, observability is key, especially for debugging purposes. I use the same patterns in both cases: a lot of state machines and event driven design, because I get “debugging” for free (I just need to log state + events and I can reproduce any scenario). The big advantage of web, and one that I always have to adjust to when I come back from a period of time in embedded, is that you can YOLO a lot. YOLO to prod, you can always easily revert. YOLO the UI, because you can trust the user to refresh their page or workaround it (your hardware peripheral won’t). YOLO everything because you’ll never really brick stuff. YOLO timing because you usually don’t have hard or even squishy-hard realtime requirements. YOLO behaviour because you can have realtime feedback on how your system is doing, and pushing a new version is only minutes away. But “web dev” done right, and I really like having something fast, robust, repeatable and observable, is quite the challenge too.