The Hours Coding Estimate graph gives one approximation of how much time has been spent programming. If you learn one thing about it: the approximation is likely to be lower than the actual time spent programming. We expect to incrementally improve the measurement over time, and the user can participate in improving their own time estimates. Those opportunities are described in depth in the sections below.
Time spent coding is expected to be lower around the holidays
Anyone who cites this graph should begin by recognizing it isn't built to precisely track time. That would require user involvement (out of the scope of GitClear's current concerns). Its purpose is to help individuals get a directional sense for how much time has been available for, and spent on, coding (vs meetings, messaging, and other obligations).
In spite of the graph underestimating time as of its beta launch in 2024 Q1, it is provided on the basis of providing certain some types of utility:
The error in the calculations (generally 10-30% as of its beta launch, Q1 2024) is systematic. Given that "unaccounted time" is a constant factor, the derivative of this chart can be expected to provide signal. That is, the directionality is likely to trend toward accurate when viewed over larger time frames.
If users care sufficiently, they can audit their time spent per commit to improve the accuracy
It had been a repeated request by programmers to estimate their own time spent coding
Also, for those who track their Diff Delta velocity, it can be useful to explicitly see the quantity being used as the denominator in that derivation.
linkWhy does the graph underestimate actual time used?
Time estimation is discussed at depth in our help article on the topic.
As you can learn from that article, if GitClear has few heuristics by which to estimate the time for a commit, then no time estimate will be assigned. Even a small number of commits without estimates assigned can leave relatively large holes in the time estimate for its day and week.
The best way to isolate and amend commits without a time estimate attached is to visit the main "Code Review" tab, with the full list of commits for the resource. From here, you can filter on commits that have not had a time estimate deduced:
Below the Commit Activity Browser, the commits list allows filtering on commits that don't have a time estimate
This will provide a list of recent commits without time estimates. You can click through each commit to see its content and provide an estimate on how long it took to author. If users request it (by voting on our feature voting board), we could also update commits so that the time used for a commit could be edited inline.
linkDeveloper friendliness considerations
If developers believe the chart is being misused against them, that would drive us to discuss paths by which to adapt the chart to avoid those situations. Initially, we are launching it with the same limited view access described in our Policy on Developer-Friendly Analytics: this chart has restricted access on an individual committer-level. The data for the chart is presented by team, and Managers are encouraged to consider team-wide hours available for coding.
The more time the team has available for coding, especially when that time is uninterrupted, the higher that developer velocity can climb
linkWhat are the plans for v2?
We improve the incrementally improve this graph to the extent that users find it useful. Since only a few programmers have asked for it, we haven't spent a great deal of time crafting and refining it as yet.
If customers find it useful, there are many ways the precision of the measurement could be improved. For starters, one could allow developers to install a VS Code or Jetbrains extension that automatically tracks time in the IDE, to the extent that is what the user wishes to measure.
We could also update the estimation so that, when unknown commits are received, we insert a placeholder value, like the median value of all commits for the day.