Philip Guo (Phil Guo, Philip J. Guo, Philip Jia Guo, pgbovine)

The Ph.D. Grind: tl;dr Edition

For impatient readers who don't mind spoilers, here are selected excerpts from my e-book The Ph.D. Grind, which is the first known detailed account of an entire Ph.D. experience.

Exactly one year ago, I published The Ph.D. Grind on this website. So far, it's been downloaded over 100,000 times, and I've received hundreds of heartfelt email responses from readers around the world.

Many of these readers finished the entire book in one sitting, usually taking around 2 to 3 hours. For the impatient, here's a tl;dr edition comprised of selected quotes taken from each chapter. This version should take 10 to 20 minutes to finish.

(Spoiler alert: I end up graduating!)


“Since I felt bored by my engineering internships and somewhat enjoyed my time as an undergraduate teaching and research assistant back in college, I set my sights on university-level teaching and academic research as future career goals.”

“Although I wasn't passionately in love with my master's thesis project, it turned out that aligning with my advisor's research interests was a wise decision. [...] These accomplishments, along with my advisor's help in crafting my application essays, won me admissions into several top-ranked computer science Ph.D. programs.”

“However, at the time, I had absolutely no idea that my first year of Ph.D. would be the most demoralizing and emotionally distressing period of my life thus far.”

Year One: Downfall

“I was interested in research that could help [computer users and programmers] become more productive. For example, I wanted to design new tools to assist scientists who are analyzing and graphing data, system administrators who are customizing server configurations, or novices who are learning to use new pieces of software.”

“During my first meeting with [my future Ph.D. advisor] Dawson, he seemed vaguely interested in my broader goals of making computer usage and programming more productive. However, he made it very clear that he wanted to recruit new students to work on an automatic bug-finding tool called Klee that his grant money was currently funding.”


“Although my task [of using Klee to find bugs in Linux device drivers] was conceptually straightforward, I was overwhelmed by the sheer amount of grimy details involved in getting Klee to work on device driver code. I would often spend hours setting up the delicate experimental conditions required for Klee to analyze a particular device driver only to watch helplessly as Klee crashed and failed due to bugs in its own code.”

“This was the first time in my life that I had ever felt hopelessly overwhelmed by a work assignment. In the past, my summer internship projects were always manageable, and although lots of schoolwork in college was challenging, there was always a correct answer waiting to be discovered.”

“Dawson gave high-level strategic advice from time to time, but like all tenured professors, his role was not to be “fighting in the trenches” alongside his students. It was our job to figure out all of the intricate details required to produce results”

“Even though I fully accepted my lowest rank on the pecking order, my emotional brain still took a huge beating during those first few months because the work was so damn hard and unrewarding.”


“By the time we got those favorable results [from our Klee enhancements and experiments], there were only three days left until the paper submission deadline, and nobody had even begun writing the paper yet.”

“We ended up submitting an embarrassing jumble of text filled with typos, nonsensical sentence fragments, graphics without any explanations, and no concluding paragraphs. It was a horrid mess.”


“I spent the next ten weeks daydreaming of my own research ideas in a complete vacuum without talking to anyone. Since I had such a negative initial experience working in a research group for the past few months, I now wanted to be left alone to think for myself.”

“I lived in complete isolation, mentally burned-out yet still trying to make some gradual progress. Every single day, I tried reading several computer science research papers and taking notes to get inspired to think of my own creative ideas. But without proper guidance or context, I ended up wasting a lot of time and not extracting any meaningful insights from my readings.”

“In retrospect, going solo so early during grad school was a terrible decision. Contrary to romanticized notions of a lone scholar sitting outside sipping a latte and doodling on blank sheets of notebook paper, real research is never done in a vacuum.”

Year Two: Inception

“My summer internship at Google was a welcome break from research. The work was low-stress, and I had fun socializing with fellow interns. By the end of the summer, I had recuperated enough from my previous year's burnout to make a fresh start at being a Ph.D. student again.”


“[When I visited Boston for an end-of-summer vacation], I emailed a few MIT professors whom I knew from my undergraduate days to ask for their guidance. When they met with me, they all told me roughly the same thing: Be proactive in talking with professors to find research topics that are mutually interesting, and no matter what, don't just hole up in isolation.

“Although none of my specific ideas won Scott over, he still wanted to work with me to develop a project related to my general interests. At the time, he was an assistant (pre-tenure) professor who had been at Stanford for only three years, so he was eager to publish more papers in his quest to earn tenure.”


“Since I wanted to create tools to help improve the productivity of programmers, Scott first suggested for me to observe some programmers at work in their natural habitat to discover what real problems they were facing.”

“[To find programmers to observe at work,] I decided to drive to the Mozilla headquarters and walk in the front door. I accosted the first person I saw and introduced myself. He generously gave me the names and email addresses of two Mozilla Foundation leaders who might be interested in such a research collaboration. I cold-emailed both of them later that day and was amazed that one responded favorably. Unfortunately, that was the last I heard from him; he never responded to my requests to follow up.”


“At this point, Scott decided to have [his Ph.D. student] Joel and me team up to create a lab study together. [...] Joel, Scott, and I designed a lab study where we asked Stanford students to spend 2.5 hours programming a simple Web-based chat room application from scratch.”

“We wrote up our lab study findings and submitted our paper to a top-tier HCI conference. Three months later, we found out that our paper was accepted with great reviews and even nominated for a Best Paper Award.”

“I felt satisfied to see this project conclude successfully with a prestigious top-tier conference publication, in stark contrast to the embarrassing Klee paper rejection from my first year.”


“At the end of my first year, I started exploring research ideas in a subfield called empirical software measurement—specifically, trying to measure software quality by analyzing the development history of software projects. It turned out that [my advisor] Dawson was also interested in this topic, so we continued working together on it throughout my second year.”

“Dawson and I had a lot of trouble getting our results published. [...] The underlying cause of our publication troubles was that we were not “insiders” in the empirical software measurement subfield (sometimes also called empirical software engineering) to which our project belonged.”

“In the cutthroat world of academic publishing, simply being passionate about a topic is nowhere near sufficient for success; one must be well-versed in the preferences of senior colleagues in a particular subfield who are serving as paper reviewers.”

“As I prepared to begin my third year at Stanford, I was desperate to cling onto anything that had a reasonable chance of producing publishable results. And that's when I returned back to the project that haunted me from my first year—Klee.”

Year Three: Relapse

“It was now the middle of my third year, and many of my fellow students and I fell into a state of “limbo” where it became difficult to motivate ourselves to consistently come into the office every single day. We also experienced isolation and loneliness from spending day and night grinding on obscure, ultra-specialized problems that few people around us understood or even cared about. Our advisors and senior colleagues sometimes provided high-level guidance, but they rarely sat down together with us to work out all of the grimy details.”


“Despite repeated failures with Klee, I still wanted to keep working on it because that was the only project Dawson cared about. I was starting to hate Klee, but I had already sunk thousands of hours into wrestling with its code, so I wanted something concrete to show for my efforts.”

“At this time, a first-year Ph.D. student named Peter joined Dawson's lab group and was looking for a project. I talked to Dawson about teaming up with Peter, figuring that the two of us working together might get better results than each working alone.”

“I think that Dawson expected Peter and me to have gotten publishable results much faster, so to him, we either seemed incompetent or not serious enough about our jobs. As a professor at a top-tier university, it's a sad reality that all of Dawson's students are probably less competent than he was as a Ph.D. student. The explanation is simple: Only about 1 out of every 75 Ph.D. students from a top-tier university has what it takes to become a professor at a school like Stanford (or maybe 1 out of every 200 Ph.D. students from a regular university). Unsurprisingly, neither Peter nor I was of that caliber. If Dawson had worked with a younger clone of himself, then progress would have been a lot faster!”

“Even though we put in a solid effort during those two months, Peter and I felt like we had really let Dawson down on a project he cared deeply about. Peter was so discouraged that he switched advisors and then later dropped out of the Ph.D. program altogether. With my teammate gone, I grew more disillusioned and decided to quit Klee for the final time.”


“Since Dawson had tenure, his job was never in danger. In fact, one of the purposes of tenure is to allow professors to take risks by attempting bolder project ideas. However, the dark side of this privilege is that professors will often assign students to grind on risky projects [such as new enhancements to Klee] with low success rates. And the students often can't refuse, since they are funded by their advisors' grants.”

“I don't mean to single out Dawson or Klee in particular. This mismatch of incentives between tenured professors and Ph.D. students is a common problem in most labor-intensive science and engineering research projects.”

“A tenured professor can survive several years' worth of failures, but a Ph.D. student's fledgling career—and psychological health—will likely be ruined by such a chain of disappointments.”


“Immediately after my third year of Ph.D., I spent the summer of 2009 in Seattle, Washington as an intern at the headquarters of Microsoft Research. It was one of the most fun and productive summers of my life: My internship project led to the publication of three top-tier conference papers and, more importantly, helped establish the motivation for my dissertation work.”

“At present, Microsoft Research is the premier corporate institution for producing top-notch academic research. Research labs in most companies are usually focused on R&D efforts to directly improve their own future products. However, the primary mission of Microsoft Research (abbreviated “MSR”) is to perform fundamental science and engineering research with the intent of publishing top-tier academic papers in computer science and a few related fields.”

“Perhaps the longest-lasting impact of an MSR internship is the friendships we all made. During that summer, I had the privilege of getting to know some of the brightest and most inspiring young computer science researchers of my generation.”


“Even though I had a wonderful summer “intermission” from my Ph.D. program, I still didn't have any plans for my dissertation project when I returned to Stanford in the fall. All I knew was that I didn't want to keep working on Klee, but I had no idea what I could do that was both personally motivating and, more importantly, publishable.”

“And then, on July 24, 2009—halfway through my internship—inspiration suddenly struck. In the midst of writing computer programs in my MSR office to process and analyze data, I came up with the initial spark of an idea that would eventually turn into the first project of my dissertation. I frantically scribbled down pages upon pages of notes and then called my friend Robert to make sure my thoughts weren't totally ludicrous.”

Year Four: Reboot

“By altering the Python run-time environment (called an interpreter) in some innovative ways, I could eliminate many of these inefficiencies [that I observed computational researchers facing as they analyzed data.] I named my proposed modification to the Python interpreter “IncPy,” which stands for Incremental Python.”

“I rebooted my Ph.D. career as I began my fourth year at Stanford, severing my ties to the previous three years and starting anew. No more working on already-established research projects, no more trying to scheme up ways to align with the supposed interests of professors and senior colleagues, and no more worrying about what kinds of research the academic establishment liked to see.”

“Although I was filled with newfound excitement and passion, a part of me was scared because I was breaking away from the establishment to do something new and unproven without any professor support.”


“Having a good idea is necessary but nowhere near sufficient for producing publishable research. Junior researchers—usually Ph.D. students—must spend anywhere from hundreds to thousands of hours “sweating the details” to bring that idea to fruition. In computer science research, the main form of labor is performing computer programming to build, test, and evaluate new software-based prototype tools and techniques.”

“Implementing IncPy involved some of the grimiest programming grind that I had ever done. [...] Even though I wasn't in love with my previous research projects earlier in grad school and during college, the technical skills and judgment that I gained from those experiences made it possible for me to now implement my own ideas that I truly cared about.”

“I became fiercely self-driven by an enormous amount of productive rage. I turned steely, determined, and ultra-focused. Every time I reflected back on the inefficiencies, failures, and frustrations that I had endured during my first three years of grad school, I would grow more enraged and push myself to grind even harder; I was motivated by an obsessive urge to make up for supposedly lost time.”


“My [preliminary IncPy workshop] paper was accepted with great reviews, and I attended the workshop [in San Jose] in February 2010 to give a 30-minute talk on it. In particular, I was honored that Margo, the program committee co-chair, personally praised my paper and mentioned how it was related to a new Python-based project that her student Elaine was starting.”

“Although giving a talk on my IncPy workshop paper was great for getting feedback and especially for meeting Margo, that paper didn't count as a “real” publication for my dissertation. I knew that I still needed to publish this work in a conference that professors in my department recognized as legitimate.”

“The next relevant top-tier conference submission deadline was in seven months, so I aimed to have a paper ready by then. I spent lots of time trying to find case study subject programs and potential users for deployment. Without those, there would be no evaluation, no conference publication, no dissertation, and no graduation.”

Year Five: Production

“I knew that IncPy would not be substantive enough for an entire dissertation. So besides working towards the upcoming paper deadline, I also spent some time thinking about my next project idea. I wish I could say that my solo brainstorming sessions were motivated by a true love for the pure essence of academic scholarship. But the truth was that I was driven by straight-up fear: I was afraid of not being able to graduate within a reasonable time frame, so I pressured myself to come up with new ideas that could potentially lead to publications. ”

“On July 29, 2010, almost exactly one year after I conceived the initial idea for IncPy, I came up with a related idea, again inspired by real problems that computational researchers encounter while performing data analysis. [...] I named this proposed modification to the Python interpreter “SlopPy,” which stands for Sloppy Python.”


“By this time, a nascent dissertation theme was beginning to form in my head: Both IncPy and SlopPy were software tools to improve the productivity of computational researchers. Thus, to think of my next project idea, I returned to identifying problems computational researchers faced in their work and then designing new tools to address those problems.”

“As I was jotting down more detailed notes [about an extension to IncPy that would record experiment histories], a moment of extreme clarity struck: Why limit this experiment recording to only Python programs? With some generalizations to my idea, I could make a tool that enables the easy reproduction of computational experiments written in any programming language! Still in a mad frenzy, I sketched out the design for a new tool named “CDE,” which stands for Code, Data, and Environment.”

“Over three intense weeks spanning October and November 2010, I super-grinded on creating the first version of CDE. As I suspected, although the research idea behind CDE was straightforward, there were many grimy programming-related contortions required to get CDE working on real Linux programs. I lived and breathed CDE for those weeks, forgetting everything else in my life. I programmed day and night, often dreaming in my sleep about the intricate details that my code had to wrestle with.”

“I felt ecstatic when, after three weeks of coffee-fueled fully-immersed grinding, I finally got CDE working on my scientific program demo.”

“From a research standpoint, my mission was now accomplished: I successfully built an initial prototype of CDE and demonstrated that it worked on a realistic example use case. The common wisdom in most applied engineering fields is that research prototypes such as CDE only serve to demonstrate the feasibility of novel ideas. The job of a researcher is to create prototypes, experimentally evaluate their effectiveness, write papers, and then move on to the next idea.”

“[However,] I had an urge to make CDE useful for as many people as possible. I didn't want it to languish as yet another shoddy research prototype that barely worked well enough to publish papers.”

“At present (summer 2012), CDE has been downloaded and used by over 10,000 people. I've received hundreds of emails from users with feedback, new feature requests, bug reports, and cool anecdotes. Although this isn't a large number of users for a commercial software product, it's extremely large for a free and open-source research tool being maintained by a single grad student.”

“Those few months were by far the most enjoyable period of my Ph.D. years, even though I knew that none of my software maintenance activities would contribute towards my dissertation. After the initial success of CDE, I no longer cared if my graduation was delayed by a year or more due to lack of additional publications; I got so much satisfaction from knowing that a piece of software I had invented could improve many people's computing experiences.”


“CDE also enabled me to achieve one of my long-time nerd dreams: to give a Tech Talk at Google that was broadcast online on YouTube. [...] My talk went quite well, and afterwards a Google engineering manager (whom I had never met) pulled me aside [and] offered me an internship where I could spend the upcoming summer working on CDE at Google.”

“My gut intuition was that this was a unique and well-timed opportunity that I couldn't turn down: I would be paid a great salary to spend my summer continuing to work on my own open-source software project. In contrast, almost all interns—including myself back in 2007—were expected to work on internal company projects assigned by their managers.”


“Back at the beginning of my fifth year—long before the IncPy, SlopPy, and CDE papers had been published—I hatched a backup plan in case my own projects failed. I cold-emailed Jeff, a new assistant professor in my department who shared some of my research interests, to ask whether he was open to collaborating on a project that might contribute to my dissertation.”

“I was hedging my bets with this plan: If my IncPy, SlopPy, and CDE projects couldn't get published, then at least I would still have a “legitimate” professor-sanctioned project with Jeff, who was now one of my thesis committee members.”

“Towards the end of my fifth year, I took a break from CDE and spent 2.5 months creating some new extensions to [an interactive data reformatting tool from his lab called] Wrangler. My enhanced version was called “ProWrangler,” which stands for Proactive Wrangler.”

Year Six: Endgame

“As I began my final summer internship at Google, I looked forward to spending three carefree months polishing up CDE, but I felt a bit anxious because graduation wasn't yet guaranteed upon my return to campus. I needed one more burst of inspiration, and it ended up coming from an unexpected source.”

“During a break between sessions at [the conference where I presented my CDE paper], I spotted Margo sitting by herself working on her laptop. Recall that I had met Margo during my fourth year at the San Jose workshop where I presented my original IncPy [workshop] paper. [...] I briefly told her that I was about to give a talk on my new CDE project and then needed to catch a flight back to California.”

“Two weeks later, I received a surprise email from Margo saying that she had been talking about me with her student Elaine. The two of them wanted me to come work with them at Harvard for a few years as a postdoc after completing my Ph.D. [...] I was very flattered by her offer, but the opportunity didn't make sense since I had already decided to retire from academia [after graduation].”

“And then inspiration struck again. Since I was in dire need of one more substantive project and thesis committee member before I could graduate, I made the following counterproposal to Margo: Instead of doing a postdoc after my Ph.D., I asked whether I could visit Harvard for four months in the fall of 2011 to work on a project with her. We could submit a paper to a conference in January 2012 and then include that project as the final portion of my dissertation. I also asked whether she could serve as the final member of my thesis committee. [And luckily, she agreed!]”


“I had an amazingly fun and productive four months in Boston as a visiting researcher at Harvard. The change of scenery was refreshing: I could focus intensely on research without the usual errands of life back home.”

“I took a pragmatic approach to my brainstorming since I wanted [Margo] to be excited about my project and to strongly support its inclusion in my dissertation. Thus, I read some of her recent papers and grant applications to get a sense of her research philosophy so that I could cater my ideas towards her tastes. By now, I understood the importance of aligning with the subjective preferences of senior collaborators (and paper reviewers), even when doing research in supposedly objective technical fields.”

“After batting around a few ideas, I came up with something that Margo loved: a tool that monitors researchers' computer-based activities and helps them organize and take notes on their experiments. [...] Margo jokingly suggested the temporary codename “BurritoBook” to describe our proposed tool, since it seamlessly wraps many layers of activity monitoring around the user's normal workflow. Elaine later shortened the name to “Burrito,” which grew on me and eventually became the official project name.”


“In early November 2011, I turned into a programming beast for the final time in grad school to transform my Burrito idea into a working prototype. I did 72 consecutive days of programming with only 5 days of breaks spread intermittently throughout the 2.5-month sprint. This period was the longest I had ever sustained an almost-painful level of nonstop intensity thus far.”

“For those few months, I morphed into an antisocial grump who shunned all distraction and became deeply immersed in my craft. All I thought about was computer code; I could barely speak in coherent English sentences except during my weekly progress meetings with Margo. Even though I appeared and acted subhuman (i.e., an unshaven disheveled mess), my emotional state was blissful. I was programming and debugging for over ten hours per day, but my mind was quite relaxed since my technical skills were well-calibrated for the challenges I faced.”

“By mid-January 2012, the Burrito prototype was in fine shape, so we ran an informal evaluation, wrote up a paper, and submitted it to the conference as planned. I took a few days off to return to normal human mode, said goodbye to my Boston friends, and flew back to California for the Ph.D. endgame.”


“I took a highly entrepreneurial approach to my Ph.D.—opportunistically seeking out projects and collaborators, walking a fine line between being unconventional and conforming enough to get my papers published. I feel extremely lucky to have been able to take charge of my Ph.D. career in creative ways; I wouldn't have had nearly as much freedom without the fellowships that funded five out of my six years at Stanford.”

“In the end, like most Ph.D. dissertations, mine expanded the boundaries of human knowledge by a teeny microscopic amount. The five prototype tools that I built contain some interesting ideas that can be adapted by future researchers. In fact, I will be honored if future researchers cite my papers as examples of shoddy primitive hacks and argue for why their techniques are far superior. That's how research marches forward bit by bit: Each successive generation builds upon the ideas of the previous one.”


“So why would anyone spend six or more years doing a Ph.D.? Everyone has different motivations, but one possible answer is that a Ph.D. program provides a safe environment for certain types of people to push themselves far beyond their mental limits and then emerge stronger as a result. For example, my six years of Ph.D. training have made me wiser, savvier, grittier, and more steely, focused, creative, eloquent, perceptive, and professionally effective than I was as a fresh college graduate.”

“Here is an imperfect analogy: Why would anyone spend years training to excel in a sport such as the Ironman Triathlon—a grueling race consisting of a 2.4-mile swim, 112-mile bike ride, and a 26.2-mile run—when they aren't going to become professional athletes? In short, this experience pushes people far beyond their physical limits and enables them to emerge stronger as a result. In some ways, doing a Ph.D. is the intellectual equivalent of intense athletic training.”


“Some aspects of the Ph.D. experience were very fun: Coming up with new ideas was fun; sketching out software designs on the whiteboard was fun; having coffee with colleagues to chat about ideas was fun; hanging out with interesting people at conferences was fun; giving talks and inciting animated discussions was fun; receiving enthusiastic emails from CDE users around the world was fun. But I probably spent only a few hundred hours on those activities throughout the past six years, which was less than five percent of my total work time.”

“In contrast, I spent about ten thousand hours grinding alone in front of my computer—programming, debugging, running experiments, wrestling with software tools, finding relevant information, and writing, editing, and rewriting research papers. Anyone who has done creative work knows that the day-to-day grind is rarely fun: It requires intense focus, rigorous discipline, keen attention to detail, high pain tolerance, and an obsessive desire to produce great work.”

“So, Was it fun? I'll answer using another F-word: It was fun at times, but more importantly, it was fulfilling. Fun is often frivolous, ephemeral, and easy to obtain, but true fulfillment comes only after overcoming significant and meaningful challenges.”

Donate to help with web hosting costs

Created: 2013-06-29
Last modified: 2013-06-29