Browse Brian’s Bookshelf

Fictitious yet somehow entirely plausible quotes from imaginary former students:

He taught me an engaging writing style. Paige Turner He gave me plenty of momentum throughout my project. Stan Still He helped us overcome obstacles and produce a project that opened doors. Barb Dwyer & Dawn Hobbs As an NLP expert, he knows a lot about trees. Tim Burr He does have a sense of humour but he wasn't kidding about the emails. Jo King

You as my project student:
You need to enjoy reading emails and feel comfortable writing regular replies with honest updates including problems and mistakes. I expect you to use plain text for information, version control for everything, and LaTeX on Overleaf for your report (shared with me). Text file manipulation skills, especially from the command-line, are always handy. You need to (learn to) use appropriate tools properly especially an editor or IDE. You must also look constantly for improvements, expansions, and increased usability.

Early on you need a reasonable idea how you will define and evaluate ‘success’ in your project. Ideally you should use an end-to-end approach instead of top-down or bottom-up. You need contingencies for when things go better (or worse) than expected and you find yourself expanding (or shrinking) your goals.

When initiating contact, please include information on how much (or little) the project fits your existing skills, experience, and knowledge. There’s no need to be shy about gaps in your knowledge or be embarrassed about any courses you’ve struggled with: this is all about learning and improving. It’s less about how good you are now and more about how much better you can be. Please tell me what you expect to learn and improve from undertaking your project including any transferrable skills.

To demonstrate you have read these instructions, click the fifth word in this paragraph to reveal a code to include in your communications with me otherwise I might consider you unsuitable for my projects.

Other Advice

Two of the costliest mistakes students make with projects are spending (far) too much time writing code yet (far) too little time writing the report. You should assume that only the parts of your practical work described clearly in your report will gain marks.

A typical major mistake with the report is not telling us what you have done — it is hard for examiners to give marks to something they don’t know you’ve done. Another mistake is telling us what you have done but not what you have learnt. It doesn’t matter that parts of your project did not work: what really matters is showing what you’ve learnt from those problems.¹ Mistakes make the best teachers.

¹ Note that I am ‘allergic’ to the term ‘issue(s)’ in this context so please call a problem ‘a problem.’

As a minimum, I expect my project students to do or attempt the following:

1. The use of engineering requirements
2. Finding and following excellent guidelines for designing interfaces, like these
3. Suitable contrast in any GUI for users with low-vision
4. Any interface to be suitable for users with colour vision deficiency (colour blindness)
5. The carbon footprint of your end product
6. Test for statistically significant results where appropriate
7. Build using an end-to-end approach (tip 68) and make a minimal working example (MWE) as soon as possible
8. Design one or more overview diagrams of the project as soon as possible
9. Conduct a usability study (if appropriate)

I urge you to write the user guide before you code your interface; then code the interface to match the instructions. This greatly increases the usability of the final software.

Another trap is trying to solve every problem you encounter, so stick to the project’s main aims. While you will meet problems head-on and defeat them, be prepared to circumvent or simplify some problems. You might even need to adjust the project’s goals.

Do your best to have lots of small goals with short deadlines. Build a contingency of about two weeks into your timetable to allow for unexpected yet entirely predictable problems: distractions, anxiety, tiredness, and illness. Never forget: ‘simple’ software simply never is, tools rarely integrate smoothly, and there’s always one more bug.

Turn your presentations into PDFs so you can be more confident that they will display as you intend on another computer. Use more graphics and less text in your slides. Read and follow advice from Edward Tufte, Robert Bringhurst, and Michael Alley.

Choose professionally designed fonts that were intended for the exact purpose you want. Check professionally written reviews of fonts by other font designers. If you don’t believe that is important then read the short story by Mark Twain How I Edited an Agricultural Paper Once — it will help if you have a very basic knowledge of agriculture and farming.

Learn about colour theory to enhance your designs. Use websites, like those by paint manufacturers, to help create colour-matched designs. Check your results on WebAIM and colour-blindness simulators.

Ensure you make multiple regular backups and keep them physically separate in case of flood, fire, or theft. Be careful about putting your work on public-facing websites: assume cloud storage is public.

If you are intending to use your own computer for a computationally intensive project or running a virtual machine, it’s worth replacing the thermal paste on the CPU and GPU. I have had 3 previous project students whose own laptops were damaged or destroyed by overheating running experiments that took days or even weeks to complete. Try free software to monitor computer temperatures. If the temperatures don’t drop rapidly when the computer is idle, you probably need new thermal paste.