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

Getting Past Superficial

How to generate and implement creative ideas
To generate and implement creative ideas in any field, one must first work hard for many years to reach the frontier and then build up enough momentum on a project to burst through it.

Here is something that all experts in creative fields understand but rarely articulate to novices: The only way to generate and implement truly creative ideas is by first doing a ton of work in a given field.

Memes such as the ten-thousand-hour rule, deliberate practice, and my favorite Ira Glass quote all emphasize that it's impossible to become an expert in any cognitively-complex craft without first putting in a ton of work.

But how does sheer quantity of work translate into originality of creative ideas? The strawman counterargument is that, heck, I can spend ten thousand hours drawing stick figure doodles in my notebook, but that doesn't magically turn me into Picasso!

This article attempts to explain how quantity can lead to creativity. I will use personal examples from academic research in computer science, but the ideas should generalize to other creative fields such as art, design, writing, and engineering.

Three phases on the path to creativity

It took me five years of serious effort before I could start generating my own research ideas that were original and substantive enough for acceptance by the academic community in the form of peer-reviewed publications. I went through three phases to get here, and many of my colleagues did as well:

  1. Dreaming in a vacuum
  2. Generating ideas from existing papers
  3. Building momentum from my own work

Phase 1: Dreaming in a vacuum

I worked as an assistant on research projects throughout college and never worried about contributing creatively. However, during the summer before my senior year, I started generating ideas that I wanted to pursue for my senior project and eventual master's thesis.

Since I was interning as a software engineer at the time, I wanted to invent new tools to make the programming and debugging process less painful. So throughout that summer, I sketched out a bunch of cool-sounding ideas while daydreaming at the office. I must have read some research papers but didn't do a systematic literature review.

Back then, my idealistic conception of research was that I could just dream up whatever neat ideas came to mind, implement some of them, have invigorating intellectual conversations with professors while sipping cappuccinos, publish a paper, earn my master's thesis, and then profit! (Well, maybe not profit.) In short, I was just dreaming in a vacuum.

Dreams are fun until they get crushed by reality. When I started my senior year in Fall 2004 and met with my thesis advisor, he humored me for almost two hours listening to my project ideas. And then he strongly hinted that I should just continue working on my currently-assigned (and grant-funded!) project, implementing some vital extensions that he had been discussing with his grad students.

Even though I was disappointed that I couldn't implement my own creative ideas yet, I suppressed my ego and grinded hard for the next two years. Luckily, this decision turned out well: My project led to my first two academic publications, a master's thesis that won the annual MIT Computer Science Master's Thesis Award, admissions to top-tier Ph.D. programs, and two graduate fellowships (NSF and NDSEG) that funded five years of my graduate studies and bought me the freedom to work on my own creative ideas. If instead I had stubbornly insisted on implementing one of my self-generated ideas for my master's thesis, there was no way that I could have gotten any papers published or accepted into grad school with fellowship funding.

I'm embarrassed to share those ideas now, since they're so lame and cringe-worthy. In retrospect, I give my advisor a lot of credit for his patience in humoring me during that initial pitch meeting; he must have wanted to double facepalm the entire time.

Before anyone can develop and implement truly creative ideas, they must first reach a frontier that borders on the unknown in a given field. Beginners are nowhere near that frontier. For example, when I was an undergrad research assistant, any ideas I generated were unoriginal and well within the confines of what thousands of other people just like me could dream up while sipping lattes and doodling away in their Moleskine notebooks. Back then, I was so far away from the frontier that I couldn't even see it. There was no way of getting past the superficial just yet.

Phase 2: Generating ideas from existing papers

When I started my Ph.D. in Fall 2006, I felt that surely I must now be ready to implement my own creative ideas. After all, I had already paid my dues for two years and won graduate fellowships that funded me to work on whatever I wanted without being tied to any professor's project-specific grants. Now was my time to shine!

I wasn't so naive as to completely dream in a vacuum this time around. Instead, I printed out over a hundred papers related to software engineering and debugging tools, read them in varying amounts of detail (while consuming many lattes at local coffee shops), scrawled a ton of margin notes, and brainstormed new ideas to improve upon the work presented in those papers. After all, that's what research is, right? Taking existing work and incrementally improving upon their ideas? I was starting to feel like a real researcher now.

But there was one big problem: I wasn't actually building anything. I was still just dreaming up ideas, although my current dreams were a bit more grounded in the research literature. Reading hundreds of papers was absolutely necessary to bring me to the frontier of knowledge in my field, as Matt Might illustrates:

But I eventually discovered that it's impossible to make even a small dent in that frontier without lots of additional hard work; it's like trying to break the sound barrier.

So why is it so difficult to take ideas from an existing paper and extend them in creative ways? Three main reasons:

  1. The paper is only a tiny superficial sliver of the final outcome of a particular research project. Just from reading the paper, you develop no intuitions about the thousands of hours of trial and error, experimentation, and tweaking that went into producing that paper. You know who does? The people who wrote that paper! Who is in a better position to extend that work in meaningful ways – you or them?

  2. Even if you received a brain-dump of the paper authors' experiences, you still don't have the code, data, or equipment necessary to build upon their project. Sure, some researchers share code and data, but it's hard for even the most well-intentioned researchers to make their artifacts available in a form that others can readily build upon. For every project like LLVM, there are thousands of tarballs of uncompilable junk tied together by virtual duct tape. What about reimplementing their ideas from scratch? It will take you thousands of hours before you can reach the same frontier that they already reached; by then, you will be too exhausted to innovate.

  3. By basing your ideas off of an existing paper, you greatly constrain your creative potential. You will inevitably generate ideas that are incremental tweaks rather than original new initiatives. No matter how hard you try, your mind will be heavily influenced by what you've been reading. This is perhaps the most pernicious effect of reading too many papers – your thinking gets too constrained by what other people have done, and you lose your creative edge. (Of course, you still need to read a lot of papers to understand the state-of-the-art in your field, but just don't go overboard.)

Running head-first into this barrier is one of the most frustrating parts of being a junior researcher. You're right at the edge of the frontier but unable to step even a bit beyond it.

Most Ph.D. students get stuck at this phase for two to four years; I was no exception. But it's not like I was only reading papers for four years without doing any actual work, though. I tried implementing lots of little prototypes, running experiments, and making tweaks to existing projects by downloading and modifying their code, all to no avail.

The breakthrough moment came for me – and for many of my colleagues – when I gained the confidence to stop letting my research thinking be dictated by what other people have done.

Phase 3: Building momentum from my own work

The first research idea that I wholly initiated, implemented, and published was IncPy. I started working on it at the beginning of my fourth year of Ph.D., five years after that awkward meeting where I pitched those lame dreaming-in-a-vacuum ideas to my undergrad advisor.

How did I come up with the idea for IncPy? It wasn't by reading old papers and brainstorming ways to incrementally improve upon them. Rather, I generated ideas based on my gut intuitions developed from working on various research projects over the past couple of years. Wait a minute ... wasn't I just dreaming in a vacuum again? The crucial difference here is that I was now near some frontier of research knowledge, so my ideas at least stood a chance of being creative enough to be considered novel academic research. However, I had no idea whether IncPy would finally be my first success or yet another failed prototype. But there was no way to find out unless I dived in to actually implement it. Read Year Four: Reboot of The Ph.D. Grind for more details.

When I began the IncPy project, the initial idea had some potential for originality, but it wasn't thrillingly creative. However, as I gained more momentum by building the IncPy code base week after week, month after month, I was able to develop more creative and non-obvious insights.

Like all aspiring researchers, I realized that only by immersing yourself into a project can you begin to generate ideas that are more substantive than what curious bystanders can brainstorm on a whiteboard with absolutely no context. If somebody can just dream up your idea in a vacuum, then it's probably not very original. Your own project is your best platform for developing in-depth expertise, for getting you past the superficial when generating new ideas.

External interactions were another source of creativity: Throughout a 1.5-year period, I gave several talks on my fledgling IncPy prototype to various research groups, chatted informally with even more colleagues to solicit their feedback, took tons of notes, and read papers on related research projects that they recommended to me.

Unlike my meandering paper-reading sessions from the early grad school days, reading now had a ruthlessly practical purpose: I was no longer generating ideas to extend other people's projects, but rather looking for other people's ideas to graft onto my own project. Like an ever-growing Katamari, IncPy gradually picked up more and more steam by piling on the best ideas from discussions and paper reading ...

... until it finally reached a bit beyond the frontier into the uncharted territory of novel academic research. After almost two years of grinding, the IncPy paper was published in the middle of my fifth year of grad school.

I bet that every researcher, artist, writer, designer, and other creative professional remembers their first Katamari moment.

Parting Thoughts

Okay, this article is a bit unsatisfying since it doesn't teach you how to reach your Katamari breakthrough moment. It feels like:

I don't have a magic recipe for sparking creativity. All I know is that it's impossible to generate and implement truly creative ideas without first putting in a ton of work to painstakingly fight your way to the frontier of your field.

Unfortunately, the first two seemingly-unproductive phases – dreaming in a vacuum and emulating prior work – are necessary for reaching the frontier. So I encourage all aspiring researchers to dream up lots of fanciful ideas, get genuinely excited by them, talk to people about your ideas without fear of sounding naive, read tons of papers in your field and take copious notes, and keep experimenting and prototyping to get feedback from more experienced colleagues. However, remember that it's normal for everyone to go through several years of futile attempts at originality; there are no shortcuts. So keep grinding.

I'll end with my favorite Ira Glass quote (emphasis mine):

“What nobody tells people who are beginners – and I really wish someone had told this to me ... is that all of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, and it's just not that good. It's trying to be good, it has potential, but it's not.

But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase. They quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn't have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it's normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story.

It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I've ever met. It's gonna take awhile. It's normal to take awhile. You've just gotta fight your way through.”

Created: 2013-11-26
Last modified: 2013-11-26
Related pages tagged as Ph.D. student life:
Related pages tagged as research: