I was a graduate student when my son was born. As much as I was euphoric about my son’s arrival, reality hit me hard. I was not ready. It was brutal but I pulled through graduate school and here is s selected list of tricks I’ve learned from having been a graduate student parent.

Buying time

Time became one of the scarcest resources. The first thing I did to buy more time for research was saying “no” to social activities, meetings with no clear goal, not-so-related review requests, side projects, system upgrades, etc. as most parents do. I decided what activities/projects/commitments to say no to based on my gut feeling. One big problem with this approach was that I couldn’t tell if I missed interesting and important opportunities that are unforeseeable from the day I said “no”. I started to explicitly allocate time for explorations and update my goals/plans frequently to adjust my plans based on findings from the explorations[^1]. Doing this became easier as I became more aware of my own work/research velocity, which I gained slowly by rigorously tracking my time usage and goals for each week/month/year.

I still felt like there wasn’t enough time for work hence the second thing I tried was securing money, e.g., by asking family members and applying for financial aids available via my department or university. I did not know about any financial support opportunities but learned about them as time goes on by talking to a few other graduate student parents that I didn’t know the existence of prior to becoming a dad.

The final trick I learned was delaying tasks[^2]. Delaying tasks is a great trick because often delayed tasks disappear completely due to priority changes. In the beginning, I delayed tasks that I felt very comfortable delaying, e.g., polishing plots before submitting a paper or renaming variable names in codebase while setting up experiments. Gradually, I started delaying seemingly more important tasks such as polishing related work sections or optimizing infrastructure/refactoring codebases (for initial submissions) essentially to verify get feedback on the more important content earlier, e.g., the main research direction. In practice, the most difficult part was knowing what kind of tasks are okay (or not okay) to delay on at first sight; sometimes delaying seemingly not-so-important tasks comes back after becoming a much bigger task. To mitigate this risk, I started to put some time to identify the worst consequences of delaying a certain task and prepare a plan for the worst outcomes.

Minimal viable product

After trying to buy as much time as possible for about a year or so, I made the following observations:

  1. achieving the last 10~20% takes as much more effort as achieving the first 80~90%
  2. re-visiting/working on something always takes much more time than the initial take
  3. there is a huge difference between having something finished vs. not, e.g., at least you get a chance to receive feedback

These observations made me want to always shoot for the minimal viable product (MVP). In the past, I tended to overshoot because I didn’t understand the evaluation criteria well and hence wanted to be “safe” by achieving an arbitrary high quality, which was an extremely expensive approach because of 1. and 3. (sometimes I gave up when a task became too big). To address this problem, I spent more time on (1) understanding the evaluation metrics well, and (2) prototyping early to feel out the requirements in the context. After clearly defining the evaluation metrics for the MVP, I found using them to efficiently execute something to the completion super helpful, esp., towards the end when I’m tired.

Managing attention

After having countless sleepless nights and physically demanding days, I’ve realized the most expensive resource was my attention and not the time. The quality of my attention was not only dependent on my physiological conditions but also my surrounding environment, e.g., the amount of natural light, my team’s mood, etc. With everything going on, I usually only had about 2hrs of the peak attention per day; 4hrs if lucky.

To best use this time, I identified the most likely time of the day that I have the best attention and protect that time slot for the most important tasks. Whenever I face a big task, I would start breaking it down and think about different approaches while I’m away from the desk, e.g., while commuting, picking up or dropping off my son, etc. Usually, the most important tasks such as core algorithm/system design, initial draft writing, big meeting/presentation, etc. reveal themselves[^3]. These tasks require deeply exploring many ideas with caution to make a big dent towards a knotty problem[^4], so I used my protected time to only work on these tasks. I used times with a medium level of attention for execution tasks; I used to do execution tasks in the protected hours but with well-thought-out approaches, execution tasks didn’t require as much attention as the core problem-solving tasks. Finally, everything else, emailing and scheduling, resolving meeting topics, writing down new problem-solving approaches were done on foot, e.g., while watching my son at the park.

Closing thoughts

Even after trying all the different tricks, I still missed countless deadlines and took countless bullets of consequences. When I felt like I hit my limits, the only thing I could do was changing my mentality. I accepted my limit, lowered bars for myself, thought about the meaning of what I’m desperately chasing after in the grand skim of things, and try to enjoy the process more.

Time to time, I ask myself–was it all worth it? As much as I try rewiring my brain to reply with “yes” to that question, I cannot bring back the times I missed with my family and I’ll always feel the guilt of not being around much (physically or mentally) when my son needed me the most. Yet, I’m working on this blog post while watching my son at a playground.


Acknowledgments

I consciously and unconsciously picked up the habits of other parents who I closely worked with and had much more responsibility than me like my grad school advisor Maya Cakmak, and my past team leader Christian Fritz.

I decided to write this blog post when I discovered the existence of similar blog posts from authors I respect:

Last but not least, I have to disclose that I relied a lot on my wife who sacrificed her time for watching our son. This note might change the perspective/legitimacy of all tricks I mentioned above.


Footnotes

[^1] This trick was somewhat inspired by GIST Planning and Startup Engineering.
[^2] The Eisenhower matrix is a great task prioritization technique, however, in my experience, applying the technique in practice, specifically, classifying tasks clearly into one of 4 slots, wasn’t trivial and hence had a similar problem.
[^3] Often, combined smaller tasks such as a task decomposition task combined with an execution task also required my full attention.
[^4] I consider these tasks as combinatorial optimization problems and try to act like well-known algorithms such as branch and bound or iterative deepening when exploring paths to solutions.