How I use time tracking for continuous improvement

How I Use Time Tracking for Continuous Improvement

You have heard about time tracking for developers, but are using taking full advantage of the collected data? Booking 15 minutes a week to look at your timings can have a big impact on how you work.

Developer timings rather than a tool for control should be about advancing your ability to attain mastery.

Time trackers don’t need to be about making you feel proud about the hours spent coding or guilty about distractions and time wasted.

Their data can help you understand how you spend your time and point out areas where it’s worth improving.

What follows is a series of learnings and observations after collecting time tracker data from several projects over the last two years. Screenshots have been taken with CoderMirror, a project I started with the goal of creating a time tracker with a focus on continuous improvement for developers.

Explore the timings

Initially, I start looking at branches. There is usually a 1–1 relationship between branch and task and from there I drill down into the details.

When there is an outlier and if the task took longer than expected, the first question I always try to answer with the recorded data is why.

The branch report shows a coding timeline, times, files and a log of files accessed while coding. Often that is enough to remember the key details and understand how time was spent, why and seek solutions if needed.

In other situations, the key to improvements is in more general reports.

Typically, time spent reading the code and with the IDE in the background dominates, but an unusually low percentage of writing code time is often caused by poorly understood specifications, unfamiliar technology, a difficult to extend code base or interruptions.

Prioritize Opportunities for Improvement

Time spent on layers or time spent in domain vs infrastructure code helps to rank what kind of improvements affect your productivity the most.

Time spent in infrastructure code serves as a hint that time searching for useful libraries for your problems or in-depth learning of your framework of choice might be good investments. Something that might not move the needle on productivity if most of your time is spent on domain code.

Similarly, improving your controllers might not serve to increase your productivity if most of your time is spent on the database layer.

Code sections with high reading times are an indicator to check if refactoring for readability could be useful in those areas.

Once a decision is made, its effectiveness can be monitored by looking at how coding times have changed through time or comparing snapshots between two selected dates.

Look at the Big Picture, not only Coding

Have you ever observed how redoing work just finished takes less time than originally? It is often experienced when coding the same kata several times your completion time decreases significantly with each trial, sometimes a subsequent attempt takes 90% less than that on your first try.

The developer time is roughly split in 95%: decide what to do, understand and solve the problem, figuring out why the code doesn’t work, and 5% typing the code.

A common mistake is to focus exclusively on technology and on measures that affect only typing time while discarding actions that have a greater impact on your times and are not related to technology.

The cost of complete a feature might not have been on the coding part and detailed metrics like read/write/background timings uncover that kind of patterns.

Outside team management practices, more time in the specification or the design phase, talk to domain experts, draw CRC diagrams, discuss alternative implementations before jumping into code are effective approaches to address the situation and help deliver faster.

Time Tracking as a Guardrail

Constant self-improvement requires trying new things and time metrics give an accurate measure of the impact of your change.

When introducing new technologies or techniques time tracking serves as a measure of its effectiveness in helping you reach your goals.

For example, the introduction of a new library is often expected to impact the timings in one application layer, and a lack of improvement in the expected time frame might indicate the action is not working as expected.

Another common scenario is a new technology or technique not applied correctly. It is a scenario I have seen several times when teams introduced TDD or unit testing.

They are deceptively simple practices, that despite being easy to understand they can be difficult to apply in practice because it takes time to get used to the new flow. In addition, effective unit testing requires code with proper object-oriented practices, and a code base without unit tests is likely lacking testable classes.

I have found that 20% is a common metric of the time is invested in unit tests but in a team new to unit testing that number grows significantly. Monitoring the ‘Code vs Test’ report can serve as a guideline to invest further in unit testing training.

Conclusion

Most of the time our perception of how we spent our time and our decisions of what should be improved is right, but faced with competing tasks not always we make the best decisions. Time tracking allows you to challenge and double-check your perception about where are the most promising areas for improvement.

It can take a long time for time metrics to show patterns you can leverage, you have to be for the long run and turn timing retrospectives into a routine.

Once turned into a habit, you will have the confidence to decide what to improve next, what to learn next, objectively, learning from past decisions by measuring its outcomes.

How I use time tracking for continuous improvement was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.