Writing Conventions for Computer Science
The conference is the venue of record, not the journal
Top computer science conferences are peer-reviewed with acceptance decisions that count for careers, and journals often come second. This shapes the writing: a fixed deadline, a fixed page count, and a paper that must be self-contained because there is no revise-and-resubmit in most cycles.
Related work positions your paper, it does not survey the field
The section exists to say what the nearest three or four systems do and precisely where yours differs. Every paragraph should end in a contrast; a neutral summary of prior work leaves a reviewer wondering what is new.
Double-blind review changes how you cite yourself
Under anonymous submission you cite your own earlier work in the third person — “Prior work [7] introduced…” — never “our previous system [7].” Anonymizing repository links and institution names in the artifact is part of the same obligation.
Tense splits between the system and the experiments
A system is described in the present tense because it exists — “the scheduler batches requests.” The evaluation is past tense because you ran it — “we measured throughput across five workloads.” Mixing them makes it unclear what is a design claim and what is a measurement.
Claims about performance need the setup that reproduces them
Hardware, dataset versions, hyperparameters, and the number of runs with variance belong in the evaluation, not in a footnote. Artifact evaluation tracks at many venues will check that a reader can rebuild what you describe.
Algorithms and complexity get formal treatment
Pseudocode appears in a numbered float with a caption, and complexity claims are stated in standard asymptotic notation with the assumptions they rest on. If a bound holds only in the average case, the sentence has to say so.
