Doing research is hard. During the grinding process, I have gradually realized that merely adequate English communication skills and willingness to read paper is far from enough. Due to the complexity and uncertainty, there are so many traps towards finishing a project, and there are so many lessons to learn from. Therefore, I would like to reflect on myself, summarize lessons learned, and try not to do that again. In this blog, I plan to summarize 10 lessons I learned from previous projects. The main purpose for this blog is to warn me not to make same mistakes in the future — I know it is hard. Therefore, these contents only represent my own preference and opinion. Have fun watching me how I blame myself, and hope some opinions helps you in some way.
Read. If you always want to catch every technical details and understand every single proof or formula in the paper it will become a task full of misery and burden. However, reading papers should be a thrilling journey of discovery. To quickly obtain the idea and be amazed at the author’s talents, you need to focus on the high-level logical flow. Focusing too much on obtaining details of the paper is no good, because you lose the big picture of the entire paper, which is disasterous in understanding the paper. Besides, not all papers are worth reading, even in top conferences. Therefore, it is critical to spend your time wisely, and read the papers with clever mind.
From my perspective, some paper can be discarded upon reading the titles (i.e., neither in my research scope nor interested in), and some others may be discarded when I go through the introduction (e.g., poorly written, incremental work, etc). I will only go over the paper when I find the introduction is insightful and interesting — or those paper who have been recommended by our peers.
Let’s do maths. A PhD gets around $2,000 bucks a month, which makes around $70 a day. Suppose your advisor expects you to work 14 hours a day (冗谈だよwww), you worth $5 hourly. To carefully read and fully understand a paper takes from 30 minutes to 2 hours. As a result, if you do not read selectively, you will very likely spend time worh of $3 to $10 on a rubbish. Why don’t you do down stairs, grab a cup of coffee and watch an episode of Rick and Morty?
Before reading the papers, one of the most important thing is to look at the authors. This helps to establish the sense of “who are doing what” in the CS circus, and is extremely useful to help you remember all the papers you read. When you need to find related researches in the future, you can recall the author, then the paper, then his other papers, etc… It is also very interesting to know different people and their focused areas.
Then we can read papers. To do so, the silliest approach is to read from the beginning to the end, which means you can easily fall into the authors’ narratives and hard to raise your own questions. I had written an outdated version of how I read papers here. However, I have learnt a lot during this year, but simply do not have enough time to write a new version again. This will be listed as a future to-do.
Write. When reading, do not forget to take down notes, especially when you are preparing a group meeting. This helps you to think and raise questions, rather than just following the paper and taking anything in it as granted. Most importantly, you wouldn’t like to use Ctrl+F when you are presenting the paper to a group of researchers. Trust me. (And if you are printing them out, there are not even a Ctrl+F to use)
Listen. To improve your understanding, listen to their presentations. You may get a lot things wrong if you merely read it and think for yourself. Listen to their presentations and email them with your questions if necessary. This helps you to better understand the paper, and get to know with talented researchers (well, maybe…) — if you are polite enough when sending emails.
Speak. Doing research is not merely about sitting in your own little cold bench. Doing research is all about discovering and sharing. The advantage of sharing is two-fold: you can learn great knowledge if there are someone willing to share his favorite paper, whereas you can train your presentation skill and learn more details by pushing yourself to fully understand a good paper.
My advisor said, as I quote, “The greatest difference between a scientist and a crank (民科) is that scientists think SYSTEMATICALLY.” He also said, “Doing research is all about challenging. You should always be curious, and ask why not this, why not that. Always challenge yourself.”
Doing research means creating formalized knowledge, which requires polishing and hard thinking. I had not been keeping this in mind during the past project, and the result is, my cooperators often raise questions that hangs me there wordless — After several “eh-“ and “hmm…”, I could only say “Well I need to look into that…” Awkward, isn’t it?
If you use syntactical analysis, you should ask yourself about semantic analysis. If you say static, you should thunk about dynamic. If you look at ‘can’ and ‘must’, you should look at ‘might’ and ‘could’. If you summarize something, you should think whether it is all of it. A well-categorized problem should be exhaustive, and each part of the category should have no overlap but adds up just towards the entire problem. This is what we strive for, and what we need to keep in mind. (To avoid being challenged by reviewers!)
Procrastination is the rival of each PhD student. The root cause may be complex. For me, there are two main causes.
The problem is hard. I have no idea what to do. If I cannot get an idea for a long time, I will go have a bath and sleep (let the dream do the job!). When I was a bachelor student, quite some new ideas are raised in the bathroom. Of course, some one else argues that we need to be extremely careful with the ‘bathroom ideas’, which often proved to be useless . But I think it is okay, because it is not horrible if we have too many useless ideas. If the ideas runs out, then that is the REAL apocalypse.
The solution is ugly. As Professor Matt Might quotes , “Good enough” is always better than “Perfect”. I went into this trap in March when I updated with my cooperators, and stuck on a trivial and silly problem: “This solution is too ad-hoc!”. We wasted one and half an hour of valuable time. And then my advisor Dr Lin said, “I just don’t understand why you are so worried about this, just do it and see whether it works.” Then I suddenly realized, many elaborate approaches are not born as they were, but polished to what they are. Ugliness is not the problem because we can polish them later. Void, however, is the real problem. There will be nothing if you hesitate about its ugliness and be reluctant of implementing that.
The universe wsa born in a chaos. Nothing is naturally neat and clean. This blog has been redrafted several times but I am still not satisfied with it. But anyway, just get the damn ass moving.
Doing research is a long and grinding process, and is least likely to be a dash. There is no need to rush: rush programming, rush writing, rush experimenting. The only result is poorly formalized problem, flawful paper writeup, messy statistic scripts, and unrecognizeable code. At that phase, when you have to painfully re-organize everything, you will really hope that Stephen Hawking invented time machine to let you travel to the past and punch really hard on yourself. I mean I really want to do so NOW.
So, why hurry? Think well and then do it. As a Software Engineering student, why not develop nice code managing protocols first?
But no rush does not mean treating the PhD as 9-6-5 work. There are too many clever mind who needs no sleep. Still, hardwork is required to do nice research — but that, of course, does not mean pushing too hard to dash all the way through the marathon will do the trick. Doing research is still mind-intensive. So, I would quote once again my advisor’s advice: take every minute, have some rest, and try to make progress everyday.
I am not that kind of extremely self-prompted student that pushes himself everyday without outside intrution. But I have my own way. That is to force myself to report my progress every day or every two days, to keep myself progressing step-by-step. From some perspective, reflecting on myself and writing this blog is also sort of “making progress”, isn’t it?
My first few meetings were messy. Then, I got the advice from a senior PhD student in our group. When having meeting, we need to respect everyone’s valuable time. Therefore, we need to let audiences obtain high-level knowledge of what we would like to introduce today, then come to the details:
- Make slides. Do I need to explain?
- Summary first, then break down. Summary last week’s plan and how you address them this week. Make the audience know what you are going to say, do not say anything as soon as you think about it
- Conclusion first, then how it is done. The audience would not like to hear you telling story on how hard it is. They all understand that you work hard. Conclusion first, then say how it is done, or how hard it is to do.
- State challenges and future plan. State the challenges one by one to discuss and get their advice. Be sure to highly summarize that. For example, what are the current solution, their pros and cons, why they do not work well, that is the main problem there. After the discussion, record and state your future plan.
- Avoid too much details. You may discuss further one-to-one, not when all the professors and senior students are present. If this meeting is called to solve a specific problem, there is an exception.
Be responsible of what you say. By deepening into your own tiny field, you need to become an expert.
- Be responsible. If there are no irresistable factors, finish whatever you promised to do. You can say it is not possible to be done in weekend because you want to meet some friend. But you cannot adopt “okay and sorry” strategy. Estimate well about the amount of time to finish, and leave some flexible time window. I am still not doing this well.
- Be honest. If I did, then I say I did it. If I did not, I must be honest. Never say ‘did’ something when actually something is ‘going to be done’, or ‘will be done as soon as you get up’. That is no good.
- Be careful. When using any word, think about their actual meaning. What is the difference between tags and elements, and what is the difference between document and documentation. And be responsible for the consistency in the paper. There had been so many ‘taken-as-granted’ words and inconsistencies that almost drove my advisor mad (of course this was exaggerated hahahah)… Therefore, the terminology is really important.
- Be grateful. I often made the mistake of saying “my idea”, “my paper” when that was actually other’s idea and suggestion. When I was suggested about this problem, I really took a lot of attention on this issue.
I had often brutely interrupt others’ talking and inserting what I think they are talking. This is hell of a bad habit. Now I am trying to hold my gushing ideas by taking them down, and discuss after I fully understand what others said.
One more thing, because the poor network connection, it is normal when we cannot hear others well. Just ask them to repeat. How can it be ever embarassing? (Blaming on myself in the past)
When formalizing the problems, I once got two contradictory suggestions from two collaborators. I really respected them two and thought both of their suggestions were really plausible. As a result, I made two entirely oppotite changes within one day. Then my advisor said to me. “You should not simply agree with everyone, I say this, you agree this. He say that, you agree that. You have to have your own opinion, your own idea. You need to challenge me, what I said is wrong.”
In the next meeting I investigated the two suggestions and proposed my own. This time, I got a positive reponse: “sounds good.”
Start early! Write the papers! Record how your problem gets formed and re-formed. Do not wait until the system is almost there. You will find that there are so many problems uncovered and not systemmatic, and as a result the system needs reforming too. This is especially driving people mad when it comes to the deadline. So keep thinking systematically and begin writing early.
Writing is a reader-oriented process. Many reviewers may not be familiar with what you do. To make them easy to parse and understand, you need to hold their hands, step by step, and make sure there are no logical jumps. Make sure to give readers high-level impressions, and put less priority on the technical details. As introduced in Lesosn 1, most readers do not care much about the details. When you mention something, there has to be a connecting clause to show the relationship with the prior sentences. And when you start to introduce something else, there has to be a connecting sentence to show relationships too. Just write it with sentences attached to each other, do not suddenly grab a new terminology and “bang” throws it away on the readers — this will make them freak out, and then they will “bang” throw a rejection on your paper, and you will also freak out. This requires long time training, so there is still a long way to go, at least for me.
 Several of my classmates and young peers
 As quoted by my roommate Xiangzhe’s advisor, Xiangyu Zhang