Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Not to Do Time Tracking for Software Developers

7pace.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#131

Post by spion »

wink wrote: post #130
spion wrote: post #72

Earlier quoted context omitted.

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…

You can't just automatically use the results - at the end I group them by window title and look at things that are > 5m

Not perfect but decent.

Re: How Not to Do Time Tracking for Software Developers

#132

Post by wink »

spion wrote: post #131
wink wrote: post #130

Earlier quoted context omitted.

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…

You can't just automatically use the results - at the end I group them by window title and look at things that are > 5m Not perfect but decent.

Of course I did some post-processing, didn't really help - for me - as I wrote.

But just take the category "browser usage" as an example.

Semi-relatedly, one reason I hate web apps for "persistent" things that should be standalone, e.g. stuff like Slack or E-Mail. Not only does it not fit my mental model with alt-tabbing, it also lumps this uselessly together like "GUI usage vs CLI", so broad is "browser".

Re: How Not to Do Time Tracking for Software Developers

#133

Post by wogg »

mikepurvis wrote: post #63
bm98 wrote: 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…

100% agree with the trigger being the hard part, and with wanting the observer robot. I know there are partial solutions (RescueTime is a big one) which watch your text editor, or watch your web browser, or suck in meeting data from your calendar, but I've never really been that happy with them. The further complicating wrinkle for me personally is that I work at a robotics company, so I spend a bunch of time at ssh…

If you have RescueTime window titles / details enabled for your terminal app, and have configured your terminal app (if it supports it) to promote active shell command to window title, you get this details, regardless of where you are ssh'd to. Works for me at least on macOS + iTerm2.

Re: How Not to Do Time Tracking for Software Developers

#135

Post by spion »

wink wrote: post #132
spion wrote: post #131

Earlier quoted context omitted.

You can't just automatically use the results - at the end I group them by window title and look at things that are > 5m Not perfect but decent.

Of course I did some post-processing, didn't really help - for me - as I wrote. But just take the category "browser usage" as an example. Semi-relatedly, one reason I hate web apps for "persistent" things that should be standalone, e.g. stuff like Slack or E-Mail. Not only does it not fit my mental model with alt-tabbing, it also lumps this uselessly together like "GUI usage vs CLI", so broad is "browser".

Window titles are recorded by this script. I wonder if you noticed this? You could have pretty decent filters with those, e.g. you can get a result for "time spent reading comments and writing on hackernews". If I use slack in the browser, i can even get the time i spent talking to different people / channels.

Re: How Not to Do Time Tracking for Software Developers

#136

Post by Bartweiss »

stesch wrote: 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.

Back in school, I worked part-time for a group that used limited time tracking; you input when you worked and how many hours per project, but didn't have to match hours to tasks. The one minor flaw in this program was that it didn't let you pick your hours worked - it simply asked for a single start and end time each day. Working two hours in the morning and two in the afternoon was impossible to input.

Blessedly, it was an internal tool rather than a way to track client billing; the standing instructions were to just choose some random block of hours corresponding to your total time worked, so that you could get to the project-hours fields that actually mattered. But internal usage also raised the question of why they were voluntarily keeping a tool slightly less effective than a century-old punchclock.

Post reply on HN