Building knowledge every day, one paper at a time

The method described in this entry is simple to apply and is flexible enough to accommodate a fast-paced, challenge-oriented learning approach. Because a paper needs to be read every single day, qualities necessary to successfully apply it are diligence and perseverance. I thought of sharing this approach because it might be useful to computer science and engineering researchers who find that the traditional "waterfall" approach to research is not flexible and fast enough. After all, there is no unique approach to acquiring and producing knowledge and finding the right one for a given situation remains a challenge. 

When I started researching on new ways to build modern software for my MSc thesis, I was overwhelmed by the quantity of knowledge to probe and wasn't exactly sure what subject I would focus on. Many students are encouraged to dedicate a period of time to gather knowledge from literature and assimilate concepts before choosing a subject, needless to say before proposing new ideas to advance a field. Successful as it may be, I was dissatisfied with this approach because this period of time could be longer than needed and I had grown the habit of a more hands-on, iterative approach to knowledge acquisition during my engineering studies at Sherbrooke University (1). I must also admit that the iterative nature of the Agile development methodologies has also influenced the way I plan and execute work.

(1) - The approach used there was called APP, a french acronym for "Apprentissage par Problèmes et par Projets" which translates to "Learning through Problems and Projects". Through projects lasting roughly two weeks each and a large one each semester, knowledge was studied, practiced and applied in concrete situations. For every project, a report was produced and an exam was issued. A project generally covered the equivalent of a course, which means instead of building knowledge in parallel during a whole semester, I built it sequentially and applied it iteratively into a large project which covered parts of every courses in this semester.

I proposed a different approach to my research director which was fairly challenging, yet more compatible with my work style: after a week of researching and reading, I would read one paper per work day for a period of four months (2). The goal was therefore, for 20 days on average each month, to read a total of 80 papers. Of course, reading was not sufficient: the papers had to be annotated and added to a bibliography database to be able to easily search through them and include them in a paper. I used Docear, a free software which I highly recommend if you intend to use LaTeX for your paper (which, really, you should). The integration of JabRef allows to produce a bibliography up-to-date with your library and adding a new one is easily done through copy-paste of BibTex descriptions generated by major indexing engines. Enough on tools, let's get to how the actual work is done.

(2) - The four months period was appropriate in my case since I took the summer semester to focus on my research.

How
Because a paper needs to be read every day, objectives are not really clear at the beginning. That is why the first week is entirely reserved to explore the field you want to contribute to. The goal is to read more extensive work like roadmaps and landscapes of research in order to grasp the state the field is in. Once this week is completed, with some luck you will be struck by questions regarding challenges in your field. The idea is to produce some work like a prototype demonstrating an idea which aims to partially solve a challenge at the end of a certain period, say two weeks. At the end of the period, a small one-to-two pages report will be produced which explains the challenge, the work and the idea it implements. The work will also be criticized and at least three improvements will be suggested. Then, a new challenge is chosen, related or not to the previous one, and the same is done for the entire research period.

With a challenge identified, it will be easier to search papers which aim to partially or completely solve the problem. If the challenge has already been solved, the paper will point to new challenges which can be tackled in the current iteration's work, or researched on the following day. The whole process allows to look for new knowledge while working on challenges to better assimilate concepts. Another twist to this approach is to not prepare a fixed reading list for the iteration, but instead listing interesting papers on a bullet-list and prioritizing them every day. At the time, because a paper is taken out of the list every day, I would add at least one paper every day too. That way, I was sure to always have papers up-to-date with my current interest, especially as my understanding of the challenge progresses throughout the iteration.

Now, reading a paper every day might be seen as a large workload, especially when you work on some prototype which you know will need a lot of work to be completed by the end of the iteration. A way to deal with this load is to limit the time devoted to paper reading for any given day. I found that about 1.5 hour was sufficient to read, annotate and quickly search concepts and other interesting papers mentioned in a 10 to 15 pages paper. For any paper larger than 15 - relevant - pages, I would split the reading in multiple sessions which would equal to a 1.5 hour of reading. This effectively reduced the number of total papers, but the amount of knowledge extracted would be more evenly distributed among days. The biggest challenge is probably to not miss a single day as this becomes a slippery slope. On the other hand, I found myself reading over the week-end to spare me a paper during the upcoming week.

Results
This approach allowed me to build a bibliography of now 86 papers and theses during the summer of 2016 for my MSc thesis. At the same time, I produced several prototypes which all built on the previous ones and developed the draft of a library alongside as an integration project. As my understanding of core concepts became clearer and my ideas to contribute to the field of adaptive software engineering more mature, I was able to assimilate knowledge at a dangerously fast pace while producing valuable work. In fact, I was able to produce a draft of my first paper using parts of my previous reports (which were all already written in LaTeX using the official IEEE article class). These reports were also a very nice way for the university to follow my research and comment on my work from a very early point compared to the traditional approach.