Live data from Hacker News

How Not to Do Time Tracking for Software Developers

7pace.com

121–130 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#121

Earlier quoted context omitted.

Interesting comparison. With a film, you normally don't start production without a script. You also appoint a director that (hopefully) is fully responsible for the vision of the project. In comparison, with software, we often don't know what we want to build except in vague terms. It's a bit like one of those failed movie projects where they know they want to make a Superman film, but they don't actually have a scri…

What? A script is exactly like a vague description at the start of a software project. It doesn’t detail what sets are built, costumes, who will star, how much it will all cost, who will be hired, where the lights go, the music, and a 1000 other things. Your comparison is silly.

A script contains a description of exactly what will happen from the start of the movie to the end. It contains all of the dialog. It contains descriptions of the important interactions with external entities like the location and any props you will need.

I was suggesting that the script is a bit like what we used to do when we wrote requirements documents. I doubt many people do it any more, but a long time ago we used to describe all of the workflows for an application before we did any design even. It was a description of exactly what would happen in every scenario. Sometimes it would have UX descriptions, but often not -- those would come later. This almost always fails because usually people's initial ideas are poor and it takes iteration to come up with a product that actually works well.

I don't think it's too far of a stretch to compare a script to a requirements document. Of course apples aren't oranges even though they are both fruit. You can find commonalities in anything and also differences. My main thought was that the OP suggested that filming a movie required complete control over the process, even though it was a lucrative endeavour. I thought, what's the difference between a movie and a software project, then? Are we missing opportunities because we don't apply enough control?

I don't think so. I think a movie project has a lot more information about what they are building before they start than a software project. That's the reason that control works better for them. However, I do think that software projects often lack vision because often nobody is responsible for that vision. Interestingly, as I said, movies appoint someone to be in charge of the vision of the project. Would the same thing work on a software project? I think it would.

If you think that my comparison is silly, then how do you rationalise the OP's claim that control is necessary for making a movie, while it appears that control is something we want to avoid for software projects? Or do you believe that software projects do require control in the same way that film making does?

Re: How Not to Do Time Tracking for Software Developers

#122
post #67

Earlier quoted context omitted.

Couldn't agree more, I also can't reliably track the context switches when contracting. The only thing that works for me is to let my app give me a reminder every few minutes. I used Toggl and set it to 15 minutes. It's annoying most of the time, but it also saves my butt routinely, and is the only thing so far that's worked reliably.

I do exactly the same thing, but when you think about it, isn't this just a pomodoro? You work for 25 minutes. An alarm rings. You take a 5 minute "break". In reality, in that "break" I quickly write down what I accomplished in the last 25 minutes and update my TODO. I also look at my DONE tasks in my TODO list and think about what I was doing and why. I've often found this kind of retrospective to be valuable. I'll…

I'd have to think about the pomodoro thing. Maybe, but I developed an almost unconscious reflex to hit the 'ok' button on the timer to make it go away. I would try very hard to not have it make me think about anything, just confirm which task I was in the middle of. The main thing it caught was when I hadn't re-started a timer after finishing something and stopping it, and when I switched tasks without telling the timer. I'd take a second to fix it, but not stop to reflect, nor break down my tasks. After the first reminder, I'd try to ignore them again.

Re: How Not to Do Time Tracking for Software Developers

#123
post #59

Tracking time is part and parcel of being a consultant, at least if you have multiple clients and overlapping work. After doing it for 15+ years, I've tried it all - everything from the spreadsheet, to the apps, to forgetting and having to go back and reconstruct. I read this article and I think it's missing the point about what's so hard about time tracking. What's hard is: Implementing the trigger on the context sw…

I’ve stopped doing it reactively and instead take 30 mins at the start of my day to roughly plans out when I’ll be doing things in my calendar.

I get a notification 15 mins before a task change occurs so I can decide either to continue because I’m on a role (often not the case, actually just flailing at a bug) or move on.

If plans change I can usually retrofit my day as the calendar reminds me of the general structure.

It’s worked significantly better for me than reactively tracking my time unless the task length is small e.g. sub 30 mins (something like marking a single students work).

Re: How Not to Do Time Tracking for Software Developers

#124
I just went through this with a client. They have something called Team Work which is fine for tracking hours. What wasn’t good is they wanted all time accounted for and they wouldn’t let you add new tasks, management had to add them. So if you wanted to fill out the task honestly (“changed font”), you would need to get the PM to add the new task. So to record 20 minutes of “new task” would require at least another 20 minutes to find the PM for that project and have him add it.

I eventually solved the problem by telling them I would finish the current project but “this isn’t working for me”. Poof, no more time tracking requirement.

Re: How Not to Do Time Tracking for Software Developers

#126
post #106

The crux of the story is this sentence: "They’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team." This is true for every company, no matter the tool. This could equally apply to a Methodology, meetings, deliverables, timelines, or any other top-down approach designed around coercion. I'm reminded on Tom DeMarco's t…

In Film production control is crucial, because although the returns might be huge, only control allows you to get the best out of a limited budget. Good control means also to know precisely where to leave creative freedoms, otherwise you will end up exactly with a bad version of what was planned.

I always smile when I notice shots that look expensive and don’t seem to add much. It would have been a slam dunk for a bean counter to kill each one in isolation. But without any, it would be a much weaker film. Either directors have a lot of power or producers are remarkably sophisticated about leaving some “waste” on the table.

Re: How Not to Do Time Tracking for Software Developers

#127

Earlier quoted context omitted.

Caveat though: in a competitive market, all projects will tend to move towards margins of Project A (or worse). When all low-hanging fruits are long gone, and bosses are still trying to optimize some more, tightening control to eliminate variance starts to make sense... for the company. It seems to me that human values like happiness and respect can only exist where a market isn't efficient yet. It certainly seems so…

Isn't the point of unions/minimum wages designed to artificially lift the floor (or lower ceiling of efficiency) of an efficient market to keep human values of happiness and respect decent? I suppose then you're still left with competitiveness between countries.

I think that would be their (unions/minimum wages) stated purpose, though in practice, implementations have their own set of problems (e.g. unions being corrupt and acting as rent collection instead of being the counterbalance to market optimization, minimum wage being too low, etc.).

Re: How Not to Do Time Tracking for Software Developers

#128
But the best came at the end:

"If you really want to demoralize your engineering team and galvanize their distrust for time tracking and management, then you can use their time sheet data against them.

Call them into a meeting. Pour over their time entries line by line and pick apart how they spent their week."

=> Useless meetings are much worse than useless timetrackers.

Re: How Not to Do Time Tracking for Software Developers

#129

Nothing beats that time our company had us filling out 3 different time tracking systems at the same time and complaining that some of us were adding time tracking as a task that required time tracking.

And there I was feeling weird having to manage 2 time trackers at work.

Re: How Not to Do Time Tracking for Software Developers

#130
post #72
post #59

Tracking time is part and parcel of being a consultant, at least if you have multiple clients and overlapping work. After doing it for 15+ years, I've tried it all - everything from the spreadsheet, to the apps, to forgetting and having to go back and reconstruct. I read this article and I think it's missing the point about what's so hard about time tracking. What's hard is: Implementing the trigger on the context sw…

I have this in a cron: * 08-23 * * * ~/.local/bin/with-i3 '~/.local/bin/record-active-window' this is record-active-window: # set LOGFILE to whatever place you want to record things. echo "DATE = $(date +%s 2>&1)" >> $LOGFILE echo "IDLE = $(xprintidle)" >> $LOGFILE xprop -id $(xprop -root _NET_ACTIVE_WINDOW | sed 's/.*# //') WM_CLASS WM_NAME 2>&1 >> $LOGFILE this is with-i3 #!/bin/bash source I was too lazy to figure…

I did something similar and found it to be useless for how I work. I even wrote a second tool in Rust that uses the WINAPI (throwback to 1998 when I last used it). Sure, numbers might be 50% correct, but maybe they're not.

Say I'm supposed to write some code, so the IDE should be the front window. But I get carried away trying to test an edge case, so I spend 4h in a shell doing stuff that's 100% related, but not in the IDE. Not really a contrived example. Or spending 3h in a browser researching something and reading docs and forum posts about $software when I was supposed to write a one liner fix.

TLDR: Didn't work, gave up with it.

Post reply on HN