# #
TL;DR: Yes.[1]
Papers, papers, papers. Papers have gotten a lot of attention these days. There are Twitter accounts, meetups all over the world, GitHub repositories, and lots and lots of chatter about reading papers. With all this talk about papers, people are bound to ask:
“Should I read papers?”
I think you should. I’m on the record saying so quite a bit and I continue to assert that for a variety of reasons, it’s a great idea for people in any field.
But this still leaves a lot of questions unanswered, which I’d like to address now. In the spirit of unpacking dense language, let’s look at each of the four words in the question:
“Should I read papers?”
Of the four words, the “should” is probably the most challenging. What do I mean you “should” read papers? Who am I to say? Do I really want to dictate your behavior?
No, I really don’t. If you don’t want to read papers, don’t. That’s fine. But I wanted it to be on record why I think you should.
I mean should in the same sense that you should eat healthful food, or you should get out in the fresh air as often as possible. I mean it in the sense that if you believe that you should bring purpose to your work, then you should be doing whatever you can to improve and to understand the universe you work in a little bit better each day.
“Should I read papers?”
Who is the “I” that I’m addressing here? My current milieu is that of people involved with computers in some way, but primarily I’m addressing software developers.
I was fortunate enough to study with some amazing people who taught me that if you make things with computers, it behooves you to understand how they work. To not accept the status quo in artistic or creative tools that computers provide, but to look under the hood, emulate, and make your own tools.
So if you’re one of those people, who sits down in front of a computer every day to make things either for yourselves or others, you’re included in that I.
“Should I read papers?”
Because of the amazing elasticity of human language, even the word “read” in this context is very loaded. Doesn’t read just have one meaning? If it did, most people would say something like:
“You have read something if you’ve consumed the entire thing from beginning to end.”
But that is a fantastically terrible definition for read in the sense of “Should I read papers?” To read a paper is to interact with in even the most surfacey of ways:
This is because to read a paper means to have a relationship with it. Over a long period of time. You may sit down and “give it a good read,” but really, if it’s worth reading, you’ll come back to it again and again.
In other words: you can’t be “too dumb” to read a paper. Anyone can read any paper at any time. Don’t be afraid, be encouraged. You will learn something.
Keep in mind that “reading a paper is not the same as reading a blogpost or a novel” and also don’t forget: you are not alone.
Even though the question at hand is “Should I read papers?” you’re barely ever alone. There’s almost always someone else going down a similar pathway as you. And now more than ever those people are reachable, either in person or virtually.
“Should I read papers?”
Finally (maybe this one should have been first?), what is a “paper?” A paper is a crystallized idea presented in written form. It could be tiny. It could be significantly longer than that.
It could be an idea that someone captured, or the result of a life’s work, or anything in between.
As fluid as the definition of read is above, that’s how you should think of a paper. The person or people who wrote it aren’t necessarily “smarter” than you. They almost certainly have very different life experiences. Who knows where they come from, or what they were trying to do?
I’m drawing your attention away from the paper and toward the people on purpose, because they’re one and the same.
My answer to the question “Should I read papers?” is a resounding yes, but really what I mean is: you should stretch.
Give yourself a challenge.
There’s more beneath the surface than you could ever imagine.
Thanks to Zeeshan Lakhani, Tom Santero, James Golick, Alex Kahn, and Ken Keiter for their help with this post.
[1] This is the one and only “TL;DR” that I will ever publish.