[aurelius]

None of them. Study Knuth. Study the Intel manuals. Study “The Art of Multiprocessor Programming”. Study compilers. Study TCP/IP. Study algorithms and data structures. Write lots of code for all of those things.

Disregard the noise. Ban yourself from reading blogs and magazines and tech news. Focus on what is fundamental to the field. Look where nobody else is looking.

[haolez]

I don't know about this. It seems that there is more demand for high level work than low level. But I hope you are right!

[spacecadet]

I think OP is saying to go off and study tech and build shit, don't waste time reading hype noise BS. I agree!

[notjoemama]

If I did I wouldn't have seen their comment and given that perspective consideration. It's almost like...a reasonable balance is the best path. lol

[wegfawefgawefg]

Going monk mode for 3-6 months is good for a man.

[bawolff]

I mean, hacker news is fun and all, but i dont think its making me a better programmer.

[bawolff]

Good knowledge of fundamentals translate well into high level work.

Understanding the timeless things deeply will serve you much better than continually trying to understand what is hyped only to have to constantly move on to the next hyped thing before being able to get more thana superficial understanding.

[adrianN]

Low level pays pretty well.

[ethbr1]

Does it? Every time I check embedded salaries I'm shocked in a bad way.

[adrianN]

Embedded is not the only low level work there is. Databases for example require a lot of low level knowledge, but the market big enough to pay well.

[coolandsmartrr]

> Study the Intel manuals.

Which Intel manuals in particular? How much relevance remains in Intel's content given the popularity of ARM nowadays?

[rerdavies]

Intel® 64 and IA-32 Architectures Software Developer Manuals

https://www.intel.com/content/www/us/en/developer/articles/t...

Before the internet, Intel used to distribute these manuals in hard-copy for free. One just had to drop by your local Intel sales office to pick up a copy. A good solid foot of shelf-space.

These manuals used to be so much easier to read back in the 486/Pentium era. One could almost build a complete mental model of how a 486 worked, and how to manually optimize code to best effect by avoiding processor stalls.

Since then, intel processors have accumulated an extraordinary amount of cruft, so it becomes much harder to develop a complete mental model. Compilers have also gotten a lot more clever as well, in order to deal with the added complexity of SIMD instruction sets.

For those of us who started with the 8086 Architecture manuals, each generation of processors added additional features which one learned by occasionally revisiting the architecture manuals for new processors.

Coming to the Architecture manuals without having the foundation of previous Architecture manuals as a basis must be a daunting task. But I'm sure there's rich material there anyway.

[gperkins978]

I miss the days of printed manuals, or even manuals at all. I killed a big software purchase years ago because they did not even have a PDF manual. The jerks told us to use their forums. No way I would spend money with such arrogant pr_cks. Needless to say, I find myself spending real coin on manuals on ebay. They are worth it.

[wyclif]

When you say "the Intel manuals", what books are you specifically referring to?

[golly_ned]

Have you done these things?

[gaws]

Absolutely not.

[jwoq9118]

Guys like Sam Altman did exactly not this. They gained breadth in what was specifically relevant to the problem being solved.