Live data from Hacker News

How Not to Do Time Tracking for Software Developers

7pace.com

61–70 of 136 posts

Re: How Not to Do Time Tracking for Software Developers

#61

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.

I wouldn't read that much into it without even asking for elaboration, "it fell apart" can mean a lot of things including "they messed it up after I left". That it really just fell apart under its own weight without anyone doing anything is probably the weakest plausible interpretation of what they wrote. After all, if it brought in $100M/year yet was of low quality, why didn't they hire some people to recreate a bet…

Well he did said

> fell apart without me

Re: How Not to Do Time Tracking for Software Developers

#62
post #45

Earlier quoted context omitted.

Many products have a key person. It's not really surprising.

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.

Re: How Not to Do Time Tracking for Software Developers

#63
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 terminals to remote machines (robots, shared VMs, etc) where it is neither practical nor desirable to install vim plugins hooked up to my personal time tracking setup.

So I'd love for the observer to be able to be able to also watch my remote shell sessions and record things like which file paths I'm editing and commands I'm invoking, from which I could fairly easily construct rules about which general problem area I'm working in.

Re: How Not to Do Time Tracking for Software Developers

#64
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…

So a manager!

Re: How Not to Do Time Tracking for Software Developers

#65
I have a problem with these articles often not because I disagree in principle that knowledge workers need to lose autonomy and become mere pawns of management, but because the authors so often argue something like: Our job is so different and special from manual labor that we deserve special privileges and respect.

All workers deserve autonomy and respect, should resist work "speed ups" at management's insistence, and should demand sane working conditions. We should show a united front across all sectors, not try to claim that our job is special.

Re: How Not to Do Time Tracking for Software Developers

#66
post #45

Earlier quoted context omitted.

Many products have a key person. It's not really surprising.

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

That depends on why it fell apart, and what he would have done about it.

Here is one possibility. The developer checked on the lead system every day, which mostly ran itself. After the developer left, they checked a few times and then stopped looking at the lead system's reports because it was always good. Then months later another team replaced a key system that the lead system needed. Nobody noticed until sales reports sucked. By the time they fond and fixed it, they lost $X million and the people who got fired got fired for not having followed the recommendation to keep the system monitored.

I've seen variations of that story before. And I've seen companies get hurt because of it.

Now there might be blame for the developer. But there are enough ways that the developer wouldn't deserve blame that I wouldn't assume the worst.

Re: How Not to Do Time Tracking for Software Developers

#67
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.

Re: How Not to Do Time Tracking for Software Developers

#69
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 feel like it'd be nice to have a foot switch or hardware you can plug in to USB with maybe 5 buttons and an accompanying app. Maybe you can tap these buttons to switch the counter and press the active button again to pause the current counter.

I still feel like some type of foot switch would be better though.

Re: How Not to Do Time Tracking for Software Developers

#70

Fuck everything about these breathless, one-sentence-per-paragraph articles. It's infuriating to read.

In this case it's a real bummer because it's as if a perfectly fine article was then cut into little pieces, with some of them swapping position. It takes very little to improve it lots, e.g.

> We’re outspoken advocates for tracking time. After all, we are a team of software developers who willingly and knowingly created an application specifically for the purpose of time tracking, right? Our philosophy is simple: time tracking is like fitness tracking, it’s a way for you, as an individual, to assess yourself. We think that it’s totally normal and healthy for developers to want to own their time in a quantifiable way, measure their own abilities, and master their craft.

> But it’s no secret that most developers have a visceral reaction to the very idea of tracking time, and the truth is that most companies do time tracking entirely wrong. The reason why developers hate tracking time so much and fight tooth-and-nail against the idea of having to log hours is because companies have royally screwed it up, 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. 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.” What kind of employee-employer relationship do you think that creates?

> With almost anything in life, there’s a right way to do things and a wrong way, and time tracking is absolutely no different. It can be an effective tool for helping developers own and improve their own abilities, but only if management resists the temptations to use it in other ways. In most cases, if the developers on your team hate time tracking, it’s because of how it’s being implemented (or because they have PTSD from a previous job where it was implemented poorly.)

Post reply on HN