Yes! I’m also considering are adding topic tags, maybe quoting abstracts and adding arbitrary notes. It’s one of the reasons I’m generating the README based on a yaml, so I can easily rearrange and extend it.
P.S. I noticed you link to The Mythical Man Month, which is a medium-length book. How do you resolve it with your second criterion, “The papers shouldn’t be too long”? – edit: oh, seems like you link to only one chapter of the book. So I’ll update my question: How did you choose which chapter to link to?
It’s indeed only one chapter (the one that has the same title). I also included separately “No silver bullet”, which is also part of the more recent editions of the book. I chose those two because they work as standalone papers, because I think they’ve been the most influential (at least the most widely cited afaict; the first being the classic essay about the project management side of software development; the other the classic on how to deal with complexity), and because those two are the ones I found most useful when reading that book.
I’ve read most of these, and I agree that they’re all papers that are valuable to study. Solid choices.
I’m especially glad to see all four of those Parnas papers on modules. Most people miss all but the first one. There’s a couple other cool ones as well that extend that, though they’re not as crucial.
I feel ambivalent about this. REST as Fielding described it is a theoretical description of the structure of the web and the features that he believed (probably correctly) were important how it functions in practice. The term REST API has been co-opted to mean an API exposed via HTTP that uses a broader set of methods.
This is well organized! Have you considered adding explanations of why you think each paper is worth reading?
Yes! I’m also considering are adding topic tags, maybe quoting abstracts and adding arbitrary notes. It’s one of the reasons I’m generating the README based on a yaml, so I can easily rearrange and extend it.
It’s always nice to have another list, when I feel like learning something random.
Here are a few more lists of programming papers from my bookmarks:
https://michaelfeathers.silvrback.com/10-papers-every-developer-should-read-at-least-twice
https://ordep.dev/posts/my-favorite-papers
P.S. I noticed you link to The Mythical Man Month, which is a medium-length book. How do you resolve it with your second criterion, “The papers shouldn’t be too long”? – edit: oh, seems like you link to only one chapter of the book. So I’ll update my question: How did you choose which chapter to link to?
It’s indeed only one chapter (the one that has the same title). I also included separately “No silver bullet”, which is also part of the more recent editions of the book. I chose those two because they work as standalone papers, because I think they’ve been the most influential (at least the most widely cited afaict; the first being the classic essay about the project management side of software development; the other the classic on how to deal with complexity), and because those two are the ones I found most useful when reading that book.
I’ve read most of these, and I agree that they’re all papers that are valuable to study. Solid choices.
I’m especially glad to see all four of those Parnas papers on modules. Most people miss all but the first one. There’s a couple other cool ones as well that extend that, though they’re not as crucial.
Here’s another decent source for recent papers for anyone interested:
https://jeffhuang.com/best_paper_awards/
Also check out Papers We Love! https://github.com/papers-we-love/papers-we-love
I’d like to chip in: “A Programming language” -Kenneth E. Iverson “How Do Committees Invent?” -Melvin E. Conway
The conway one is already below mythical mal month. I’ll check the other one thanks!
You’re right, my bad. Missed it.
For a broader view, perhaps https://mitpress.mit.edu/books/ideas-created-future. Still on my reading backlog though, since the local libraries don’t carry it.
Another one that’s great, and incredibly influential for modern web development, is the REST chapter of the Roy Fielding dissertation.
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Oh this is interesting, I thought about fielding dissertation but discarded it for being too long, I hadn’t considered the rest chapter as standalone.
I feel ambivalent about this. REST as Fielding described it is a theoretical description of the structure of the web and the features that he believed (probably correctly) were important how it functions in practice. The term REST API has been co-opted to mean an API exposed via HTTP that uses a broader set of methods.