Tired of the hype on the web/js (every week new library to learn about), I am thinking to switch career in the next 1-2 years, and move lower in the stack. I am into Rust in the last 3-4 months and I really enjoy it, but I would like to learn more, what would you consider essential books/papers/resources that a system's programmer should know?
Ask HN: What should a systems/low-level software engineer know?
1–10 of 231 posts
Re: Ask HN: What should a systems/low-level software engineer know?
#2Know that third party libraries often are not a solution. Often have a limited lifecycle, departed authors, and 90% of code you are not using, yet have to consider in regards of security etc.
Re: Ask HN: What should a systems/low-level software engineer know?
#3I would like to start by Ulrich Drepper' famous paper What Every Programmer Should Know About Memory [0]
[0]: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Re: Ask HN: What should a systems/low-level software engineer know?
#4In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values).
This comes up incredibly frequently, and having it be second nature will benefit you.
A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your method signatures should be. For example, if your data can can fit in a uint8_t, why waste bytes on a uint32_t?
This isn't the be all and end all, especially since modern architectures use larger word sizes/RAM is plentiful/bandwidth is cheap, but it can be a helpful way to frame the conversation when you're architecting software (especially network protocols).
Re: Ask HN: What should a systems/low-level software engineer know?
#5I think for low level systems it’s important to be knowledgeable about the design of OSes. For example, how memory works, caching and paging, how programs are executed, how threads and processes are managed, how communication with peripherals is typically done ... a good way of learning this could be implementing a cpu emulator of some kind in rust, which will probably give you a good idea of what areas you need to explore further. There have been a few floating around on HN lately.
Re: Ask HN: What should a systems/low-level software engineer know?
#6Designing and writing explicit state machines. They seem to come up more in low-level code than high-level code.
I prefer to generate them, so I would add to that "tools for generating C code and state machines".
(Tangent: A guy who worked on Verilog and FPGAs told me that the "whole idea" is state machines... and they are hard to get right.)
Re: Ask HN: What should a systems/low-level software engineer know?
#7In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values). This comes up incredibly frequently, and having it be second nature will benefit you. A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your met…
IMO the book "Computer systems : a programmer's perspective [Randal E Bryant; David R O'Hallaron]" provides a good foundation on this and other lower level system details.
Re: Ask HN: What should a systems/low-level software engineer know?
#8I would like to start by Ulrich Drepper' famous paper What Every Programmer Should Know About Memory [0] [0]: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Genuinely curious how useful this has been to you, personally.
Re: Ask HN: What should a systems/low-level software engineer know?
#9I would like to start by Ulrich Drepper' famous paper What Every Programmer Should Know About Memory [0] [0]: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Genuinely curious how useful this has been to you, personally.
well, I'm the guy asking weird questions in interviews :)
Re: Ask HN: What should a systems/low-level software engineer know?
#10In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values). This comes up incredibly frequently, and having it be second nature will benefit you. A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your met…
IMO the book "Computer systems : a programmer's perspective [Randal E Bryant; David R O'Hallaron]" provides a good foundation on this and other lower level system details.
I second this. Make sure that you do the labs that are available from the books web page.