ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Purpose
2
There are a number of reasons to read papers. First and foremost, papers are typically peer reviewed by high quality experts, and are therefore high quality source of information, as opposed to, for example, an unvetted blog post on the internet. Second, many problems that are troublesome for programmers have excellent existing solutions, papers often capture said solutions, building a common vocabulary and understanding. Third, being exposed to deep thinking outside of simply your direct experience broadens horizons. Fourth, as you and your team tackles harder problems, not consulting (industry or academic) research is very costly, as you'll spend more time reinventing the wheel and making many mistakes along the way. Lastly, it is the hallmark of a good developer to be able to take a research idea, implement it, and bring it to production.
3
4
Recommendations
5
For the full meal deal, it's recommended that you start with the 'Problem Solving' section and progress to the right.
6
7
This may not work for everyone, in which case, I suggest picking some from the non-general tab, and then asking people who've read the paper, to provide guidance around prerequisites.
8
9
Check out the "How to Read Papers", and "Suggested Format for a Reading Group" Sections below.
10
11
How to Read Papers
12
I've often heard, "I don't get much from papers", or "It's so hard", or some other complaints. It's sometimes the paper, but it's also the reader. I'm going to address the reader portion.
13
0) Learning is hard, and contrary to popular belief, what some consider memorization, actually repitition, is a key part of learning -- I used to think otherwise, I took a course, turns out I was all sorts of wrong.
14
1) Setup a reading schedule, don't cram it all for the days prior. Little bit everyday is easier anyways, and you'll read much faster. (focused thinking during readings and diffused thinking between readings)
15
2) Prior to reading, review all the notes you've taken thus far, read one sentence, cover it up, and try and recall all the surrounding details. (spaced reptition)
16
3) Read a paragraph, cover it up. Then recall everything you can about it, ideally note everything you recalled. Read it again, and see how much you got. The harder the paragraph, the more times you'll have to do this. Summarize the paragraph into a sentence covering the key point. I scribble this in the margins of a printed copy in the paper.
17
4) Persist. Papers become easier to read as you go, it's partially a skill, the more papers you read not only will you get better at it, but papers are referential, and you'll have read the references. All those notes you made, you'll be able to review those, instead of having to re-skim the referenced paper.
18
19
Suggested Format for a Reading Group
20
0) Have someone be the moderator, as the moderator, you'll make mistakes, don't worry about it. Try and balance moving things forward, but keeping people engaged/discussion alive.
21
1) Introductions (people introduce themselves and their background). You can skip this if everyone knows each other.
22
2) First impressions (this is a chance for people to provide their broad strokes throughts about the paper, this should be brief, and discussion should be kept to a minimum)
23
3) The moderator moves through the paper in a structured fashion, start with the abstract and move through it section by section. People, including the moderator, should volunteer questions, comments, concerns, and related anecdotes. Ones that tie it back to examples at work is a great idea.
24
4) Devolve into free-form disucssion, revisit tangents that might have been killed earlier.
25
26
Suggestions/Additions
27
If you have any suggestions/additions please see Saem
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100