This document offers guidelines and practical tips I’ve gathered while supervising thesis work, which I hope can help students navigate the writing process.
These tips focus on the practical aspects of writing a thesis rather than “strategic” elements such as selecting a supervisor, defining a topic, establishing timelines to meet graduation deadlines (particularly when results may be uncertain, as often happens with cutting-edge research), or determining potential outcomes including the final grade.
These are unique, personal aspects of thesis work that extend beyond the writing process itself. When seeking guidance on these matters, I recommend discussing them openly with both one’s peers (who may share similar concerns or offer valuable advice) and faculty members (researchers and professors) who are there to help students identify their interests and chart a path toward pursuing them.
Writing a thesis (for a bachelor’s or master’s degree) is a significant undertaking that demonstrates a student’s ability to conduct independent research while providing an opportunity to engage with and contribute to the state of the art in their field.
Theses have broadly four parts, frequently each corresponding to one (or more) chapter(s):
While readers typically progress through a thesis from beginning to end, that doesn’t mean one has to write it in that order. In fact, jumping straight into the introduction can be tough because the rest of the ideas for the other chapters are still swirling around in one’s head rather than being neatly organised into chapters.
For this reason, I generally recommend beginning the writing process with the pulp and doing it alongside the development of the thesis work in a structured note-taking style — not as a daily journal (“Day X: Today I implemented…”), but as organised technical notes that, once the work is complete, capture all the key aspects of the contribution.
This approach ensures one has comprehensive notes to effectively describe their work and helps to avoid situations where one has to try to recall details of work completed months before writing — at best, this might mean wasting time reviewing code to remember certain design decisions; at worst, it could mean failing to report or incorrectly guessing details about experiments that can’t be replicated before the thesis deadline.
As one refines these pulp chapters, I suggest listing in the background chapter the technical concepts that appear and need explaining for the non-expert audience (see below, about the “time-machine” exercise), as this categorised collection forms the content of the chapter on background knowledge. Once the structure of the background section is established, gathering the necessary information — presented concisely to give readers only what they essentially need to understand the thesis work — becomes relatively straightforward.
With the “pulp” and background chapters in place, it becomes much easier to write the conclusion, followed by the introduction. I recommend tackling the conclusion first mainly because it allows for more technical detail than the introduction. Additionally, having completed all other chapters makes writing the introduction significantly easier since the thesis structure and content are already established and one can refer to the latter to guide the writing of the contents of the introduction.
I noticed that one of the hardest parts of writing a thesis is formulating a convincing introduction. After all, the Romans already knew that “Dimidium facti, qui coepit, habet” or “They who have begun are half done”, or, looking at the other side of the coin, “Getting started is half the battle”.
Indeed, if one writes an effective introduction they are giving the reader all the necessary information to convince them of the aspects and validity of the thesis work. However, reaching that point is far from easy and requires efficient structuring to guide the reader from being a complete stranger to the work to appreciate its contributions.
For this reason, while I do not suggest following a specific template for the other chapters, I include below a basic layout for the introduction which I’ve seen working efficiently for most students.
The introduction usually begins by situating the thesis work within the broader field of computer science, gradually narrowing the focus toward the specific problem(s) which lead to the research (questions) that motivate the work. This kind of presentations tend to form a sort of “funnel” that drives a non-expert reader (but one with a bachelor/master-level computer science background) from the broad context to the problems and contributions of the thesis.
As an exercise, I usually advise the students to consider the task as if they have to explain to their colleagues their thesis work or (in a more introspective and sci-fi(ish) fashion) as if they had a time-machine, went back in time, and had to explain their thesis contributions to themselves before they started working on them, i.e., as complete novices. Their task is to introduce their thesis, aiming to present the work in a clear and accessible manner that a non-expert could understand, reflecting on the knowledge and perspective their interlocutor has, before delving into the details of the work (pondering what are the more and less important ones, leaving out the latter to the “pulp” chapters1), and figuring out how to explain the importance and context of the work, considering their interlocutor’s knowledge and perspective. In doing so, it’s useful to focus on offering a narrative that bridges the gap between the more generic, superficial understanding and the insights gained after finishing the work.
It’s standard to conclude this chapter with a brief presentation of the structure of the remaining chapters, which helps readers navigate the document and understand how the pieces fit together.
In particular, it’s important to describe the contributions without delving too much into the details that the reader has little to no knowledge about and would struggle to position within the general perspective they are building of the thesis, i.e., explain the key techniques/methodologies/tools/frameworks employed/presented but leave out details that are too specific (e.g., the specific configurations used to run the experiments) or not peculiar/novel with respect to the thesis work (e.g., the usage of a standard technique and/or specific software to implement/run the experiments). ↩