How to Write a Conference Paper | Computer Science PhD Student Advice

Conference-paper writing becomes far less mysterious when it’s treated as a repeatable workflow: form a problem, iterate toward a workable solution, validate it with evidence, then draft the paper starting from the sections that are already “done” in your research. The process matters because it prevents the common failure mode—spending weeks staring at an introduction while the core results and methodology are still unstable.

The workflow starts with an idea strong enough to drive a project. That idea often comes from existing topic and subtopic areas, or from questions that surface during readings. From there, the work splits into three phases: solution forming, actually building the solution, and writing everything up. In the solution-forming phase, problem solving follows a four-step creative cycle. First comes preparation: gather background knowledge, take notes, sketch angles on the problem, and run a literature review to understand what’s already been tried and what remains unsolved. Second is incubation: step away—walks, breaks, even a few days—so the subconscious can keep working. Third is illumination, the “aha” moment when a promising approach becomes clear. Fourth is verification, where the proposed solution is tested and refined through multiple cycles until it holds up.

Once a solution direction is credible, the project moves into implementation. In computer science, that often means trying multiple models at different points, checking whether they improve accuracy, and cycling back when they don’t. The process doesn’t end at “a model works once.” It ends when the solution is stable enough to stop iterating and when the necessary data for evaluation has been collected. Regular check-ins with a supervisor are positioned as a practical accelerator: after each candidate solution, results are shared, next steps are proposed, and feedback helps avoid dead ends. This collaboration is framed as a habit—keeping both people aligned throughout the project rather than only at the end.

Evaluation then turns research outputs into proof. The goal is to gather the graphs and evidence needed to show the solution works across multiple conditions and is robust, not just effective in a single test. After that, drafting begins with the easiest sections. Methodology is typically the first target because the work has already been done, making the write-up straightforward. Next comes results/evaluation (or analysis), since the graphs exist and the task becomes explaining what they show. The related work section should already be largely prepared from the early literature-review stage.

With those core sections in place, attention shifts to the harder parts: discussion and introduction. The advice is to write discussion before introduction when possible, or to fold discussion into evaluation if the format doesn’t include a separate section. The introduction is described as hardest because it requires knowing what the finished work actually produced, so it’s often easier to write at the end. Finally come the abstract and conclusion, which can be drafted together to keep the summary consistent. The paper’s structure should match the target conference’s norms, and templates—often in LaTeX—can reduce formatting friction. Keeping the supervisor involved during drafting, including sharing the LaTeX document for oversight, is treated as part of the same iterative discipline that drove the research.