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

111–120 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#111

Post by manicdee »

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…

I use the Pomodoro Technique and Rescue Time.

Pomodoro forces a context change, every half an hour. This way I don’t end up yak shaving for half a day when all I needed to do was realise that this solution would require yak hair, go find a different solution.

Rescue Time helps me figure out what I was doing as a kind of forensic tool. There’s heaps of prodding and follow up available in the premium package (apparently), but for me just knowing that I will need to explain to myself why I spent three hours on HN and Reddit today helps me stay away. Mostly.

Re: How Not to Do Time Tracking for Software Developers

#112

Post by mikekchar »

dahart wrote: post #67
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…

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 notice that there is a better way to accomplish what I'm doing, etc, etc.

As crazy as it sounds, I've even experimented with 5 minute "pomodoros" using this technique - 5 minutes on and 1 minute reflecting. What can you do in only 5 minutes? When I first started it was hard to think in those terms, but as I got better at it, I realised that almost everything I do takes less than 5 minutes. If it takes more, then it's an indication that I need to rethink my approach.

For example, if I'm reading code, it makes sense that it would take more than 5 minutes, so I'll make a goal -- find out how X works. If I'm not finished in 5 minutes, in my 1 minute retrospective I think, "Am I approaching this task in the right way? Is there a better approach?" If no, then the next 5 minutes will be the same as the first. However, I often find that having that break snaps me out of doing unnecessary things.

I can't do the 5 minute thing every day (it is exhausting). I'm dramatically more productive with it, though (surprisingly so). It's made me realise that these kind of enforced reflection periods are really valuable. While you are reflecting, it's easy to write down what you just did, so it's kind of 2 birds with 1 stone.

Re: How Not to Do Time Tracking for Software Developers

#113

Post by _bxg1 »

welder wrote: post #101
_bxg1 wrote: post #55

I just make mine super vague. I put in the number of hours I was in the office, and I summarize most days with some variation on "Made improvements and bug fixes". That's the only way I can spend time doing anything other than actively writing code without stressing out about it.

Sounds like WakaTime can help you. It's an automatic time tracker for programmers, but the part you would like: It shows when you started and stopped working for the day. An example chart: https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...

I just look at the clock when I arrive, round to the nearest quarter hour, and unless there's something pressing I leave 8 hour later

Re: How Not to Do Time Tracking for Software Developers

#114

Post by mikekchar »

atoav wrote: post #106
JamesLeonis wrote: post #88

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.

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 script and are constantly rewriting as they go. Also, unless you have a very enlightened group, usually there is nobody that is responsible for the vision of the project except in very vague terms. If you have a question, "Should we collect the user's login data before we allow them to see the welcome splash screen?" usually nobody knows. When someone makes a decision, it's not necessarily due to having an overall vision of how the product works, but more a random choice. Often the people making the decisions about how the product will work are marketing, sales or management figures, instead of people on the creation side of the equation.

I think the latter issue can be fixed and I think it would go a long way towards making better products. The former issue, though, I think is not fixable. We tried the "analysis upfront" approach for decades and it never worked well for software. Usually you can't tell what you need until after you built it at least once.

Re: How Not to Do Time Tracking for Software Developers

#115

Post by megablast »

mikekchar wrote: post #114
atoav wrote: post #106

Earlier quoted context omitted.

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.

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.

Re: How Not to Do Time Tracking for Software Developers

#116

Post by spion »

jms wrote: post #108
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…

Have you come across arbtt? It's a script that pretty much does exactly the same thing, but comes with a few extras for categorization and analysis.

I don't like arbtt because it has an undocumented binary log format making it unnecessarily difficult to build tools on top of it. Its documentation in general is also poorly written.

This is not perfect either, but its just a little extra work to convert it to JSON and put it in elasticsearch to use kibana on it.

Re: How Not to Do Time Tracking for Software Developers

#117

Post by vonseel »

ralmeida wrote: post #92
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…

The Timing app for macOS (no affiliation) does essentially that, and then displays in a timeline of sorts. When one really needs to track time spent on tasks/projects, a quick after-the-fact look at the timeline makes it easy to spot blocks of "downright coding", "wondering how to do something", etc. The UI is great for that as well - identify a block that is made up of several 1-minute back-and-forths between browse…

That sounds like a great app, thanks for the tip

Re: How Not to Do Time Tracking for Software Developers

#118

Post by jakecopp »

TeMPOraL wrote: post #96
JamesLeonis wrote: post #88

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…

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.

Re: How Not to Do Time Tracking for Software Developers

#119

Post by dahart »

wolco wrote: post #102
dahart wrote: post #74

> It’s like the company’s way of saying, “Sure, we trust you to do your job….but–just in case–we’re watching you.” This feels hyperbolic. There are legitimate reasons to measure time spent, and it doesn't amount to lack of trust. And similarly, failure to meet time expectations doesn't amount to shirking or lying. That said, I personally think it's wise to track your own time for a variety of reasons, one of which is…

I didn't realize that most were working 9-5 or some variation or less in the game industry. Do you find on most days you usually work 8 hours and leave. You work an hour extra one day but leave an hour earlier on friday?

I wouldn't generalize to the industry, this data point is specific to one studio I worked at. And most were working some overtime, just not quite as much as they thought. Only a minority were working 40 or less.

Personally, I was working much more than 40. I thought I was working 75-80 hours, but it was closer to 60-65 at the time. It legitimately felt like 75 even though I know exactly what 80 hours a week feels like, even though I had worked those kinds of hours for long stretches before that.

One of the issues is that during crunch when people start staying late, often they start coming in later as well, so the day slides. The studio would buy dinner at 7 for the employees staying late, so quite a few people would roll in around 10:30 and leave after dinner. They felt like they were working a lot of overtime because they were staying late, but not accounting for coming in a bit late.

Re: How Not to Do Time Tracking for Software Developers

#120

Post by acutesoftware »

wdfx wrote: post #15

I took the approach of recording the type/category of work I am doing, and time it exactly using a tool I created for the purpose: https://doug.pacifico-hammond.co.uk/software/hardware/2018/0... As a lead/director it is rarely useful to know exactly which task I am working on, but better to know that I spend the right % of time on each project or type of work.

Nice! When I first saw this, my initial reaction was "cool but why would I do that". Thinking about it - it would be better than most software approaches due to the 'lower mental cost' for logging time.

Even adding a spreadsheet row with macros takes a few clicks, but simply reaching over and pressing a physical button would be the fastest way to do this.

Post reply on HN