Writing Guide


Scientific Writing Guide for Non-PhD Students

This guide is meant to be a general introduction to scientific writing for non-PhD students. It is meant to be starting point for getting to know the structure and to provide practical advice on the most important aspects (in my opinion). Please also read Mary Shaw's paper on "Writing Good Software Engineering Research Papers".
This is a general guide to the typical sections of a scientific paper and their purposes. Not all papers will have all of these sections, and some papers may have additional sections. The specific structure of a paper can vary depending on the field, the journal, and the nature of the research. However, this guide provides a common framework for understanding the typical components of a scientific paper.
  • Purpose: To provide a standalone, high-level summary of the entire paper. To help readers quickly decide if the full paper is relevant to their research or interests. This is the most-read part of the paper, so it should be the most polished section.
  • What it includes: The core problem (what challenge are we addressing and why is it relevant?), the approach/methods used (how are we addressing the problem?), the most important findings (what did we discover or how did we evaluate our approach?), and the main conclusion (what are the implications on the real world).
  • Tips: Write the abstract last, after the rest of the paper is complete. Keep it concise (typically 150-250 words). In most cases the abstract is a combination of a shortened introduction and a shortened conclusion.
  • Purpose: To establish the context and explain why the research was conducted. To hook the reader and clearly define the scope and importance of the study. This section usually takes the most amount of effort to re-phrase, because every sentence counts and every word should be chosen well.
  • What it includes: Background information on the topic, the specific problem or knowledge gap being addressed, the key idea behind the approach or hypothesis being tested, and a brief outline of the paper's contributions (ideally an itemized list).
  • Notes: It is fine to overlap with the abstract. A good introduction is written so that the first sentence of each paragraph mirrors the abstract.
  • Tips on Structure: A good introduction should start from very abstract and general ideas and becomes more specific as it progresses The first paragraph can be written by a very wide audience. Then it becomes more concrete and might be written for a more targetted audience. Then in the end, it goes back to a general audience and broadens up to the implications of the research on the more general field.
  • Purpose: To situate the new research within the existing body of knowledge and to prove the authors understand the field and to explicitly show how their new work is different, better, or builds upon what has already been done.
  • What it includes: A summary of previous studies relevant to the topic, highlighting their strengths and limitations. A comparison of how our work is different from theirs or how our work is based on theirs.
  • Tips on Structure: Group studies by area. Use subheadings to clearly label each area and make it easier for readers to find relevant information. Whenever possible, discuss a body of work (multiple citataions of similar paper, e.g., "For example, the systems Phriky [62], Phys [38], and Physframe [37] use type checking to find inconsistencies in assignments based on physical units or 3D transformations in ROS code") instead of purely discussing individual studies.
  • Purpose: To explain how the research was conducted. To provide enough precise detail so that another qualified researcher could replicate the study and verify the findings.
  • What it includes: Detailed descriptions of the experimental design, materials, equipment, algorithms, datasets, or theoretical frameworks used.
  • Purpose: To objectively present the data and findings. To state what was found without bias or subjective interpretation.
  • What it includes: The raw facts, statistics, graphs, tables, and charts resulting from the approach.
  • Purpose: To interpret the results and explain their significance (the "so what?"). To give meaning to the data and demonstrate the broader implications of the findings.
  • What it includes: An analysis of whether the results answered the research question, how they compare to the "Related Work," and an honest acknowledgment of the study's limitations.
  • Purpose: To provide a final, memorable takeaway. To wrap up the narrative and point to the next steps for the scientific community.
  • What it includes: A brief restatement of the primary finding, the overall impact of the work on the field, and suggestions for future research directions.
  • Notes: The conclusions section is NOT supposed to be a summary. The abstract is the summary. A conclusions section should synthesize the findings rather than repeat them and contextualize them.
This is a general guide to the style and tone of a scientific paper.
  • Clarity: Use clear and concise language. Use scientific terms when appropriate. Avoid jargon or informal language.
  • Hypothesis vs. Fact vs. Opinion: Clearly distinguish between hypotheses (predictions that we plan to test in the paper), facts (observations shown by other cited work or in the data), and opinions (subjective recommendations or interpretations that we make) throughout the paper.
  • Examples:
    • Hypotheses: "To reduce the modeling effort and make formal analysis more accessible in practice, this paper presents a static analysis technique to infer X"
    • Facts: "In this course, 17 students across 4 teams successfully designed and implemented a complex system", "Recent graduates often lack important software design skills, such as generating and comparing alternative designs, communicating them effectively, and collaborating across teams [10, 32, 63]" "Robotics systems can be comprised of hundreds of software components, each of which can have complex behavior [10, 45, 76]", "However, ensuring that robotics software systems are safe and operate correctly is hindered by their large size and complexity [42, 54]."
    • Opinions: "Therefore, we believe adding additional homework to practice interface descriptions in the first half of the semester would help students", "We believe this discussion particularly helped students grow and integrate all major design skills more than they would have otherwise", "Potential improvements could use interleaving of different model types to train students to identify which aspects of a design are best represented using which type of model", "Therefore, we believe software design is most effectively taught with a large-scale multi-team project that closely simulates the complexity and challenges of professional software development projects"
  • Objectivity: Present information and arguments fairly, without bias (e.g., don't say "The best approach is to...". Instead say "The approach with the highest bug finding accuracy is to...")
  • Precision: Be specific in your descriptions and avoid vague statements. The more concrete you can be with your words and phrases (while still being correct) the better! (e.g., say "The system was able to process 1000 requests per second" instead of "The system was fast")
  • Consistency: Use consistent terminology, structure, and punctuation throughout the paper.
  • Skimmable: Use headings, subheadings, and bullet points to break up text and make it easier to scan. Do not assume that the reader read the previous sections (repetitions are allowed!). Name paragraphs and headings in a way that allows readers to quickly identify if they like to skip it. For example put all important related work into the introduction and all peripheral work in the "related work" section that is mostly intended for reviewers and researchers building on the work. Create an "implementation details" section to which you move all the specific choices you've made that most readers don't care about.
Most paragraphs should follow the pattern of 1. summarize the main point, 2. provide details, 3. summarize the implications. For example: "Students took more time for this milestone than we anticipated, requiring us to extend the milestone by one week. In the end-of-semester survey, many students said “More time should be given to this milestone because ... some of the members in the group are still in the learning stage of some frontend/backend framework.”. Furthermore, due to the higher workload of picking and learning a framework, students’ time efforts shifted more towards implementation than design, leaving less time to consider alternatives and evaluate the impact of implementation decisions on the system design [48]. Providing more implementation support, specifically on frameworks that might be useful for the project, might help address this issue." The purpose of this structure is to allow readers to skip the paragraph if the first sentences gives them evidence that they don't actually care about this fact. What makes this a bit counter-intuitive for STEM students, is that it leads to making each paragraph start with the conclusion, then provide the evidence for the claim, which is usually the opposite of how you were taught in in school, but it is optimized for reading speed. If you believe that this structure does not work well (which is often the case for empirical research where results need a lot of context to be understood), you may keep the main claim in the end but put a box around it or bold the sentence.