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

81–90 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#81

Post by TeMPOraL »

mercer wrote: post #30
Klathmon wrote: post #14

I'm curious if anyone here has had success with more "coarsely grained" time tracking? I've found that I'd have no issues tracking my time by day or at most half-day increments, especially since for the most part that's how I end up working on things in a lot of cases (as a developer, not a manager). I feel like it would give most of the same benefits with a magnitude less work, but I haven't ever tried it out in a r…

I've had mixed results with more coarsely grained time tracking. On the one hand I'm more likely to actually do so when I don't have to clock in and out all the time. On the other hand, I kept forgetting to clock in or out because it wasn't 'regular' enough to do it automatically. These days I use Emacs org-mode for todo items and time tracking (+ pretty much everything else), which makes it much easier to be extreme…

> That said, I try to keep myself from calculating how much time I 'need' to save to offset the time it took me to get everything set up and to get comfortable with Emacs/Org-Mode ;).

Between increased efficiency, less proverbial papercuts from alternative ways of doing things to cause your death, and things you just didn't do before you reduced your friction, switching to Emacs/Org-Mode has probably paid for itself many times over :).

Re: How Not to Do Time Tracking for Software Developers

#82

Post by quickthrower2 »

I quit 3 jobs in the last 5 years and time tracking by management is high up on the reason list. I will now refuse to work for any organisation that does it.

The code and design quality turns to shit in such places. Everyone is trying to keep to the beat of their allotted time. Here’s your shovel. Dig a tonne of soil. You have 2 hours. No one is thinking of hiring a JCB because well thinking about that takes time from your time tracked task.

Places that don’t track time probably get better results although they can’t prove it with metrics. Compare it to parenting, why aren’t we timing nappy/diaper changes? Oh because it’s mostly instinctive. A bit like programming!

Sure we need to make sure we are on track but this can be done at much a higher level. Story points used properly fill this goal. Where I work we use them but there is no punishment for not meeting the story points. Not even a frown of disappointment that when we added up some numbers from a random distribution, they didn’t add up to some arbitrary number. Story points are a useful indicator, but they are part of a vector of information. We didn’t meet the story points because we worked on some technical debt, because ... for example.

So in conclusion don’t you dare track my time and pull me in a room because I didn’t dig that hole quick enough.

Re: How Not to Do Time Tracking for Software Developers

#83

Post by user5994461 »

mandelbrotwurst wrote: post #62
ryandrake wrote: post #51

Earlier quoted context omitted.

I wouldn’t boast about writing software that “falls apart” by merely not having you around. Not exactly a high quality bar.

Well, if he's the sole maintainer and they don't replace him, falling apart is inevitable. Software dies when its dependencies do and that doesn't imply low quality.

Dependencies take many years to move. It's rotting slowly, not falling apart.

A software that brings a hundred million dollars couldn't fall apart, the company would get guys to reboot the server and have a look.

The rare cases of software suddenly dying is when the source code and/or the setup is lost. The software or the database stops one day and nobody can figure out how to start it again. There is a lot of blame to put on both development and management for reaching this situation.

Re: How Not to Do Time Tracking for Software Developers

#84

Post by whyisthewhat »

commandlinefan wrote: post #75
whyisthewhat wrote: post #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~).

I think this bears some elaboration because I feel the same way, but if we don't talk about _why_ we feel this way, it looks like we're spending our time playing video games and pretending we're working. ("After lunch I just... space out... for a couple of hours. But it looks like I'm working!") I spend a fair amount of time reading documentation; no matter how many programming languages or tools or environments I kn…

I agree that it’s perfectly reasonable to be expected to be able to give an account of how you spend your time. My point is simply that whether or not this becomes an exercise in serf-like dehumanization and Taylorism depends on the fundamental organizational structure of the workplace, not the technical details of its implementation.

Re: How Not to Do Time Tracking for Software Developers

#86

Post by [deleted] »

QuadrupleA wrote: post #50

Sorry, couldn't get past the arrogant know-it-all writing style. "With almost anything in life, there's a right way to do things and a wrong way." Is that so, Socrates? I'd say the opposite, with almost anything in life there are complex and subtle tradeoffs and many good alternatives. Absolute, black-and-white thinking (and writing) is comforting but narrowminded.

[deleted]

Re: How Not to Do Time Tracking for Software Developers

#87

Post by WilliamMayor »

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 found the context switch trigger too hard a problem to solve. The real problem for me was that I found any app that tried to watch me work just too creepy. So then any simple app required lots of manual effort.

I built myself a solution that means I can add events to a calendar that describe my day. Different calendars for different clients and different event titles for each project.

This worked well for me and now I’m trying to build it out and sell it. If you’re interested it’s here: billabl.co. I’ll warn you though, it’s early days and likely to break (although I’ve been using it for years).

Re: How Not to Do Time Tracking for Software Developers

#88

Post by JamesLeonis »

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 thoughts about Control and what kind of projects need such controls [1]:

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

- Project A will eventually cost about a million dollars and produce value of around $1.1 million.

- Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.

[1]: https://www.computer.org/cms/Computer.org/ComputingNow/homep...

Re: How Not to Do Time Tracking for Software Developers

#89

Post by mixmastamyk »

commandlinefan wrote: post #75
whyisthewhat wrote: post #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~).

I think this bears some elaboration because I feel the same way, but if we don't talk about _why_ we feel this way, it looks like we're spending our time playing video games and pretending we're working. ("After lunch I just... space out... for a couple of hours. But it looks like I'm working!") I spend a fair amount of time reading documentation; no matter how many programming languages or tools or environments I kn…

Part of being a mature "senior" developer is to stop budging on estimates. Give an estimate to the best of your knowledge. Don't budge. If there is not enough time, cut back on scope, not necessary tasks like research. Cite Steve McConnell if you need back up.

Re: How Not to Do Time Tracking for Software Developers

#90

Post by kbsletten »

WilliamMayor wrote: post #87
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 found the context switch trigger too hard a problem to solve. The real problem for me was that I found any app that tried to watch me work just too creepy. So then any simple app required lots of manual effort. I built myself a solution that means I can add events to a calendar that describe my day. Different calendars for different clients and different event titles for each project. This worked well for me and no…

Minor bug, but it looks like all your call-to-actions on the features page are too large. (FF on Pixel 1)
Post reply on HN