When I sat down to
write this post, I had an opening line in mind that was going to
bemoan me being a bit remiss with my blogging of late. That was
before I checked my last post and realised it had been ten months,
and 'remiss' feels a bit inadequate: I basically stopped.
I had a pretty
good reason, in that I needed to finish my PhD. Those ten months have
basically been filled with write paper, submit paper, thesis thesis
thesis, do a talk, thesis thesis thesis, get paper rejections,
rewrite, resubmit, thesis thesis thesis … then finally viva (and a
couple of more paper submissions). It is exhausting, and frankly
having either a thesis or a paper to be writing at any one given time
takes the shine off blogging somewhat.
Now that it's done
and out of the way (no corrections, wahey!), I begin to turn my mind
to getting the blog up and running again. What have I been up to
lately that I could write about, I asked myself. Well, there's always
this big blue beast.
Having been the
major task of the last year of my life, I've spent more than a little
time thinking about the process
of thesis writing, so I thought I'd share some pointers and thoughts,
maybe being the usual and the obvious.
1) Everything
takes longer than expected.
This
is the best advice I got going in, and is always the first thing I
say to anyone who asks. In a perfect example of Hofstader's
Law, no matter how much time you think a given task should
take, in reality it will take longer.
2) Be consistent.
The longer a given document is, the more chance there is that
inconsistencies will creep in. Theses are long documents that are
invariably only read by accomplished academics (or those in
training), many of whom have a keen eye for finding such
consistencies. 'n=5' on one line and 'n = 4' on another. 'Fig1:
Blah', 'Figure 2 – Blah blah' and 'Fig. 3 Even more blah'. These
might not seem like big deals, but added up they can make the
document feel less professional. Choice of spelling (e.g. UK or US
English), where you put your spaces, how you refer to and describe
your figures and references, all of these types of things: it doesn't
matter so much how you choose to do them, as long as you do them the
same each time.
On a related note, many technical notations – such as writing gene,
protein or chemical names – are covered by exhaustive
committee-approved nomenclatures. Use them, or justify why you're not
using them, but again, be consistent.
3)
Make it easy for yourself: get
into good habits.
Writing
long documents is difficult, so don't make it hard on yourself. Start
as you mean to go on, and go on like that – I made a rather foolish
decision to change how I formatted my figures one chapter in to my
writing, and going back to re-format the old stuff was time I could
have been spent writing*. Doing something right the first time is
much more efficient than re-doing it two or three times.
Make
sure you make full use of reference manager software. This will sound
obvious to people that use them, but I am consistently surprised by
the number of PhD students I meet who write their bibliographies and
citations manually. I personally use Mendeley,
which operates perfectly well and has a nice reading interface as
well, although there are plenty of others. You are probably going to
have a lot (hundreds) of references, and even more citations: doing
them manually is a recipe for disaster.
Similarly,
don't do any manual cross-referencing if you can avoid it – the
document as you write it will likely be entirely fluid and subject to
change for months,
so any 'hard' references you put in could well end up needing to be
changed, which not only takes time but increases the risk of you
missing something and carrying an error along to your finished PhD.
If
you have the time, I would recommend trying to get into LaTeX
(with the 'X' pronounced as a 'K'), which is a free, open-source
code-based type-setting program. It's a bit of a steep learning
curve, but there are plenty of good templates and once you've got a
grasp of the basic commands it's incredibly powerful. Crucially, as
your file is just a text document (which effectively just 'links' to
pictures when you compile your PDF) it remains small in size, and
therefore easy to load, backup and play with. It also makes
referencing, cross-referencing, and generally producing beautiful
looking text a lot easier then most word processors.
Theses
are often full of technical words and abbreviations, and it's
entirely likely your examiners won't know them all beforehand –
therefore they need to be defined the first time they're used.
However, if you're moving chunks of text around (sometimes whole
chapters), how do you know which one is the first time? My tactic was
to not define anything
while writing, but whenever I did use a new phrase I added it to a
spreadsheet, along with its definition. Then once everything was set
in place I worked through that spreadsheet and used 'find' to add the
appropriate definition to the first instance of every term. What's
more, that spreadsheet was then easily alphabetised and converted
straight into a convenient glossary!
4)
Be
prepared to get sick of it ...
You will spend an
unhealthy amount of time doing one thing: working on this one
document. It will bore you, and it will make you boring, as it will
take over your time, thoughts and life**. It is basically guaranteed
that you will bone-weary of sitting down to your computer and working
on it again. It's relentless,
it just keeps going on and on and on, to the point where you forget
that your life hasn't and will not always just be thesis-writing.
5) ... but remember it will end.
It might not seem like it at the time, but it will. You will finish
writing, you will finish checking, you will hand it in. You'll then
find some errors, but that's OK, your examiners are never going to
read it as closely as you do when you check it. Remember that your
supervisor(s)/thesis committees/whoever shouldn't let you submit
unless they think you're ready, so the fact you're submitting means
you're probably going to be fine!
*
For
what it's worth, the final way I did my figures was better, I should
just have thought about it and done it first.
Basically I outputted my plots from Python and R as SVG files and
compiled them into whole figures in Inkscape
(which is also great for making schematics)
and saving these as PDFs. A word of warning thought – certain
lines/boxes in occasional Python-saved SVGs failed
to print (apparently something to do with the way fancy printers
flatten the layers), so it is probably worth keeping backup EPS or
non-vector versions of your Inkscape files on hand.
** Look at me, I've just
closed my file for the last time (before uploading to university
servers) and the first thing I do is go and write a thousand words
about it!
No comments:
Post a Comment