Flow Vs. Distractions
At some time in our lives we’ve probably all felt a sense of absorption when performing a task that borders on euphoria. When in this state we seem to be able to think clearly and effortlessly about the task at hand, we feel like we are outside time and that distractions are lessened. This state is usually referred to as flow and is generally regarded as the optimum state in which to work creatively and efficiently, however for most of us this state is not that easy to achieve or hold onto, usually due to either distractions or motivations (the task is boring). [1]
What is not common knowledge is the true cost of being continually knocked out of a state of flow by distractions during our working day. In fact it is estimated to take on average at least 15 minutes to regain a state of flow after a distraction [2]. If you think about this in relation to a working day, it would only take interruption every fifteen minutes to effectively eliminate any chance of achieving a state of flow that day: this would require 28-32 interruptions or distractions to eliminate productivity over a 7-8 hour working day. This may sound like a lot of interruptions but consider for a moment that most people work in a communal work space e.g, in an office where distractions and interruptions include: email, telephone, co-workers, instant messaging, the internet, meetings, eating etc. It is easy to see how we can end up with days where we achieve very little due to some disruptively timed interruptions, and this can be easily observed by noting which of your co-workers come in early or stay late to ‘get things done’ as they can’t ‘get anything done here 9-5′.
So how can we minimise or eliminate as many of these distractions as possible? Here are some ideas:
- Meetings: Meetings are an essential way of exchanging information and decisions making but they can also be very disruptive to getting things done. The most effective way I’ve found with dealing with meetings disrupting my working day is to book myself for chunks of time I call work blocks. Usually these blocks are for the duration of a morning or afternoon and I will also block off a full day each week plus usually at least two or three smaller blocks. The more I discuss this with more senior and experienced individuals the more widespread I’ve discovered this technique to be, in fact the more senior the person the more likely they are to be using some form of this strategy. Yet most people starting out in industry are not being told about it, which means they are having their days fragmented by meetings which could easily have been scheduled at a less disruptive time.
- Email: First off, if you are in a large company chances are you are on more internal email lists than you need to be. Cull any that are not useful. Next turn off all new email notifications, especially the visual or audio ones, and leave notifications on for messages marked as high priority so when it is truly important you can be contacted quickly.
- Telephone: Your companies telephone system will probably support the ability to set your phone to go straight to voice mail without ringing: use this when you are trying to concentrate during a work block.
- The Internet: Having the internet freely available can be great when you need to look something up for your job, however I’ve found it too distracting at times to get sucked into a infinite cycle of looking things up, especially if what I’m looking up is more interesting than what I’d otherwise have to work on. I’ve tended to combat this by getting my IT department to block my internet connection to non-work related sites from 10:00-12:00 and 13:00-16:00 as I’ve found this the simplest method to break my internet news checking habit and most IT departments will discreetly set this up for you. If I think of something I want to find out I make a note of it and look it up later if it still seems important.
- Instant Messaging: Instant messaging software like MSN Messenger, ICQ, GoogleTalk etc can become very distracting, personally I’ve not had too many issues in this area and if I’m wanting to not be disturbed I either mark myself as ‘Do No Disturb’ (DND) and my contacts respect that or I sign out of the system while I’m working.
- Co-Workers: Interruptions from co-workers can be a very common form of interruptions either with drive by questions or just wanting to chit-chat. There is nothing wrong with this if you’re not in the middle of something but it can be very disruptive if you’re trying to concentrate on something complex. The easiest way to manage this is have some visual que to inform your co-workers of your preference to be interrupted or not. This can include: wearing headphones, a DND sign, closing your office door etc, which I’ve found most people will respect 90% of the time.
[1] Csikszentmihalyi, M. (1990). Flow:The Psychology of Optimal Experience. New York: Harper and Row
[2] DeMarco & Lister (1999). PeopleWare: Productive Projects and Teams. (2nd Ed). Dorset House Publishing; New York.(p.63)
Taking breaks
One of the things that you seldom hear being discussed is the importance of taking breaks from typing and staring at your monitor to prevent overuse injuries (RSI) in your hands, arms and eyes. As a novice programmer I remember thinking it would never happen to me but eventually it did, and although it took a lot longer to happen than it took for most other people I know with RSI it did still happen. Possibly my use of natural/ergonomic keyboards for most of my professional life slowed down the process to some extent. In the end working eight or more hours a day typing and then going home and playing a game like World of Warcraft for hours which also involved lots of repetitive typing was my downfall as it gave my arms/hands no rest apart from when I was asleep.
To prevent me going home in the evening with sore hands I have a two part strategy: the first part is to use high quality ergonomic peripherals like my ergonomic keyboard, with footpedals (at home and work) and a trackball (at work) and graphics tablet (at home). The second part of my strategy is to use programs to monitor my time spent using my keyboard and mouse and to tell me when to take short micro breaks and longer rest breaks from typing or mousing to help give my muscles and tendons a rest.
The two programs I use for this are WorkRave (above screen shot) on my PC at work and Anti-RSI (right screen shot) on my iMac at home. I’d recommend these programs to anyone who is interested in preventing or recovering from RSI like symptoms. The programs are free and of a high quality with the rest periods and intervals fully customisable by the user: I tend to rest for 30 seconds every 3-5 minutes and break for 3 minutes every 30-45 minutes depending on how my hands are that day. Getting used to the micro breaks is the hardest challenge for me, as initially they feel like interruptions to my flow which was quite frustrating but now I try to think of them as a chance to pause and think about what I’m doing which is more constructive.
My eyesight has been spared by my habit of staring off into space when thinking: according to my optometrist the best way to give your eyes a break when working at a monitor for long periods is to stare off into the distance. So my eyesight is still perfect even if it has mostly been by a lucky habit, as I only found out about eye breaks when I got my eyes tested about two years ago. I also tend to avoid white as a background colour in my code editors as I find it is hard to focus on black text on white after a while so I tend to use light grey instead, I also find black on grey easier in low light environments.
Bugs / Source Code
This at least is how it always feels: a mystical 10% of the code base causing 90% of the reported bugs. This makes it very important to identify the 10% of the code that is causing the bugs and then resolve those issues as a matter of priority. Wasting effort on the other 90% of the code base until the problem 10% is resolved will not make a noticible improvement in the product quality.
Explanations
I recently helped a co-worker explain a new concept to another co-worker, as they were struggling to explain it themselves even though they were experienced working with the technology they wanted to explain. This started me thinking afterward about the art of explaining something complicated without leaning on the established jargon for that subject, as the person you’re explaining things to is unlikely to know the jargon either.
During university I worked part time as an IT technician, which I think forced me to deal with explaining things to people without technical knowledge of the concept I was explaining. At first I was surprised at how unsuccessful I was at this and that got me thinking about why. Being able to explain something complicated in a manner where someone who has no technical knowledge can understand, is I think a very important skill to have as these sort of explanations will be required often in most sorts of careers. And often it is those who can communicate most efficiently that succeed more than those that are the most technically proficient, as what use is proficiency or ability if no one can understand you?
The key to becoming good at explanations has a few key parts in my mind:
- Paraphrasing while learning: When learning something new, it is highly beneficial to then paraphrase the new information in your own words. This practice has two benefits: first you will quickly find out if you understand what you’ve just read and secondly it will get you into the habit of thinking about the information using your own terms rather than just the terms in the texts (which is what you’d be doing if you simply memorised the text).
- Limiting your explanation: If you’re anything like me you’ll want to be as helpful as possible when explaining something, as well as exercise your whole range of knowledge on the topic at hand. This is actually the worst thing you could do, as if you think back to when you last learned something you’ll most likely realise you didn’t learn the whole subject in one sitting but by digesting it a piece at a time. When you are explaining something you are effectively teaching, which means someone else is learning and that means you need to keep your explanation short and compact in scope to give your student a hope of remembering it.
- Paraphrasing to verify learning: One of the best ways to check someone has understood your explanation is to ask them to paraphrase it back to you in their own words. This is not easy to do if they are not used to it so be patient; if it takes them a few attempts, they will improve with practice.
Programming Software Development: Testing Visualisation
by Daniel
leave a comment
Adventures with Test Driven Development
I’ve recently had a chance to use Test Driven Development (TDD) while developing a new piece of software; this is something I’ve been wanting to do for a while but was waiting for the chance to try it out with a completely new project. The work involved wrapping a C library with a C++ wrapper and then wrapping that C++ wrapper with a managed C++ wrapper so I could then use the library in a C# application. I originally planned to use only one C++ wrapper but I couldn’t figure out a way to deal with abstract C structures in managed code so I ended up creating the C++ wrapper to isolate the managed code from those abstract structures.
For those that have not heard of TDD, or can’t remember what it involves, it is essentially a methodology that encourages the use of unit tests and quick iterations to develop software that matches the functionality specified in the unit test. TDD can be thought of as a five stage loop where one complete rotation is one iteration of the software, the five stages are:
- Write a new unit test.
- Run all the unit tests and see if the new test fails.
- Write the minimum amount of code to make the test pass.
- Run the unit tests and see the test pass.
- Refactor were necessary to remove duplication.
This sounds simple and it really is; the core of the idea is that the test in step one is effectively specifying some new functionality, which we then test and if the test fails, implement in the simplest manner possible in step three. This is followed by making sure all the new tests plus older tests still succeed in step four, and then in step five we refactor the program as required to remove duplication.
I’ve always like the idea of unit testing software as it seemed to me it would make regressing testing very easy and gives the developers more confidence in the quality of their software, as well as making refactoring a lot easier as the unit tests provide a simple and easy way to test to see if the refactoring caused any unexpected breakages. All these benefits observed during my trial use of TDD, plus one unexpected benefit, made me think a lot more about my program composition and my interfaces. This proved an unexpected bonus and was mostly born from a desire to make it easier to test my classes and methods.
One of the most common arguments I heard against unit testing is that it costs more time than it would to not write the tests; this is simply not true as this chart highlights. Writing tests for TDD may take longer to do than implementing the same solution without tests but the cost of fixing the bugs are moved forward in time with TDD which makes them a lot cheaper to fix, as the closer in time the detection and correction of a bug the quicker (and hence cheaper) the fix. So the assertion that unit tests mean ‘X% less features’ is simply wrong; unit tests mean more features as they make bugs cheaper to fix. This does not mean TDD and unit testing is not without flaws. I’ve yet to hear of an easy or simple way to unit test Graphical User Interfaces (GUI) as well as we can currently test source code.
In summary I’d recommend you give TDD a try if you haven’t already and if you’re using a .Net language I’d recommend NUnit as your unit testing framework.
