The Morning Paper

My recommendations are not exactly what you ask but what I suspect you'll enjoy if you're asking this.

(1) "Understanding Computation" by Tom Stuart.
Not "fundamental" as a deep textbook, but very approachable for programmers intro into a big chunk of CS, explaining deep ideas about languages using rigorous working clean code (in Ruby, no prior knowledge needed).
I especially loved the first few chapters about what it means to define a programming languange and various kinds of formal semantics.

(2) Designing Data-Intensive Applications, Martin Kleppmann. This gives you a phenomenally good survey of concepts and practice of distributed systems. This is more software engineering than pure CS, but in my view you can't approach the field of distributed systems without blending both anyway.

(3) POODR — Practical Object-Oriented Design, in Ruby, by Sandi Metz. This is 100% software engineering, where there is no single definition of "foundational", but many people who read this swear by it. It's remarkably thin but lucid distillation of ideas that were "in the air" but Sandi nailed them down. An important thesis is that good code is not an aesthetic judgement of how it _now_ looks, but objective question how easy it will be to _change in the future_. Not Ruby-specific at all, but it teaches the original Smalltalk "message-passing" view of OOP, that for people that only learnt statically-typed Java, C++ etc view of OOP is a fundamental idea they're missing on.

Finally,…

Learn how to work with other people effectively (not just programmers, but PMs, finance types, legal experts, etc.) Took me like 15 years to be any good at this at all.

Get exposure to customers. Try to get involved with decisions involving them. Many companies actively discourage engineers from having customer contact; this is bad, IMHO.

Get exposure to the financial side of whatever industry you're in. You don't need to do official work, but definitely make sure you understand how your company makes money and what its risks are. (Do a start-up or two; this will give you a visceral feel for what money is worth assuming the places you work at are run well).

Read a paper a week (e.g., something from usenix or the ACM, or whereever). Sites like The Morning Paper (https://blog.acolyer.org/) are pretty good; the thing is not to get caught in a rut.

If you're doing IT work, get involved in dev work. If you're doing dev work, get involved in IT. These feed pretty heavily off of each other and operational background will boost your engineering skills as much as coding skills will help your IT work.

Things I wish I'd studied harder, earlier: Statistics, practical aspects of databases and SQL, at-scale networking [didn't exist when I was a sprout], practical aspects of operating systems implementation (the stuff they didn't teach you in your course at school), maybe the first six months of an EE course . . . I could go on for quite a while. The good news is that there's no way…

A few ideas:

1. Add "abstract" to your search query to surface papers.

2. Search for "... reading list". For example, Heidi Howard maintains https://github.com/heidihoward/distributed-consensus-reading-list

3. Read blogs like "The Morning Paper" (https://blog.acolyer.org) but skip fields that are outside your scope. You don't have time to follow more than one or two (or three) major fields.

4. Use Google Scholar to find the most cited papers, or to find papers that build on papers you think are good.

5. Keep an eye out for the conferences where these papers were presented. Then read the other papers that were also presented.

6. When you come across an amazing paper, read other papers by the same authors or supervisors.

7. If you're lucky you might also find good "survey" papers that cover and reference the state of the art.

8. Lecture notes from Stanford or MIT or another university can also be a great way to get a big picture of the evolution of techniques for a given data structure or problem. For example, these lecture notes are just brilliant for getting started with stuff around memory hierarchies: https://www.eidos.ic.i.u-tokyo.ac.jp/~tau/lecture/parallel_distributed/2018/slides/pdf/memory2.pdf

These are a few tricks that I find useful. What else?

My approach is mostly to curate your news/social/stream feed to individual people that post the sort of things you like, and to slower-moving publications. Limit your follows on social media. Prefer blogs and RSS over Twitter-style social. And/or read journals/magazines/books and reviews of them instead.

E.g. the old "The Morning Paper" blog by Adrian Colyer (https://blog.acolyer.org/) seems maybe up your alley? It's over now; dunno if what the new online versions of that are. For substantive programming stuff, these days I mostly read magazines and books, like CODE, Logic, and 2600. (IEEE Computer Society and ACMD have journals, but they're prety theoretical and academic; guessing that's not what you want here. I haven't found them very useful in my own programming work.) Sad to say, the current scene for this doesn't seem great. Old school Dr. Dobb's sounds like maybe what you want, but AFAICT there isn't really much like that any more? LWN and OSNews seem like modern online versions of stuff in that area, for system programmers at least. MIT Technology Review is also decent, but less about programming per se.

>Reading white papers is a skill in its own, but as almost anything else, it can be learnt.

I'm currently taking this great course [1] with Dave O'Hallaron (co-author of Computer Systems: A Programmer's Perspective / the 213 textbook [2]), in which we read and discuss papers about building scalable Internet services (list of papers available on the site).

As part of the course we write critiques of each paper, including a quick summary and some notes about likes, dislikes, and questions for discussion. Taking the time to write this out explicitly really forces me to think more deeply about what each paper is about.

And, the reading-group format with discussion with other people is helpful - hearing different perspectives and opinions really improves my understanding as well.

I'd definitely recommend taking notes and trying to find a reading group for better understanding. As other comments have mentioned, Adrian Colyer's The Morning Paper [3] also has interesting reads.

[1] http://course.ece.cmu.edu/~ece845/

[2] http://csapp.cs.cmu.edu/

[3] https://blog.acolyer.org/

Funnily enough, there is a paper on exactly what you're referring to from Microsoft Research called "Flexible Paxos":

https://arxiv.org/pdf/1608.06696.pdf

The gist of it is that there are realistically 2 quorums to be had: One for read/write to a cluster, and one for leader election. Assuming leader election is a relatively uncommon event (as it is in Paxos), you can require more quorum nodes for leader election while allowing less quorum nodes for quorum read/write. This means you get strong consistency with better performance.

Distributed systems are one of my favorite things. I literally spent part of an evening with a beer reading a small handful of papers like this one. If you want an absolute treasure trove of similar works, visit the blog of Adrian Coyler:

https://blog.acolyer.org/

He has a good writeup on the Flexible Paxos paper as well:

https://blog.acolyer.org/2016/09/27/flexible-paxos-quorum-intersection-revisited/