Academic writing for students

WritingPhDTipsResearch

Do I put this in the methods or the related work? What makes my writing informal? How do I order the results section? I get these writing questions all the time. Many computer science students struggle with the same academic writing problems. In this blog, I share my most-repeated advice and give you lots of actionable tips to improve your academic writing.

Academic writing is the written communication of research ideas or findings, targeted at other researchers. Academic writing is more formulaic than most students know: we have strong traditions for the content, structure, and style of the writing. We’re expected to learn this, yet many university programmes don’t have a dedicated writing course for undergrads. We learn writing slowly, painfully, through feedback on our assignments. Our computer science students at Leiden University need to do three forms of academic writing:

• Research proposals
• Reports or papers
• BSc/MSc theses

In this blog, I’ll focus on reports/papers, but you can apply most of these lessons to proposals and theses, too. I have three goals:

1. Help you avoid the most common writing mistakes (and save me time on repeating feedback ;) )
2. Make writing easier for you by explaining the most important academic writing principles (the big picture!).
3. Point you to resources to help you with writing.

I will cover how to decide what information goes in (content), in what order to present it (structure), and how to choose the right words (style). I will also write about the process of writing: from the blank page to your first draft, and what happens when you submit your writing to your supervisors. Finally, I’ll show you two real examples of how I would grade my own proposal and corresponding paper right now.

The first thing people struggle with when writing papers is deciding what to put in which section. I remember I was especially confused about the difference between the related work and the methods. Let’s look at the parts of computer science papers and what information a researcher reading your paper expects to find in each one.

Computer science papers always have the following sections (though they may have different names):

• Abstract: a short sales-pitch of the paper to draw people in.
• Introduction: sets up the problem and introduces your contributions
• Related work: explains how your work fits into your research field
• Problem statement: a formal, often mathematical, description of the problem
• Methods: detailed description of how your method works
• Empirical setup
  • Research questions: the questions you want to answer with your experiments
  • Data: description of data. Can be a separate section and come earlier in the paper if it’s very important (e.g., you designed a new dataset)
  • Baselines: describes how you chose your baseline methods
  • Experimental details: describe how you run your experiments (hardware, number of runs, hyperparameter settings, evaluation metrics)
• Results: present and interpret results towards answering your research questions. Discusses limitations & implications.
• Conclusion: a summary of your paper + directions for future work

The abstract is a mini-summary of your paper, designed to make people want to read the paper. It should briefly mention the research field, what problem you solve, the methods you use and the most important findings.

The introduction sets the stage for the rest of the paper. It needs to:

• Explain on a high level which research field your work fits into (is this contrastive learning, time series, etc.)
• Identify knowledge gaps / unsolved problems in existing research
• Motivate your solution.

After reading the introduction, the reader should be convinced that there is a problem to solve and that your approach is a promising solution.

Do you ever get angry when you watch a movie, and the main character is suddenly saved by something entirely new, like magic or a weapon that appears out of nowhere? This is a plot device called deus ex machina. It’s an unoriginal and often unsatisfying end, and it can mess with our academic writing as well.

The reader must learn early on what they can get out of this paper: is it a methods paper, are the results positive? If you fail to mention something important, like a key part of your method or a surprising result, the reader can feel confused or even manipulated. Therefore, the introduction has to at least hint at every key method, result, or other plot twists.

The key to a strong introduction is to make the problems as specific as possible. The broader the problem, the more evidence you have to provide to show that you fixed it. More AutoML4EO papers than I can count present ‘designing neural networks is hard’ as the knowledge gap, but then only evaluate their methods with 1-2 specific satellite image datasets. In this case, the scope of the introduction is too broad for the evidence presented. You don’t solve the problem of design of ALL neural networks by showing results only from satellite image datasets. Instead, you need to present a knowledge gap specific to this type of data/problem.

Isaac Newton wrote:

If I have seen further it is by standing on the shoulders of giants.

His words emphasise that all our research is only possible because of the work of people before us. In the related work, we summarise the previous research the reader needs to know to understand our contributions. But the related work is also more than that: it shouldn’t just be a chronological summary of the field. The related work should set out how your work fits in with related papers. What do you approach the same way? What is different? You can use the related work to further flesh out the knowledge gap: which alternative approaches are you not considering, which questions are people working on? You don’t have to explain why you don’t do all those other things. The point is more to clarify overlaps and differences with other papers.

Now, I always think the background is a strange section. It is the place all essential information goes that does not semantically fit into the introduction, related work, or methods. The background lays out the theory and foundational information needed for your peers to understand your thesis. Think mathematical formulas and notation, and domain knowledge about the data you have learned during your project but your peers might not know (like a subsection about satellite data). So in contrast to the related work, this is not about other methods.

The methods section has two broad goals:

• Reproducibility: your methods should be described clearly enough so somebody else can re-implement it;
• Persuasion: you also need to motivate your design choices (why this network and not another? etc), basically to convince the reader that this really is the best idea of solving the problem.

The first mistake people make is to focus too much on previous work. In this section, your proposed solution should take center stage. Avoid lengthy descriptions of pre-existing methods. These may fit better in the introduction or related work. Or, you might not need that much detail and it can be enough to just refer readers to the original paper.

The second mistake is not making clear which bits are your solution and which methods were invented by somebody else. Many people accidentally use language that signals to scientific readers that you invented something, when really you just applied an existing method. This can be considered improper credit attribution, which is a form of plagiarism (even when it’s unintentional). You can avoid this by:

1. Citations! Researchers attribute credit mainly by citing other papers. A citation alone is not always enough (it can, for example, refer to an argument made in another paper rather than the method presented in it), but it is the absolute minimum.
2. Using the proper reporting verbs. Reporting verbs like ‘presenting,’ ‘proposing,’ and ‘applying’ have different meanings. In computer science, the phrases ‘we present’ and ‘we propose’ imply that you invented this method. The implications of reporting verbs vary from field to field, to make it more complicated. Honestly, úse the right verbs’ is shitty advice because it’s very hard to do right from the start. You learn slowly by reading many papers & receiving feedback on your writing. But awareness is the first step in learning, so now you know how small words can affect how your writing is interpreted.

Finally, it is very helpful to add diagrams and/or a pseudoalgorithm to show your methods. It is sometimes easier to understand than a textual description.

The empirical setup of a machine learning research project is incredibly important. It doesn’t matter how persuasive your idea is if the experimental design is shaky. In the empirical setup section it’s your job to convince readers that you did everything you could to make the evaluation of your methods as solid as possible. You need to describe the research questions, data, baselines, and experimental details.

The empirical setup is mostly a very dry section with lots of details. A few do’s and don’ts:

• Do provide nitty gritty details like the number of images in the dataset, how you split the dataset into train/val/test, which optimiser you use, which learning rate, batch size, how many epochs, which evaluation metrics you use, the type of GPU/CPU, how often you repeat each run, which statistical test you use;
• Do motivate your choices: why this metric, why that baseline? Convince your reader that these are strong baselines (hard to outperform). Sometimes, you can motivate a choice by referring to preliminary experiments without showing those results (or put them in appendix);
• Don’t write in great detail about things described in other papers. If you copy somebody else’s data pre-processing or training procedure, just say ‘we follow < citation>. ‘
• Don’t show or discuss results here. That’ll come later.

The results section seems to speak for itself: it’s where you show your results. But it’s not only that! In computer science, the results and analysis are merged into a single section. Therefore, the results section shouldn’t just display the results but also discuss the interpretation, implications, and the limitations. It’s very important to not only describe what the tables and figures show, but to draw conclusions from the results. What does it mean that method A is better than method B?

The conclusion is a super-short section at the end of the paper that looks a lot like the abstract. Where the abstract is a sales-pitch designed to draw people in, the conclusion is more like a short report. Like the abstract, it’s a stand-alone summary of your paper: you have to be able to understand it without having read the rest of the thesis. Be aware that researchers often don’t read theses and papers linearly. It depends on the person, but often people will read the abstract and conclusion first before reading the rest. So don’t dive straight into the conclusion of your results, briefly repeat the topic, problem, and solution. Finally, mention ideas for future work. These can be things you want to work on, or research directions for other people opened up by your work.

Many beginning researchers don’t realise how strict the structure is we expect academic writing in. It’s not just about what information goes into which section, but also in which order it is presented. A strong structure helps readers navigate the text and follow your argumentation. Academic writing follows the inverted pyramid: start with a general introduction, and narrow it down further and further.

Therefore, structure-wise, the most common writing mistake is to skip writing introductions to each section. The abstract, introduction, and conclusion are a bit different (either by their length or custom structure), but other sections should always start with a few high-level sentences describing the contents of that section.

Adding introductions also means avoiding stacked headings: you should always have a short introduction between a section heading and a subsection heading (and other level-headings).

Every section has its particular structure. I will not go into great detail, because there already is a great resource on this topic: the commkit from the MIT EECS communication lab. Use this for outlining! Here, I want to say some more words about the structure of the introduction, methods, and results. Finally, moving down the inverted pyramid, a word about paragraph structure.

As I said, the introduction is a little special. It does follow the inverted pyramid, going from the general topic to the very concrete contributions of your thesis. Instead of starting with an outline (as I recommended for other sections), it rather ends with an outline of the thesis. As the introduction is at the start of the thesis, you don’t want to bore people with an outline. First, you have to convince them that your thesis is worth reading (after the abstract has sparked their curiosity). You do this using a very particular structure, that’s used throughout all of academia (not just ML): the CaRS structure.

CaRS stands for Creating a Research Space. You do this in three steps:

1. Establish a research territory: broadly describe the field of research. In my case, that’s machine learning-based methane plume detection.
2. Create a research gap: mention some related works, and highlight the problems they are not solving. Now the key here is not just to list a random list of problems, but to list only the ones that you will be solving. Also describe the properties a method needs to have to solve the problem, and explain why existing methods don’t fit these properties.
3. Fill the gap: in the previous step you’ve set the stage, now you can describe your solution. This should be the focus of the introduction, I’d aim for at least 50% of the introduction. Here you explain how your method solves the problems you introduced in the previous step. In computer science, you also list the contributions, which are typically a mix of methods and results.

Then, in long pieces of writing like a thesis or a survey paper, add a one-paragraph outline of the rest of the work.

I cannot stress enough how important it is to focus on your methods here. Don’t go on too long about previous work, there will be space for that in the related work. Also, when doing interdisciplinary work, make clear from the very top that this is a computer science/machine learning work (so avoid writing only about satellite data, then dumping the ML as a surprise later on).

In the related work, you need to choose a logical way to group related methods. The three main options are:

• Chronological: makes sense if the work is not interdisciplinary/combining multiple methods;
• Hierarchical: make it increasingly specific. For example: computer vision, multimodal image classification, satellite image data fusion.
• Modular: (mostly) non-overlapping topics. For example: methane plume detection, missing data & fair ML

It depends on your project what makes the most sense. In any case: add a short introduction at the top of the related work introducing the categories. Don’t wait until the end of the related work to link it to your work. Link to your methods at the end of each category or subsection, and give a summary at the end. If this is vague, look at a few machine learning papers and highlight where they talk about their own methods in the related work.

The methods section of machine learning theses secretly consists of two sections: the problem statement and the methods. The problem statement is a formal description of the task (e.g., image classification) often using mathematical notation. As in the introduction, check if the scope matches your paper here. Make the problem statement as specific as your method. For example: if you’re doing data fusion, a problem statement about standard image classification is not specific enough. It sounds hard, but the nice thing about the problem statement is that it should be very similar in related papers solving the same problems. Look to those papers for inspiration.

My favourite way to structure the methods section is by breaking the methods down into the components. After the problem statement, first introduce these high-level components of your method. Then, write a subsection for the details of each method component. Stick to the inverted pyramid!

I like to organise the results section by research question. You can also split it by dataset, if you evaluate multiple. I’d say that the best structure is the one that:

1. Puts all related analyses close to each other. The most common mistake in structuring the results section is to scatter related information. For example, if a single conclusion is supported by multiple experiments, it makes sense to create a subsection for that conclusion and discuss all related experiments together.
2. Avoids repetition. If results are similar across datasets, it doesn’t make sense to write a separate subsection for each one. Cluster by main findings instead.

Then, the second tip is to order the subsections by importance. Start with your most important, ‘biggest,’ results, moving on to the smaller results that nuance the main result. For example, if you combine many different methods, you can choose to start with the results of the full method (all X components), then put the ablations (turning individual components on and off) at the end.

Going down the hierarchy of structure we have: sections, section structure, and then paragraphs. Paragraph structure is another very common mistake in academic writing. Here’s what goes wrong: Students write very short paragraphs: random line breaks are placed in the middle of a topic. Within a paragraph, the sentence order is not very effective. At the end of the paragraph, students forget to link the topic of the paragraph to the paper at large. You may have in your head why that information is relevant, but you need to explain to the reader why, for instance, the description of a particular problem is important for the thesis.

There is nothing inherently wrong with short paragraphs, but it’s important to know that in academic writing and persuasive writing in general, one paragraph should be one full idea or argument. Sometimes, paragraphs can get quite long. Don’t compare academic paragraphs to blogs, news articles, and columns: those are different genres with different conventions. Before pressing enter, ask yourself if you’re moving on to a new argument or topic. If not, restrain yourself!

Just like papers and sections have very particular orders, researchers also expect a certain structure from paragraphs. This is a structure that is most effective at persuading the reader of your points, very similar to essay writing. There are many different models, I really like the TEECL structure. It is a bit confusing and hard to get used to at first (it can help to practice by asking an LLM to rewrite a few of your paragraphs in that structure). Practice is the key.

The ‘L’ in TEECL stands for Link, and that’s the sentence at the end of the paragraph that many people forget. I suggest you analyse one or two papers you like and just go through the last sentences of the paragraphs (in particular the related work and results). This will help you get a feeling for how much you need to explain explicitly.

Writing tone & style are hard concept to grasp. Some people have almost perfect academic tone from the start, others write very informally. Tone is how the text sounds like: is it your professor speaking, or the person behind the bar? Tone particularly is something you pick up by reading lots of papers. Writing style, most of us have to work at to improve. Writing is a craft that requires skills, just like playing sports.

Regarding tone, the biggest mistake is to write informally. Academic writing is really formal, which means two things:

1. The writing is objective. We avoid subjective adverbs like ‘superb, amazing, horrible,’ etc. Instead, we describe methods and results by more factual observations: method A performs better than B.
2. The writing is precise. Use the most precise words and terms you can find to describe what you mean. No ‘sort of,’ no woolly descriptions. Sometimes we think that formal writing means using difficult words, but we only use difficult words when they are appropriate (e.g. very precise jargon words that can summarise a complex concept). Avoid difficult words that don’t really mean anything! Here’s an example from a real research paper. You can write this much more simply without being informal.

Then there are some small things, like avoiding contractions (can’t, don’t, won’t) and spoken language, which is considered informal.

Writing style is the subject of many books and courses. People devote their life to honing their style. I cannot do this topic justice here. Here are my main style tips: Use as much active voice as you can. It is more direct and clearer than passive voice. However, passive voice is not forbidden. It has its uses, particularly in the empirical setup section.

• For Dutch speakers: English sentences are structured slightly differently from ours. We like to put new information at the beginning of the sentences, while native English speakers prefer new information at the end of the sentence. This is also called the concept of end focus. You can use it to make your writing sound more native.
• End weight principle: order phrases within a sentence from short to long (when you can). For example, in a list, start with the shortest items and progress to the longer ones.
• Alternate long and short sentences to improve rhythm. Too many short sentences after each other sounds weird, and too many long ones are hard to read.
• Parallelism: structure each sentence in a list the same way.
• Academic phrasebank: as I’ve said many times before, academics are sticklers for tradition. This website has a lot of template sentences for describing various things in academic writing. Want to learn more about writing style? Grammarly has lots of tips, and the Elements of Style by Strunk & White is has lots of tips (though one or two haven’t aged well, I warn you).

Writing is much more than putting the right words in the right place. Writing starts when you’re doing your literature review, when you’re designing your problem statement. All of this research and design work needs to happen before you can write about it. However, that doesn’t mean you cannot start writing early in your project. When do you start writing? And where do you start? And when is it finished?

My biggest piece of advice regarding your thesis research is to resist the urge to start programming and experimenting right away. Every student I’ve worked with, myself included, felt daunted by the prospect of their first large research project and wanted to get ahead as soon as possible. However, it’s very important to design your research first so you don’t spend weeks running random experiments and realising at the end it’s not really going somewhere (or worse, someone else already did the same thing).

A good first step is to draft a research proposal. A proposal does not have to be written perfectly, but has to describe the core idea and resources needed. A proposal should highlight:

• The knowledge gap (and therefore also a short related work)
• Your solution and motivation for the solution (the high-level idea of your methods)
• Preliminary empirical setup:
  • Research questions
  • Dataset (check how large it is and if you can access it)
  • Baselines (what will you compare against)
  • Metrics (how will you measure performance)
  • High-level experimental plan (which analyses do you plan to run).

By itself, it’s not a very long piece of text (maybe 2-10 pages) with lots of bullet points. Take enough time to think carefully about your design. Don’t rush this foundation, because if the problem statement & solution (including motivation) aren’t strong, you won’t be able to fix it in the experimentation phase. You’ll probably need more than a week. If you struggle coming up with a concrete problem or research question, you need to read more papers, do preliminary data exploration or very small-scale experiments, or talk to your supervisors.

Once the design is set, you can start implementing and running your experiments. Expand the sections from the proposal as you go. For example, write the methods after you’ve implemented them, and update the text as your research changes. (the plan always changes). Some people recommend to write the introduction last. Personally, I think you can write it already early on as long as you already designed the problem statement. I do recommend to leave the abstract and conclusion until the very end (because they are summaries of the rest of the paper).

I just glanced over the comments. In reality it can be one of the harder and more frustrating parts of writing. I was certainly surprised by it. Supervisors can leave conflicting comments, especially if they are from different disciplines. And sometimes you don’t understand at all what the comments ask of you.

Here are my strategies for dealing with these situations:

1. After receiving a round of comments, read through them all but do not address any of them. Sleep over it for a night and get back to it the next day. The feedback can feel very personal because the research was your idea and you worked hard on it. I assure you, your supervisors only want to help you make it better. Sleep on it for a night if you feel upset.
2. There are a few ways to deal with conflicting comments. In general, it is good to try to take everybody’s feedback into account as well as you can. Don’t disregard one person’s feedback completely because you like another’s better. It can negatively impact your grade. When it’s about something small/unimportant: choose whichever way you think is best. If it’s an important point or you’re unsure: ask your supervisors to resolve it together. Meet with the people involved and let them discuss it (children of divorced parents may be familiar with this strategy :P).
3. If you don’t understand the comments, meet with the person face to face (or online) and ask them to explain on a high-level what their main feedback is. That can often help to clarify individual comments. If you’re still unsure, just ask them about it.

Finally, every person has different commenting styles. My supervisor’s strategy is to read as if she were a reviewer, an external person that doesn’t know you. If you don’t know this, it can sound as if she didn’t understand your research at all. But the point is: she reads your text carefully and checks if someone without the knowledge we have may misinterpret it. Sometimes small words can change the meaning of what you want to say. Be prepared for this, and don’t be afraid of asking questions.

I went back into my overleaf archive and found my own project proposal and report of the course I’ve been teaching during my PhD. The assignment was to design and carry out a research project starting from an existing paper. It’s like a mini-research project. You can find the PDFs with my comments here. I hope it makes the explanations in this blog clearer.

As always, please reach out if you have questions or additions!

---

Julia's guide to figures and tables

June 7, 2025

How to improve all your projects in five minutes

June 20, 2024

Avoid these mistakes when presenting in your master's

January 17, 2025

← Back to Blog