As a, by now reasonably experienced, PhD supervisor, students (mine and others) sometimes ask me the question how they can improve their work. Of course the answer to that question varies as much as individuals and their experiences do, but there is one reply I give more than any other:

Read more scientific papers.

Reading papers is great. You learn what the state of the art in a field you are not intimately aware of is, you learn what others are currently excited about (spoiler: right now it’s LLMs), and you invariably improve your own writing skills. Maybe most importantly, I have found that the best way to generate ideas yourself is to read and think about other’s research.

And yet I see that surprisingly many talented PhD students in software engineering do not quite know how to best interact with the existing body of research. Overall, I believe many PhD students make one or multiple of the following mistakes:

Problem 1: “You don’t read enough papers.”

It’s hard to give a specific number of what is “enough”, but overall my impression is that most students would profit from reading more than they do. As a guideline, reading multiple papers per week in an average work week should probably be your normal.

My suspicion why students often don’t read enough is that reading feels like a low “Return on Invest” activity, that there are usually other ways to spend your time that feel more productive in the moment.

But: reading is easy. (Almost) no matter how tired, unmotivated, or distracted you are, you can still read papers. Use reading as a downtime activity when your brain isn’t quite in the state to do the more demanding parts of your PhD.

Problem 2: “You don’t read the right papers.”

Even when students read, I often feel they are not reading the right papers. My recommendation is to read broadly rather than getting stuck in your specific research niche. Personally, I regularly read papers on virtually all topics of software engineering, along with the occasional work in programming languages, distributed systems, or databases. Every now and then I also read in psychology, education, or business. On the other hand, there are plenty of articles in my narrowly defined area of research that I know exist, but have never actually read.

Why? Because I strongly prioritize good papers over relevant papers. I would much rather read a really cool, well-written, thought-provoking article in programming languages than torture myself with a badly-written and/or uninteresting performance engineering piece. A corollary of this is that the likelihood of me actually reading an article is inversely proportional to the article’s length.

Don’t torture yourself with bad papers. Every now and then we all are forced to work through some very confusing piece of research (either because we are asked to review it, or because it is sufficiently close to our work that we just cannot ignore it), but for the largest part — if a paper is not interesting to read, nobody can make you.

If you hate reading or think it’s a huge chore, that’s probably because you are reading the wrong papers.

Problem 3: “You don’t read papers the right way.”

When I talk about “reading” a paper, I rarely mean “study a paper carefully end-to-end.” The goal of reading a paper rarely is to understand 100% of it or memorize the results. Instead, focus on the main take-aways, ideas, storylines, writing styles, what datasets are being used, what methodological approaches authors take, or what visualizations they use. Any interesting paper, even from a different domain, will have something that you can take with you for your own work.

Feel free to glance over sections that you don’t find so relevant (interestingly enough, for me this often means that I read the introduction and method, but then entirely skip the actual results — turns out I was more interested in how they planned their experiments and some high-level findings, but did not care all that much about their detailed numbers). If no section in the paper seems particularly appealing, skip the entire paper. There is nothing wrong with opening an interesting-sounding paper only to close it again 5 minutes later — I do it all the time myself. Authors are not owed our time and attention.

Overall, I believe you should learn to be able to go over a paper in an hour or two. If it takes you most of a day to read a paper in an area that you have at least some prior knowledge in, you will inevitably fall behind in your reading and start resenting it.

Also, don’t batch your reading. Doing a “literature review” where you spend a month doing nothing but reading every day is much less valuable than checking out a few papers every week, next to your own experiments and writing. Papers crammed in a literature review will invariably start blending together in your head, and a short time later you will not remember specifics about any of them.

One thing that is important: after reading a paper, take the time to reflect on what you have learned. Ideal would be to discuss the paper with a colleague or supervisor, but that’s often not possible. Honestly, I often talk to myself about interesting papers I read, and that seems to work (almost) as good as discussing the paper with colleagues. However, as we know from didactics, without any form of repetition you will struggle to retain much of what you have read.

In the end, the papers you read will shape the papers you write — so choose wisely, read broadly, and read often. And remember that, just as you do not owe attention to anything others have written, your papers are not owed attention purely by existing, either.