Posted tagged ‘Focusing’

An Idea for Tracer Bullets

August 6, 2010

My favorite software development related book, The Pragmatic Programmer, has a section in it where it mentions tracer bullets. The tracer bullet system they describe really reminds me of the scaffolding system that Rails made popular. It’s sort of a loose structure that gives you something to play with but that really needs to be fleshed out for your finished application. The idea behind using a tracer bullet, or scaffolding, is to have that basic structure to build with and help avoid the ‘blank page’ problem (writers and programmers both know that a blank page is the most difficult thing to write from). So scaffolding is useful, and what Dave and Andy remark as tracer bullets I’m going to call scaffolding for this piece. I would like to introduce a different idea for what tracer bullets are, and how they can help you focus on good Test Driven Development (TDD) and battle the problem of forgetfulness due to complexity.

Book cover for The Pragmatic Programmer

This is an amazing book. My top choice for any developer, especially ones just out of college or with limited 'real world' experience. Buy it, it's worth the price.

If you’ve ever worked on a new system or a larger refactoring of an old system, you’ll have noticed that you get into a sort of groove with what you’re doing. You look at the big picture and you start making your modifications. Something comes up though where you change a method signature and you have to adjust all of the places that use it, which maybe makes you rethink some basic designs and causes another smaller refactor or something during your larger one. Eventually when that’s all done you go back to what you were originally doing. You’re testing all the way which is good, but eventually you get to a point where you stop and say “I’m done”. Or at least that’s the idea. Often it comes out  more like “Am I done?” and you wrack your brain trying to think if you remembered to put everything into place or are you leaving out some small bit that’s going to cause a bug later on. If this has never happened to you and you don’t understand what I’m talking about, you may stop reading.

The main problem seems to be that you have this grand idea at the beginning, and you know pretty much all of the parts that you’re going to have to modify to make things work, you just loose track of what you’ve done and what you haven’t done. Now you can make a paper ToDo list at the start and check everything off, and that’s a viable method. However I would submit that you should utilize your best programming tool right from the start to keep track of your progress: your tests.

When you first collect your refactoring (or basic design) idea, you should know many of the places that you’ll need to modify in order for it to function. Create unit tests for each of these major ideas. These tests should fail with an error message relating to what the idea is and a note that it isn’t actually implemented yet. As you start to refactor, replace these tests with the actual tests for that piece of functionality. You won’t be fully removing the tests (just by having those tracer bullet tests to start with means there’s something that needs to change and those changes need to be tested), but you’ll be adding real tests for your changes to them. When all of your tracer tests are replaced, you should know that you’ve covered everything that your design required.

That doesn’t mean additional testing shouldn’t be done, there are often times areas that need to be modified or added that you did not originally envision. However, it should be a good start to tracking down those areas that need work. It should also prevent you from forgetting any of those key areas that you thought about originally but lost track of during the hectic course of development.

Tracer Bullets in this sense are really just empty failed tests that provide guidance as to what you need to work on. They’re not real tests, but they’re placeholders for where tests should be in the future. They act as a guide to help you figure out what you should be working on next. In addition, since you need to modify those failed tests for your build anyway, it should encourage you to work in a more test driven way by writing your tests first. Since you’ll look at your list of failed tests as your “ToDo” list, it will encourage your first action being to change those tests to something useful rather than a paper ToDo list which encourages you to jump into writing the application code before your tests.

Storm Trooper Helmet

As additional encouragement to practice Test Driven Development, here's the coercive face of failure.

Anything that keeps us more organized and removes unnecessary burdens to our mental flows is a helpful device for a programmer. Being able to utilize any technique that will increase your likelihood to properly test your application code is also a great benefit. This is just an idea I’ve been pondering for some weeks and I’m sure it’s not the only one for combining your design and testing in an up front mannor. If anyone else has any suggestions or practices that they use, please feel free to let me and others know what they are.

A Month of the Pomodoro Technique

December 16, 2009

[The new location for this blog post is here. This blog has been moved to]

It has been one month as of today that I started using the Pomodoro Technique at work in an attempt to increase my productivity. I think that after a month of use I can provide an evaluation of the technique; what I find good about it along with some of the negative sides. While I think that using pomodoros has increased my productivity overall, there are still some gaps that I have yet to discover ways of filling.

There were several reasons why I started to use the pomodoro technique. I was first drawn in to the concept by an article in the free PragPub magazine. This made me interested enough to read the Pomodoro Technique Illustrated book. I decided to give the technique a try to see if it could allow me to focus more on my work. I had been bouncing a bit too much from task to task as new tasks get added on by management, and older tasks would get forgotten about until they were asked about again. The technique was my own decision to improve myself as far as time management and work efficiency.

A quick intro for those who don’t know: The pomodoro technique is a time management system for minimizing multi-tasking along with prioritizing activities. Work is divided into 25 minute chunks called pomodoros that are separated by 5 minute breaks. The main idea is that for those 25 minutes you should be focusing 100% to the task at hand and avoiding internal and external distractions as much as possible.

My Process

There are many aspects of the pomodoro technique that I really like and that have helped me over the last month. I think the first and most important one is the artifacts that the technique produces. By artifacts I mean the Activity Inventory, the daily Todo sheets, the memory maps, and the Record sheet. These items add a lot of organization to my workflow along with preventing me from forgetting tasks I may have been working on.

For the activity inventory, I use a fairly basic legal notepad. I write down entries of things to do, one per line. The sheet often extends to multiple pages. At the end of the day I cross of anything that was completed on my Todo sheet for that day so that I can just look at the uncrossed entries when deciding what to do at the start of my day. I sometimes put my estimated number of pomodoros next to each item, but not always. I also try to write down everything I can think of, even if it isn’t work related but I want to get it done at some point. Some non-work related items I can get done during the day, but others are just good notes to myself that I can read each day and give myself reminders like making dinner plans for the week or calling the dentist.

My Todo sheet is done on a large spiral notebook of grid-paper. Grid paper is my favorite type of paper for notes, and it works very well for the Todo sheet. I leave 4 boxes empty to the left of each entry in case I need to add a U (unplanned) or small note to a task. I try to leave at least 7 boxes free on the right hand side so I can draw in the pomodoro boxes. I write down each task I want to do that day in pen and then I draw empty boxes in pencil to the right of it, each box indicating a pomodoro I think it will take. There’s usually enough space between those boxes and the item that I use that for marking interruptions. At the end of the day, I use the back of the page to draw up my memory map for the day.

The record sheet I keep in a spreadsheet (I use Numbers from iWork). I have 3 sheets on my record sheet spreadsheet. The first is an overview record sheet. Each row contains one day, with the columns indicating the date, completed pomodoros, internal interruptions, external interruptions, underestimated pomodoros, overestimated pomodoros, completed tasks, incomplete tasks, unplanned activities added to the todo, and unplanned activities added to the inventory. At the bottom of this sheet there is a line that gives averages for each of these columns. More on this a bit later.

The second sheet is an extended log. Here I make basically a copy of my todo sheet for the day. It contains the name of the activity, the number of pomodoros spent on it, two columns for guess errors in case I guessed the wrong number of pomodoros to complete the activity, the number of internal interruptions, external interruptions, if the activity was completed (I just put in an x if it was), and any comments. There are total lines for each day.

The final sheet is a chart sheet. Currently I only have one chart, but I’ll probably expand this when the task makes it to my todo list. The chart shows completed pomodoros for each day. I just use the data of the second column (completed pomodoros) from the first sheet to create this chart. The chart gives me a good indication of how well I was able to perform on each day and shows me some trends. I don’t show the record sheet to anyone else so it’s just for my own purposes. This whole system isn’t something I would bring up to managers during a review or anything, that would bring too much stress into the project and would lead to the temptation to lie.

Positive Aspects

One aspect of the technique that I like is the recording of pomodoros spent each day. When starting a day, you can set a goal for yourself to beat your average number of pomodoros done in a day, which is recorded at the bottom of the first sheet of the record sheet. That average is also a good indicator of how much you’ll likely be able to accomplish in a day, so you can add tasks to the todo sheet until the number of pomodoro boxes is equal to or maybe one greater than your average. If you end up completing every task, you can spend 5 minutes to add some more on and congratulate yourself for being so productive.

I also enjoy the focus a pomodoro can give to me. I try to be tangentially aware that while I’m doing a pomodoro I should ignore all IMs and emails and try to be bothered by other people around me as little as possible. Those distractions can really get in the way and derail you. If something is really on my mind and I don’t want to forget it I’ll write it down on my activity inventory or todo sheet and mark an interruption, but at least then it’s out of my head and tabled for later. It’s also really nice to be able to mark that X at the end of a pomodoro. There have been many times where I would think about getting up for some water or a snack or something but I have 12 minutes left in my pomodoro. I know that doing something like getting a snack can sometimes drive you completely off course of what you’re doing, and honestly I can wait 12 minutes. The pomodoro gives me the incentive to put off doing those things that end up being procrastinations. Basically letting you procrastinate from procrastinating, which I feel is good.

I’m also finding that having things like the extended log in the record sheet and tracking how long each task takes me that it is easier to estimate new tasks that I get. I tend to have to break down tasks several times, but by doing that and adding all of them together you can get a rough idea of how long a task will take. Also since you know how many pomodoros you can complete in a day (it will be lower than you think), you can estimate how many days longer tasks will take. Very useful since managers are all about the time estimates and wanting to know when something is going to be done.

Being able to make up a todo list daily and work on those items is also the main reason that I am able to write this blog. Often when I start a blog I make a few posts every so often but then I forget to post and it just ends up dying. By promising myself that I will post every MWF and adding an entry at the top of my todo list each of those days provokes me to not be as lax about writing entries. This has worked out fairly well so far as I’ve only missed a few days and I feel more accomplished about my blogging abilities.

Not As Positive Aspects

Ok, this technique is not perfect. I didn’t really think it would be, and I don’t think that there exists a ‘perfect’ technique. Here are some of the faults I find in the technique that impede my productivity. I haven’t figured out a solution to all of them yet.

Pomodoros are an all or nothing affair. Either you work for 25 minutes straight to mark your X or you don’t complete a pomodoro. Since marking that X is the measurable sign of progress, you start to shy away from engaging in an activity if it won’t result in an X. For instance, managers love meetings. I think it is some sort of ambrosia to them to have people sit in a room together bored out of their mind as they rant about things that they think are important. Meetings get in the way of pomodoros. Say I have a meeting set for 4:30pm. It is currently 4:10pm, meaning I only have 20 minutes between now and the meeting. If I start a pomodoro, I won’t be able to finish it because I only have 20 minutes. Managers will come by your desk and poke you to go to the meeting at the exact time the meeting is supposed to start, so I can’t just show up 5 minutes late. In these instances I tend to not start a pomodoro because I won’t have enough time to complete it anyway. I try to fill up the time with administration tasks like catching up on email or organizing, but sometimes I honestly just end up reading blogs.

This can be a real problem, especially if you have lots of scheduled meetings every day or even daily meetings. I had a morning standup for a while that took all of 10 minutes, however it took place about 45 minutes after I got into work. I could spend the first few minutes putting together my Todo list and having my computer turn on. After my todo list was created, I wouldn’t have enough time to do a full pomodoro before the meeting started. This meant that I couldn’t start any real work until that meeting was over, which is about an hour after I’ve come in. So the first hour in my day is wasted because of a meeting and the techniques inabilities to deal with time slots less than your designated pomodoro time (defaults to 25 minutes).

Long meetings, like presentations or informative meetings, are also a small difficulty for pomodoros in that you often don’t get those 5 minute breaks every half hour. This makes me cautious on counting meetings in my Todo sheet as something I can mark off as having spent a pomodoro or two on. Sometimes I feel I can do that, other times I’m not as sure.

I think overall my main problem might not even be with the technique at all, just meetings. It’s an area to consider.


In the end, I like using the pomodoro technique. It’s fairly simple and it keeps me organized. I found a very nice simple application for the mac for measuring pomodoros so I don’t need a real kitchen timer. I like this because it’s easy to see on my computer, doesn’t get in the way, can provide the ticking sound, proper notifications, and has easy keyboard shortcuts. It’s also good that if I keep the volume at the correct level on my computer, it doesn’t irritate my coworkers like a kitchen timer would.

I’m going to continue my current path of using the technique, but I might tweak some things. There are additions I would like to make to my record sheet and I still need to work out a good way to deal with smaller units of time in a useful manner. Maybe a separate series of mini-pomodoros that are tracked differently.


November 14, 2009

I’ve been having trouble focusing a lot recently. When faced with a difficult problem that I can not find an obvious solution to, I tend to procrastinate or shy away from the problem. Other things become important suddenly; like checking email, talking on IM, reading slashdot. All these things do not lead to a productive day.

If I’m not productive, my energy level in general goes down. I notice that when I finish a day of work where I felt like I accomplished something, my evenings are so much better. There is less stress, and I feel proud of my work and what I’ve done. Even if I didn’t finish what I set out to do, as long as I’ve made some notable progress I get this effect. But I’ve been failing to do that with a particular problem I’ve been working on recently.

I’m a regular reader of Pragmatic Programmers. I believe that the original The Pragmatic Programmer is probably the best book for programmers around. There’s a new one that is still in “beta” called Pomodoro Technique Illustrated: The Easy Way To Do More In Less Time. It’s a fairly basic technique about time boxing and learning to focus on focusing. The basic technique is to pick a task you want to complete, set a kitchen timer for 25 minutes, then do that task and only that task until the timer dings. This means avoiding any distraction, from checking email to going to the bathroom or answering the phone. Now since things come up that you can’t ignore (the phone sometimes, or a colleague), there’s a system for dealing with interruptions. If you complete the full 25 minutes without being interrupted, both internal and external interruptions, then you mark an X next to your task as having completed one pomodoro. The sense of accomplishment you get at the end of the day is how many X’s you’ve built up.

There’s a free PragPub magazine on the Pragmatic Programmer’s website that has an article in the November issue that talks about the basic technique. You can try it out with just the knowledge in there. I ended up buying the book as a way to really force myself to focus, but I’m sure the basic idea is enough to get many people started.