Masters or Ph.D?

I just talked to Jeff Erickson last week, and he gave me some very interesting feedback. He said that I am very smart and willing to work very hard, and that I am able to get a lot done, provided that I am give a specific problem to work on. However, the one thing that I haven't shown myself to be abole to do yet is to make independent decisions about which directions to take my research and what are important research problems to work on, and that's what I will need to be able to do to get a Ph.D. He suggested that a better direction is to focus on getting a Masters' thesis first, and then at that point re-evaluating whether I want to continue toward a Ph.D. or just stop there.

The more I think about it, the more I think that a Masters may be the best option for me, for a few reasons:

1. First, one thing about getting a Ph.D. in computer science is that it doesn't actually involve writing that much code; or at least code isn't the primary product. As my advisor said, the main "product" you're producing as a Ph.D. student (and later as a professor) is ideas; code is just the way of implementing those ideas. But I think my specialty isn't necessarily really in developing theory, but more in the combination of math/theory and code. In particular, there are lots of people who are experts in the theory (or who are experts in a specific problem domain, like engineers) but aren't that good at actually writing code, and there are lots of people who can crank out lots of code without really understanding the theory, but I am very good at both understanding the theory and algorithms and translating it into code. So my main niche is to bridge that gap.

2. In particular, when I look at the things that really sound cool to me and "wow, I would really like to be working on this," it's generally not the theoretical stuff; it's more the stuff that involves taking a real-world problem, one not necessarily in computer science, and figuring out how to formalize and understand it in a mathematical context so you can write code to solve it. For example:

2a. At my work at the U.S. Census Bureau, we were studying disclosure avoidance in survey data - that is, how to disseminate data from local level surveys in ways that preserve the statistical patterns in the data but don't allow users to figure out who answered what to any particualr question. This question involves first defining specifically what it means for a respondent's privacy to be preserved (What if an adversary can make a good guess at the missing information but only some of the time? What if an adversary has access to a different database unrelated to the survey that they can combine with that information? Is there a way to prove things about what an adversary can figure out?), then to figure out what algorithms can implement that, then to code and test those algorithms.

2b. I was offered a job at Amazon.com after graduating from University of Maryland, though I chose not to take it so I could go to graduate school. One of the projects they were working on there was figuring out how to optimize their web pages to increase sales - so they had collected all this data about how the page layout and the time it takes to load the page affect users' behavior. Again, we have a practical problem, then there's a step of formalizing the problem (Exactly what function are you trying to optimize? Is it just number of sales, or are other things like which products get sold or how long it takes the user to go through the process also important? How can you determine which changes in output are caused by which factors? What data can be used to shed light on these questions?), figuring out what algorithms can be used to analyze the data, and then implementing and testing these algorithms.

2c. Another example of something I tried to do once was when I was learning how to produce foam tipped arrows for Belegarth (a game in which players dress up as medieval warriors and fight each other with padded replicas of medieval weapons). There are several factors that you need to consider when making the arrow, such as the type of foam to use, the weight of the arrow, how hard or soft the tip is, and so on. My first response was to try to figure out if there was a way to mathematically model what happens when the arrow strikes the target so as to better understand why the design is the way it is and if there is any way to improve it. I did some research and soon concluded that the formulas themselves wouldn't be overly complicated but that the data you would need to calibrate the model isn't readily available. But you can see this is another example of how I like to try to understand a problem by putting it into a mathematical framework.

3. Of course, most of the problems above aren't actually computer science research problems; they're engineering or business problems that have a math/computer science component. But I think that might be the kinds of things I want to work on: to work closely with the engineers or business people to understand what the computational needs are, then go and figure out what computer science techniques can meet those needs*. I talked to Bob Haber about this and he said that if I wanted to actually "do an application" for my Ph.D. thesis, I would essentially have to go back and take some undergraduate level engineering (or physics, or whatever) courses to learn all the field-specific stuff I would need to know to do research in that area. So if I want to do this kind of stuff, it would make much more sense to work at a lab or company than in academia.

So, the plan we have come up with is as follows. I'll work toward a Masters, and at the same time I'll also start looking for internships and jobs elsewhere. Los Alamos National Laboratories and Sandia National Laboratories do lots of scientific computing stuff so they are good possibilities. Then once I get a Masters, I will decide whether I want to stop there or whether I want to keep going.

*Although, I might be naively optimistic as to how much sophisticated algorithmic stuff is actually involved in these types of problems. I am reminded of a professor from University of Maryland (I think it was Bill Gasarch but I'm not sure) who, when he was teaching about job-scheduling algorithms, planned to bring his wife (who worked in a machine shop) in to talk about all the exciting new techniques they use to optimize their scheduling to improve production. He quickly cancelled this plan when she informed him that the actual algorithm they use is "whoever yells the loudest gets their job scheduled first."