Maybe it's useful if you want to make something like a more performant version of grep? (aka ripgrep?)
This is why we can't have nice things.
It’s not like reading 10 bullet points on the subject is “diving deep” and making huge time investment.
It’s just getting the minimal context, so later on at least some keywords are known.
Not sure how many computer related topics you know/want (“The more you know, the more you know you don't know”), but for me, 50 topics on programming seems sufficiently high at frankly a very low effort/commitment.
True, but you're using so many abstractions that the rule can't feasibly be "read a short summary of every abstraction you're using." There are just too many. At some point you have to choose a threshold where the likelihood of an abstraction leakage is sufficiently low. When you're debugging a CSS selector you will almost certainly never need to know about even the existence of, say, Fermi–Dirac statistics.
Rule - no. Goal - yes.
Some topics are more stable and valuable then others, so prioritisation helps.
“How utf8 generally works” vs “implementation details of js-node-utf-related-library-X.”
But it’s rarely because some developer didn’t understand page caches, and usually because it obviously didn’t revive enough QA or UX input.
If you're programming at enterprise scale, this sort of stuff is the responsibility of architect-level programmers and senior systems engineers.
Even most linux sysadmins know all about block alignment (well, if they predate most of the various tools figuring out block size/alignment stuff for you.) It's nothing new - RAID arrays work best when properly aligned, for example.
Makes sense to me. At Google we were told to stop thinking about all this stuff, that the storage hardware and software people were responsible for hiding things like wearout from application developers. This article is really "things you should know if you plan to directly access an NVMe device" but there is a huge class of programmers who are better off not knowing.
and as a result Chrome slams SSD by writing cached Youtube videos to disk .... except Youtube never reuses cached video data (not even when rewinding more than couple minutes to already watched spot in same video), it explicitly generates hashed requests with custom URL parameters googlevideo.com/videoplayback?expire (~6hour shelf life) &range &sig &lsig. Heavy YT viewing results in wearing out your SSD by tens of gigabytes per day for no particular reason. This is just one small example of side effects from such brilliant decisions.
1-13) General background info that informs the rest.
14-25) Important for any programmer that does enough file IO that they need to optimize it.
26-29) Important for any system admin to ensure they aren't inadvertently limiting the performance of their hardware.
Choice of db schema impacts physical layout on ssd. E.g. Different tables are more likely to be on different ssd pages resulting in random writes.
Databases are insanely complex, but not magic.
There is probably a small but non-zero number of these on here.