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:

    • You've asked for it two weeks in advance of the deadline.
    • You've given me all of the information you have about what is expected in the letter.
    • You've shared with me why you need the letter.
    • You've explained why I'm one of the best people in your network to write the letter.
    • 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, what would I even say in the letter? "They were in my class, but I don't know them?" If you're in that situation, I would love to get to know you, but if I spent the time to do that with every student who asked for a letter, I would probably be spending more than a dozen hours a week meeting with students just to write letters. I definitely cannot do that; I have too many other responsibilities in research, teaching, and service.

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


    Copyright Amy J. Ko. See this site's GitHub repository to view source and provide feedback.