Writing your thesis and preparing for your viva

Writing your thesis

The first question to ask yourself is "who am I writing for?" Ok, you're writing for yourself and your supervisor, but you and (s)he know the work too well. Think instead of the examiners, and others who will read it now and in the future.

Sticking with the examiner for the moment, you should realise that the examiners want to pass you: you make it simpler for her if she can find all the evidence she needs as easily as possible. In fact, this is just as applicable when you're writing papers in general, and particularly for when you're drafting a research grant application. So, here are some specific points 

• write it as you would say it: that means keep the language straightforward … just because it's written, there's no need to use longer words, or more complicated constructions;
• if in doubt, include it: it's not a problem to read something that you know (within reason) but is is a problem to come across a TLA that you don't understand;
• give a clear statement of contribution of the work: what have you done that goes beyond the state of the art (which you will explain in a "related work" chapter) … also it's worth saying where to find those contributions in the thesis (by giving section cross-references)
• if some of the work has already been published in jointly authored papers, it's very good for you to give a clear statement of your contribution to the papers;
• make it easy to read the thesis by including the right signposting, which means that anyone reading the thesis knows precisely what you do, where; in particular, I'd advise you to include:
• an overview of the whole thing in the introduction
• a summary at the beginning of each chapter, section by section
• and a conclusion at the end summarising the contribution of the chapter

To get another perspective on what to aim for in writing, you can look at the criteria for the CPHC/BCS Distinguished Dissertations competition, which aims to reward the best theses in CS in the UK. This prize looks for

• whether the thesis makes a noteworthy contribution to the subject, and what that contribution is;
• the standard of exposition;
• how well it places its results in the context of computer science as a whole; and
• how easily a computer scientist with significantly different interests would be able to grasp its essentials.

As you're writing there are people who will give you feedback. At Kent someone from your supervision panel will help, as well as your supervisor, it's worth checking early on who from your panel will do this.

A cardinal rule in getting feedback is only ask for feedback on things that are final, albeit final first drafts. There's nothing worse than giving feedback on something and then being told "oh yes, I was going to do that" … it should have been done (preferably) or at least there be some note to the effect that it's still to do. Why do I say this? The first reading is always the most effective … when you read for a second time, it's inevitably going to be shaped by the results of the first read. 

Finally, make sure that you've fixed the problems pointed out first time before you ask someone to read it again!

Preparing for your viva

First, make sure you check when it is, and keep in touch with the internal examiner and supervisor about what they need you to do specifically to prepare for the viva.

Candidates are often (usually?) asked to give a summary of the main contributions of the thesis at the start of the viva: this could be a 10 minute oral presentation (no slides) or (sometimes) with slides …  either way, it's worth be prepared, and check with your supervisor about this.

Read the thesis again in the days before the viva, so that you're familiar with what is where … it will probably be a few months since you submitted it, and so it will have gone out of your mind. While you're reading thorough, it makes sense to keep track of typos that you find, so that you can fix them in the final version. You can go armed with errata lists, either personal or to share with the examiners, that you compile while reading it.

Will your supervisor be present? The Kent rules are they are only there with your explicit permission, and this is entirely up to you. At other universities the rules might be different, and other people might be there – this might be an independent chair of the proceedings, for example – or the viva might be recorded. It may be that you would like to invite your supervisor to be present after the viva is over,  if there are corrections to be discussed once the decision has been made.

Another way of preparing is to give a seminar to your research group: that will help you think about what your contribution is, and also how the parts of the thesis fit together, something that may well be a question in the viva itself. I've heard of people having a mock viva, but I'm not sure that's such a good idea … each viva will be different, and preparing by reading and giving a seminar should be enough.

Wear something comfortable … and take some water with you.

Probably you'll have access to a whiteboard, but just in case not it's useful to take along some paper if you want to draw diagrams or otherwise explain things visually or symbolically. 

Once the viva gets going,

• think before you answer … it's no problem to consider what you want to say before you say it;
• if you don't understand a question, ask for clarification … if it's not clear to you then it may well not be clear to the other examiner either, and
• if things seem to get stuck into a discussion of a particular point, politely ask to move on. 

Finally, some common questions that get asked,

• as I said earlier, examiners often begin by asking you to give a summary of the contribution that your work makers,
• and this might be followed by going into some more depth about how the bits of the thesis fit together  – it is supposed to be a "body of work" and it's worthwhile thinking about how you would explain that in your case;
• other questions might ask about your knowledge of work by others in this field,
• or get you to talk in detail about "your argument on p34" or "your proof on p31" … it's not all high-level and context, but will engage with the details of what you have written, and how you justify it.

So, good luck with the writing and the viva itself!

The ideal graduate

The School of Computing has a stakeholder panel, made up of representatives from companies and other organisations that we work with. Its job is to give the school strategic advice on its teaching, research, enterprise and public-facing activities in general. In a recent meeting we discussed what it is that panel members look for in the interns, placement year students and graduates that they recruit.

One of the distinguishing features of computer science at Kent is that about eighty percent of students - over 100 this year - take a year's industrial placement between their second and final years. It's therefore not a hollow promise to say that their degree overall is a single package, delivered jointly by the school and its industrial partners. We teach what it makes sense to learn in the classroom, while our partners are able to give students the experience that can only come from working on real projects for real customers.

So, what is it that this selection of our graduate employers look for?

• First, it goes without saying that strong technical skills are required: in particular, our students need to be able to program. Not all CS graduates are competent programmers (!) - and many employers will test applicants' programming competence. Theory and maths were discussed too. But what other attributes do they need?
• Curiosity and the drive to learn. It's clear that all our graduates will be working in a quickly changing environment, and so will have to keep up with new technologies and applications. When presented with a situation, the best graduates will ask "why?", and try to find out the answer. They will likely have an agenda of what it is they want to learn, and what skills they want to develop. As a school, we therefore need to make sure that we help our students to be independent learners, both individually and together in groups.
• Approach. It's not enough to roll up your sleeves and start coding … nor is a system finished when it compiles without errors and passes a handful of tests. Those who are able to plan their work using pencil and paper before getting into the details of the work are likely to perform much better. Similarly, systems need to be unit tested, but also whole applications need to be exposed to potential users, and tested to destruction. This leads on to …
• Empathy. Testing is just one aspect of this. There are end users who'll need to interact with what a developer does, and having some sense of their needs, and how they will use the system: listening skills, and understanding the context of work - what does drive this: money? user engagement? - isn't an optional extra. Others may well work with challenging groups, for example clients of social care, with a particular approach and needs. 
• The flip-side of this is being able to tell a story, or have a "value proposition". We can all suffer from this - I certainly have colleagues who can write research applications that are all about a great solution, but the problem is it's not clear what problem it is solving, if anything. So, begin able to appreciate context, and explain an idea from a different point of view, is key.
• More traditionally, I guess, are project skills: team working, appreciating the lifecycle - there's testing again, agile processes (our students, and students in general, seem to cling to waterfall models), and general infrastructure skills. A nice angle on testing was "what will be the impact of this software on the system when I integrate it, in terms of functionality, performance and scalability?" - it's not just a matter of meeting those few unit tests.
• Many employers saw students come in wanting to be developers, while an employer will be looking for wider ambition, ultimately. Employers are also looking for diversity in their recruits, not just in terms of gender, but all dimensions of difference.

Looking at this list it's easy to see that some of these are skills which students will acquire through their placement year, or in the Kent IT Consultancy, but there's a clear challenge there for academic departments in how they develop students as independent learners, curious about the world in general and tech in particular. Experiencing failure - in a "safe" environment - would also really help, and immersion in a topic can really help: a one week intensive MSc project some years ago was one of the most positive teaching experiences I have had … that also reminds me of teaching Open University summer schools - a year's worth of university experience in a week!

Monadic Functional Reactive Programming

Reactive programming - programs that interact with the "outside world" - present a problem to the pure functional programmer: how to program in the traditional style in the absence of updateable state? But problems can also be opportunities, and in this case the opportunity is to rethink the problem from a different perspective. The result that ensues is "functional reactive programming", often abbreviated to FRP, originated by Conal Elliott and Paul Hudak.

The essence of FRP is to think declaratively, or in other words to think about how to make a mathematical model of the problem domain. The key insight is then to see that the functional world offers just the right set of abstractions to do this. A continuously varying quantity - such as the position of an object in an animation (or indeed in a robot world) - a given by a function from time to coordinates. Continuous quantities can trigger discrete events, for example when a position exceeds a certain value, and conversely events can trigger changes in continuous quantities - such as the rebound of a (simulated) billiard ball from a (simulated) cushion. So, FRP gives very general - and declarative - models of hybrid systems.

So far, so good. We have a very powerful model of a very general set of systems, but how is this to be implemented? We are in a functional language, so we can describe a naive implementation, but sadly that is desperately inefficient, and so the history of the last decade or so has been one of searching for sufficiently efficient implementations gained without losing too much of the original power and elegance of the framework. One approach is to make everything discrete, which is the approach of the Lustre language, but aiming to keep as close to true continuity as possible, at least as an abstraction, has proved to be more of a challenge. Elliott has provided a number of implementation ideas, as has Nilsson; the paper here provides a new approach in which a monadic interface is designed for FRP. 

Under the monadic approach, continuous behaviours are allowed to terminate (and also to begin) and so there is a natural sequencing operation between them. As well as giving a more familiar API to the programmer, the author claims that this allows a clean - i.e. declarative - yet efficient implementation of the system. While it is too early to give a definitive judgement on this - we should wait to see what the take-up is - it may be that finally FRP has come into its own with this work. If so, we can look forward to a whole set of new libraries for high-level reactive programming in interface design, graphics, web programming and more. Watch this space …

This review of Monadic Functional Reactive Programming, from the 2013 Haskell Symposium, was drafted for Computing Reviews, but too long for their liking. So, I have posted it here instead :-(