5 ms·

Tangential question: what would be a career path for a typical product developer to become one of the programming gods who get invited to such discussions? (Eve

Tangential question: what would be a career path for a typical product developer to become one of the programming gods who get invited to such discussions? (Even if it's technically open mailing list, you know what I mean). How many years of experience and how much formal CS education would it take to acsend to that level?

ris 6y ago
Heavy reading of LWN.net articles.
- stevekemp 6y ago
  Reading is certainly step one. Steps two to ten probably involve lots of trying things, experimenting, learning, practicing.
jonahbenton 6y ago
They aren't gods, just normal programmers with specific interests. The knowledge and skill base involves details that are close to the machine. It is less of a "deep CS" thing and more just being patient and interested in details of old things, rather than new things. That is why they self-deprecatingly refer to themselves as plumbers. The big difference between eg product dev and kernel dev is mindset, not skill. Product dev is about novelty, building new features, inventing new tools. Kernel dev is about making old stuff work better. Very few kernel devs would succeed in a conventional product dev job, instead of creating value they would be tinkering with some superfluous detail. If one has the mindset, getting into kernel programming is probably a six month to 2-year initial investment, depending on prior background. Most "operating system" CS grad courses introduce kernel programming as a teaching tool, but a whole CS undergrad isn't required, just an understanding of C and some other basics around low level machine operation. (Edit: side note- for emphasis- kernel programming is highly specific, extremely empirical and experimental. Not abstract or theoretical. Academic CS tends toward the abstract/theoretical. One can be a poor academic but an excellent kernel programmer.) The best standalone resource is a book by a fellow named Robert Love called Linux Kernel Development. One of the best technical books I have read and a good indicator of the presence of the mindset. Cheers!
coldpie 6y ago
Formal CS education is pretty much useless for systems programming. Systems programming deals with real-world hardware, CS is theorizing about about fantasy machines. "Computers are to Computer Science what telescopes are to Astronomy." They're just different fields. They intersect, of course, but systems programming isn't very near that intersection. Being good at analyzing a DFA on a Turing machine isn't going to be much help when you need to bang bits to a non-compliant USB device. If you want to get into these discussions, you need to be a kernel dev. That means you need to write kernel stuff. Probably the easiest thing is to write or improve a driver for some device you have (game controllers; steering wheels; audio devices; drawing tablets). It's not rocket science, it's all just bits and bytes and code, just like any other programming. Edit: Just for an example, here's where the PlayStation controller driver parses the data it gets from the device into something applications can read over the input subsystem. Don't be intimidated, there's nothing magic here, just C code reading data and transforming it. Suppose you maintained this driver and wanted to re-write it in Rust. You could have some input into the discussion! https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c#n940 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- nikki93 6y ago
  Re: the first paragraph--a lot of "formal CS education" focuses on systems and there are systems tracks. Where BSD came from, for example. So I wouldn't call it useless (while the parts that do not focus on systems do, indeed, not focus on systems). In fact, even the non-systems stuff isn't entirely useless for systems--eg. how ideas from ML and Cyclone influence Rust and its application of those ideas to systems use cases. That said, all this is independently learnable, as is true for all things software.
- golergka 6y ago
  Honest question: why is this downvoted? Is it bad advice? Which of it is?
  - jonahbenton 6y ago
    I upvoted, it's all good advice, but the blanket statement that "formal CS is useless..." is a little strong. CS undergrad is generalist and mostly about types of problems and surveys of solution flavors and POCs of specific solutions in domains that are hot or cool or whatever and geared to students who are just trying to get through and don't have time or patience to work through bespoke granular details. Getting the idea is good enough for a B. Kernel programming is largely the opposite in all respects. Many topics, problem domains, solution approaches e.g. usually covered in CS undergrad are not relevant for kernel programming. Not useless, but not relevant. Kernel programming relative to most CS undergrad courses is like taking a semester-long lab, but starting from the best A+ project from the last 5 years, and instead of newly solving the problem, spending time working on understanding why the best A+ solution still sucks, under what edge conditions it fails, and then testing how it can be made better.

ris 6y ago

Heavy reading of LWN.net articles.

stevekemp 6y ago
Reading is certainly step one. Steps two to ten probably involve lots of trying things, experimenting, learning, practicing.

jonahbenton 6y ago

They aren't gods, just normal programmers with specific interests. The knowledge and skill base involves details that are close to the machine. It is less of a "deep CS" thing and more just being patient and interested in details of old things, rather than new things. That is why they self-deprecatingly refer to themselves as plumbers. The big difference between eg product dev and kernel dev is mindset, not skill. Product dev is about novelty, building new features, inventing new tools. Kernel dev is about making old stuff work better. Very few kernel devs would succeed in a conventional product dev job, instead of creating value they would be tinkering with some superfluous detail. If one has the mindset, getting into kernel programming is probably a six month to 2-year initial investment, depending on prior background. Most "operating system" CS grad courses introduce kernel programming as a teaching tool, but a whole CS undergrad isn't required, just an understanding of C and some other basics around low level machine operation. (Edit: side note- for emphasis- kernel programming is highly specific, extremely empirical and experimental. Not abstract or theoretical. Academic CS tends toward the abstract/theoretical. One can be a poor academic but an excellent kernel programmer.) The best standalone resource is a book by a fellow named Robert Love called Linux Kernel Development. One of the best technical books I have read and a good indicator of the presence of the mindset. Cheers!

coldpie 6y ago

Formal CS education is pretty much useless for systems programming. Systems programming deals with real-world hardware, CS is theorizing about about fantasy machines. "Computers are to Computer Science what telescopes are to Astronomy." They're just different fields. They intersect, of course, but systems programming isn't very near that intersection. Being good at analyzing a DFA on a Turing machine isn't going to be much help when you need to bang bits to a non-compliant USB device. If you want to get into these discussions, you need to be a kernel dev. That means you need to write kernel stuff. Probably the easiest thing is to write or improve a driver for some device you have (game controllers; steering wheels; audio devices; drawing tablets). It's not rocket science, it's all just bits and bytes and code, just like any other programming. Edit: Just for an example, here's where the PlayStation controller driver parses the data it gets from the device into something applications can read over the input subsystem. Don't be intimidated, there's nothing magic here, just C code reading data and transforming it. Suppose you maintained this driver and wanted to re-write it in Rust. You could have some input into the discussion! https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c#n940 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

nikki93 6y ago
Re: the first paragraph--a lot of "formal CS education" focuses on systems and there are systems tracks. Where BSD came from, for example. So I wouldn't call it useless (while the parts that do not focus on systems do, indeed, not focus on systems). In fact, even the non-systems stuff isn't entirely useless for systems--eg. how ideas from ML and Cyclone influence Rust and its application of those ideas to systems use cases. That said, all this is independently learnable, as is true for all things software.
golergka 6y ago
Honest question: why is this downvoted? Is it bad advice? Which of it is?
- jonahbenton 6y ago
  I upvoted, it's all good advice, but the blanket statement that "formal CS is useless..." is a little strong. CS undergrad is generalist and mostly about types of problems and surveys of solution flavors and POCs of specific solutions in domains that are hot or cool or whatever and geared to students who are just trying to get through and don't have time or patience to work through bespoke granular details. Getting the idea is good enough for a B. Kernel programming is largely the opposite in all respects. Many topics, problem domains, solution approaches e.g. usually covered in CS undergrad are not relevant for kernel programming. Not useless, but not relevant. Kernel programming relative to most CS undergrad courses is like taking a semester-long lab, but starting from the best A+ project from the last 5 years, and instead of newly solving the problem, spending time working on understanding why the best A+ solution still sucks, under what edge conditions it fails, and then testing how it can be made better.