Part 2 â€“ Cracks in time
InÂ part 1Â I talked about how to get the most out of minimal sleep. I discussed a little about my average day and how and where the hours go and why I get minimal sleep in the first place. I also talked about the number of projects I have on the go at any given time.
Living in the cracks
Letâ€™s talk about maximising the efficiency of the small amounts of dev time that can be found in between other time commitments. Last post I spoke of the idea of â€œthe cracksâ€ of time in our day. For me, a lot of my day is accounted for before I even think about things like running my own business. Thereâ€™s full time work and the commute to and from it. There are the kids and getting them ready for day care in the mornings and bed at night. Thereâ€™s making time to talk to my wife, sometimes just about whatâ€™s on TV or something that we read about that day. For anyone with a partner, this is critical. If you want to fit being an indie around having a family and full time job, you must build in time for them. That time is not the flexible kind. Thatâ€™s part of what you are fitting the dev work around. So the cracks for my day are the times that fall in between all that. Which is usually the commute on the train in to work, which is where Iâ€™m writing this right now, my lunch hour, though today that is given over to a meeting of organisers for the Game Technology and Game Development Brisbane meet ups. The commute home. And maybe, a couple of hours between getting the important night routine things done and going to bed. All up, I might be able to find 4 hours, if Iâ€™m lucky, scattered around the day. On the weekends, itâ€™s often less. I dedicate most of that time to being with my family.
Identifying the traps
Any programmer will tell you, a continuous block of time is way more efficient than a shattered one. There is an excellent description on why programmers seem to get way more put out by interruptions than seems fair in a post calledÂ Why Programmers Work At NightÂ which you canÂ read here. Thatâ€™s darn accurate. Attempting to put down a half coded thought to pick up again later can be very frustrating. Sometimes you can feel your train of thought crumbling the second someone starts talking to you. Or in my case, as the train voice over says the next station is my station and I have to quickly save and pack up my mini â€œoffice-in-a-lapâ€ before the train stops. Weâ€™ll talk about ways to manage distractions shortly.
2. Planning (or lack thereof)
When working in the cracks, you are going to find youself sitting down to do some work on a project and knowing you only have a couple of hours, or perhaps as little as 30 minutes, to be productive. The next thing you know youâ€™ve spent half that time either thinking about the best thing to work on, or being distracted by other things like emails and Facebook notifications. Both of these are side effects of the same problem. You havenâ€™t planned your time. You must know what you are going to work on before you sit down to do it. In the next couple of chapters of this series Iâ€™ll talk about how you can do that from a higher level. But for the sake of this article, Iâ€™ll just say, know exactly what tasks you plan on tackling before you sit down to do them.
Factor in the amount of time you have. If you have a 30 minute commute, then donâ€™t give yourself the task of writing the dialogue system for your RPG. If thatâ€™s what you want to work on, you can certainly do it, but spend some time breaking that system down into components that are smaller and can be completed and signed off in a relatively short amount of time. In fact, that planning is a perfect task for a commute.
One advantage to breaking a system or large task down like that is that the pieces become much easier to put down if you do need to. If something turns out to be trickier than you expected (and letâ€™s be honest, it usually does) then you can usually make a couple of quick comments on where you were headed and pick it up again later without it being a panic inducing issue. To refer to the link earlier, the construct you have in your head is simpler and less likely to shatter as soon as you have to drop it.
Pomodoro is a time management technique. There is plenty written about it online and in books. But to put it in very simple terms, there are two rules. Work without interruption for 25 minutes. Take a break for 5 minutes.
In the Pomodoro technique, you set yourself a timer for 25 minutes. During that 25 minutes you do not let yourself be interrupted. By that I mean, you flat out ignore them if you can. If you work with other people, make sure your timer is very visible and let them know that while the timer is running, they arenâ€™t to interrupt you except in the case of emergencies (like the building is on fire). For anything less, they can either send you a message or email, or wait till the timer runs out (preferably not by standing behind you watching the clock).
Any notification you receive, be it email, text message, Facebook chat, Google Hangouts, Skype, Viber, Slack, the postman or God Almighty speaking to you directly, is ignored (or noted down quickly on a list) while that timer is running and you focus completely on the task at hand.
In an ideal world you would try to break your tasks down into ones that can be completed in 25 minutes. But that is rarely practical, and itâ€™s perfectly fine that a task run over the 25 minutes.
At the end of each 25 minute block, you take a break. No matter what. Even for a task that is extending into the next Pomodoro. For this time you have some options. Either spend that time actioning some of your interruptions list (maybe respond to that text message), or do something completely unrelated. Relax. Do some small exercise. Stand up and step away from your desk. Stare out the window. Anything except think about what you were working on.
At the beginning of the next Pomodoro, take a few minutes to re-evaluate your plan. Were you side tracked during that last pomodoro working on something that isnâ€™t technically necessary for what you are doing right now? Is your original solution or idea still the most viable? Regardless of whether you completed the last task, or are still working on it, spend a few minutes reflecting on what you got done in the last Pomodoro and evaluating the direction to go with in the next Pomodoro.
If your timeframe to work within is less than an hour, I personally recommend you just treat that as a single Pomodoro. The train ride in, for instance, for me is around 30-40 minutes. I just treat that as a single, focused session and the break comes when I stop and get off the train.
You have the option, depending on how long your total work session is, to take a long break every third or fourth break. Taking 15 minutes, you can make yourself a coffee. Read a blog post youâ€™ve been meaning to read, send some emails. Whatever you like, just like the 5 minute break.
Test Driven Development
I would like to mentionÂ Test Driven Development (TDD)Â at this point. TDD is a programming technique in which you write unit tests for your code before writing the code to pass that test. You then write the next test and then the code to pass it, making sure all previous tests still pass and so on until you are complete. There are a number of benefits to TDD. Your code becomes more robust and better designed because you design the classes feature requirements when figuring out what tests will be needed, before any of the class code is even started. Itâ€™s less prone to bugs and if any do show up, they are usually cases you forgot to test for. For that reason, it is often easier to debug, as you know most of the places that the bug isnâ€™t. The down side is that it will take longer to write a class and it takes some practice to learn how to write good tests and what to test.
I mention it because I believe itâ€™s an excellent productivity tool despite it adding development time. Iâ€™ve mentioned itâ€™s benefits above, but the one I want to reiterate is improved design. By making a list of the functionality you want to test, you are breaking your already broken down task into an even smaller list of units. Ones that can very easily be recognised as completed as you go. To the point where you can usually get a test runner that will give you a little green tick right there next to the test name. There couldnâ€™t be a clearer representation of a todo list. If you havenâ€™t used TDD before, I highly recommend you learn more about it. Especially readÂ Test Driven Development by exampleÂ by Kent Beck. Itâ€™s an easy and enjoyable read and does a fantastic job of using a practical example to take you through the process.
Letâ€™s quickly cover the main points again:
â€“Â Â Â Â Take advantage of any time you have thatâ€™s at least half an hour can be dedicated to your work. Itâ€™s all valuable.
â€“Â Â Â Â Break down your todo list as small as you can. Treat this break down process as the first task on your list. If you want to be effective at using 30 minute â€œwideâ€ cracks of time in your day, you need to be able to sit down and begin actioning a task instantly. And to do that, you need to know exactly what they will be.
â€“Â Â Â Â Embrace the Pomodoro technique.
â€“Â Â Â Â Dedicate yourself to a task for 25 minutes, ignoring all interruptions (within reason. If the train is being evacuated, donâ€™t wait for your timer to sound before actioning that).
â€“Â Â Â Â Always take the 5 minutes. The break away from your current task is as important as the 25 minute focused attention youâ€™re giving it the rest of the time.
â€“Â Â Â Â If youâ€™re a programmer, consider at least learning more about TDD. Itâ€™s a valuable tool in itâ€™s own right, but I believe itâ€™s also an effective productivity tool.
Iâ€™m hoping that the ideas here inspire you to embrace those smaller times of the day that we so often write off as not usable. Iâ€™m telling you they absolutely are.
Have you ever added up how much time you just let slide past? Commute times, the time between when you sit down to work of an evening and when you start actually working. Try keeping track of it for a week and let me know what you come up with.