After doing a little research online I found that there is the idea of the “Programmer Log”, which is simply a time and dated log of things that you have done in the day, things that you have learned that are related to your job, and even problems to watch out for as you go through your work day. Also I started to log my days everyday at work and at home for the past month to see what this logging idea was all about. In this short period of time I have found just how much more effective you can become in work and life if you keep track of the things that you have done and encountered throughout your day.
The Premise
Starting to log your day is pretty simple stuff. You just write (or type) the date and time and explain what you have done or even something that you have learned. For instance, I noticed that there was some small differences between a production server that I was working with compared to other development servers at work. I wrote down these differences in my log in detail and then got back to work. Doing this took a whole 20 seconds but what I gained in the long run was input to a document that I created for my entire team on subtleties between environments.
Another example is logging when you start to work on a task or project and then logging when you stop work on those things. This builds a realistic view of how long something takes to accomplish that you can use to make adjustments as well as estimates on future tasks or projects. So, the act of logging is simple; pretty much everything you do write it down with the date and time. Of course, that in itself is the end. You have to use your logs to become more effective.
Using and reviewing your logs
Having a log isn’t enough. You have to go through and review the stuff that you have written down to see if anything needs brought up at a meeting or with other people, a project needs created, another task needs done, or you just want to see how much time it takes to do something. In other words, if you are a GTDer, you are looking for potential “inbox items” that are hiding in your logs. Finding these can be a little difficult at first, but after a few days of reviewing your logs you can pull out meaningful content. Let’s take my above example about the differences between two servers. At the end of the workday I noticed those differences I pulled them out of my logs and added a project to my project list: I then identified some next actions and proceeded to add these actions to my context lists. Pretty standard GTD stuff here. But in reality, this process isn’t “standard” for most people, and because of that potentially meaningful and needed work is missed. Something else nice about logs is that if you are speaking to someone about a certain topic that you have been working with you can always go back and review what you have done (or even what you haven’t done) with this topic. Being able to present the things that you have done in a current team project or personal project, you can then see where to go next.
Becoming more effective
The definition of effective is: Keeping a detailed log helps you produce intended results in projects by tracking what you have done, the time that it took to do it, and anything that came up in the process. Being able to look at these logs when you approach a project gives you the data you need to make decisions on next actions as well as how long something will take. In personal projects it may not be as important to decide how long something will take to complete, but if you work for “the man” or even your own business, having realistic outlooks on the time a project will take to complete is invaluable and one of the only ways to produce the intended result. So, readers, I challenge you take a log of you day for an entire week to see the things that you may miss that are project or action related that you wouldn’t have tracked otherwise. For me, it was an eye-opening experience to track my work for the last month; something that I will continue to do because of the boost in my effectiveness. Give it a try and see how it fits.
