Are you a K-12 teacher interested in research next summer? Fill out our interest form.
Maybe. All of the following must be true before I commit to writing you a letter:
For many students, this is easy to satisfy. For example, postdocs, doctoral students, and undergraduate researchers in my research lab easily satisfy all of the criteria above. They don't even need to ask if I'll write; it's a given. But I receive many requests from students I've had in classes that I've never talked to. In these cases, I'd have nothing to write in my recommendation.
If you satisfy these requirements, write me with the following:
There are some exceptions to the policy above. If the "letter" you need is really just a form that I fill out attesting that I had you in class, I'm happy to do that. If you just need a reference for a job, I'm happy to be a reference; I rarely get called, and when I do, it's rarely onerous. And if you're a student in one of our lablets, there are specific conditions for earning a letter.
I think of Computer Science and Informatics like we think about Physics versus Engineering: the former concerns itself with a phenomenon as it occurs in nature and the latter is concerned with applications of it for humanity. CS fundamentally asks what is computing, what can be computed, how can it be computed. Informatics fundamentally asks what should be computed, how should computation be used, what role does computing play in society. If you find computing intrinsically interesting and wouldn't mind talking about it endlessly, CS is a great major for you. If you just want use it as a tool to solve the world's problems, Informatics is a great major for you. Some people are interested in both. Maybe that's you! Both are competitive majors, both lead to wonderful jobs, and both will teach you a lot about the world, one from the perspective of computing, one from the perspective of people and society. Both perspectives are necessary and valuable.
You can read more about my view of information and computing in a blog post I wrote about big ideas about information.
Shriram Krishnamurthi has a wonderful guide on Getting a Computer Science PhD. It's focused on CS programs, but much of the advice is good for any discipline.
There are many resources on this. Matt Might's advice has a sobering but practical look, including a fun visual metaphor of what it means to do a PhD. I also like Jennifer Rexford's view of Ph.D. life as individual growth by leveraging the group, because it complements more pragmatic views. The Economist also has some practical advice on Why doing a PhD is often a waste of time. And, for a lighter glimpse into Ph.D. life, there is always Ph.D. comics.
Learning to do research is hard! Developing good questions is just one of the many challenges in research. I wrote a book chapter that covers many aspects of developing good research questions. I use the same practices with the students in my lab.
I advise a lot of doctoral students, but also advise a lot of faculty who advise doctoral students, and one of the most common areas of concern that comes up is how to do co-advising well. I wouldn't say I'm an expert on this, but I do feel like I know the challenges that arise. Here are the questions I think are key for everyone in a co-advising situation โ co-advisors and co-advisees โ to have shared agreement on:
What other questions do you think are important to answer?
When writing and reviewing scientific papers, there are a lot of mistakes one can make. Several have written helpful guide:
My Ph.D. students often ask me whether they should accept a paper review request. Here's some of the advice I give them for doing or not doing it:
Reasons to do it:
Reasons not to do it:
I often get questions from researchers asking for help to design studies to evaluate the developer tool what they've built. I could write a whole book on this (and several people have, just not on the topic of CS research).
For my part, I wrote a journal paper that walks through several practical details of evaluating developer tools:
Several of my colleagues in software engineering and programming languages also wrote a well reasoned analysis of claims in evaluations called The Truth, The Whole Truth, and Nothing But the Truth: A Pragmatic Guide to Assessing Empirical Evaluations. This is a great lens through which to evaluate the validity of your evaluation.
Casey Fiesler has a helpful blog post about this decision. My own policy is to pay for open access if I believe it will actually increase access to audiences without digital library access. I always post a copy on my website so that search engines can find it.
Last updated 12/22/2024. To the extent possible under law, Amy J. Ko has waived all copyright and related or neighboring rights to the design and implementation of Amy's faculty site. This work is published from the United States. See this site's GitHub repository to view source and provide feedback.