Window Managment on Large Monitors
I have had a 24″ monitor at work for a while and recently bought myself a 24″ for use as a second monitor on my 17″ iMac at home. I really enjoy the extra screen real estate that a large monitor with a resolution of 1920×1200 provides. However most applications don’t really make good use of the massive screen real estate of a large LCD monitor e.g. web browsers viewing fixed width webpages. This leaves you with the problem of how to maximise your usage of your screen real estate, if a single application using the whole display is sub-optimal then viewing two or more applications can be more useful.
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.
Effective Work Breaks
I have made an interesting discovery since I started taking our new puppies to work with me: I actually seem to be more productive now than I was before I started taking the puppies to work! The pups generally need to be taken outside to relieve themselves and run off some energy every hour or so for about ten minutes. These puppy induced breaks are fairly practicable and not skippable unless the pups are asleep at which point I think it is better to let sleeping dogs lie.
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?
Fail fast, fail cheap!
I was explaining this to some junior programmers the other day and it’s worth repeating. Failure is fine in software engineering, in fact it is expected: I get nervous if something works first time these days as I know my limits and expect to make mistakes. However I think that new programmers don’t always realise that failure is acceptable and in some cases failure is preferred, this is especially true during research and development tasks. Consider the following diagram representing three programmers A, B and C working on a task over a period of time, each arrow represents one attempt at a solution.
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.
Getting work done: the empty office effect.
You may have noticed the lack of updates this week, I was in the office all weekend implementing something for a customer, so that they could then evaluate it this week which they were not expecting. I do not mind doing the occasional brief bit of overtime like this, especially when it is my idea. And it also gets me ahead of schedule plus it allows me to surprise my customers with an early delivery! It did however mean that I did not have time to write posts, for that I apologise!
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.
Productivity: Learning productivity Programming Reflection
by Daniel
leave a comment
Reflection for improved performance
Regularly taking time to pause and then review and reflect on how you could improve, and then experimenting based on those thoughts is key to personal improvement and increasing productivity. This technique has really been highlighted to me since starting to use Agile development methodologies like Scrum where at at the end of each sprint (short iteration period) a retrospective meeting is held. These meetings allow those working on the sprint to pause, review and reflect on their performance during that sprint and to discuss how performance could be improved. The regular retrospective meeting is in my mind one of the most important innovations introduced by Scrum and Agile, as otherwise retrospective activities were limited to once per development cycle after shipping the product.
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.
Personal Oragisation
Since starting work at my current workplace, which has almost two thousand employees in the same building, I’ve found myself in more meetings that I am used to. This is due to being in a central technology team in a large studio with many teams we need to communicate with via meetings. This, combined with a large corporate directory for the studio which means more telephone numbers than I can easily memorize and a desire to be able to create tasks and notes for myself in meetings or on the go, has lead me to recommission my trusty old Palm Z22 Personal Digital Assistant (PDA). I used to be a die hard PDA user starting with a Palm Vx then a Palm Zire, then a Palm Zire 21 and finally onto my current Z22. I’ve always loved Palm’s Palm Desktop software but when I moved to using an Apple iMac at home I found the Palm Desktop port to be a poor port, to such an extent that I actually stopped using it for the last few years.
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.
