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?
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.
printf function in MATLAB to round the numbers until I know C, because it comes from C".
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!
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.
