It's still worth a lot to be good at systems programming. Outside of the HN bubble there are plenty of companies willing to pay extremely well for people who can do systems programming, particularly under high performance constraints.

name 5 companies and typical salary ranges for junior dev or senior developer experience.

Name 5 please

google facebook microsoft amazon baidu

All of those places will pay just as much for (as well as hire far more of) enterprise Java/Go/HTML/JS code monkeys There's nothing wrong with that, but picking 5 companies with their hands in damn-near anything is disingenuous.

Is your goal to be paid extremely well for doing systems programming relative to other people in the same company? Or to be paid extremely well for doing systems programming?

The latter: solid salary for sys

So it's less about getting paid for your work and more about a dick measuring contest with your coworkers.

I think that's your issue.

ng nasa boeing lockheed spacex

The current hotness is AI/machine learning/deep learning. Maybe after that it will be something like "quantum programming"?

Just my guess.

http://www.newsweek.com/2017/04/21/quantum-computing-ibm-580...

It seems like in that field you can use some of your knowledge of system programming. Overflow and underflow happens a lot with the big data volumes you face. Another systems programming topic discussed in most big data courses is floating point accuracy.

Understanding floating point arithmetic is even more important than over/underflow of integers in dynamic languages such as Python (see e.g. https://www.python.org/dev/peps/pep-0237/).

The next boom will be in whatever _isn't_ being hyped right now.

There was definitely a recent boom in fintech / high-frequency trading.

The problem is these sorts of things are trivia. They are things that sufficiently smart tooling should handle for us so people can spend time building higher level constructs and less time worrying about individual bits.

A smart compiler should have caught (a + b) / 2 and fixed it to be correct, there's no way the overflow situation is what the programmer wanted.

"sufficiently smart tooling" has got to be one of the best jokes in programming.

On one hand, it is true that the tooling is possible. On the other hand, it remains an open problem.

I'd accept a warning, but a C compiler shouldn't be making guesses at what the programmer intended. In another language? Sure, if it's consistent with other behaviors in that language.

If you don't mind me asking how did you get into Systems Programming? (Or how would you recommend someone getting into it?)

I liked xv6. https://pdos.csail.mit.edu/6.828/2016/xv6.html

https://pdos.csail.mit.edu/6.828/2016/xv6/book-rev9.pdf

https://pdos.csail.mit.edu/6.828/2012/xv6/xv6-rev7.pdf

The labs are very informative: https://pdos.csail.mit.edu/6.828/2016/labs/lab3/

I also worked through the 6.824 Distributed Systems course, which is a lot of fun:

https://pdos.csail.mit.edu/6.824/

Lab 4 is fiendishly difficult, but you end up learning a lot.

Beyond all that, there's no substitute for just diving in and breaking stuff. Just go with whatever area you find the most fun. Maybe that's compiling and modifying the Linux kernel, or maybe it's tweaking a software rasterizer like https://github.com/blitzcode/rust-exp.

I got into systems programming mainly as a consequence of being a game developer -- when you write your own engines, you're forced to consider a hundred low-level details like memory layout, pipelining, threading, simulation, adding a scripting interface for your designers, cursing AMD when you run into GPU driver bugs, etc. There are a lifetime worth of interesting problems to solve in that area.

I wish it was worth a lot to be good at assembly these days. It seems like the huge salaries are for c++ devs. I spent like ten years getting really good at this stuff but nowadays it feels like being really good at trivial pursuit.

Edit: Did not mean to "mock" the OP, just merely trying to showing that you can apply that thought to almost anything in the programming world by replacing the technology/language names.

Except it's a bad analogy. Rails is not the next step up from systems level programming, it's a completely different (and honestly far less difficult) domain. Most of those rails devs could never be good at the hard stuff.

It is worth a lot to be good at assembly these days. It's a big piece of how my team makes a living. As one of my older colleagues puts it: there are fewer relevant jobs, but those jobs pay significantly more money, and you can only hold one job at a time.

Are you mocking the parent poster? Why?

Nah, I thought it was a good point. It's easy to forget that we either change or become obsolete. It's one thing to know it abstractly, but it's hard to make any lifestyle changes, especially if it involves switching to a job in a completely new domain.

http://thecodist.com/article/the_programming_steamroller_wai... is a good essay on this.

EDIT: previous discussion: https://news.ycombinator.com/item?id=7204515

That's an amazing article. Thanks for sharing.

Yes and no. My response to that article is "The more things change, the more they stay the same." There is no steam roller. The fundamentals are not changing. So much touted (even here on HN) as new and innovative are little more than re-hashed versions of what we were already using 5, 10, 20, 30 years ago, just prettier. Sure the syntax is always changing a little, and the frameworks and tools are evolving, but at a fundamental level the job of a programmer is little different now than it was in any of those eras. I have no doubt that a competent programmer from then, if picked up and plopped in front of a MacBook in 2017 could do a little reading up and perform proficiently in most programming jobs today. Probably more proficient because 1. they've seen it all before including the bugs and pitfalls and 2. I'd argue programming is much easier today than it ever has been.

EDIT: I swear I did not read the top comment in the (newly) linked HN discussion of that article before I wrote my response. I agree completely.

I really wonder about this. It seems true to me that it's easier now and anyone who could do it back when it was harder could do it now.

But then, I wonder if it just seems that way to me because I'm a product of "now", which makes me more proficient in how we do things now, which makes it seem easier. It's possible neither is easier, that they are just different, and for everyone, the other seems harder than the one they already know.

I'm not trying to argue that this is the case: I could see it being either way and I sincerely wonder which way it is.

grep for "fundamentals" | "first principles" in that article.