[7777fps]

Looking through that comparison, I find it funny that "time tracking" is touted as a feature.

My grand-boss might love the idea but the fact that GitHub is missing time tracking is a blessing as a developer.

Making developers track their time is hostile. Development is not something you should clock in and out of. A time-box in JIRA or GitHub shouldn't replace management being aware of what their team(s) are working on and how their progress is.

It too often turns into a stick to beat developers with.

There are all kinds of better metrics by which to hold developers accountable. Tracking time just puts developers off from improving code or refactoring. If you write bad code it's not your time that suffers, it's the next developer who has to work on that section.

[emilycook]

That's interesting feedback, I'll pass it along to the product team, although this is an angle they've probably thought about more than I have. The way we use it isn't really as an accountability metric, more of an estimate that can change dynamically when new problems arise so we can roughly plan out when a feature is going to be released. Granted we don't have a boss who would beat us over the head with that. Thank you for the feedback though I'll make sure to pass it along.

[kirubakaran]

> Granted we don't have a boss who would beat us over the head with that.

For every boss that wouldn't, there are a hundred bosses that would, with very little understanding of what is even being measured. Sure, the "guns don't kill people, gun users kill people" argument applies, but maybe don't hand people free guns with their milk purchase?

[emilycook]

Oh no I agree, that was just a comment recognizing that my experience is different because I'm in a more ideal situation than other developers are surely dealing with. I still passed along the feedback to our product team!

[jshen]

As a "grand-boss", you may want to consider that having visibility into how an organization of a few hundred developers is spending their time is just like being a systems engineer and wanting (needing) to have monitoring of how your system load / resources are being utilized.

More often than not, I use time tracking to manage Sr Executives, and business partners, not developers. It may be invisible to most developers, but your executive probably has to fight for the budget that is funding your work on a regular basis. Having a pie chart that shows where time is spent is a great tool to convince your business partners that they can't cut everything but new feature development. It's sad how often I have to have this conversation.

Don't get me wrong, there are bad bosses, but there are many good uses of information like time tracking that may be invisible to the average developer.

[zimbatm]

Same sentiment here. It would actually be useful if the "time tracking" supported sizing and estimations but right now it's completely focused on precise timing which makes this counter-productive.

[sytse]

Just making sure that you are aware that GitLab supports sizing and estimations via weights https://docs.gitlab.com/ee/user/project/issues/issue_weight....

[CameronNemo]

I still think it would be useful to specify an 95th percentile error value for time estimates. I told my PM that the estimate in jira has an error range once and she flipped. Having that idea backed up by the tools we use would really help planning be more realistic.

[sytse]

That is a great suggestion. GitLab has burn-down charts https://docs.gitlab.com/ee/user/project/milestones/burndown_... that show that progress isn't linear.

What is small change we can make to stress planning has error bands without affecting the usability?

[shrimp_emoji]

From my professor:

>Consider this. What if the repository in which we craft our products is configured with cost estimates in mind? At the moment our logged hours reaches the total we projected, the repo would freeze and we grade the work. How would this affect our work?

>Do you have confidence in your plan? Would you bet your course grade on the quality of a project frozen at that point?

[rgoulter]

> How would this affect our work?

This reminds me of the appetites and bets that Basecamp's "Shape Up" describes. https://basecamp.com/shapeup

Instead of keeping scope and time 'fixed' and sacrificing quality, instead try and keep quality and time 'fixed' but be willing to sacrifice scope.

Having an 'apetite' in mind for how much you want a particular feature then mitigates: if you fail to achieve what you want in the fixed time period, do you want to try again later or is it more effort than it's worth to you.

[lux]

I'm not a fan of time tracking as a managerial stick to keep developers "productive", but there are reasons for tracking time beyond managerial oversight. For example, in Canada accessing any of our grant programs or tax credits requires time logs as part of their reporting requirements.

Fortunately, they actually seem to prefer the reported times to be rounded to the half-hour/hour so the numbers line up with the financials. I think this helps discourage the temptation to nickel-and-dime developers over their time.

[bJGVygG7MQVF8c]

> Development is not something you should clock in and out of.

I agree that imposing time-tracking from above (especially using user-hostile tools or especially employee-hostile management) is objectionable, BUT:

Org mode is fantastic and a great way to organize your day:

https://orgmode.org/manual/Clocking-commands.html

[sytse]

I think time tracking in GitLab originated as a way to track time if you're working for multiple clients, but I'm not sure.

[folmar]

This is what I use it for.