I suspect that there are many more, and which papers are important to any one person is as varied as the disciplines we have within software engineering.
- Out of the Tar Pit 2005, a paper on Functional Reactive Programming that is an excellent read for anyone doing functional programming, UI programming, or a number of other things.
- Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web 1997, important read for anyone working in distributed systems or services with any sort of scale.
- Roy Fielding's dissertation 2000, to learn just how widely applicable REST principles are and how misunderstood it is as a design.
- The Part Time Parliament 1998, the original Paxos paper, important basis for anyone working with distributed systems.
- The Cathedral and the Bazaar 1997, an essay not a paper, but a good background to the open source world.
I think the implications of that paper double every time I read it. Last time I walked away from that paper I decided I wanted to write a pure SQL logic evaluation system and now we're actually using it in our product to expose customization opportunities.
I almost worry what another read through might reveal. The last one was a really painful realization about wasted human capital.
Edit: I just realized the parent posted this as:
> a paper on Functional Reactive Programming
It is incredibly important to note that this is incorrect. It should be:
> a paper on Functional Relational Programming
It actually doesnt have much to do with "reactive" programming model as we know it today, and is more about managing complexity.
> It actually doesnt have much to do with "reactive" programming model as we know it today
What would you say is the ”reactive” model as we know it today?
If you asked me what FRP is, I’d tell you about Functional Reactive Programming. Maybe I’d point you to Conal’s writings or something like Your Mouse is a Database. Andre Staltz did a nice writeup on how it’s useful to think of FRP in more broader terms than the original definition would require:
> it would make sense to talk about "functional reactive programming" as a paradigm or an idea where you build applications using listenable event streams (or "signals"), creating and composing them using pure functions
For me, that’s the spirit of FRP. And when I read Out of the Tarpit, that’s exactly what jumps at me. The paper seems to describe data that’s changing over time, and other data being derived from those such that when the original data changes, so does the derived one. That’s pretty much precisely Functional Reactive Programming to me, even if the words are different.
You might have another sense of the words in mind; I’d like to understand what you think, and why.
So I'll ask you and others here: what do you think are the most important and applicable insights from that paper?
* Statelessness for horizontal scaling
* Idempotency to handle network partitions
* Request state must be inline or addressable by URL
* Hypertext As The Engine Of Application State
* Media type negotiation
* How to exploit pervasive caching
I think having these formalized in a coherent framework was very valuable, and I don't see how this couldn't help but influence your career, unless all you write are desktop applications.
In other words, all HTTP APIs devolve into screen scrapping, which is actively thwarted by terrible libraries. So just give up any expectations and do whatever scores the most agile scrum kanban karma on your team.
Distrust any one who claims they do understand. Because they don't.
Our study group chewed thru REST in Practice. It's very reasonable, approachable. Good advice for a lot of design choices that you'll likely run into.
Sadly, REST is like Agile. It's not possible for any two people to reach consensus on any aspect, big or small.
And just like Agile, REST doesn't matter. What ever you do will be wrong.
So just smile and play along.
If you pick SQLite you can also lean on their exotic-tier test coverage and the fact that you can author application defined functions for utilization from SQL (i.e. your DSL in this usage context).
So yeah, the original paper might be fun or funny, but not the easiest for understanding the basis for consensus protocols.
This is uncontroversially true. The controversial opinion that Raymond holds is that this implies an inherent genetic deficit in intelligence rather than simply being reflective of socioeconomics.
> Marion Barry abuses the D.C. mayor's office and snorts crack on video and `movement' blacks march in the streets to get him acquitted.
> Who will wake up the poor blacks in our cities to the fact that they've become their own worst enemies, slaughtering each other in numbers the Klan could only dream of, yearly racking up casualty figures reminiscent of a medium-sized war?
Is he asking any black people what should be done? Not in this essay. He's laying all blame at the feet of black people. He doesn't mention any issues caused by non-black people.
Also, he's asserting that some anti-racism initiatives are threats.
> `Afro-centrists' agitate for their own (segregated) schools and curricula that would consciously try to write the white man out of the black child's version of history.
(Increasing black representation is writing the "white man" out of history?)
> Who will speak the hard truth: that, against this hideous backdrop, continued attempts at the moral blackmail of innocent whites with reminders of past racism will only drive them into the arms of hatemongers like David "Sieg-Heil" Duke and his scummy gang of knock-off Nazis?
(The worst racism is calling something racist?)
If this essay was supposed to convince me he doesn't hold some racist views, it backfired miserably. His vision of "non-racism" appears to be conscious ignorance, where the biggest racist threat is people saying something is racist.
I have spent a good part of my life doing things like device control, and direct, native, user interface. These can get mui hairy.
It's difficult to talk to a lot of folks about these, as everyone is focused on "the Big Picture," to quote Peter O'Toole.
Device control, in particular, has a lot of aspects that are unique, and not particularly applicable to many other disciplines. With the advent of some of the new communication techs, like Bluetooth, and advanced serial buses (like USB and Thunderbolt), we're starting to see a bit of cross-pollination with communications (another discipline that many software developers never need to worry about).
UI has always been best served (not exclusive, but best), as native. This means that each platform tends to have a specific framework.
Learning frameworks, SDKs, and APIs has always (for me) been the most time-consuming part of adapting to a platform or system.
But that's just me. YMMV.
I guess I’m talking about myself here too. I have no Computer Science training and can’t say I’ve ever felt like I need it. I could take the time to read an academic paper about the next 700 programming languages or I could read an introduction to iOS development with Swift. I know which one is most likely to help my career.
That point is now, and it's partially out of boredom. I've worked with many languages, frameworks, libraries, patterns, and they're all starting to look the same. I've become a master of tools, able to reach for the right tool given a specific scenario, but I'm starting to find I'm lacking a sense of curiosity and depth.
Maybe without a strong foundational knowledge, we'll only ever be users of the tools, and never creators. I feel like I need to start giving back at some point in my career. Maybe it's time to start working on foundations.
Did a CS degree (92-95); Database design + SQL has been the only thing properly relevant to my career* (and then only the theory side because the practical was Oracle embedded Pascal...)
Not relevant: Prolog, SML, electronic design, 68000 assembly, Pascal, processor design, compiler design, etc.
* some of them have been relevant in personal fun projects though
For that, we have Mickens, The Night Watch: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
I too have spent a lot of time in the direct access mines. Everything has been just a bit too specific to write papers about, it's mostly a question of digging registers out of reluctantly provided datasheets. Fortunately I get to do it in C# now.
I am not a Linux guy, but I’ll bet the Linux Kernel has a bunch of stuff.
Platforms tend to have foundation-level device support, and, nowadays, it’s unwise to go around it.
I’d definitely look at the device control foundation library (C#, maybe Windows?), as a starting point.
One of the lessons that I’ve needed to learn, was to get out of the weeds, and use the tools at hand.
Most communication and device control stuff tends to have two main characteristics:
1) They are composed of “layers,” with increasing granularity, as you get closer to the hardware.
2) They tend to be highly asynchronous, with a lot of “reactive” behavior.
When I found and started reading those papers it was like finding life in another planet. It completely changed my way of thinking. I dropped out school and focused on learning as much of the cool stuff as possible (on the internet). It payed off well :)
Computing Science should not have deep dependencies on certain tide of computing devices(be it hardware or software). Instead computing conceptual models should be taught, so that students are better equipped with those ideas to express them and find transformations and implementations when needed.
Though certain getting hands dirty coding is also needed, but all too often we kind of thinking in a tool users' manner.
But at some point, if you want to educate people to build real working products, in the real world - and this is what the vast majority of CS students are going to do - then you have to teach also exactly this. How to build things for real and not just thinking about how to build things.
I appreciate more about some theory when I've programmed mechanically for a while. And I also found writing some code to be relieving when I drank too much theoretical kool-aid.
Reflections on Trusting Trust is seminal. In the age of networked computing and open source (and decades of apparently no one mounting a meaningful exploit along these lines) one is asking the reader to do a lot of work to generalize from the concepts in the paper to ideas of security and trust that align with their experience. I could imagine (and did) reading this paper in a class with a moderated discussion. But without the discussion I suspect it would fall flat for many readers.
In the comments people suggest the original Paxos paper. It is cute, but incredibly difficult to understand IMO. For people already aware of network programming primitives, Lamport doesn’t use any of them instead inventing his own metaphors. I tend to think Raft was so successful when it came out because it was described more clearly, not that it was a better algorithm.
It would be interesting to find better more accessible ways of learning the same material. Or maybe the best would be an edited volume, like a textbook, interleaving these classic papers with modern analysis, reflection, and commentary.
However, at some point, they will all write some software that does arithmetic on arbitrary data. They will all be tempted to calculate an average by adding all the numbers and dividing by ten. Therefore, I propose that all developers should read and re-read Goldberg regularly.
Maybe it's just me but I don't think reading a paper about `A Laboratory For Teaching Object-Oriented Thinking` is relevant anymore except for historical purposes.
By A. M. Turing
This paper introduces the concept of the Imitation Game, which would eventually be referred to as the Turing test. 
Big Ball of Mud
Brian Foote and Joseph Yoder
I wish Ken writes more papers & documents.
"Kernighan has written ten times as much readable prose as has Ritchie, Ritchie ten times as much as Thompson. It's tempting to say that the reverse proportions hold for code, but in fact Kernighan and Ritchie are more nearly tied and Thompson wipes us both out." -- Dennis Ritchie
Note how this list has little on program correctness, performance (big O or real world), distributed systems, operating systems, networking, team organization.
Homesteading the Noosphere, Eric Raymond [http://catb.org/~esr/writings/homesteading/homesteading/]
There are more that I've found interesting over the years but that paper really helped me shift how I think about programming and the design of programs. It lead me to many others and to appreciate type theory.
I was very confident that the list would contain the Logical Clock paper by Lamport, but alas it doesn’t.
By and large most software projects still seem to fall into the pits described in this paper.
10 years ago https://news.ycombinator.com/item?id=2922108
12 years ago https://news.ycombinator.com/item?id=496830
02. [A Note On Distributed Computing – Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall](https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...)
03. [The Next 700 Programming Languages – P. J. Landin](http://thecorememory.com/Next_700.pdf)
04. [Can Programming Be Liberated from the von Neumann Style? – John Backus](http://www.csc.villanova.edu/~beck/csc8310/BackusFP.pdf)
05. [Reflections on Trusting Trust – Ken Thompson](http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...)
06. [Lisp: Good News, Bad News, How to Win Big – Richard Gabriel](https://www.dreamsongs.com/Files/LispGoodNewsBadNews.pdf)
07. [An experimental evaluation of the assumption of independence in multiversion programming – John Knight and Nancy Leveson](http://sunnyday.mit.edu/papers/nver-tse.pdf)
08. [Arguments and Results – James Noble](http://www.laputan.org/pub/patterns/noble/noble.pdf)
09. [A Laboratory For Teaching Object-Oriented Thinking – Kent Beck, Ward Cunningham](http://c2.com/doc/oopsla89/paper.html)
10. [Programming as an Experience: the inspiration for Self – David Ungar, Randall B. Smith](https://suif.stanford.edu/~lam/cs343/programming-as-experien...)
... but none of them will teach you how to show up to a customer's house on time to install a toilet quickly, efficiently, and accurately, with a smile on your face.
I cringe when I see a team blindly implement the design in a paper. Design to your needs, not somebody else's! Papers are great places to take ideas from, but you should never treat them like gospel, or copy them outright. It's the same trap as designing your solution around your tools rather than vice versa. When someone brags about implementing the design in a paper, I expect it to work poorly (at least until they figure out all the stuff that wasn't in the paper).
Papers are experiments, whereas Best Practices are the experiments that were reproduced by many people in many places over a long period of time. If what you're building matters (not R&D), implement the best practice first, not the experiment.