This genuinely inspiring lecture was delivered by the late Randy Pausch at the University of Virginia in November 2007. The lecture is made all the more poignant by the fact that Pausch was battling terminal cancer at the time, and so had very pertinent views on the subject of time management.
The lecture is loaded with practical advice, and details any number of meta-skills, tips and tricks that anybody can use in a work environment to get more done. Pausch was an engineering geek though, so his sage advice is of real relevance to programmers. It might seem like a long video, but think of these 76 minutes as an investment! I guarantee you’ll take away at least one useful thing that you can put into practice straight away.
Getting a view of your workload A view of your workload is a self-defence mechanism, and a time management tool that allows you to manage the people allocating work to you. Without this view, it is very easy to get that swamped feeling, and needlessly inject pressure into discussions about workload and priority.
As a programmer, work can arrive on my desk through a number of different channels, and the timelines, priorities, importance and urgency of each task evolve and mutate on a rapid and regular basis, making it easy to occasionally feel swamped.
Like many work-a-day developers, I generally work on a combination of production defects and development projects, but my team also has a rotating general support role – or ‘SWAT’ as we call it (that’s swat as in flies!). This means that, one week in four, you’re the SWAT guy, so the other tech team members can bat over any mundane internal queries and support requests from other people in IT, as well as the urgent production issues. It’s great when you’re not on swat, because you get to concentrate. On the other hand, when you’re on swat, that swamped feeling can be a regular visitor!
We use Jira for bug tracking which is great, and our help desk application can give me a view of the work assigned to me in that particular system, but how do I see all the work I’ve got on my plate right now? What about swat work? This can arrive from shady, illicit sources, such as meetings, emails and conversations, much of which is not ‘logged’ on either the development or production support systems (unless the developer pushes for it). Surely somebody’s keeping track of all this though, right!?
Abstractspoon’s ToDoList gives me that view of my own work, and I noticed recently that I’ve been using it for about 18 months now! This tool has honestly helped me a lot, to the point where I’m becoming a bit of an evangelist in my office.
a recent workload list
Although the tool only explicitly promises to give a clear view of workload, I’ve found also has other benefits that are very helpful for a busy programmer. Here are the main benefits for me:
It’s just the right amount of technology for what I needed. You can simply, and quickly put all of your workload in one place, set a priority on every open task, sort work by priority, and work on the most important task first.
The critical factor is to reset task priorities when a new piece of work is assigned… ANY work! For me, this involves a discussion with my gaffer about what’s now the most important! He generally appreciates this kind of discussion, as he retains final say over what I’m working on and in what order.
Closing tasks is very satisfying, but you can also delete tasks when they’re complete! Crossing out a bullet point on a handwritten task list just doesn’t cut the same mustard!
Linking to documents and web pages is a simple way of grouping all the most relevant information to all the current tasks in one place. That’s a massive plus for me.
Two or three times a day, I do some orientation, and update the tasklist with what I’ve recently worked on. This might be a very brief text description, or links to new information or documents. This takes less than five minutes, two or three times a day, but it gives me an great feeling of keeping on top of things, (this helps whenever that swamped feeling starts to creep in!)
Shared workload lists are a simple way to handover task lists to someone else, and this has been very useful for our swat role. Why feel swamped on swat, when you know you don’t have to finish everything by Friday?! (This uses a really cool little version control feature.)
It’s free!
Other features include estimate tracking, time monitoring, sub-tasks, deadlines, and loads of other stuff I haven’t even mentioned!
Unequivocal successes are rare enough in software development, so it’s nice to be able to share one. Today I did a show-and-tell presentation to the I.T. department of a Balsamiq plugin for Jira, and it got a pretty positive response.
If you haven’t seen Balsamiq, I’d recommend taking a look and being the one to suggest that your IT department implements it. The video demo says it all, but it’s essentially a screen mockup tool, it can save significant development time (and cost) at the early stages of a project. Ultimately, the mockup can act as a spec in itself, reducing the need for boring, quickly irrelevant documentation.
The combination of Jira integration and the low price were the deal-makers for my bosses. Seriously though, after taking a look, what’s not to like!?
If the talking heads in your IT organisation espouse an interest in agile development methods, and are loath to part with cash at the moment, this should suit you down to the ground. We spent $150 (c. €106) on the three-license option, with the ability to upgrade in future if the demand is there. To quickly compare the cost with the benefit: think of any requirements you might be planning this year that involve screen changes, and how much time you would save doing a mockup before a screen prototype…. sold yet!?
For anyone who has ever had a passing interest in the dark arts of a software project, I’d heartily recommend Scott Rosenberg’s “Dreaming in Code”. Rosenberg’s entertaining book is a fly-on-the-wall report of the progress (and ultimate crash-and-burn) of a ambitious software project over a three-year period from 2001 – 2004.
The main goal of the open source project, which eventually came to be known as the Chandler project (that’s Raymond Chandler, not Chandler Bing), was to create an intuitive calendar for end users that could be shared over the web on a peer-to-peer basis. The context of this was before the advent of cloud computing or Gmail, so if Chandler was quick to deliver a good product, it could have been a real winner.
The project was led by Mitch Kapor, the creator of Lotus 1-2-3, and a man bringing a track-record of achievement in the software development domain. The team was made up of talented software professionals, all with a passion for the job, and a desire to really deliver something special. Much was expected of Chandler, but after three years, the still unfinished product did not live up to expectations, and Chandler was ultimately deemed a failure.
If you’re a software development professional, there’s much to take from this honest account of a too grand design that never really made it to fruition. However, there’s also much of interest in for those outside of the trade. Rosenberg intersperses his account of the project with witty and interesting asides, which document and explain some idiosyncratic aspects of the software development profession, such as the counter-intuitive nature of open source, the personality of the software developer, and just why it is that ‘software is hard’! (According to Hofstadter’s Law, “it always takes longer than you expect, even if you take into account Hofstadter’s Law”!)
The book is well researched, and Rosenberg’s writing is fresh, lively and involving. The description of the slow death march of the Chandler project is warts-and-all, which makes for rather painful reading at times, but ultimately, the book reflects very well on the participants, in that they allowed this experience to be immortalised.
I really enjoyed ‘Dreaming in Code‘, and would definitely recommend it.
For anyone who has ever had a passing interest in the dark arts of a software project, I’d heartily recommend Scott Rosenberg’s 
Paddy Corry's Blog 