Live data from Hacker News

How Not to Do Time Tracking for Software Developers

7pace.com

31–40 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#31

I track my time, too, and my biggest complaint is how long it takes. I think it's a great idea for companies to show why time tracking matters so it doesn't feel so futile.

What level of granularity are you required to track? I track how much time a spend working on a particular feature, regardless of the type of work being done. When I take a break or start working on a different feature I make a note of how long I worked since I started. It takes less time than writing a commit comment, which I usually do right before I jot down how long I worked on it.

Re: How Not to Do Time Tracking for Software Developers

#34

I track my time, too, and my biggest complaint is how long it takes. I think it's a great idea for companies to show why time tracking matters so it doesn't feel so futile.

Some companies just want a panopticon. Many of them want to micro-manage, and have weird ideas that software development is a direct correlation between time and effort.

My current company it makes sense to try my best to the hour/half-hour, because we're consultants and that's how we bill our clients.

A past employer for me was the worst of both worlds because they had a consultant's mindset towards billable hours having been born of a law firm, but not the consultant's approach to billing software development work. We were classified purely as "overhead" and not allowed to "bill" our (internal) clients. Meanwhile, despite starting life as a law firm it was by that point mostly a call center, and call staff to lofty law firm partners look like babies that need a strict panopticon.

Re: How Not to Do Time Tracking for Software Developers

#35
post #29
post #11

Earlier quoted context omitted.

Ugh. I don't ever want to work for a company where my time tracking has to be so fine grained that I have to log bathroom breaks. Holy shit that sounds like a nightmare!

I actually worked for a company where they didn't allow me to have a bathroom break during working hours while I was remoting...such is life as a 53yo developer trying to make any kind of living in this industry. In fact, I had to log X keystrokes and Y LOC every hour in order to be paid for that hour...talk about being a factory worker.

I hate to use the "you should be looking harder" trope, but every company I've worked at has had developers at or over 53, and not one of them had such onerous time tracking requirements.

One tracked time to attempt to get r&d tax credits on certain work. The other was an agency that tracked time in case of disputes with unruly clients (such as the time we had gone through 3 project managers and 2 CFOs while we worked with them, and they were desperate to recover money from their own bad mistakes). The rest didn't track time at all.

Not to mention that LOC as a metric has been an industry joke at least since the early 80's: http://www.folklore.org/StoryView.py?story=Negative_2000_Lin... I've heard of funnier versions of that story, but haven't tracked them down yet.

Re: How Not to Do Time Tracking for Software Developers

#36
There is no technical fix that will make managerial time-tracking less of an exercise in control and relentless optimization at the expense of the developer. If you want to preserve some autonomy and dignity, you need to fundamentally restructure the relationship between yourself and management (like with, for instance, a ~union~).

Re: How Not to Do Time Tracking for Software Developers

#37
The "How Knowledge Work Happens" graphic is really what resonates with me. I run a dev shop and I hate time tracking for the complexity implied in this image. Questions come to mind.

What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable.

What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable.

What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time".

Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway).

To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not.

Re: How Not to Do Time Tracking for Software Developers

#39
post #32

At my last employment they had a time tracking software that said that three tasks @ 20 minutes each are 0.99… hours. Hmm. As a software developer you get really frustrated when you have to deal with this expensive piece of software.

I wouldn't be surprised if this was an intentional hack to get around some regulatory bullshit.

>if we don't report whole number cap-ex hours on our return, we'll avoid an audit!

Re: How Not to Do Time Tracking for Software Developers

#40
post #32

At my last employment they had a time tracking software that said that three tasks @ 20 minutes each are 0.99… hours. Hmm. As a software developer you get really frustrated when you have to deal with this expensive piece of software.

Reminds me of the SAP software a previous employer used.

One of my reports worked 4 days a week ... so if they took a half day of leave at any point come the end of the year they would typically have 0.499. or 0.999. left to take.

Post reply on HN