Part 1: Travelling minds #
In the last post I promised to share some more information on techniques I came across and found useful under an
increasing work load. Instead of taking a close look at my professional calendar I decided to use my private one as an
example - first because spare time is even more precious then working hours, simply because there is so few of it and
secondly because I am free to publicly scrutinize not only the methods for keeping it in good shape but also the
entries in it.
I am planning to split the article in four pieces as follows as keeping all information in one
article would lead to a text longer then I could possibly expect to be read from beginning to end:
|
Several years ago, I had no problem with tasks like going out reading a book for hours, working on code for hours, answering mails only from time to time, thinking about one particular problem for days. As the number of projects and tasks grew, these tasks became increasingly hard to accomplish: Writing code, my mind would wander off to the mailing list; when reviewing patches my mind would start actually thinking about that one implementation that was still lingering on my hard disk.
There are a few techniques for getting back to that state of thinking about just one thing at a time. One article I found very insightful was an essay by Paul Graham. He gave a pretty good analysis of thoughts that can bind your attention and draw them away from what should actually be the thing you are thinking about. According to his analysis a pretty reliable way to discover ideas that steal your attention is to observe what thoughts your mind wanders to when you are taking a shower (I would add cycling to work here, basically anything that lets your mind free to dream and think): If it is not in line with what you would like to think about, it might be a good time to think about the need to change.
There are a few ways to force your mind to stay “on-topic”. Some very easy ones are explained in a recent blog post on attention span (Thanks to Thilo for the link):
- Organising your virtual desktops such that applications are
sorted according to tasks (one for communication, one for coding project x, another one for working on project y) helps
to switch off distraction that would otherwise hide in plain sight. Who wants to work on code if TweetDeck is blinking
at you next to your editor? In contrast to the original author I would not go so far to switch off multiple monitors:
Its great to have your editor, some terminals, documentation in the browser open all at the same time in one workspace.
However I do try to keep everything that has do with communication separate from coding etc.
- Train to work for
longer and longer periods of time on one task and one task only: The world does not fall apart, if people have to wait
for an answer to your mail for longer than 30min - at least they’ll get used to it. You do not need to take your phone
to meetings: If anything is starting to melt down there will be people who know where you are and who will drag you out
of the meeting room in no time. Anything else can well wait for another 60min.
- When working with tabbed
browsing: Don’t open more tabs then you can easily scan. You won’t read those interesting blog post you found four
weeks ago anyway. In modern browsers it is possible to detach tabs. That way you can follow the first hint of keeping
even the web pages sorted on desktops according to activity: You do not need your time tracking application next to
your editor. Having only documentation and testing application open there does help.
- Keep your environment
friendly and supportive. Who has ever shared an office (or a lecture at university back when I was a student) with me
knows that close to my desk the probability of finding sweets, cookies, drinks and snacks approaches one. Being hungry
when trying to fix a bug does not help, believe me.
One additional trick that helps staying just focussed enough for debugging complex problems is to make use of systematic debugging by Andreas Zeller (also explained in Zen and the Art of Motorcycle Maintenance). The trick is to explicitly track you thoughts on paper: Write down your hypothesis of what causes the problem. Then identify an experiment to test the hypothesis - you should know how to use your debugger, when to use print statements, which unit tests to write and when to simply take a very close look at the code and potentially make it simpler for that. Only when your experiment confirms that you have found the cause of the problem you really have identified what you need to fix.
There are a few other techniques for getting things off of your head that are just there to distract you: If you ever have read the book “Getting things done” or seen the Inbox zero presentations you may already have an idea of what I am hinting at.
By now I have a calendar application that works like a charm: It reminds me of meetings ahead of time, it warns me in case of conflicts, it accepts notes, it has an amazing life span of one year and is always available (provided I do not forget it at home):
For week to week planning we tend to use Scrum including a scrum board. However that is not only for planning as anyone using Scrum may have expected already.
For my inbox the rule is to filter any mailing list into its own folder. Second rule is to keep the number of messages in my inbox to something that fits into a window with less than 15 lines: Anything I need for further reference (conference instructions, contacts, addresses that did not yet go into my little blue book, phone numbers not yet stored in my mobile phone) goes into its own folder. Anything that needs a reply is not allowed to stay in the inbox for longer than half a week. For larger projects mail gets sorted into their own project folders. Anything else simply goes to an archive: There are search indexes available, even Linux supports desktop search, search is even integrated in most mail clients. Oh and did I mention that I managed to search for one specific mail for an hour just recently, though it was filed into its own perfectly logical folder - simply because I had forgotten which folder it was?
To get rid of things I have to do “some time in the near future but not now” I keep a list in my notebook - just so my mind knows the note is there for me to review and it knows I don’t forget about it. So to some extend my notebook is my personal swap space. One thing I learnt at Google was to not use loose paper for these kinds of notes - a bound book is way better in that it keeps all notes in one place. In addition you do not get into danger of throwing notes away too early or mis-place them.
The only thing missing is a real product backlog that keeps track of larger things to do and projects to accomplish - something like “I really do need to find a weekend to drive these >250km north to the