It's been quite a busy few months. After handing in my PhD thesis at the end of June, I did manage to have some time off, but as is always the case, I ended up involved with some new projects and the inevitable job search that followed afterwards.
Some smaller, nice things first. I had one of my pictures exhibited at the Duke of York's Picturehouse during August as I've previously mentioned. Back then, at the time of writing, I hadn't actually seen the finished framed result. I had a custom frame made for me by the nice folks down at Spectrum Photo in Hove, and they did a great job. For a pretty reasonable price I got an archival dibond mount and frame. Here's a particularly rubbish picture of it because it's hard to not have anything reflecting in it when you take the shot.
Then, at the beginning of September, thanks to the invitation from Ollie Glass, I installed a modified version of my PixelWorms simulation at the after-party of Update 2011, which was hosted in Brighton Museum at night (which was very cool). Rather than the simulation being based on the weather as before, I made it into a hands-off game where visitors could pop their name in via a website, and then the worms would roam, breed and fight on the display. Judging by the number of people hanging out near it on the night, it seemed to go down pretty well. The log file that PixelWorms generated that night is available here if you fancy having a look through it. There was one brilliant benefit to having made something; the Royal Banquet at Brighton Pavilion on Sunday night, of which I got two complimentary tickets. It was just incredible, and this 360 degree panorama doesn't need too many words.
Shortly after, I got another year older. Rebecca made me an awesome cake.
I'm also happy to say that after a fairly gruelling few months of job interviews, considering commutes (and some were really epic commutes), companies, academia and industry, I chose to take up a position at Brandwatch. Out of all of the places I went, and there were a few, I couldn't find any that gave me the same "this is right" feeling. Plus, I walk to work and it takes me about 15 minutes. And there's pastry Mondays. And Fridays. And 20% personal project time. And private healthcare. And free food and drinks. And there's a bunch of smart folk there. All in all, bon oeufs.
My PhD viva is lined up for the 14th October, so that's the next thing in the pipeline. The Winter issue of ACM XRDS has wrapped up and the Fall issue has just been published. Here's to a good rest of the year, because it All Worked Out Fine In The End.
I've had the luxury of having a bit of spare time to do some fun programming on the side since I submitted my thesis the other week. The last couple of days I was having a play with the Yahoo! weather feeds, which let you get weather information based on a geographic location.
I made a little project called PixelWorms, which is a model of a patch of grass in Brighton, England. It uses the aforementioned weather feed to work in real time with the current weather conditions. The pixel earthworms are more likely to appear and reproduce if it is cloudy, night time, or cool outside. Worms are less likely to appear and reproduce if it is overly cold, dry, or hot. If it's raining outside, then the worms show a lot of activity. If it's night time outside, the visuals are meant to (sort of) look like you're viewing the ground through a pair of night vision goggles.
Thanks to Daniel Shiffman for providing an example of how to use the Yahoo! weather feeds.
I had an idea for a painting today, however it dawned on me that I cannot paint. So, instead, I programmed it. Here's five of an infinite selection of random number distribution visualisations of which I am being pretentious in calling the "Slider" series. Blogger appears to have some size limitations, so I'll post more of these on my actual website soon.
This piece of advice might seem really silly, but it's incredibly important. The primary goal of your PhD is to produce your thesis, and that's a lot of words that need to be written. More importantly, it's a lot of good words that need to be written. So, it's essential that during your research you practice writing as much as possible. I've noticed that the standard of writing in computer science is very varied, and quite often, it's very poor. This is a terrible thing, because you may have some of the best ideas in the world, but if you can't communicate them correctly then nobody is going to bother to read your work. This is a tragedy if you want to continue in academia.
So, how can you improve your writing? The only way is to write, and to keep writing. Writing is very much like programming in that you learn by experience. One can be extremely well-versed in technique and grammar but completely incapable of putting together a sentence that reads well. Style tends to be learned through osmosis, by reading broadly from scientific papers, to fiction, to newspapers and magazines.
The more you write, the better you get, and the easier that subsequent writing becomes. I've met various PhD students who absolutely hate writing. They tend not to publish very much. As a PhD student, you can incorporate writing into your daily routine in a number of ways:
When reading a paper, write a short summary once you've finished.
Keep a diary of your work every day. This can include notes, reminders and other ideas that you had alongside what you were currently doing.
Consistently write a weekly or monthly report of your work. You can use this report in your supervisor meetings too, as a way of tracking your progress and reflecting on how much more you know now compared to before.
One excellent side effect of performing these tasks is that nothing is wasted. Summaries of papers that you write will feed into your literature review chapter. You will have also gotten better at writing abstracts to your own papers by doing this. Your work diary will ensure that your ideas are not forgotten, and most importantly, will always remind you that you are making progress, even when you're having a terrible week. Your weekly reports, assuming that they are detailed, can be reused to show your methodology in your thesis.
Another way of improving your writing and also helping others is by offering to proofread your colleagues' papers and chapters. By doing so, you get to read a writing style that is different to your own. You can then ask some questions as you read. What's good about it? What's bad about it? How would you change it to make it better? What good points can you take away in order to improve your own writing?
As I consumed an ever greater number of scientific papers, I noticed a definite trend in the papers that I liked. That trend was a simple, yet engaging writing style with no jargon. Only use big words and flowery language if you absolutely have to use big words and flowery language. If there's a simple way of saying something, say it in a simple way. Often, the ideas in papers are hard enough to get your head around, so it's useful if the reader doesn't have to fight with the communication medium as well!
One final point about writing, and this may be a very unscientific thing I'm about to say. You have to learn to let go of what you've written. That way, if people criticise your writing you won't take it personally. If your supervisor tells you that you need to completely restructure one of your thesis chapters, you don't want to get upset about having to scratch out large portions and start them again. Your writing is merely a way of communicating with others. The words are not you, and much like you frequently kick around and change your ideas, you need to get comfortable with kicking around and changing your writing to make it better.
Keep writing, keep writing and keep writing. That way you'll always be better than the previous week, and constant weekly improvement will give you a vastly better thesis and larger collection of published papers at the end of the tunnel.
My third piece of advice: set your own deadlines, make sure you meet them, and manage your time.
When you embark upon a PhD, especially if you're doing one earlier rather than later in life, you may feel that the process is extremely open-ended compared to what you've previously encountered. In fact, depending on how demanding your supervisor is, you may even feel like you're not being told what to do at all. During your undergraduate and masters degrees, and in the workplace, you would have mostly been used to other people telling you when something has to be completed by, whether that involves handing in a piece of coursework or getting something shipped to a customer. The PhD process is very different.
At the most abstract level, the PhD process looks something like this if you're in the UK:
Start PhD.
Some amount of time passes between 2-n years.
Hand in thesis.
Some informal discussion with people who have succeeded say that the process goes something like this instead (in an ideal world):
Start PhD.
Spend time reviewing the literature in your area of interest to see what has been done, and more importantly, what hasn't been done. Produce literature review chapter. (1 year)
Decide on what your project will be, start planning out ideas, get them verified by supervisor, start initial experiments and data collection. (1 year)
Finish experimenting, coding or theorising and start getting some results together. (1 year)
Write up the thesis. (1 year)
Hand in thesis.
My experience was a little different to this. Firstly, my literature review period took a lot less than 1 year, but this was mostly because I joined a project where there was a very clear portion of work to be done, so I didn't spend ages finding a niche in the market. Also, I wrote everything up as I went along (more on that in a later post) so that final "write up thesis" stage was more like "copy and paste a whole load of things together".
Still, deadlines 1 year apart are not that easy to get motivated about. You need to set yourself deadlines that are short-term enough so that you get fired up to meet them, but also have just enough work so that 1) you don't get bored and 2) you don't burn out quickly. It's a marathon rather than a sprint, after all. I found it best to work in weekly deadlines that ended the day before I met with my supervisor for our progress meeting. This way I was motivated to have something good to show which I could receive some praise for, and then the feedback from the meeting could drive next week's deadlines.
For example, in your first year when you start out, you might want to set yourself 3-5 papers to read a week, and your goal is to write a 500 word summary of each one, of which you talk through with your supervisor. You could continue this until you start to see where there is a gap in the market in which your own research could be done. This deadline is also nice because it's easy to chunk that work into daily portions as well, such as one paper and 500 word segment a day. If you're in your second year and deep into programming, then it might be worthwhile to dedicate four days a week to coding and debugging, and one day a week for writing up what you've been doing.
The most important thing is making your deadlines matter. I touched upon one way of doing this in the previous post, and that is using your supervisor. At every meeting you have, give your supervisor the list of deadlines that you want to have completed by next time, and ask them to hold you to these. Then, you're letting them down as well as yourself if you don't get them done. I used to print all of mine out once a week and stick them on the wall above my desk. This way everyone else in the lab could see them as well as myself, and it was also very satisfying scribbling things out in red pen when I'd got one of them done. Another great way of making deadlines matter is finding out when the relevant conferences and workshops are in your field, and then planning your work around these, trying your best to get something done and written up for submission. Even if papers get rejected, you'll get great feedback from the research leaders in your area of which you can then incorporate into your own work. I'll talk about this more next time.
Research is irritating in that you often have a lot of different things going on at once: programming to do, bugs to fix, papers to write, papers to read and so on. I experimented with lots of different ways of keeping a todo list, and the one I found the most successful was the one that Randy Pausch talked about, which is from Steven R Covey's 7 Habits of Highly Effective People.
The entire video is long and touches on many other things, but it's well worth watching. If you don't have time to watch it (but you should watch it), then you organise the things you have on your todo list into four sections. This is what Randy talks about at 20:54.
Important things due soon.
Important things not due soon.
Unimportant things due soon.
Unimportant things not due soon.
At a given time, you keep working on 1) the important things due soon. Now, the key point is this: once you've finished with 1), where do you go? A lot of people say that the next thing to work on is the unimportant things due soon. However, that's wrong. Once you've done all of your important things due soon, you do the important things not due soon. Hopefully, all of the unimportant things just get ignored, and just drop off into the bottomless pit where they don't bother you ever again. You buy back time by spending less time doing unimportant things, and more time doing the important things sooner. This works for me really well.
What are you going to achieve this year in your PhD? What do you need to do each quarter to get this done? What does this quarter need done each month? Each week? Each day? Break up your tasks, get them written down in order of importance, tell other people about them, make yourself accountable and then get stuff done. Have fun crossing off the things that aren't important as time goes on. It's a great feeling.
Having a good working relationship with your supervisor is essential to getting your PhD done. I'm hoping that any current students would have chosen their supervisor due to a number of reasons such as liking their work and respecting them as a person. However, getting the most out of this relationship can be difficult if you don't know how to manage them. Yes, manage them.
Here's my second piece of advice: it's your problem.
Out of this list, which do you think are your responsibility, and which do you think are your supervisor's responsibility?
Making sure you are putting in full time or part time hours (depending on your arrangement) for your work.
Arranging weekly meetings to check-in and discuss what you have been doing.
Making sure you have the equipment and materials that you need to do your work.
Keeping up to date on the important research in your area.
Writing posters, workshop papers, conference papers and journal papers.
Going to conferences and networking with other academics.
Setting deadlines and getting things done.
The unfortunate truth is that all of these things are your responsibility. Now, I'm not saying that, for example, if you need a specific piece of equipment in order to do your research that you should go out and buy it yourself, but it is your responsibility to initiate the acquisition of this through your supervisor, or IT support, or likewise. But, the key message is that ultimately, you are responsible for your own fate.
Ideally, a PhD student should not only be pushing themselves in terms of the knowledge they are gaining and the results they are finding, but they should also be pushing their supervisor's understanding also. When this relationship works well, it has has mutual benefits for both parties: publications, knowledge and growth. When it doesn't work well, your supervisor still has a job and plenty of other research projects to focus on, but you'll end up not getting your PhD.
I remember when I was an undergraduate it took me a long time to realise that the first priority of (some of) my lecturers wasn't actually teaching. In fact, they had a wide variety of different priorities which I now understand. In no particular order:
Doing their own research
Teaching and grading
Sitting in on school and departmental meetings
Supervising 3rd year dissertations
Supervising Master's dissertations
Supervising PhD students
Answering email (never underestimate the amount of email some people get)
Writing grant proposals and securing funding
Supervising PhD students ranks more highly than some of the other activities, but as a PhD student, you have to realise that you're not at the top of the stack. This isn't necessarily because you're not worth anything, but it's because you're one of a number of different things that your supervisor is dealing with. However, there are techniques for remaining near the top of the stack.
The trick is to be visible, but not annoying. Some of the things that worked for me are as follows:
Being there in person. I know that a PhD does technically allow you to work wherever and whenever you want, however, from experience, turning up every day to the lab does wonders for your (lack of) social life, and it lets you be around the few people who actually understand what you're going through. The other major plus point is that quick 5 minute questions that may get ignored by email can be answered by your supervisor instantly when you knock on their door.
Regular meetings. At the beginning of your research, speak with your supervisor about how you like to work. Discuss whether it would be best if you should have a short weekly meeting or a long monthly meeting, and whether you'd like to do this orally or by preparing a written report every time of what you've been up to. Different people work in different ways, but it's important to keep touching base, otherwise it's surprising how quickly you can slip away from their mind.
Be honest about your intentions. Talk to your supervisor about why you are doing a PhD. Is it because you want to become an academic, or do you want to do clever work in industry? Depending on your goal, your output could be different, and you should make your supervisor press you for this output. Hard. If you want to become an academic, they should regularly push you to produce posters and workshop papers (earlier on) and conference papers and journal papers (later on). However, it's up to you to find the venues and journals. If you're aiming more towards industry, then you might focus more on producing software tools that could be made open source, making a contribution to the programming community as well as completing your thesis. These may be extensions to existing compilers or simulators, or a brand new tool you can put out there. They should push you to get these done too.
Share your deadlines. You should be setting yourself regular deadlines (more on that soon), but you should give these to your supervisor and make sure they know about them. That way there is someone other than yourself accountable for getting work done. And when you're potentially letting someone else down, the motivation to get things done increases.
The relationship with a supervisor is strange in the sense that they are more like a mirror than a traditional manager. The more you keep your supervisor informed, and the more targets you set yourself, the more supervision that you'll get. You're training yourself to do research. Imagine that your research is a huge boulder than you can't see over. Their job isn't to pull you and your research along. After all, it's research: they don't know the answer. Your supervisor should be standing beside you as you push it, making sure it's going in the right direction.
One week ago, on Thursday 23rd of June, I submitted my PhD thesis. By now, any current PhD students would have thoroughly scoured the Internet in search of comforting advice about the long and hard road to a doctoral degree, so my own advice may not be entirely original. However, I felt that there were a number of things that I had learned. I'll roll them out over a series of posts. This advice is primarily aimed at computer science doctoral students, but it could possibly be applied to other fields as well.
My first piece of advice is this: know your customer.
So, as a doctoral student, who is your customer? Fundamentally, your customer is your supervisor and thesis committee for the duration of your research, and your internal and external examiners afterwards. By the same logic, your customers are also the reviewers of any conferences and journals that you submit your work to. Institutions vary, but there is an important point that comes from this observation: your achievements and progress will be judged by words on paper, not by what is on your computer screen.
This can come as a surprise, especially to doctoral students who have spent a lot of time in industry beforehand. As a doctoral student, you are not creating a software product. There is no software deliverable. Instead, the software you write is merely a tool for performing experiments and getting results. This way of thinking is not always apparent, and I have seen many doctoral students spend a lot of their time trying to make an implementation perfect, trying to make it run more and more efficiently, and continuing to add new tweaks and features that would certainly impress an end user. But there is no end user.
Most, if not all, computer science doctoral students will have to write code while working on their thesis. However, how much code you write can be controlled if you have your priorities straight before starting. The following points should be considered:
How will this piece of software help my research? Is creating this software essential for me to obtain the results I want?
How much of this code has been written before? Are there existing libraries or software tools that do a lot of the grunt work for me?
Am I tied to any particular language? If not, which language will get the job done most quickly?
What is the bare-minimum interface to this software? Can I get away with command-line input and output?
How long am I willing to spend attempting this implementation before I reconsider other avenues?
During my own thesis, I had to write a lot of code. Most of it was in C++. I don't really enjoy writing in C++ all that much. Like everyone else, I get tired as the day goes on, and the sloppier my coding gets, the more segmentation faults I have to deal with. With the complexity of the algorithms that I was implementing, debugging often became a nightmare. Often I would wake up in the morning in a stink knowing that I had an entire day of complicated debugging ahead.
Now, why was I writing in C++? Originally, I was writing in C++ because I thought that I was going to eventually incorporate my code as optimisation passes inside the LLVM compiler, and this is also written in C++. However, by the end of my thesis, I was generating LLVM bitcode (a text representation) as output, and then using this in order to generate code. The short story is that I could have used any programming language at all in order to do this. I didn't need C++ at all. The slightly longer story is that my stubbornness prevented me from rectifying this much earlier on, and then starting again using Java or Python, or something similarly more programmer-friendly than C++. I wasted a lot of time debugging memory errors that I could have avoided completely if I had used a different language. My stubbornness also made me create my own graph libraries from scratch, rather than using the excellent graph libraries that come with Boost, or similar.
From my customer's perspective, they don't care how I created my software, or how long it took. They probably won't ever use the software at all. Their interest is in the results that came from my work, and these are written on paper in my thesis. So don't be like me. Save yourself as much time as possible when it comes to implementation. Write good quality software that does as little as is required to demonstrate your ideas and the subsequent results, and make sure it can be expanded upon in the future if needs be. But, if you're sitting there wondering what the best colour is for your GUI, or whether the command line output could be spaced more nicely, then you're not actually doing research - which is what you're meant to be doing.
