[nik5]

I don't know if it is just me who finds such lists overwhelming. They bombard on you like hundreds of resources. FOMO kicks in and I star them for false sense of effectiveness but hardly end up completing anything or even starting.

[thundergolfer]

When I first started learning software I liked to 'collect' these kind of lists as educational busywork. Now that I've been learning software engineering for over 6 years I think they're super unhelpfully overwhelming like you say. You want _one_ short list that you actually use.

For me that is teachyourselfcs.com. It recommends only two books if you don't have "multiple years" to self-study part-time. They are: Computer Systems: A Programmer's Perspective and Designing Data-Intensive Applications. If you do have multiple years it recommends ~9 books. The OP list has almost 100 books just on software architecture.

It takes so long to read one good textbook that I'd bet 90% of software engineers haven't read more than three or four cover-to-cover. I was rare in my computing theory class for actually using the textbook and doing the exercises and I only got 2/3 through. Given my current progress rate through 'Computer Systems: A Programmer's Perspective' it will take me at least 150 hours to complete.

[maxFlow]

Thanks for this recommendation. I agree with you about quality over quantity. Working through a ~600-page (sometimes more) technical book is no easy task, and in fact can be pretty demotivating especially if you're learning on your own.

I feel like some people are compelled to gather these monster lists due to their hoarding inclinations---and it probably serves as "useful" procrastination as well. As I get older and curate my bookshelf further, I find myself either discarding a lot of overlapped material or skipping through the majority of the content. Otherwise there is no escape, as the SE field is so dynamic and complex, that the list of "required readings" trully is overwhelmingly large.

[dgb23]

On the other hand it is different for collecting interesting and influential papers and essays. You read them in an afternoon and ponder over them for quite a while! Then you revisit them way, maybe years, later again.

But yes, you don‘t need more than one good introductory book on architecture, most of the books listed don’t have anything to do with architecture anyways, but rather software culture.

Maybe you don’t need to read one at all, but rather a paper from someone who analyzed or created a piece of software with interesting and useful architecture.

[one2three4]

One afternoon? Hm, it depends on the paper really and how close it is to your daily work.

2 pages in FoundationDB paper (https://www.foundationdb.org/files/fdb-paper.pdf) I knew I was looking at one month's reading material if I really was to grasp everything. It'd be much easier if I worked with DBs and Distributed daily but I don't.

But, yes, I see your point.

[thundergolfer]

Totally agree about papers and essays and revisiting them years later. I built a website based directly on that idea. https://whitelist.sh. It’s almost finished. Just need to reorder some items in the list.

[dgb23]

That looks pretty cool! But I meant papers and essays from the likes of Edsger Dijsktra, Gerald Sussman, Alan Kay, Joe Armstrong, Daniel Ingalls, Peter Naur, Tony Hoare, Niklaus Wirth, Betrand Meyer, John McCarthy... and many, many others[0], including ones that are not necessarily as known but have discovered deep and useful insights into programming and computers.

Blog articles are really useful too, especially if they concentrate on say something more specifically practical that doesn't warrant the same polish and rigor of a paper or essay. Also something I noticed is that many, who will make more general assertions in these articles, are typically echoing something that has been written down by researchers quite a while ago, so why not go to the source?

[0] Apparently I can't stop writing down names because it feels like I'm leaving out too many...

[thundergolfer]

> But I meant papers and essays from the likes of ...

Oh they're all in there! They're just put at the back end of the 4 years partly because the more advanced content goes towards the end and partly because I haven't distributed everything properly.

I've spent quite a few hours curating the ~800 items and have in that process learnt a few new names that you mentioned, such as Niklaus Wirth. From him, the list has "Good Ideas, Through The Looking Glass".

I don't recognize Daniel Ingalls and Peter Naur so I'll look into them and consider adding them to the list. Cheers :)

Edit: Oh, Peter Naur would be the Naur in Backus-Naur form. He'd be in there.

[andi999]

It takes month to go through a technical book cover to cover, except if you have already learnd the content before then you can read it rather quickly like a novel. But if you know then content why read it.

[eatonphil]

Here are my four: Designing Data Intensive Applications, the Google SRE book, High Performance Browser Networking, and Effective Python.

https://notes.eatonphil.com/books-developers-should-read.htm...

[Xunjin]

I love Fluent Python, Luciano is a great professor and writer, also is a Brazilian (even more points for being a countryman)

[potamic]

It's fairly low effort curation based off public reviews of books. The problem with such things is that it's hard to gauge the quality of review or the subject matter expertise of the reviewer. Curation should ideally be performed by someone who is an expert in the field, has deep knowledge on the subjects and has actually consumed the content in order to make the judgement call on whether it passes the bar or not. Otherwise, it's nothing more than a listing of most popular books.

[dragon96]

There ought to be a rule that any "curated" list of N books should also include N books not to read in the same category

[abecedarius]

An example of following a similar rule (briefly list other standard books and why the recommended books are preferred): https://www.lesswrong.com/posts/xg3hXCYQPJkwHyik2/the-best-t...