The simplest solution to this is to manually position and size the windows of your applications so you can view two or more at once.  Arranging application windows manually quickly becomes tedious, due to the many events that can occur in a modern operating system which cause your application windows to be moved around, re-sized or moved to another monitor.

The solution to this problem is using Window Management utilities which allow you to easily re-size and move application windows around, typically using key combinations.  These utilities exist for most operating systems for Mac OS X the window management utility is called SizeUp, the equivalent utility for the PC is called WinSplit Revolution.  I use both of these applications daily, WinSplit is freeware but SizeUp costs a minimum of $4.99 and its worth every cent.  Each utility has some unique features: WinSplit allows you to chain several window configurations on a single key combination and SizeUp allows you to set up a key combination for moving windows between monitors.

I would struggle to maximise my use of one or more large monitors without a Window Management utility.  Hopefully one day this functionality will be built into operating systems as large monitors become more common.  Until then Window Managment utilties are going to be an essential tool that ever serious power user needs.

Previously I had been using programs like Work Rave and Anti-RSI to make sure I’m taking sufficient work breaks, mostly to keep me sane and free of RSI like injuries (I still recommend these programs).  I confess I am guilty of skipping breaks suggested by these applications fairly frequently, which perhaps is not a smart thing to do as it increases the likelihood of fatigue, injury and lowered productivity.  I had thought this system to be effective but I’m finding puppy breaks even more effective: possibly due to the lack of a skip option.  As puppies with full bladders cannot miss a break without risking an accident!

I think perhaps this lack of a skip option to puppy induced breaks is giving me more of a sense of having to make the most of the time between the breaks, this is helping me focus which results in increased productivity (which is not what I would have expected).  This is a most welcome and unexpected side effect to having the puppies at work with me: aside from the obvious benefits of canine companionship and having a very good excuse to go for a walk at lunch time!

I have found over the years that any sort of regular break gives me a chance to pause and reflect about my current task and that is very useful for considering options and possible solutions to problems.  The end result is that stopping to reflect about what I am currently doing regularly results in a superior end product than just hammering away at a task.

Do you have regular breaks and do they help or hinder your productivity?

Assume the task that has been set is complex and contains some degree of uncertainty which means that the first few attempts will probably fail.  Which programmer would you want working on the task?  If the task is actually impossible then programmer A will be the cheapest from a business standpoint as they fail earliest followed by programmer B and finally programmer C.  Also, programmer A will have five attempts at a solution compared to programmer B’s two and a half attempts and programmer C’s single attempt.  As iteration leads to improved quality (Boyd’s Law) this means that programmer A is also likely to hit on a more superior solution than programmer B or programmer C in the same time period.

The interesting thing here is that in my experience new programmers tend to work like programmer C: they will attempt a single solution working diligently to overcome any hurdles they encounter, no matter how severe the hurdle.  This sounds harmless but remember that few things are impossible in programming, so the more a programmer hammers away at a problem the more likely they are to fudge a solution and that solution (in my experience) is not often of a high quality.  The counter point to this is that more productive programmers will rapidly discard attempts early in each attempt when it becomes clear that the solution though possible is not actually desirable e.g. the dog is hungry and solutions include: A) feed the dog B) kill the dog.

This can also be observed by monitoring how long a programmer will remain stuck for before asking for assistance.  The most productive programmers will get help within minutes of becoming completly stuck.  However the least productive (and often least experienced) programmers will often struggle with the problem for days before actually asking for assistance and this delay is expensive in terms of money, deadlines and product quality.

Working this last weekend and observing the results (on our scrum’s burn down chart) did get me thinking about just how much more productive I can be over the course of a day at the weekend compared to a normal weekday: I believe I did 3-4 weekdays of work over two days this weekend.  Yet I did not work any more hours than I would during the week but I achieved more in terms on implementation and testing than I would normally expect.  I also experienced that familiar loss of a sense of time (losing track of hours while working) which I’ve come to associate with really productive periods of work: some people call it ‘the zone’ which sounds a bit too dramatic (and cheesy) to me.

As to the causes for this bout of hyper productivity I think part of it was that I went into the weekend knowing exactly what I wanted to get done in terms of goals and also having a fair idea of how to achieve those goals.   I believe that helped me a lot, as a large portion of development time can be swallowed up with experimentation, thinking and research.  So knowing what needed done helped me focus my efforts but I don’t believe it was the sole reason for the apparent (brief) doubling of my productivity over the weekend.

Perhaps another beneficial factor was the lack of people in the building over the weekend (sorry folks).  The area where I work was very very quite this weekend, I was alone for most of the time with only one co-worker popping in and out for a few hours.  This meant there was no external distractions like background conversations, people (or dogs) moving about or folk asking me questions to distract me from my task at hand.   The building being mostly empty also meant there was no external electronic distractions e.g, email or instant messaging icons competing for my attention.

The lack of meetings was also great as this meant I had large unbroken periods of time to work in rather than an hour or so between meetings, as most experiments have shown that when you are in ‘the zone’ any disruption costs you about 15-20 minutes of time before you can get back to your ‘zone’ or train of thought.  As I have mentioned before in previous posts I make a practice of booking myself in my office calender system for meetings that I call work blocks during the week.  These blocks are usually about half a day in size and help prevent my day from getting horribly fragmented by meetings.  Working this weekend has just reinforced to me just how disruptive meetings can be to actually getting work done and how important it is to have uninterrupted periods of time for getting work done in.

Yet for all that an empty office helped me get stuff done this weekend, I would I be as productive over the long term working in such a solo fashion?  I’m not sure as these days software like games are suck large undertaking and require large teams of developers which means that communication and synchronisation becomes such key factors in development sucess but also key bottlenecks as well.

I think that those short development iterations and regular reflection sessions at the end of each iteration introduced by Agile/Scrum are perhaps the two components of these methodologies that help drive process improvement the most, but they are perhaps also the easiest to overlook.  It would seem that the natural inclination for most workers (especially when stressed) is to not stop and think about how they are working, which means they do not truly understand their work flow and this limits their ability to improve their performance.

Some of the most productive individuals I’ve met, or have heard about, are those that regularly take the time to pause and think about how they are working not just about what they are working on and then experiment to improve.  This habit goes against the instinctual urge most of us seem to have when ‘busy’ which is to not stop to think about the how as we think we don’t have the time to spare.  This is a huge misconception, as taking time to pause and think about how we are doing things and how we can improve can yield large gains in terms of increasing productivity and reducing frustration.

Another overlooked aspect of reflection is that it can make a mundane repetitive task more interesting and stimulating by turning it into a personal challenge: can you tune your work flow and improve your performance on a set task?  For example, habit can even be applied to repetitive manual tasks like mowing the lawn: can I mow the loan in a shorter period, where can I save time or remove repetition?

In summary, pausing and reflecting during your working day and then experimenting to improve can help drive a habit of efficiency which will increase your productivity and potentially improve the development process for your whole team, and this is what all development efforts need to suceed.

Since my responsibilities have increased at work and I find myself in more meetings with more potential to forget when my next meeting is if I’m not at my desk, I’ve brought my trusty Z22 out of retirement.  Fortunately as the Z22 has no email client getting IT approval to use it was simple.  I don’t think I’d want a mobile email device for my work email like a blackberry, Palm Treo or Apple iPhone as it would be far too distracting for me I think.  I’ve also made the switch to syncing my Z22 to Outlook 2007 instead of Palm Desktop, which is taking a bit of getting used to as Outlook’s Tasks and Notes features are not as powerful as Palm Desktops.

My favorite features of PDAs are:

• Calendar: It is incredibly useful to be able to sync the calender on my workstation at work with my PDA so I can review my schedule at any time and anywhere.
• To-do lists: creating, managing, sorting and completing tasks is very satisfying not to mention useful, especially as task management software has gotten smarter to allow recurring tasks, notes and alarms on tasks.
• Digital Notes: have always been a favorite of mine, even during periods when I’m not using an electronic PDA chances are I have at least one or more Moleskin notebooks on the go, to keep information in.
• Contacts: I previously did not need to use the contacts facility much but since I’ve started working in a larger studio and needing to keep more peoples telephone number, email and office location close to hand I am starting to use the contacts facility more and more.
• Security: Old school Moleskin notebooks are great but unless you memorise equally old school encryption techniques to protect the data in them you become limited in terms of what you can store in them, as without encryption they are effectively public.  Thankfully PDA’s provide various options in password protecting your device, locking the device either on a timer or schedule, preventing anyone from syncing with the device and the option to encrypt the memory of the PDA.

• The brick wall: you’re working fine and then suddenly you’re stuck and you’ve no idea how to continue.
• Recursively stuck: this one is hard to spot. You’re trying solutions to something but each attempt takes so long to work through that by the time you’ve tried it you’ve forgot what started that attempt, you then try the first thing that comes to mind which often is the last thing you tried, repeat until you notice…
• Too many options: something that appeared straight forward on closer examination has multiple potential solutions and you’re not sure which.

My approach to becoming unstuck is as follows:

• Take Notes: As soon as I realise I’m stuck I start taking notes: what I think I know, what I suspect, what I’ve tried and what I want to happen.  Doing this helps me prevent myself getting bogged down by attempting the same solution repeatedly. Also by recording what you think and what you’ve tried you give yourself an agenda of potential solutions to work through as you attempt to solve the problem, as once you’ve ruled everything on your list out what you are left with is usually the issue, although at times that may seem ridiculous!
• Ask Google: There are very very few new problems in the world that haven’t already been encountered by someone else and chances are there is something Google can find for you that may give you the pearl of insight you need to solve your issue.
• Ask the community: Chances are unless there is some sort of general community for the language and/or technologies you are dealing with, which you can ask via email, forums or IRC about your issue.  A lot of the time Google will give you results from these communities if their archives are somewhere the Google spiders can reach.
• The cardboard programmer: This solution sounds silly but it works, find anyone (they don’t need to be technical at all) and then step through your problem with them talking over the source code. A lot of the time you will realise your error mid way through your explanation!
• Ask an experienced co-worker: Find a more experienced co-worker and ask them about your problem in an intelligent fashion e.g, giving details on the issue and what you’ve tried.

My golden rule for becoming unstuck is:

• Never be stuck for long! I can’t emphasise this enough, this is an industry where programmer productivity is the number one priority, not solving the issue yourself.  If you’re totally stuck don’t sit for more than an hour (ideally half an hour or less) before you start involving more experienced people in finding a solution.  Don’t believe me?  Watch the most productive programmers around you, I would put money on them never sitting for long if they are stuck before they start asking for help, it is not a weakness, it is simply more efficient!

Boredom is common, especially during tedious tasks that involve repetitive tasks.  The solution to this is automation, either with tools or a scripting language. A good software engineer should be lazy and by this I don’t mean they should do no work, I mean they should not do the same task more than twice in recent succession before they start looking for a way to automate the task so they don’t have to do it again manually because its just plain boring:

• Doing lots of copy and pasting?
  Chances are you are either copying the same code snippet around, if so that is screaming out to be factored into a separate function: copy and paste duplication of code is evil, especially if you don’t fully understand the snippet you are moving around. Are you sure it is safe to put that snippet there in that method?  Or have you just renamed something and are now searching for and replacing each instance with the new name? Don’t do this manually!  Invest in some refactoring tools. Most good editors and IDEs now come with some form of refactoring tool sets built in, find them, learn them, love them they will save you tons of time!
• Calling a n step pipeline of tools manually?
  Invest some time in learning a scripting language like Python, shell script, php or Perl (my favorite is Python): n step tool pipelines are the tedious problems that scripting languages were designed to solve by automating them into a single script call.  Scripting a pipeline becomes an investment especially if this pipeline is being run a lot by many users, think of all the time you are saving all those users and the removal of operator error by taking the time to automate it.
• Waiting on an external dependency?
  Are you waiting on something from someone else that is blocking you?  First off: do they know they are blocking you?  It may not have been communicated to them, don’t assume they know: check.  If they know but they can’t give you their deliverable yet, is there anything you can do to help them or to prepare for the coming integration (e.g, refactoring)?  If all else fails, do you have any other task you can do while you wait?  Maybe something you’ve been meaning to do but didn’t have the time?  Still nothing?  Find your lead or manager, there will be something else for you to do while you wait, if there isn’t I’d be worried!
• Waiting for bugs and in code base lock down?
  So you’re near the end of development in your current cycle, most of the bugs have been found and fixed, your code base has been locked down and you’re not allowed to change anything except for bug fixes?  You have several options here still, the most immediately useful is to see if anyone else has a bug they could give you to keep you going.  Then if there is no spare bugs start testing your application yourself, be pro active, find bugs, torture your areas or responsibility to make sure they work.  Bored of that now eh?  If you’re near the end of a development cycle chances are there is going to be a sequel: start your own mini postmortem of the project, think about what went well, what didn’t and what you would do differently next time.

Next we will look at being stuck…