I developed Chronos, a task management tool, to manage my personal task lists, compare execution strategies and project future delivery dates. Specifically, I wanted a local-first task app where I could quickly update estimates, add and reorder tasks, and see a calendar of projected completion dates.

One thing I quickly realized when building Chronos was that, almost for free—so long as I kept the task estimate for the current task updated as I worked on it—Chronos would accumulate a reliable record of my historical day-to-day on task time.

I’ve been eating my own dog food in 2021, so I now have an accurate history of all of my on-task days for the year. As the year is almost to a close, now is a good time to look back and ask—professional speaking, did I do anything of value?

For fun, I’ll generate a random date from 2021 and look at my Chronos history to see what I was up to:

$ date -j -f %Y-%m-%d -v +$((RANDOM%365))d 2021-01-01 +%Y-%m-%d
2021-06-17

What was I doing on June 17th?

Here’s a screenshot of my task list in Chronos, representing some tasks that I completed in June:

Note: I’m going to have to obfuscate my data a bit, as my weekly tasks come from my full-time salaried position and I don’t wish to leak any proprietary information.

Here, I’ve blurred out the other tasks and obfuscated the focused one’s description by translating it through multiple languages, which is why it reads a bit hilariously: “Strengthen the management and development of the governor of the central bank”.

I don’t know how “central bank” came out in the translation; I’m not in the banking sector1; but the obfuscated text at least captures the essence of what I was working on: an implementation task that wasn’t testing or bug-fixing, for example. So on June 17th, I was working directly on the implementation of an actual feature—always good to know2.

A few things in the Chronos UX. To the right of the task description are task links (); in this case, one is to a Github pull request related to this task and the other to a related issue in my team’s collaboration system (Jira). This was all useful data at execution time and remains relevant for our forensic historical data analysis.

The calendar on the right shows the actual on-task days for the task. In fact, I can walk the entire lineage of my tasks for the year and see the on-task days for each one:

Once again, apologies for the blurred view—just note the calendar highlighting. As focus moves from task to task (on the left), the calendar highlights the corresponding days on-task (on the right).

One thing to glean from this blurred view is what a real-world task list looks like from a distance.

Real-world software delivery is a messy affair but, by following a simple process of using estimates to check off tasks, Chronos makes it straightforward to produce a reliable record of personal day-to-day on-task data over time.

One thing of interest with my June 17th task is that I didn’t complete the task on that day; I was interrupted and switched over to a “discovered” task related to a dependent “caching” need.

(This “caching” task is blurred out in the screenshot above, but I can see from my task lineage that I eventually returned back to my original task after a four-day interruption.)

This gives me an idea about what might account for some inaccuracies in my 2021 planning and delivery3 that I can leverage for improvement going forward.

For a simple first analysis I’ve categorized my 2021 tasks into coarse-grained categories:

  • Implementation (86 on-task days) design and code tasks for core features delivery
  • Testing (40 days) tasks to design, implement and pass unit tests
  • Bugs (26 days) tasks related to bug fixing post feature-delivery
  • Discovered (50 days) tasks (both impl and testing) not in original plan for core features

Historic data is notoriously useful for producing accurate future estimates; not only will I consult my task history when estimating future tasks, but I can also make some macro observations from this end-of-year vantage point.

Interestingly, 25% of my year was spent on discovered tasks, tasks that didn’t make it into the original plans for my core feature deliveries.

After further analysis of my task history, most of these discovered tasks occurred due to faulty assumptions about system dependency capabilities: features I’d assumed existed in core infrastructure that would serve my top-level feature delivery. This is certainly something to feed into the 2022 checklist, to improve planning accuracy where needed.

Another note of interest here is that my time spent on Testing comprised less than half of my overall Implementation tasks. Whether or not this is meaningful is highly context-specific; for my project, I know this is on the short side and I’ll likely start the year off with an audit of test coverage over the relevant features before product ships.

What else can we do with personal task data?

While this personal data is extremely valuable for estimating and predicting future outcomes, it can also be used to objectively answer questions about personal performance and throughput, including:

  • Negotiating compensation and career advancement. Day-to-day personal task data can also be used as an objective basis for negotiating compensation or career advancement with our manager or employer. Trying to pitch our worth without accurate data can be lossy and difficult, as otherwise we’re left stitching together an imperfect recollection of our historic on-task time.
  • Reviewing on-task data for self-improvement. Just as different code implementations have better or worse runtime complexities and architectural qualities, the iterative steps and strategies we spend delivering value are at risk of being severely non-optimal in time if we don’t look at them reflectively, or even have our plans reviewed by competent peers.
  • Keeping ourselves focused and honest. For the entrepreneurial-minded, especially—continuously evaluating our time with respect to value delivery is essential to keeping ourselves honest to our outcome objectives, and in maximizing our limited time resources. Did we spend our past year, month, or week on the right things; can we do better in the next iteration?

It can be a difficult thing to do—looking at objective personal data—as it might dispel certain imaginations of ourselves or our work. Have we been delivering in accordance to the 10x, or even 1x4, engineer, that we imagine ourselves to be?

Or might we surprise ourselves: maybe our pull request throughput wasn’t up from last year, but, in terms of value delivery and overall strategy, we’re up5—in any case, we can only assess these things with objective data in hand.

Incidentally the kind of reflective analysis described in this post is not an exclusively end-of-year activity for me—not in the least: consulting my on-task past is a near-daily activity that results in a constant reconsideration—via task refactoring, in Chronos-speak—of my future plans.

Chronos was explicitly designed to make this kind of daily dynamic planning a fluid and integral part of the developer workflow.

Try Chronos

If you’d like to try Chronos, you can download it for a free twenty-day trial. The Chronos tutorial is a step-by-step introduction to using Chronos effectively.


Footnotes

0 Chronos will highlight on-task dates for both past and future tasks.

1 Or am I? 🤔

2 As dutiful software engineers, we know that there’s other important work beyond just writing implementation code—unit and system testing, refactoring & design investment, utility & domain abstraction are all worthwhile activities—but investing too much on tasks other than material delivery has destroyed many a software project and is equally an anti-pattern. Being able to track and analyse our data in this regard and tune our efforts accordingly can lead to significant risk reduction or competitive advantage.

3 Planning and estimates are typically inaccurate until the last moment, but the estimation skill set can be improved and leveraged over time to significant business and career advantage. That’s one motivation for tracking and analyzing objective personal task data.

Software developers that evolve their technical skill set without attention to the estimation and planning skill set do their professional self a massive injustice. For the initiated, Jacob Kaplan-Moss’s Estimating Software Projects series nails it.

4 😜

5 Mastery optimizes Value / LOC over time. The hallmark of the “expert beginner” is lots of code and not much material value at the top. How do you know you’re not stuck in expert beginner-land? ⟶ Analyse personal data objectively, with respect to value delivered.