Be More Productive: Avoid Task Switching
not-implemented.com
not-implemented.com
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.
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.
While I agree that it's a problem, reducing waiting is the best solution for me.
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).
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.