How Not to Do Time Tracking for Software Developers | Hacker News Reader

How Not to Do Time Tracking for Software Developers

7pace.com

152 pointsencorekt130 comments

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 switch.

You're working on one thing, something happens and you make a context switch to something else - and in order to track your time, you need a trigger to fire to prompt you to record the switch. It doesn't matter if it's in a spreadsheet or an app or on a piece of paper - I find that my brain doesn't fire that trigger very reliably. Especially if I'm busy.

If someone can solve that problem with a fancy app, I'd be impressed!

I've said it in another thread [1]: I want a robot that watches me and quietly makes intelligent decisions about what I'm really doing, and tracks that.

[1] https://news.ycombinator.com/item?id=15790918

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 <(cat /proc/`ps -e | grep ' i3$' | awk '{print $1}'`/environ  | sed -r -e 's/([^\x00]*)\x00/export \1\n/g')
  bash -c "$*"

I was too lazy to figure out what env vars were missing from the cron (probably dbus socket) so i copied them all from the i3 process above

That plus the habit to lock the screen while I'm away from it works fairly reliable.

edit: you also have the idle time in case you want to ignore result where you've been idle for way too long (forgot to lock screen)

edit2: a sample log entry (idle is in miliseconds, date is unix timestamp in seconds)

  DATE = 1550608681
  IDLE = 2456
  WM_CLASS(STRING) = "google-chrome", "Google-chrome"
  WM_NAME(UTF8_STRING) = "Edit | Hacker News - Google Chrome"

If only Slack changed the window title when I change chats, I could also track how much time I spend talking where :) The web version does it though, so I might stop using the electron app...

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.

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.

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.

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.

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.

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).

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

Ha! Cheers! I’ve not checked on my phone for a while, that’s definately not right.

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 browser and IDE, drag across that, and enter task, for example.

That sounds like a great app, thanks for the tip

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.

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.

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.

I just gave up on that and use an app that makes it super easy to go back and reconstruct [1]; either a few minutes after the context switch (I just type "-14 Project 2" and it changes the task 14 minutes in the past), or later through a nifty graphical interface.

The provided reports are also great, but if I need anything crazy, I can easily extract the data from the SQLite database.

It's been working for me for many years now.

[1] https://github.com/projecthamster/hamster

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).

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.

I use different desktops for different tasks/clients and have a script that keeps track of which one I'm on.

Using the desktops is an extra bit of information I can use to give context to the robot to help with tracking.

So a manager!

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.

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

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 if you look at worker treatment vs. margins/competitiveness.

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.).

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.

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?

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.

I recommend activity-watch[0] if anyone wants a good, open-source, at-a-glance system of tracking for their own computer usage. It's definitely helped me rebuild a memory of my activities on days that got away from me.

[0] https://github.com/ActivityWatch/activitywatch

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 know, there's always something new to learn. This is true whether I want to learn something new or not - even if I were comfortable just using the stuff I knew when I graduated college, I'll eventually inherit or have to work with something that somebody who knows something newer wrote. As a result, learning new things, reading documentation, experimenting with unknown systems is part of the job - which is completely unappreciated. When I was younger, the managers would ask me what my plan for accomplishing task "X" was and I would start with, "Ok, the first thing I need to do is to learn the environment" and invariably they'd go apeshit when I suggested that I "waste" their time and money on something as pointless as "learning". If I was competent, I'd already know this stuff, and admitting that I needed to waste time reading documentation was sort of an admission of weakness. Of course, being young and naive, I'd try to reason with them but after years and years of having the same circular arguments I finally learned to give bland, inane responses like "research" and avoid giving specifics.

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.

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.

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.)

* I agree.

* I only have time for bullet points :)

I prefer it over an essay on one line, always wrapping, and never breaking for paragraphs.

Part 2 is about how not to write blog posts.

The "How Knowledge Work Happens" graphic is really what resonates with me. I run a dev shop and I hate time tracking for the complexity implied in this image. Questions come to mind.

What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable.

What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable.

What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time".

Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway).

To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not.

Time Tracking to 15 minutes or unicorn points in sprint estimation, beancounters will glom onto it and the stats will be juked, padded, and hoarded.

“When a measure becomes a target, it ceases to be a good measure.”

Time tracking just makes developers better liars. It gives clients the room to be angry, fight contractual obligations, and essentially not pay for the development time.

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

If you are an emacs/org-mode user, it's quite easy to clock in and out of tasks as you work, and generate summary reports of your time.

I've done this with good success when I was required to track my time. If I'm not required to do it, I find that I just dont bother.

I used to have that problem but now that I'm freelancing, I actually take care to always have an active clock running on a task I'm working on. It's even improving my focus in a way - I have a constant reminder in my mode line (both in Emacs and in WM) what I'm focusing on.

The key to making this work, when I couldn't make it work in Jira, is lack of friction. In Emacs, if I want to switch tasks I'm working on, it takes the following sequence of keypresses:

  C-a a -- switch to Org Agenda
  C-s taskn... <ret> -- find new task "taskname" via incremental search
  i -- clock in, automatically clocking out the previously active task
  s -- save all open org-mode files
  q -- close Org Agenda window

It's in my muscle memory, and I can do that faster in there than it takes for a single Jira page to refresh (reason #123 I prefer desktop native over web apps, and don't consider the latter as proper tools).

Org mode for VS Code has timestamps - which I use for keeping a record of when I thought of things rather than time tracking.

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 real situation before and I'm curious if it holds up.

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 extremely granular in my tracking without having to expend much effort. Since I have my todo list in front of me for any task anyways, starting the clock is just one keystroke away.

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 ;).

> 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 :).

I've had great success tracking my team, and my team's time, by the day. On the level of "I'm working on project A, project A is now done and I'm now working on project B." It's obviously imperfect but it's good enough to prevent the edge cases, e.g. somebody spending a month on something low priority.

I only care about coarse grained time tracking on my team. I estimate to the quarter day at the smallest, if any task is smaller than that, it shouldn't be a separate WBS item. After all, my end-of-year bean-counter statistics are all based on person days anyways, and I'm not a consultant, so why would I care about tracking to the 15 minute increment?

I was thinking the same thing about 72 hours ago, I mean 3 days ago. In certain fields, like filmmaking, freelancers don't charge by the hour. They have a day rate. You pay them for the whole day or not at all. Some let you hire them for half a day.

I got into the habit of keeping a daily work log, and continue to do so even though I no longer work for a company that requires it. Very simple: Date, number of hours (0.5 granularity), planned work, actual work done, links to work output or meeting notes (if any). That’s it. It helps me to get back up to speed after a weekend. It allows me to tell you what happened on that day X months ago when we were in the middle of project Y without searching my email for clues. It is very helpful for yearly performance reviews, allowing me to provide a detailed accounting of everything, big and small, that I did since last year. The self-assessment pretty much writes itself.

I keep a hledger timedot file[1] open in a hot-key drop-down iTerm window. Each 15-minute chunk is logged with a dot. I group dots into hours for quick visual scanning.

    2019-01-08
    fos.hledger.sup  .
    adm.email  ..
    adm.finance  .... .... ..
    fos.plaintextaccounting  .
    fos.hledger.issues.941  .... .
    has-res  ...
    biz-res  ..

I've trained myself to update this often while at the computer, and before walking away. Delayed retroactive logging is also pretty easy. Working in quarter/half/whole hour chunks, and in rhythm with the clock, and having a pane showing recent sleep/wake/timelog-saved events, all help. Not every day is the same; this system has been quick and flexible enough to suit a range of conditions. I can set daily/weekly/monthly time budgets if I want. Some more details at [2].

[1] http://hledger.org/timedot.html

[2] http://hledger.org/Time-planning.html#simons-hledger-time-da...

I'm a programmer. I also sometimes manage others.

Time tracking and continuous code code review is an important way to spot workers who can't stay on task or are way over their head. If you can catch issues early, you can help them and the team succeed. If you lack time tracking and continuous code review many developers will "fall through the cracks" and it will take much longer to discover they are a net negative to the team. Even if it becomes apparent, it becomes much easier to point to sometime somewhat objective then gut feelings.

Time tracking is good for accountability. Time tracking should be simple. Time tracking should only loosely be associated with tasks.

* Email 0:45 * Meet with customer 1:00 * Program Complete solution and deploy it (TASK045) 0:05

I would be very wary of developers who refuse to accurately track their time.

Tracking at the microlevel is horrible. The time wasted keeping up and the padding in explainable areas to offset the undocumented task like pick up phone, talk to coworker, get water, go to bathroom, answer question.

In your example email took 15 minutes in reality it took 1 minute and I've used 14 minutes to get a coffee speak to an employee about upcoming company bake sale, holding the door for the CEO and getting to the conference room 5 minutes early to meet the client.

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.

A very smimple approach previously discussed here. https://news.ycombinator.com/item?id=16519819

That's cool! I'd opt for Minetest (a good open source clone of Minecraft) instead of Legos.

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.

Reminds me of the SAP software a previous employer used.

One of my reports worked 4 days a week ... so if they took a half day of leave at any point come the end of the year they would typically have 0.499. or 0.999. left to take.

I wouldn't be surprised if this was an intentional hack to get around some regulatory bullshit.

>if we don't report whole number cap-ex hours on our return, we'll avoid an audit!

Nope.

When the hours of the tasks didn't add up with the daily attendance you had to tweak your data or you couldn't close the day. Either added or removed 1 minute to the work day.

So a work day with 8 hours maybe had 7.98 hours of tasks. You tweak around a bit so that they both matched.

This was a reported bug (incl. explanation from a programmer) that wasn't fixed for a very long time. Maybe it's still broken.

IEEE floating point is hard!!

It does seem a little aggressive to try to get an employee to do useful work in 2^-53 of an hour. First you'd need a keyboard that could report 25 trillion words per minute…

> 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 to have some defense against someone else's measurements.

I worked at a game studio where the employees were on average reporting 60+ hours of work. The managers wanted to verify the survey data, so they implemented opaque time tracking (meaning they didn't show the employees the data, and they anonymized the data and didn't use it to come down on individuals, only to collect aggregate information.)

The result was that employees were factoring their commutes as well as optimistic expected arrival and departure times, and fairly dramatically over-estimating how much they actually worked. The average was much closer to 40, and 25% of the company was working less than 40 during final production crunch. I personally tracked my own time at the same time, and it turns out I was also working less than I thought. There's no doubt that crunch feels like more work, but measuring revealed a discrepancy between feelings and reality.

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.

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.

cached version: http://webcache.googleusercontent.com/search?q=cache:viP3hB4...

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.

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.

My time tracking - LibreOffice calc spreadsheet. ctrl+; to insert date, ctrl+shift+; to insert start/end time. Two columns for project and task name. Takes like 5 seconds to make a log.

I'd be really interested to know ( I was going to do a Ask HN ) on who has to track their time at work, how big the company is you work for, what detail do you track to and whether you think it's useful and if so, how is it useful?.

I personally work in a semi small product based company and we don't track time, but we have a few "point in time goals" where we need to get a solution sorted by a specific date.

I started with extreme programming in 2000 and used to use the planning ideas and velocity indicators, which is okish, but kind of a blunt tool. However the real mechanism to deal with problems is scope management. So now I just work on the idea of continuous focusing on goals and scope management of those goals. This works pretty well in a small team and time frames that are not too long (2 - 3 months).

However a lot of our development is purely feature based, which is often not time critical, but are scope managed to what I'd call "worthwhile" increments

So instead of worrying about time, my emphasis is goals/focus, feedback on progress and scope management. This tends to lead to good time outcomes.

seems very much like native advertisement: https://www.youtube.com/watch?v=E_F5GxCwizc

> Click to start. Click to stop.

That's the problem right on their website[1]. Developers shouldn't have to waste time manually time tracking, it's been automated already[2]. Unless your programmers' time isn't worth much, you're better off not manually time tracking at all. Due to context switching, manual time tracking actually hurts overall productivity. I've heard people say they get in the habit of manually time tracking and don't think about it anymore, but that's just getting into the habit of getting distracted from the real work: shipping changes.

[1]: https://www.7pace.com/timetracker

[2]: Many tools already exist for automatic time tracking.

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.

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.

Haha, Apparently how not to host a website giving tech advice includes having SSL certificate error on the website

He had to choose between meeting his sprint "commitments" and keeping the website available. He prioritized just like management told him to.

I created https://www.timecamp.com that can track processes, window titles and url (free). Those informations presented visually can help make better timesheets :)

I'll certainly bill my long weekend runs where I get most of my best ideas.

we are experimentng with timeular

https://timeular.com/?gclid=CjwKCAiA767jBRBqEiwAGdAOryNJfX4e...

It is an 8 (or more) sided shape that you flip to change tasks. The jury is still out as the people who are testing it havent had time to set it up..

wakatime! Just dont install the chrome extension haha.. i accidentally logged 197 hours on one customer..

I've been pretty happy tracking billable hours with Grindstone.

I worked for a Fortune 1000. Built a lead generation system that brings in $100M/year. They brought in time-tracking for our team, so I quit, because I hated it. The lead generation system fell apart without me, the Vice President and Project Manager in charge got fired. Nice job guys.

I track my time, too, and my biggest complaint is how long it takes. I think it's a great idea for companies to show why time tracking matters so it doesn't feel so futile.

Some companies just want a panopticon. Many of them want to micro-manage, and have weird ideas that software development is a direct correlation between time and effort.

My current company it makes sense to try my best to the hour/half-hour, because we're consultants and that's how we bill our clients.

A past employer for me was the worst of both worlds because they had a consultant's mindset towards billable hours having been born of a law firm, but not the consultant's approach to billing software development work. We were classified purely as "overhead" and not allowed to "bill" our (internal) clients. Meanwhile, despite starting life as a law firm it was by that point mostly a call center, and call staff to lofty law firm partners look like babies that need a strict panopticon.

If in the US definitely a company fail to inform. Done properly developer salary supported by time records can help qualify some portion of the salary for the R&D tax credit. At least that's what they tell us where I slave (a $FORTUNE_500)

Where things fall apart for me is logging overhead time, like time spent waking up with the first cup of coffee while reading company emails or doing IT-ish tasks on my dev system. I have no idea how to account for those times that doesn't make a mockery of the "Other" time entry.

Ugh. I don't ever want to work for a company where my time tracking has to be so fine grained that I have to log bathroom breaks. Holy shit that sounds like a nightmare!

I actually worked for a company where they didn't allow me to have a bathroom break during working hours while I was remoting...such is life as a 53yo developer trying to make any kind of living in this industry.

In fact, I had to log X keystrokes and Y LOC every hour in order to be paid for that hour...talk about being a factory worker.

I hate to use the "you should be looking harder" trope, but every company I've worked at has had developers at or over 53, and not one of them had such onerous time tracking requirements.

One tracked time to attempt to get r&d tax credits on certain work. The other was an agency that tracked time in case of disputes with unruly clients (such as the time we had gone through 3 project managers and 2 CFOs while we worked with them, and they were desperate to recover money from their own bad mistakes). The rest didn't track time at all.

Not to mention that LOC as a metric has been an industry joke at least since the early 80's: http://www.folklore.org/StoryView.py?story=Negative_2000_Lin... I've heard of funnier versions of that story, but haven't tracked them down yet.

LOC means ‘loss of consciousness’ in my industry, but I do t think that fits. What is it here?

Lines Of Code.

That model doesn't even make sense to me.

Some of the most productive hours are LOC removed.

Counting keystrokes?

That sounds nightmarish, man.

Gets me thinking. Back space, I can see arguments for it being +1, 0, -1 or -2?

This is utter horror and is pretty much asking for people to quickly code up something to type fake keystrokes when you take a break.

Usually its not that you specifically need to log your bathroom break, but rather that all your time you spent at work needs to be booked on _something_

Lol, I remember being in a billable environment and making so much shit up. Reading emails? Billed to project Y. Bathroom break? Billed to project X. Politely listening to my boss gab? Billed to project Z.

Now that I manage my own team I let them abuse the Other time entry. I only expect 70-80% billable anyways, which lines up with studies on productivity. Anybody expecting 100% productivity is an idiot and anybody reporting 100% productivity is a liar.

I'm fortunate to be in a place where our time-tracking is not expected to add up to 40 (or 80) hours a week. I log the work items I do, which sometimes is six hours and sometimes is one hour a day.

I make those a pretty broad category -- "email" "time waste" (that one's just for me). If the time tracker is simplistic and intuitive enough, then it doesn't have to be a headache.

At one previous employer I submitted a feature request for the time tracker that would have saved a lot of time - it was a button that would generate something that was basically "like last week but with some plausible looking random changes".

Now I think about it - should have been a cron job, maybe that was why it was rejected.

What level of granularity are you required to track? I track how much time a spend working on a particular feature, regardless of the type of work being done. When I take a break or start working on a different feature I make a note of how long I worked since I started. It takes less time than writing a commit comment, which I usually do right before I jot down how long I worked on it.

(Edit: Yes, I know it's working now. That doesn't mean it wasn't working, and it doesn't mean this comment is invalid. It just means that it got fixed, perhaps even because of this comment pointing out the problem.)

I'm getting this:

    Secure Connection Failed

    An error occurred during a connection to
    www.7pace.com. Cannot communicate securely
    with peer: no common encryption algorithm(s).
    Error code: SSL_ERROR_NO_CYPHER_OVERLAP

    The page you are trying to view cannot be
    shown because the authenticity of the received
    data could not be verified.

Suggestions? Yes, I've read the article via the Google cache.

No cypher overlap suggests that either 7pace's SSL settings (server side) are unusually restrictive, or your browser simply doesn't support those settings for other reasons. Could happen on older browsers maybe, or restrictive group policies on Windows, etc. Try a different browser perhaps?

Just tried again and it's worked this time. That suggests they had some of their settings wrong.

Here's an archive link: https://archive.is/yFO6l

I removed the s in https and it loaded but redirected to the https version, confusingly.

I’m not sure I understand the value prop here. It’s a time tracking software tool for software engineers? FTE or Contract? The UX also looks like complete shit. Get your stuff together bro, this is the worst pitch I’ve ever seen.

Why are you being so negative, I think the author makes valid points.

/r/iamverysmart/

We detached this subthread from https://news.ycombinator.com/item?id=19201889.

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.

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.

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 better version of the thing real quick?

Well he did said

> fell apart without me

this kind of comment not only is useless, but brings nothing to the discussion.

not only that but, this is not reddit. citing a subreddit means nothing.

and yes, some people are too important for a product.

Reply on news.ycombinator.com