Lessons from the first year of my PhD
I finished my PhD in computer science more than three years ago. Now that I have a little bit of mental distance from my PhD time, I'm going through my research diary to see if there's stuff in there that can be useful for other people.
Apparently I'm incapable of writing short-form texts, so here is part 1. ;)
General life advice
When you're stuck, ask for help.
Research
Take inspiration from chemists/laboratory workers and keep a research log. It will occasionally save your life (and sanity). My log from year 1 is 139 pages long. That's about half the length of my PhD thesis.
Your research log doesn't have to be fancy. My research log was just a very long Libreoffice document. Each entry consists of a date and whatever I wanted to write about that day! It's filled with braindumps, todo lists, project ideas, observations, philosophical ramblings, doubts, meeting notes, and questions.
I recommend that you keep your research log 100% private so there's no pressure to sound smart or sophisticated whatsoever. Express yourself freely while writing in this doc. It will help you think.
It's a perfectly valid strategy to enter a new research field by reading interesting-looking papers and painstakingly looking up every unknown abbreviation, word, concept, and technique. Here's a list from my first week at work, way back in 2018:
Definitions to look up after reading survey paper 1:
- computational linguistics
- nlproc
- canned strings
- English glosses
- lexical items
- ontological status of categories
- surface linguistic forms
- discourse history
- morphologic
- orthographic
- bidirectional grammars
- linearising words
- forest (machine learning)
Every research project starts with not knowing what you're going to do (exactly). This should not worry you or cause anxiety: it is an integral part of the process.
Start writing your thesis from day 1, even if it's just writing down the main premise of a paper in two sentences.
Research can be an intangible activity, so take measures to make it more tangible! This helps to combat PhD progress anxiety. I did this by writing my research log, evaluating my overall progress and happiness via a monthly evaluation questionnaire (blogpost forthcoming), and making daily tallies of distraction-free pomodoro sessions.
When I started my PhD, it took me an entire workday to work through a single 8-page conference paper. This will get better over time.
Never forget you're studying a subfield of a subfield of a subfield. You can't know everything. See also Matt Might's Illustrated Guide to a PhD.
If you're feeling insecure about your research work: talk about your insecurities with friends, family and colleagues - but, whatever happens, continue working. Don't let your insecurities hold you back. In the words of Matt Might: be tenacious.
When doing a PhD you will invariably bump into your own weaknesses. In the end you're the project manager and the only project contributor.
When designing experiments with human participants: it's a huge advantage if the researcher does not have to be in the room while the data gathering/experiment takes place. This way you can do longitudinal experiments without sacrificing all your research time because you have to babysit (sometimes literally) your participants.
There is a large difference in quality between PhD courses. Ask your colleagues which courses are worth your time and consider ignoring/replacing the rest.
Half of the experiments in Human Media Interaction don't involve any automated system at all. Instead these experiments are "wizarded": a PhD student sits behind a curtain and acts like an automated system, so that data gathering can take place. And yes, sometimes it's hard not to laugh when you're being the Wizard.
Applied research
If you're creating software/code artifacts during your PhD, it's worthwhile to invest in your software engineering skills. Scripting (=run once code) is not the same as software engineering! Find people that are working as a software engineer in industry and humbly ask them for feedback on your code. Thanks to the advice of my friends, I got started with virtual environments, pinning my dependencies, linters, some typechecking (but still not enough), more complex version control, and writing basic tests.
Not all learning needs to immediately pay off. You should have some time for exploring new technologies or doing sideprojects. For example, I started learning Flask, Django, test-driven development, typed Python, and Javascript in my first year. I also built a first (tiny) js game, a static site generator, a few webscrapers, a text generation demo based on grammars (so cute!), and did more devops on my VPS because I managed the website for our research consortium.
Try out demos or beta products of companies operating within your area of expertise. This gives you a sense of what industry is working on and what they're considering worthwhile problems. Example: in January 2018 I tried out "Microsoft Cognitive Services" which had a picture description API at the time. This was before LLMs with vision capabilities so this was a big deal! Another colleague (specialized in dialogue systems) was doing side-projects on a secondhand Amazon Echo device.
If you have to create artifacts (games, stories, illustrations, large documents that are not scientific papers or your PhD thesis, ...) for your research project, and they're not essential to the research itself, try to work from things that already exist as much as possible.
For demo sessions and demo markets at conferences: pre-recorded videos are the way to go. Live demos are cool, but the chance that your multi-component text generation pipeline suddenly doesn't work is not worth it. Better not waste the precious time and attention from audience in the room, or the people who wandered past your corner of the demo floor.
Demos don't have to be representative or recent, as long as they're entertaining, they bring your point across and spark conversations with new and relevant people.
Communication
It is completely unnecessary in academia to explain why you're asking a question.
Ask open questions, and try not to fill in too much when asking questions. I noticed people ask closed questions for various reasons. Some people want to look smart. Other people mistakingly think communication is more "efficient" if they can guess upfront what your answer will be. Example: if I ask someone "Did you use technique X?", they will say "No, I used technique Y", and spend most of their time explaining why they're not using X -- which is not what I wanted to know. It's better to ask "What is the underlying technique?".
Networking
Find your community within academia. Find a group of people that shares your research interests, with a positive, non-toxic, supportive culture. No, just having shared research interests is not enough.
Find your peers! Your direct colleagues at your university might not be working on the same topic as you, but some people in the world probably are. It often takes a few months before you visit your first academic conference and meet these international colleagues. Luckily, you can speed up this process a bit. Every now and then, spend some time on the internet and use your best OSINT skills to find pockets of people working on similar stuff as you. Look into social media platforms, "old-skool" mailinglists, irc channels, forums, research magazines, or special interest "workgroups". For example, my first conference was CLIN28 (Computational Linguistics in the Netherlands) and I discovered many relevant people and cool projects by trawling Twitter for historical mentions of "CLIN" or the conference website.
Great ways to find conferences to attend or follow: ask your supervisor; visit the conferences that have published your favorite paper in their "conference proceedings"; stalk your academic friends on social networks; subscribe to relevant newsletters and alerts; any websites/groups/other conferences mentioning a conference you've already visited.
I hope this was useful. See also my blogpost about using Twitter microblogging as a researcher, and tips for attending (industry) conferences.