sometimes you are required to do task switching. Multitasking is something, though mostly misused can actually help when problem solving. Sometimes you need to let your 'other side' of the brain figure things out while you continue doing something else
It's called "cognitive drift" and it's was a critical concern when I was working on medical imaging applications, there have been a number of studies on it including this google match http://www.ncbi.nlm.nih.gov/pubmed/23189449
This is one of the main reasons I find unit testing productive. You can eliminate cognitive drift triggering startup delays in your unit testing framework easier than in your application.
As an academic, often I'm running experiments and have to wait for them to finish. Worse still, sometimes I can't touch my machine whilst they're running.
For a long time, I tried the "don't switch" mentality. But you just waste a lot of time.
Solutions are:
1. Avoid it by running shorter experiments - requires intellectual effort and is much like the advice in the article.
2. Do something else, but something related to what you're doing. That way, it's not a total cognitive switch. Classic example is working out ideas for how you might best present data whilst an experiment is running, or how you might further automate the process etc.
3. If you have to switch, then do something that can easily be dropped. Usually I read a (scientific) paper whilst I wait - this could be vaguely related to the experiments I'm waiting on.
Even if so, as the article notes, if you switch to some other, yet still "productive" task, you are still task switching and losing a lot of momentum on the original task.
Also there will always be distractions; daydreaming if nothing else. At a previous employer my main work machine was not connected to the Internet (a nightmare for other reasons, like if I was on the Internet-enabled machine, may as well check email...). But even then, when waiting for a test that would take several minutes, I'd find myself reading a print newspaper.
These forced delays kill productivity for me like nothing else. Losing the task at hand every couple of minutes to retest or really slows down output.
Recently, though, I've stop listening to most of the "productivity advice" and warnings about multitasking, splitting your time into chunks, and the myriad of other approaches.
The best bit of advice I have heard is just to get on with it, work hard, and stop procrastinating about it. Too much meta is not good.
> Could the university you work for provide you with a second machine whilst the first machine runs experiments?
Sure. They do, in fact. And I use clusters for large experimentation.
However, a great rule of thumb as a researcher is to try to limit yourself to using a single laptop for your work and experiments. One advantage: your development machine and experimental machine are then identical, and they both travel with you. Academics travel a lot.
Funny, I run into the exact same problem on the exact same platform. It's what I dislike most about working in .NET.
One thing I've found that works fairly well is using the Pomodoro technique, where I force myself for 25 minutes to just work. That means even during those 15-30 seconds of compiling I can't load up Hacker News or Reddit. It helps, but it's also a little tough for me to enforce (on myself).
I find that using a Kindle or Android ebook reader really helps avoiding the task switching, as does dual monitors.
Leave your computer on the task you are working on and you won't "lose" the result in a sea of windows.
Actually, it's a great habit to use a different machine for surfing the net than the one you use for developing. Then you are very conscious that you aren't working when you are on your "other" machine.
I'm almost envious sometimes of secure locations that limit internet access to a single room rather than allowing it to be on every desktop.
I find that doing something related to what you're doing is probably the worst thing you can do. Let's say you run your specs and 5 of them fail. You fix #1 and then re-run the spec, then go and fix #2 whilst waiting to see if your first fix is good. You will end up juggling and trying to fix multiple bugs at once, which is a recipe for failure and sadness.
I strongly endorse just staring at the screen whilst waiting.
I think multitasking is very possible, but has to do more with optimizing for the various senses and developing a discipline and habit around repetition (code, push, read, repeat, etc. every 30 min).
I feel bad that I read this while waiting for tests to run. My tolerance for staring at the screen goes down exponentially as the run time of a task increases. And, I think, even staring at the screen allows my mind to wander and lose some of my momentum.
While I agree that it's a problem, reducing waiting is the best solution for me.
I'll often give my brain a break with something like a quick Angry Birds round or Bejeweled Blitz (quick 60 second rounds). Or I'll do a bit of cleaning of my desk.
Well, the client side is compiled by eclipse automatically and the client can be configured for development so that many classes aren't cached so you can test cosmetic changes without a restart.
On the server side however if you add new components, services or introduce new fields in existing entities you have to restart the JBoss and build the changed component.
It is enterprise, I'm working on the market-leading MES (Manufacturing Execution System) solution for the pharma- and biotech area. Our internal framework alone consists of around 3.700 classes.
I do Pomodoro, running tests etc. when I take breaks. And when having breaks, I try to get away from my computer, to just stare out the window, get a fruit, walk around a little, or just lay down for five minutes.
20 comments
[ 75.1 ms ] story [ 394 ms ] threadThis is one of the main reasons I find unit testing productive. You can eliminate cognitive drift triggering startup delays in your unit testing framework easier than in your application.
For a long time, I tried the "don't switch" mentality. But you just waste a lot of time.
Solutions are:
1. Avoid it by running shorter experiments - requires intellectual effort and is much like the advice in the article.
2. Do something else, but something related to what you're doing. That way, it's not a total cognitive switch. Classic example is working out ideas for how you might best present data whilst an experiment is running, or how you might further automate the process etc.
3. If you have to switch, then do something that can easily be dropped. Usually I read a (scientific) paper whilst I wait - this could be vaguely related to the experiments I'm waiting on.
Also there will always be distractions; daydreaming if nothing else. At a previous employer my main work machine was not connected to the Internet (a nightmare for other reasons, like if I was on the Internet-enabled machine, may as well check email...). But even then, when waiting for a test that would take several minutes, I'd find myself reading a print newspaper.
These forced delays kill productivity for me like nothing else. Losing the task at hand every couple of minutes to retest or really slows down output.
Recently, though, I've stop listening to most of the "productivity advice" and warnings about multitasking, splitting your time into chunks, and the myriad of other approaches.
The best bit of advice I have heard is just to get on with it, work hard, and stop procrastinating about it. Too much meta is not good.
Sure. They do, in fact. And I use clusters for large experimentation.
However, a great rule of thumb as a researcher is to try to limit yourself to using a single laptop for your work and experiments. One advantage: your development machine and experimental machine are then identical, and they both travel with you. Academics travel a lot.
One thing I've found that works fairly well is using the Pomodoro technique, where I force myself for 25 minutes to just work. That means even during those 15-30 seconds of compiling I can't load up Hacker News or Reddit. It helps, but it's also a little tough for me to enforce (on myself).
Leave your computer on the task you are working on and you won't "lose" the result in a sea of windows.
Actually, it's a great habit to use a different machine for surfing the net than the one you use for developing. Then you are very conscious that you aren't working when you are on your "other" machine.
I'm almost envious sometimes of secure locations that limit internet access to a single room rather than allowing it to be on every desktop.
I strongly endorse just staring at the screen whilst waiting.
I think multitasking is very possible, but has to do more with optimizing for the various senses and developing a discipline and habit around repetition (code, push, read, repeat, etc. every 30 min).
While I agree that it's a problem, reducing waiting is the best solution for me.
Of course a full build is only needed every once in a while but single components take 1-3 Minutes to build as well.
I usually use the time to get coffee or put together a new playlist (listening to music 99% of the time).
No background compiles? Stable interfaces between classes?
On the server side however if you add new components, services or introduce new fields in existing entities you have to restart the JBoss and build the changed component.
It is enterprise, I'm working on the market-leading MES (Manufacturing Execution System) solution for the pharma- and biotech area. Our internal framework alone consists of around 3.700 classes.