A Day in the Life
In this example, we will see most of the rtimelog commands you would use in a normal day. The
start and stop commands are the minimum that you would need, but we will go a bit further.
To begin tracking a task, you use the start command and supply text to describe the task you are
beginning. The rtimelog program assumes that you are only working a single thing at a time. I
originally tried to support the ability to track more than one task at a time and found that I never
actually used it.
Let’s walk through an example. While walking this example, you will probably find the amount of
typing to be a bit much. The rtimelog program supports features to reduce the amount of typing.
The Customized Day example shows how I would have customized my configuration
for this work. It doesn’t have all of the explanation, so you might want to go there next.
Morning
You’ve just started your day and decide to clear your email before focusing on coding. As soon as you’ve logged in, you start a task named Email in the Admin project.
A project like Admin is useful for administrative tasks that don’t necessarily fit into an actual project. That pseudo-project helps track little tasks that can consume too much of your day if you aren’t paying attention.
A task is made up of several optional parts (at least one of which must be there):
- a project (first group of non-whitespace characters beginning with ‘
+’) - a task name (first group of non-whitepsace characters beginning with ‘
@’) - explanatory details for the task
$ rtimelog start +Admin @Email
One design decision for rtimelog is that it only tracks one task at a time. Whatever task you are
working on is stopped when you start a new one.
After you finish clearing email, you decide to take advantage of the morning quiet and dig into the work on the processing module for the Foo project. This is a fairly intense chunk of work, so you want to take it on when you have time.
$ rtimelog start +Foo @Code processing module
We’re going to call this task @Code despite the fact that you will be doing design and writing unit tests while you work on the code. Those kinds of work can all be collected under Code to avoid wasting time with unnecessarily detailed task tracking.
After about an hour and a half, you are pretty comfortable with the changes to the processing
module. But, you decide to test the impact of the new code on the performance of the system, so you
decide to do a little performance measuring. Since this is a little diversion and you plan to come
back to coding when you finish, you decide to push the old task onto the stack while starting a
new task. This will simplify returning to the coding task when you are ready.
The push command performs two actions. First, it pushes your current task only the stack so that
you can resume it later. Then, it starts the new task that you provided to push.
$ rtimelog push +Foo @PerfTest processing module
We are in the same project, so rtimelog will be able to report the cumulative total of the last
two tasks when generating a report. Since we plan to come right back to coding after the test, let’s
use push instead of start to temporarily move to a new task.
After half an hour, you’ve identified some performance bottlenecks and return to coding in order to
fix what you’ve found. So, let’s resume the coding work. Since it’s been half an hour, you might
want to confirm that you are resuming what you thought you were working on, so use the stack top
command to see what it on the top of the stack.
$ rtimelog stack top
+Foo @Code processing module
Since the last item is code work, let’s resume.
$ rtimelog resume
The resume command restores the task that was current when the last push or pause command was
executed. This way you don’t need to type in the whole command (or up-arrow through your command
history) for short interruptions. Since we pushed the previous task, the resume command is
equivalent to re-typing the original command: start +Foo @Code processing module.
When you finish tidying up the performance work, you decide to move on to the database module. Since
this is not a temporary diversion, you will use start again.
$ rtimelog start +Foo @Code database module
As noon rolls around, it’s time to take a break for lunch. We can use pause to stop what we are
doing after pushing the current task on the stack to resume later.
$ rtimelog pause
Afternoon
When you get back from lunch, you decide to take care of any morning email before your team meeting
at 1pm. You start the +Admin @Email task again.
$ rtimelog start +Admin @Email
Wouldn’t it be nice to start common tasks with less typing? We’ll revisit this in the next chapter.
At 1pm, the conference call with your team begins. You start that task. Since we are going to be
talking about the Foo project, make sure to set the project name appropriately.
$ rtimelog start +Foo @ConfCall Team Meeting
When the meeting is over, you need to change tasks. During the meeting, you agreed to do some general work on the manual for the project’s software. Enter the task to begin working on that.
$ rtimelog start +Foo @Docs working on manual
About 20 minutes after you start on the manual, Emma comes by to ask about the project you worked on
last week. Since this is will be a temporary interruption, we use the push command. Once again,
this will make it easier to restore our task when the interruption is over.
$ rtimelog push +Bar @Help Emma questions
Interruptions for questions are a great use case for push. You want to be able to resume right
back into your current task when you are finished.
When all of Emma’s questions are answered, you go back to the manual work using the resume command.
$ rtimelog resume
A while later, you’ve finished with the manual for today and want to finish up the work on the
database module for the Foo project. Since you paused for lunch, you can once again use resume
to pick up where you left off.
Even though this diversion was hours ago, rtimelog still remembers that you pushed a task. This
allows you to resume to restore the previous task.
Once again, you’ll probably want to check the top of the stack to confirm you didn’t have anything else waiting.
$ rtimelog stack top
+Foo @Code database module
Since the database work was the last thing you paused, go ahead and resume.
$ rtimelog resume
You get some good uninterrupted time on this and finish up the module in time to stop at 5.
$ rtimelog stop
Conclusion
Obviously, using rtimelog adds a little bit of overhead to your daily work. This example doesn’t
make use of aliases which can reduce typing dramatically. The Customized
Day example shows these features in action.
Once you get used to it (and customize the aliases for your work), you will likely find that the overhead is not a big as it seems. The goal of the tool is to provide some benefits to make this extra work worthwhile. That benefit is the ability to see and understand where you spend time during the day through reports of your work.