Seminar Papers

Each seminar includes writing a paper of your topic.

Process

You can start working on your paper before or after your presentation. The timing is up to you. The closer the preparation is to the presentation, the more present the content will be to you.
Please, do not send in your submissions to individual team members (either moodle or db-lehre@cs.uni-tuebingen.de)
Submission deadlines:
winter term summer term
first version middle of February middle of August
review beginning of March end of August
final version middle of March middle of September
Please include paper, slides, and code (if applicable; preferably a GitHub link/invitation) in your final submission (unless moodle is used).

	winter term	summer term
first version	middle of February	middle of August
review	beginning of March	end of August
final version	middle of March	middle of September

Form

The paper of your programming topic must be written with LaTeX or Typst. For this purpose, the two-column SIGCONF Proceedings template must be used. These are the templates in LaTex and Typst.
For figures, we recommend TikZ in LaTex, and fletcher and CeTZ in Typst.
The paper should be 4-5 pages (bachelor) / 5-6 pages (master) in total and written in English.
For linguistic correctness in English, we recommend using Grammarly, DeepL, or similar tools (not ChatGPT).
You may borrow literature to improve your writing at our chair. Zobel, Justin: Writing for Computer Science

Content

[for our programming seminars:] Your paper should include some form of discussion where you critically review your work in terms of
- performance analysis (O-notation). Please, do not include measurements on how long the programm ran on your personal laptop. These numbers don’t tell us anything.
- scalability. Does run time increase significantly when choosing larger inputs? When are space limitations met (e.g. stack overflow)?
- programming language. In hindsight, was the programming language appropriate for the problem? Which language properties were especially useful/difficult?
- your implementation. Are there aspects of the implementation you would do differently next time?

Evaluation Criteria

The following evaluation criteria will be applied to the papers:

Form (typesetting, illustrations, formatting)
Language (grammar, comprehensibility)
Presentation of the own solution (intelligibility, correctness, comprehensibility, critical view)

As a rule, the paper makes up 50% of the final grade.

Examples of past, (very) good seminar papers

Befunge-93 in SQL (Tim Fischer) [SQL is a Programming Language]
Distance-Vector Routing With SQL (Alexej Onken) [SQL is a Programming Language]

Common pitfalls

we often find student papers to …	please, instead …
❌ be incomplete in terms of content	✅ abstract, introduction, discussion (critical view) and conclusion are also inherent parts of a paper.
❌ have frequent orthographic and grammatical errors	✅ use Grammarly, DeepL or similar tools.
❌ have punctuation errors	✅ use commas, hyphens, dashes, semicolons, and colons correctly (different from German).
❌ use passive voice extensively	✅ use active voice as often as possible: “I/we analyse/implement/investigate” is perfectly fine.
❌ use complicated sentences that (are supposed to) sound intelligent	✅ KISS is as important for writing as for programming.
❌ have a wall of text or one sentence paragraphs/sections	✅ choose appropriate paragraph lengths.
❌ show off the author’s intellect by using phrases like “obviously”, “very easy”, “as we all know”	✅ stay objective. At best, something is “well-known” or “straightforward”.
❌ misuse ie, i. e., “… mammals e.g. elephants, …”	✅ know your latin and use appropriate punctuation.
❌ use numbers incorrectly: “there are 3 different …”	✅ spell out numbers 1-10. When to spell out numbers.
❌ use several synonyms to vary expressions and avoid repitition	✅ stick to one word/phrase for a concept, no need to confuse the reader.
❌ lessen the strength of your statements by using filling words etc.	✅ be clear (even if it feels bold).
❌ contain errors like “in figure 3…”, “in the upcoming Section…”	✅ capitaize if a figure, table, section,… is referenced by number. If not, don’t.

Additionally,

listings: Provide a caption (below), reference it in the text, provide line numbering, use syntax highlighting and a typewriter-style font.
figures: Provide a caption (below), reference it in the text, pay attention to similar spacing above and below the figure.
tables: Provide a caption (above!), reference it in the text, use booktabs style.