The Making of a Masters

So it’s been a while since my last blog post. It’s not unheard of for technical blogs to go on hiatus, but I hope to be much more committed to mine this year. The reason for my absence has been my return to tertiary study, as I have alluded to in previous blog posts.

Anyone who’s completed a postgraduate degree will be well aware of the time pressure that builds over the course of the degree. I made the situation harder for myself by taking on extensive Teaching Assistant work writing and marking several assignments for a second year C++ course. This pushed out the date that I started in earnest on my thesis, and contributed to time pressure towards the end of my degree. If I were to do further postgraduate study I would certainly not want to miss out on this opportunity to teach the next generation of budding Computer Systems Engineers. However, I would definitely reduce my teaching workload.

So how hectic was the last part of my degree?

This comic from PhD Comics shows a significant acceleration in writing towards the end of research isn’t uncommon among research students. This seems to be a fact of postgraduate life. So how did I do comparatively?

Luckily I wrote my thesis in LaTeX, and used git to track changes over time. This gives me a fairly precise history to work with, and an easy way to track the number of words:

wc -w *.tex

This counts the number of words in all .tex files in my thesis folder. Technically this will include captions, appendices, and some other non-body content, but I’m more interested in the overall trend than the particular counts. The next step is combining this with some git scripting to generate information about how the word count changed over time. This script isn’t particularly well optimized, but it doesn’t need to be with my thesis repository history being less than 100 commits in total.

# generate a list of revisions
revs=$(git rev-list --reverse master)

# generate stats for each commit
echo "$revs" | while read rev; do
    git checkout $rev
    dt=$(git show -s --format=%ci)
    words=$(wc -w *.tex | grep total | cut -d' ' -f2)
    # handle case where there's no leading space in the count
    if [ "$words" == "total" ]; then
        words=$(wc -w *.tex | grep total | cut -d' ' -f1)
    fi
    echo "$rev,$dt,$words" >> stats.csv
done

I can also draw on one of the most valuable skills I’ve practised over the last year to produce a visualisation of this data; data processing with Python + Jupyter (formerly IPython) and a host of python scientific computing libraries (numpy, scipy, pandas). These tools were invaluable for completing my research, so it’s fitting that I can repurpose them to shed a little light on the thesis writing process.

The results show that my thesis-writing experience strongly correlates with those of others. Despite the fact that if I were to do this all again I would have started on my thesis in earnest much earlier, I have a feeling that anyone else writing one for the first time would have had a similar experience. I think firmer guidance on this point from my supervisor could have helped me get started in earnest a little earlier, but it wouldn’t have changed the circumstances that led to me starting as late as I did.

A big part of this late rush to completion is that often when conducting research it takes time for all of the information to come together and form a clear picture. It takes time to identify and build out the core ideas of the research. It takes time to pour over the work of others and absorb their ideas and conclusions.

Aside from all the writing, and all the Python data processing, I did also get to use some C and C++ code when building out the data logging and processing systems for my project, but these were relatively minor parts of the whole experience. I made good use of a few new boost libraries, including boost::lockfree and boost::asio.

One area in which I’ve experienced a huge amount of technical growth in the last year has been working with hardware. I’ve vastly improved my soldering skills, particularly with SMD components. I’ve re-learned much of what I learned in my undergrad about PCB design and fabrication, and extended that to include SMD design and learnt how to use techniques like via stitching and differential routing with Altium. I also experimented with the open source KiCad EDA software. My knowledge of the dynamics of both analog and digital systems has vastly expanded beyond what I was taught in my undergrad. The last year has given me new confidence when it comes to dealing with hardware.

From what I’ve observed, there no room in a one-year Masters program for building out significant software projects in C or C++ from scratch. The research environment doesn’t incentivise building out production-ready software, it emphasises demonstrations and proofs: creating production-ready software is the role of industry. Or at least this seems to be what I’ve taken away from my time in the academic environment.

Studying at a postgraduate level has been one of the most challenging things I’ve ever done. It’s extended my capabilities, capacity and perspective. I’m immensely grateful to have had the experience, and one day I may return to further my education. For now I have other priorities and pressures that have led me away from this path. I look forward to what the future brings, and move forward with a greater appreciation of the roles of both industry and academia in computer