Writing Advice

This page is a practical guide for students writing empirical software engineering papers, theses, and dissertations. It is intentionally link-heavy: the goal is to help you find strong resources for each section of a paper and avoid preventable reviewer frustration.

I use this page as a compact writing companion. The advice below is not a universal formula, but it reflects the patterns I recommend most often in supervision and reviewing.

Table of Contents


Research & Discovery

My tip: If you discover papers only at the end, your writing will sound late and defensive.

Good writing starts before writing. Use discovery tools early to understand clusters, competing schools of thought, and which papers are central enough that reviewers will expect you to know them.

  • Connected Papers for visualizing citation neighborhoods and research clusters.
  • ResearchRabbit for AI-assisted discovery of related work and forward/backward citation exploration.
  • Google Scholar for checking who cites a paper, how terminology varies, and whether your framing is still current.
Back to Top

Abstract

My tip: The abstract is a trailer, not a summary. Show why the study matters before you drown the reader in detail.

The abstract is the first quality filter for most readers and reviewers. In empirical software engineering, structured abstracts are often the safest option because they force clarity on motivation, method, results, and implications.

Broken-link audit note: the old Durham PDF now redirects to the EBSE site root, so I replaced it with the live Structured Abstracts page.

Back to Top

Introduction

My tip: A strong introduction narrows the reader's world step by step until your research question feels inevitable.

A good introduction helps the reader understand what is known, what is missing, and why your study is worth reading now. The CARS model is still one of the most useful scaffolds for this.

Broken-link audit note: the old Aalto URL is no longer stable, so I replaced it with the current AWELU/Lund guide that covers the same introduction logic.

Back to Top


Research Design

My tip: Reviewers forgive limits more easily than vagueness. Be explicit about what you did, why you did it, and why the design fits the question.

The research design section explains how the study was structured and why the chosen method is appropriate. In software engineering, it helps enormously to align the study with method-specific guidance and community reporting expectations.

Back to Top

Threats to Validity

My tip: Threats to validity are not an apology section. They are where you show intellectual honesty and methodological maturity.

For empirical software engineering papers, this is a high-priority area. Good validity discussion explains which risks mattered, how they were handled, and what uncertainty remains.

Back to Top

Results

My tip: The results section should answer the research questions, not merely replay the analysis pipeline.

The results section depends strongly on method, but in all cases it should stay disciplined: present findings clearly, separate interpretation from reporting when possible, and tie results back to your research questions.

Back to Top

Discussion

My tip: The discussion should explain why the results matter, not just say that they are interesting.

This is where you connect results to prior work, implications, and interpretation. Good discussion is analytical rather than repetitive.

Back to Top

Conclusions

My tip: Conclusions should leave the reader with a clean answer to “So what?” and “What now?”

Conclusions are often too vague or too repetitive. A good conclusion should state what was learned, why it matters, what remains uncertain, and what should happen next.

Back to Top

Examples

My tip: If your example needs a long apology before the reader understands it, it is not yet a good example.

Examples are important throughout scientific texts, but they are often neglected or overcomplicated. Small, precise examples usually teach better than ambitious ones.

Back to Top

Templates & Tools

My tip: Good tooling does not write the paper for you, but it removes friction that otherwise steals time from thinking.

Use templates and reference tools early. They save formatting effort and reduce last-minute mistakes.

Back to Top

AI Ethics & Integrity

My tip: If you use an LLM, treat it like an unreliable assistant, not like an author and definitely not like a source.

Generative AI can help with brainstorming, outlining, and language cleanup, but it can also introduce fabricated claims, broken references, and policy violations. Students should always check venue and publisher policies before submission.

My recommendation: disclose meaningful AI use when required, never invent citations, never let generated text bypass verification, and never assume that fluent text is accurate text.

Back to Top

Other Resources

My tip: Keep a small personal toolkit of resources you actually return to. A useful shortlist beats a huge forgotten bookmark folder.
Back to Top

Books

My tip: Read writing books with a pen in hand. If you do not translate advice into your own sentences, it stays theoretical.

These are some of the books and resources that helped me get better at academic writing.

Stylish Academic Writing by Helen Sword

A comprehensive guide to improving academic writing style without losing rigor.

Learn More

Don't Be Such a Scientist by Randy Olson

A practical guide to scientific storytelling and audience engagement.

Learn More

Videos

Back to Top