The size of my todo list just never seems to shrink. I use Trello intermittently to try to capture and manage my todos but on a daily basis there are many jobs that pop up and are dealt with without making it onto the list. And as much as I like to get things done, a part of me also balks at being super organised. Where is the room then for spontaneity and serendipity? I recently purchased a copy of Messy: The Power of Disorder to Transform Our Lives by Tim Harford. Unfortunately at the moment I can't quite place my hands on it and probably should have gone with my gut and bought a few extra copies to leave lying around.
But I read a lot and the books that resonate with me are often the ones that hold up a mirror to my own behaviour. I like to get things done and have always relied on doing good work in order to get more work. I'm a software developer and my job involves more than just building an application to a provided specification. The process of writing software is not mechanical and involves much "poking the box" as described by Seth Godin in his book Poke the Box. Seth talks about applying this process not to software development, but as a call to find, and live life to, your own cadence (at least that is my interpretation, YMMV).
Failure is an integral part of software development. So much so that we incorporate failure into our development processes. Test Driven Development (TDD) or Test First Development specifically puts the testing ahead of the coding. That may sound counter-intuitive but effectively every piece of functionality in an application or system should pass a number of tests to try to ensure the accuracy of that functionality. By writing the tests first we start from a point of failure and then write the code to pass those tests. Writing the tests first affords automated testing which in turn facilitates Continuous Integration and Continuous Deployment. James Clear tells us to Treat Failure Like a Scientist and that "failures are simply data points that help lead you to the right answer". This is tremendously empowering on many levels, not just for the development of effective software.
To build applications that meet the intent of the requirements rather than the letter of them, we also commonly follow Agile development processes such as Scrum. Building software to "spec" only to find the "spec" wasn't actually a good definition of the problem has largely been sidelined in favour of an iterative approach. We begin with a minimum definition of the problem, enough to get started and also typically to provide some broad brushstroke estimates for management. Then we iterate towards the final application or system using a feedback loop to ensure we are building the right solution. In her book The Creator's Code, Amy Wilkinson talks about flying the OODA loop. The OODA loop originated in the US Airforce and was defined by pilot John Boyd. OODA stands for Observe, Orient, Decide, Act. Rinse and repeat. This has strong parallels with Agile/Scrum and is about building an effective feedback loop to inform future actions.
What is my point? Getting things done is not easy and isn't limited by age or experience. To help my disorganised boys get themselves ready for school in the morning I wrote a small Node application that queries and updates Trello boards for each of them and displays their current state in a single dashboard format using a Raspberry Pi. That turned out to be super effective and now the dashboard just displays all the things still sitting in my own todo list. But it was great to see that what at first appeared to be an intractable problem resulting every morning in strongly expressed instructions to get dressed, have breakfast, make lunch, etc could be instead transformed into an empowering experience. We do have tools to help get things done without feeling project managed and some of the best tools aren't even necessarily software.
To summarise, find your own cadence, fail like a scientist, fly the OODA loop, and you should probably use Trello.
Published: 2 November 2016