Joining the Laboratory!
Well begun is half done.
Thank you for your interest in joining the lab! This document contains all the information you should know, so please read it carefully to proceed on.
Application Procedure
-
Contact Jeehoon ASAP.
There are nothing blocking you from contacting Jeehoon (e.g., GPA, experience, …). You can also contact Jeehoon via comments!
-
Send an application to Jeehoon (
jeehoon.kang@kaist.ac.kr
).Please prepare for a Google Docs document and give the document’s comment access to
jeehoon.kang@cp.kaist.ac.kr
. In the application, please describe:-
The most interesting experience on computing (past). It can be about course projects, research or industry experience, or anything related to computing.
-
What you want to do in the lab (future). I suggest you first read the lab’s research page and see what’s going on in this lab.
-
Your plan (future). When do you want to start an internship or apply for the graduate school? How much time you can spend for an internship, e.g., 15 hours per week? What’s your expectation and long-term plan (after internship or graduate school)?
-
-
Tell me when is convenient for you for a 30-minute online meeting.
Please create a Google calendar event and invite
jeehoon.kang@cp.kaist.ac.kr
to the event. Consult Jeehoon’s calendar for his schedule. -
Create the
{firstname}.{lastname}@kaist.ac.kr
email account and tell me (if you’re a KAIST student).-
You can add “virtual mail” in
> Upper right-hand side gear > Settings > Mail > Virtual Mail > Add Mail. -
If it is already taken, add a random number at the end of the id, e.g.,
{firstname}.{lastname}07@kaist.ac.kr
.
-
-
Finish reading this document.
Requirements
-
All new graduate students are required to finish at least two of the followings before joining the lab. So please start working on one of them ASAP.
-
Homework assignments of KAIST CS420: Compiler Design. Lecture videos are uploaded to YouTube, and you can ask questions in the course repository’s issue tracker.
-
Homework assignments of KAIST CS431: Concurrent Programming. Lecture videos are uploaded to YouTube, and you can ask questions in the course repository’s issue tracker.
-
Exercises of Software Foundations Volumes 1 and 2.
-
Reading the Corundum open-source FPGA-based NIC.
-
-
You’re also strongly encouraged to join the lab as an undergraduate intern.
Please use internship as an opportunity to see what’s actually going on in the lab. We are widely open to all undergraduate students! Though I’m encouraging potential interns to finish at least one of the above tasks before joining the lab as an intern. Then you’ll start research projects right after joining the lab.
General Advice
Welcome to the lab! Here’s my two cents about research and work in general.
What is Research?
“Research is what I am doing when I don’t know what I am doing,” Wernher von Braun
The defining characteristic of research is everything—from motivation to methods to evaluation to goal—is tentative: in the middle of doing research, you don’t know what will be the end result. As a consequence, a researcher will suffer everyday from:
-
Failures. You don’t know what you’re doing, so you’ll fail almost always. To deal with the frustration from such failures, you should be mentally tough enough to tolerate such frustration. If successful, from time to time you will be able to understand or design small things, which accumulate to a paper and then a thesis.
-
Changing plans. You don’t know what you’re doing, so your goal will be changing as you make progress on your project. So any long-term plan is destined to be significantly revised (if not cancelled). Thus you should think of the goal as a ever-moving target, the current version being just the best possible approximation of the actual end result. Your goal should be neither too concrete nor too abstract: if too concrete, it will not be resilient to the revision; if too abstract, it will not guide your research.
Management Principles
To get things done despite the fundamental uncertainty of research, this lab (ironically) aims to keep tangential uncertainty to the minimum. All uncertainty are not created equal. Some uncertainty, such as confusion on schedule or communication, is not beneficial for productivity. On the other hand, other uncertainty, such as unexplored design spaces, is the very definition of research. To be productive, we need to keep the former to the minimum and control the latter to the appropriate amount. (The meaning of “the appropriate amount” constitutes a researcher’s character; at first, please follow Jeehoon’s taste.)
To minimize the unnecessary uncertainty, this lab enforces a small number of rules on communication. Rules are good at minimizing confusions. For example, is it okay to mention someone in chatting applications during night time? People have vastly different opinion on this, possibly causing unnecessary tension among them, so we want to define whether it’s acceptable or rude in a rule. (FYI, we allow night-time mentions, but you’re required to react to them only in work hours.) On the other hand, rules are hard to follow if there are so many. So we want to keep the number of rules as low as possible.
Communication
Asynchronous Communication
-
Always, strongly prefer asynchronous communication: the receiver is not required to reply promptly. If you can say something asynchronously, please do it so as early as possible. For example, you want Jeehoon to review your document, please send it to him as soon as you finish writing it. Don’t wait for the meeting time to come. Please address Jeehoon’s comments as soon as possible, and when it’s done, please notify him of the progress.
-
While communication is asynchronous by default, try to reply to messages reasonably often. In work hours, try to reply to messages by 15 minutes. (No need to even reply in other times.)
-
Before asking for a synchronous meeting (face-to-face or online), write down a meeting agenda and share it. In the agenda, clearly state the purpose of meeting. It can be, but not limited to: (1) reporting the progress, (2) asking questions/opinions, or (3) just chatting. If you have multiple things to discuss, enumerate them at the beginning of a meeting for better planning of the meetings.
- If you don’t send an agenda, the meeting is potentially going to be canceled.
- If the meeting is to discuss a document, please send it at least by 12 hours before the meeting so that the others can review it. Share it anyway even if you couldn’t finish writing the document by the time, because the others need to start making comments on it.
Volume
-
At 10am and 3pm everyday, please leave about five sentences to the daily log about what you’ll do and what you’ve done for the day.
-
Schedule at least one meeting for at least 15 minutes a week with Jeehoon. It can be about anything such as research, coursework, TA…
Discussion
- Don’t pretend to know something if you don’t.
If you do that, then you’re losing an opportunity to (1) learn the knowledge; and (2) go deeper into the problem that leads to a great research topic.
Cherish (and even foster) your ignorance.
Don’t assume the others will look down on you if you don’t know something. I know people often do it, but it’s their bad.
- Don’t say yes (or no) if you’re not sure about it.
- Don’t say you understood something if you don’t.
- You’re encouraged to say “I don’t get it” and “I don’t know that.”
-
Be faithful to the discussion. If you disagree, say so; if you don’t like it, say so; if you’re happy with it, say so! But don’t try to win the argument. Research is not about winning and losing (especially within the same group). Try to summarize what you want to say (e.g., “Your idea doesn’t work in general”) and then substantiate your argument with evidences (e.g., “for instance, let’s look at this code: …”).
-
Don’t be angry or grumpy when the discussion is getting hotter. Research and any other creative works require different opinions clashing with each other, or in other words, hot discussions. But they don’t need to be involved with emotions clashing with each other. I know it’s difficult to separate them out, but let’s try to do that.
-
Right after every discussion, write down and share a summary note in the corresponding project stream in Zulip. For instance:
## discussions - method A won't work because of B. (but is B really relevant?) - anyway, let's first try C instead. - maybe D is also worth looking at? ## action items - jeehoon: contact D's authors - kyeongmin: investigate if B really matters, and document why A won't work in gitlab. - seungmin: implement C, make a schedule for the next meeting
Please faithfully summarize discussions. Especially, be fair to the ideas you don’t agree with.
Reliability
-
Make sure to share crucial details to the collaborators. Without a sufficient amount of communication, it’s often difficult to make progresses on your research. For instance, maybe the problem you’re solving hard right now is already dealt with by the others, so frequently tell the others about your progress. (Too much communication, on the other hand, may be burdensome but it can be easily and proactively addressed, so it usually doesn’t cause any harm.)
-
Make sure that no feedbacks or action items get ignored. More concretely, when you receive a feedback, address it or give a counterargument against it. When you’re not capable of doing action items by their deadline, please say so as early as possible.
- It doesn’t mean you need to foresee the future and always finish your work by the time. I know you’re not going to make it quite often. (It’s research!) Just tell the others that in a timely manner. That’s it.
- If you’re reliable on this, the others can depend on you to get things done. If you’re unreliable and you miss feedbacks or action items, the others also need to track them, which causes great management cost.
Writing and speaking skills
-
Try to be direct, top-to-bottom, and conclusion-first.
Don’t say “A, so B, and then C”. Try “C, because B. Should you wonder, B is due to A.”
- Read how to write papers and give talks by Dr. Derek Dreyer:
- How to write papers so people can read them, PLMW@POPL 2016
- How to give talks that people can follow, PLMW@POPL 2018
- How to write papers and give talks that people can follow, PLMW@ICFP 2017
- Use Derek’s CGI model when summarizing papers or writing proposals. Analyze the context, gap, innovation, strength, and weakness of papers and proposals. Here’s an example.
Tools
Please read a dedicated document.
It’s Done!
Please check this document again to make sure you’ve done all action items. Then send a Zulip PM to Jeehoon that you did so.