How to write a scientific thesis

Things I learnt when tutoring students during my time as a research assistent.

Written Thesis

• Don't write a research diary. That is: "Then I used Eclipse to generate code for A, but this did not work with plugin X, so I had to use a manual method.". Even though this might have been very important to your implementation at the time, nobody wants to read this in your thesis. The thesis is about results. It is not a diary.
• Present your findings in a manner that is easy to understand. Think about the readers of your thesis. Especially keep in mind that they do not have any previous knowledge in your project. Therefore, present things in a logical order, even if this is not the order in which you created your code or had your ideas (creative processes usually take weird paths).
• Care about your references. A thesis is a scientific work, this implies that your references should not just be URLs pointing to Howtos and product manuals. Use established search engines like CiteSeer and Google Scholar to find publications that are relevant to you. Cite these in the appropriate places in the text and put them properly formatted in the bibliography at the end of your thesis. Properly formatted means that each entry has the same format and is also detailed enough to actually find the publication! If there is a paper version available, cite that, URLs change far too quickly.
• Don't print all your code. Nobody is going to read ten pages of source code, let alone type them into an IDE to run the code. If you absolutely must, print small excepts (approximatly half a page) and include the whole code on a CD. Consider using pseudo code to explain your algorithms. Pseudo code is more compact, because it can do less important operations in one line (such as listOfBook = fetchAllRelevantBooksFromDB;).
• Start early. If writing is not exactly your favourite occupation, start on the text of your thesis early, not just one month before you submit. This way you always have different things to do and don't have to write text all day.
• Respect interlectual property. If you take a bit of text verbatim from another source (including web pages) put it in quotes and name the source. This rationale also applies to graphics: If you copy them, obtain permission from the author to do so and give proper reference. You don't want others to pass off your work as theirs either!

Final Presentation

• Run your program stand-alone when you present your results. Don't use your IDE to launch the demo, unless, of course, you wrote a plugin for that IDE. Would you really want to ship your "product" with a 100 MB application launcher? Also, if a program can be started from the command line properly, other people are more likely to be able to use it.
• Make sure you slides work on the presentation computer. Come a bit earlier for your final presentation and have a look at all your slides. Check that the fonts are there, that you don't have any unwanted line-breaks, that the graphics scale as expected, etc.
• Look at people, point at slides. During your presentation, look at your audience, not at your computer. It also seems like a good idea to point things out on the projection area, as the audience can see this. Nobody knows what you are talking about if you point to somewhere on your computer's screen and say "this".
• Try your code. This is really basic, but many people forget to also check on the presentation machine. Usually, if you don't require your IDE to run, migrating to the prestation machine is much easier.