On the one hand, I'd like to produce a few graphs every week so my project can move forward. Taking a month off to learn a new programming language, do a literature review, or work through a relevant textbook would hurt the pace of my research, and my advisor would wonder why I haven't done anything for a month.

On the other hand, if I take time off to learn a new skill, it may make my research faster and more efficient in the future.

What is the best way to balance these competing demands?

  • 11
    Why do you need to take time off to learn a new skill? Can't you do both at once (i.e., N% of working time on primary research and 100-N% of time on learning new skills)?
    – ff524
    Dec 7, 2014 at 20:39
  • 6
    Read on the bus, in the bathroom, or during lunch. Learn a new language of Fridays. (aka, what ff524 said). Dec 7, 2014 at 20:48
  • 7
    @ff524 Sometimes easier said than done. The question gives examples in a computational context, but as an experimentalist, I often find that doing a new kind of experiment takes me 5-10 times as much time as doing a familiar one (that is inferior but within my comfort zone). A major factor when experiments can take hours, or even days to complete!
    – Superbest
    Dec 8, 2014 at 4:33
  • Your research progress is measure by the number of graphs produced? Curious.
    – Raphael
    Dec 9, 2014 at 17:36
  • Teach it. Arrange a seminar on the method, this will force you to learn it and to organise it in your mind. Practice will come by using it, but overview is what you need in the initial time, to make the most out of it. The good thing is that, if it is not really important to you to make a seminar out of it, you know automagically that you do not want to spend time learning it systematically. Apr 14, 2016 at 8:49

4 Answers 4


A common fallacy I observe in students I supervise is that they think they need to spend some time "learning X" before they can use X productively in their research.

If you are doing research, the most efficient way to "learn X" (where X is a programming language, methodology, or subject area, that may be of use in your research) is almost always to learn it by immediately applying it directly to your research.

In other words, I tell my students that if they are "taking time off" to learn something before starting to use it in their work, they are doing it wrong.

I would give the same advice to you: instead of taking time off to learn a new skill, start applying it to your research right now. You might be a little slower than usual for a couple of weeks (because you aren't comfortable with the new skill yet), but you'll still be making forward progress on your research, while learning the new thing.

Edit: This applies even more if the thing you are learning is a fundamental skill, and not an "extra" technique. Fundamental skills include things like writing readable code, scientific writing, keeping good notes, etc. The best way to learn these things is to actively and consciously work on them as you do research. It's not generally effective to take "time off" to read some books, then go back to doing research and start practicing the things you read about.

If it's a new skill that can't be directly applied to your research, then you definitely shouldn't take time off to learn it. But you might consider spending time on it during intervals of downtime. You can't spend 100% of your working time on your primary research anyways (mental fatigue sets in at some point), so spend time learning the new skill when you need a break.

  • 31
    I disagree with this advice for the specific case of learning programming languages. The problem is that each language comes with a mental mind-set and some idioms. Without acquiring those, code will read like a mechanical translation from some language the programmer already knows. I always learn a programming language by first working through a beginner book or tutorial, before trying to write any code I intend to keep. Dec 7, 2014 at 21:55
  • 24
    I agree with @PatriciaShanahan here. The mentality of "just do what works right now, forget about doing it right" is why astronomy is plagued by IDL and unusably terrible code. Research code doesn't have to be as shiny as enterprise software, but in the long run the field is harmed by having people learn bad techniques, which is what the mentality you suggest leads to. Researchers do not work in vacuum, and creating a research code that even your own collaborators can't understand is less than worthless.
    – user4512
    Dec 7, 2014 at 22:05
  • 5
    @ChrisWhite I don't think "writing code that others can understand" requires taking a month or two off from doing research to learn how. Writing readable code is different from writing idiomatic code for a particular language, which is what Patricia is referring to. Skills related to writing decent, readable, re-usable code are not usually language-specific.
    – ff524
    Dec 7, 2014 at 22:07
  • 8
    I cannot stress the first paragraph enough. The most striking case I have seen is "I cannot use the printf function in MATLAB to round the numbers until I know C, because it comes from C".
    – Davidmh
    Dec 7, 2014 at 23:31
  • 15
    Am example where @ff524 advice would not work is for example learning functional programming when you have been using imperative languages for the most part. This is precisely the reason why so many people struggle with Haskell, i.e. they jump into it thinking they can make it work without understanding the whole shift in paradigm.
    – RJ-
    Dec 8, 2014 at 5:31

I think this is an instance of a more general problem, of trading off short-term efforts to hit particular milestones vs. longer-term investments. Those longer-term investments might be learning a new skill, but might as easily be organizing your thoughts, refactoring a code base, improving your work environment, hunting through the literature, etc.

When you can do both at once, it's ideal, but often that's not the case. If you focus on the short term, you end up in danger of neglecting the forest for the trees. If you go for the long term, you might end up engaged in some serious yak shaving.

I personally struggle with this quite a bit, especially when you also consider the additional responsibilities of writing papers and pursuing grants. The best solution that I have found so far is essentially duty cycling. On any given day, I will decide which task is my primary goal for the day, and just keep switching to make sure that neither short-term nor long-term is getting unduly neglected.


This is something I think about a lot as well. Even if you learn new things while doing research, you will still be slower and there are always things you want to learn that aren't directly connected to your ongoing projects.

I asked my advisor about this trade-off once and his recommendation was to do enough work to get to the next stage (ie do enough as a grad student to get a good post-doc, enough as a post-doc to get a faculty job) and then spend the rest of your time learning and thinking about new things. I'm actually quite fond of that answer, but the key is in knowing how much is enough!

  • 2
    Excellent advice! I think the key is to keep a check on the learning direction on the new skill, and, time and again asking if I have already learned what I needed for the current job.
    – Sundeep
    Dec 8, 2014 at 14:02

Have other people review what you produce.

Learn by doing is wonderful when it works but if you don't show your work to others you're trusting the judgment of someone who actually doesn't know what they're doing aren't you? :)

In the agile world of software development the typical time box is two weeks. Produce something (in your case a graph) in two weeks then subject it to review by other people. If it fails you go back and fix it. Otherwise move on to the next graph. Learn what you need to know to make each thing as you go. Sure, your first few graphs will suck compared to your later ones but worry about that when you're sure you can do better AND you have time.

You can fiddle with the two week time box but keep in mind that the more time you have between reviews the more rope you've got to hang yourself with. It really stinks to spend two months making something only to be told its worthless or already exists. You can try to make the time box smaller. The risk there is that your reviewer will get sick of helping you if you ask for reviews to often.

Neat trick here is that almost everyone can be effective as a reviewer even when they aren't an expert in what you are doing. So you can take your work before many people to get feedback so long as you can get them interested.

This way you get results and learn as you go. You will learn mostly what you need to know to finish that project. If you are feeling the need to take time off to learn new skills then what you're really asking for isn't time off. It's another project. One that needs those skills.

Sometimes a project runs you into an area where your skill set is weak. That's bound to happen eventually. You can respond by panicking and putting everything on hold while you fill in your skill set or you can get some help from someone and create a plan to learn and create just what you need to get back to your project.

If, say, you want to learn something (that helps you make graphs) then great, what are you going to make while you learn it? If you can't produce a graph in two weeks what can you produce? Break the problem down until the first chunk is something you're confident you can do in two weeks. Whatever it is you should also find a way to test it. If it's a language, and you've made something that works, you can get it peer reviewed at https://codereview.stackexchange.com/. So yeah, you're right back into that two week time box. When times up you darn well should have made something to show someone.

Sometimes you just need some more freedom to explore. A long demanding project can become a tyrant in your life. It will force you to learn what it needs, not necessarily what you find interesting. Taking time away from it and working on something related can be good to help you refresh but don't fool yourself into thinking you're accomplishing something while doing this. At most you're just learning something.

I've been programming professionally in Java for about 4 years now. You might think I'd be done learning it by now, but no, I haven't. I've been programming in some language or another for decades. You might think there is some language that I'm done learning, but no, there isn't.

I'd hate to think what would have happened if I waited to be done learning a language before producing something in it. Probably not a career.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .