In one week, I will be moving on to Blue Frog Gaming from Micros Retail. Everything tells me this will be a transition to a much calmer environment. Now is probably one of the last chances I have to record the big lessons I’ve learned about working in a stressful task-switching environment.
The Problems
Task Confusion
If you work on lots of similar tasks, especially if they are sometimes yanked out from under you while you work on them and replaced with other similar tasks, they start to run together. You remember that you just fixed a timeout issue that was reported by - who was that, that you worked on this morning? The Flarg Shoppe project? No, you did that yesterday. But the timeout fix was certainly on the Quux module, and only Flarg and Butterford use that module. Wait…
Splattered Attention Span
Your brain can only handle so much task switching. As you task switch more, each context transition becomes more fragile, and you can have a "bad switch". For me, a "bad switch" results in a complete loss of context - a short term memory wipe where you have to reboot and rebuild your current memory state.
Morale Shutdown
We know that task switching has negative affects on short-term memory. We also know that we do not accomplish more by trying to do multiple things at once. It might be difficult to convince management of this, but you might just get through. But sometimes, management finds this is necessary for political reasons anyway. (It actually serves a purpose for management - they can point to their actions and show that the failure doesn’t stem from the Socially Worst Sin Of Management - Inactivity In The Face Of A Problem. It is actually much more difficult to defend against an accusation of inactivity than an accusation of failure. But don’t get all high-and-mighty when you realize this - it’s the same reason we coders pull extra hours on a late and doomed project.)
But there is a point - for me, usually by the fourth activity yanked out from under me in one day, preventing me from accomplishing anything because everything is important - where Complete Morale Shutdown occurs. My brain has checked out, turn up the headphones, open Eclipse. Don’t forget to scroll the code window every few minutes until 5PM.
Stress Body Buzz
This was the worst. I’ve only had this maybe three times, and I get very worried that this has a big negative affect on health. I’ve walked out of the office literally unable to calm down. On the worst occasion, I called my doctor on Sunday because I still hadn’t recovered from Friday.
I’ve found that an extremely rigorous bike ride can greatly speed recovery.
The Solutions
Work on the Big Problem
The first lesson, of course, is that frequent task-switchng doesn’t really improve throughput or profitability - and most certainly destroys it - so seek to remove the fundamental underlying issues. This, of course, takes time and management involvement and systems thinking, and there probably aren’t any standard solutions to this problem.
The rest of this article is about interim fixes that you will need while you work on the big problem.
Turn Off E-Mail Alerts
Do you really think you’re going to forget to check your e-mail? Really?
If you can arrange it, steal time by closing e-mail and telling your manager to physically get you if something really requires immediate attention.
Use Tactile Reminders
If you work on multiple tasks in one day and they are similar, it is very easy to become confused which task for which customer you are working on. Tactile reminders such as Post-It(r) notes or index cards that you move around are very useful for this purpose. They are invaluable for rebuilding memory state during a Splattered Attention Span reboot.
Make TDD Fail
TDD in any form is a big help when coding. In a normal environment it adds a rhythm which keeps momentum from leaving, but in a frenetic environment it keeps you on task. Can’t remember what you were doing before that interruption? Click the "run test" button… ah, that was it.
If you have a research phase to your current task, write a failing test immediately for any requirement discovered. This is a bit different from the normal TDD rules, where you don’t write the next failing test until you’ve passed the last test. In this mode, you collect failing tests when necessary, and commit when they reach zero. Note that zero can still be reached a couple times on one task.
Unless you can just spit out the test’s code in one go, simply make the test fail with the fail() command and a very descriptive test name; otherwise, you are inviting Splattered Attention Span.
Use the Shell’s "&&"
As you thrash your short-term memory, your idea of what is a "long running" command becomes shorter and shorter. Longer than 30 seconds is hard to keep focused. If you need to run multiple steps, you can chain them together with your shell’s "&&" operator. Joining multiple steps reduces opportunity for a context-switch-overload full-stop.
Learn VCS Hygiene
You should become adept at using your version control system from the command-line to inqure about what changes exist. Make it a strong habit to check before coding something new and review all changes before commit. It’s harder to get an overview when you are frequently task-switching.
Use git
Git is wonderful, and it even makes a good SVN client (once you bootstrap it from your SVN repository - which is admittedly painful). Become familiar with with "git stash" - a task switcher’s savior.
Switching between branches (when necessary - running multiple branches is a bad practice when it can be avoided) is also much less painful to the short-term-memory impaired in git than SVN. In git, it is a practically instantaneous operation; in Subversion, it is an assured short-term memory snow crash.
Automate, Automate, Automate
There are many technical investments that you can to reduce the affect of task switching. Multi-step manual processes are much more costly in a stressful environment than other environments, because each step transition invites a high probability of attention-span splatter. Consequently, investing in automation is a big win.
Of course, you are trying to invest in automation in a frenetic environment… how could this work? The answer is that you need to grow these automations from tiny improvements. A few notes I’ve learned along the way:
-
For the most part, you don’t need TDD if it is a process that will be run only by you or other developers and it prints a stack trace on failure.
-
A small batch file that does three sequential things is a big win for a small investment. Use a language that you won’t mind maintaining when it grows into a big, hairy ball.
-
Weigh the possibility of reuse of your application code in your automations. If there is potential, either use the same language as your application code or a scripting language which you can bind to it (e.g. Python/Jython, Ruby/JRuby).
