Technical Report Writing

While there are a lot of similarities, technical report writing has a number of components that separate it from a typical essay. We’ll try to go through these and highlight some important points that will make sure your report is the best it can be.

Structure

While the idea of a structure is pretty easy to grasp, in a technical report the most important aspect is the flow of the report. Using a quick introduction that contains a summary and a conclusion to bring together any final points is a great way to wrap a technical report, but the bulk of it comes down to the meaty middle. It’s important that when writing the report, there’s a logical flow from one idea to the next throughout the report.

For example, using the dot points given in the Codeworld assignment page we can put together a narrative that goes through the major points of your process in completing the assignment.

Writing down your process

Given that you’ll likely be writing the report towards the end of the assignment, think back to the beginning of the process and write down considerations, objectives and conceptual approach to the assignment; for example, “I broke the assignment down into the following components and considerations before doing any code, which allowed me to better grasp expectations…” etc. Try to answer the question “How did your code evolve?”

Writing about your different versions

While coding, it’s often that you’ll have some realisation about a previous approach. This gives a perfect topic to write about as you can describe initial renditions of your solution, how it’s changed, how you came to the conclusion that it needed to be changed, and how it is better.

Reflection

Your technical report gives you a chance to make up for any shortcomings in your code. You can write about what you didn’t get to do or had difficulty with. However, it’s important to not focus heavily upon any issues you had, but instead to use the report as a chance to discuss some ideas you had but didn’t get to implement, or things that you would do in the future. By showing the marker that you have a strong conceptual understanding of the problem, and an idea of how to go about it in a manner that was better than your code indicated, you can easily boost your marks.

Passive vs Active voice

In a report there’s two ‘voices’ you can use to write in to describe what happened. passive voice describes things that were done without involving a human element. eg. “The vial was picked up with a set of tongs to avoid burns” active voice instead involves the writer or others in what happened. eg. “I picked up the vial with wooden safety tongs to avoid burns” In a technical report it’s common to use passive voice to have a more professional sounding piece. However, in the case where you’re writing about your own experiences, an active voice can be used. This also makes it more concise (remember, you have a word limit!) What’s important in this scenario is to pick either an active or passive voice in your writing, and stick to that choice. Mixing up “I coded this” and “the problem was approached in this manner” (both active and passive voice) will reduce the quality of your writing and interrupt the flow of your report.

General rules of thumb

  • Read ALL the requirements
  • Use diagrams if it conveys information easier! It’s usually more concise than trying to explain everything in words (remember you have a word limit)
  • A report is constantly about asking “WHY?” or “HOW?”. For everything.
    • Why did I choose to code in this way?
    • How did this coding style improve your program? (or how was your previous code a worse version?)
    • Why may some parts of the program be potentially confusing?
    • How are your test results significant?
    • How can the program be improved?