These are questions I'm frequently asked.

Will you write me a letter of recommendation? ๐Ÿ”—

Maybe. All of the following must be true before I commit to writing you a letter:

  • I am one of the best person in your network to write the letter, relative to your other options.
  • You've asked for it at least two weeks in advance of the deadline, preferably one month, so I have time to schedule writing.
  • I've collaborated with you on a project, or if you were a student in my class, I've had multiple conversations about things beyond the scope of a class and its requirements (e.g., in office hours, in research, or other settings).

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:

  • Remind me how we know each other, in case I don't recognize your name.
  • You've shared with me why you need the letter. What programs, jobs, or opportunities are you applying to and why?
  • Provide me with specific details about these collaborations and conversations in case I've forgotten, so I can write a letter that is specific about our interactions.
  • When is the letter (or first letter in a batch) due?
  • If there is a specific location to upload the letter, provide the location. (Most are invitations sent to me that I fill out independently.)

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.

What is the difference between computer science and informatics at UW? ๐Ÿ”—

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.

How do I get into a Ph.D. program? ๐Ÿ”—

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.

What is it like to be a Ph.D. student? ๐Ÿ”—

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.

What makes a good research paper? ๐Ÿ”—

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.

How should coadvising work? ๐Ÿ”—

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:

  • How does each advisor see their role in the student's work and success? Are they compatible? In conflict? Some advisors might see students as people who can accelerate their research focus; others might view them as students who they are mentoring. Others still might view students as collaborators. All three of these perspectives come with different expectations and relationships, and so it's important for co-advisors to come to some shared understanding about them.
  • Who is responsible for the long term funding with the student? Is that fixed or dynamic? This is key, because it shapes who feels responsible for resourcing a PhD students' time, and offering the student certainty about their funding stability.
  • Should both advisors always be a collaborator on a students' work. Or does that depend on the paper and project?. Authorship expectations are wildly different between researchers, so these should be stated and negotiated upfront.
  • When advisors' disagree on how a student should proceed, is it the student's job to reconcile the disagreement?. Are they free to choose without consequence from either advisor? Or is it the advisors' job to come to consensus? Is that done with or without the students' involvement? Everyone should agree on how this happens.
  • When there is interpersonal conflict between advisors, how is a student shielded from that? Or is a student expected to be the mediator? (Not recommended).

What other questions do you think are important to answer?

How can I become a good technical writer? ๐Ÿ”—

When writing and reviewing scientific papers, there are a lot of mistakes one can make. Several have written helpful guide:

I was asked to review a paper. Should I? ๐Ÿ”—

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:

  • You want to read the paper!
  • You need practice critically evaluating papers.
  • You're one of a handful of people who has the expertise to evaluate it. (Academia is small, expertise is rare, it's your duty to volunteer).
  • Early in an academic career, it's helpful to show that you've reviewed for prestigious journals and conferences.

Reasons not to do it:

  • You really don't have the expertise.
  • You've done too much reviewing in the past year and have earned the right to say no.
  • You're an experienced paper reviewer and don't need the practice.
  • You don't have the time due to other reviewing commitments.
  • You're overloaded on other service commitments.

How should I evaluate this developer tool I invented? ๐Ÿ”—

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:


A clip from the paper's PDF.
Amy J. Ko, Thomas D. LaToza, Margaret M. Burnett (2013)
A Practical Guide to Controlled Experiments of Software Engineering Tools with Human Participants
Empirical Software Engineering
Software engineering researchers rarely evaluate new tools with software developers, but there are several best practices that can make such evaluations less risky and difficult to conduct.
โ–ธ cite โ‹… pdf โ‹… doi โ‹… ๐Ÿ”—

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.


CC0 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.