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.<p>I read this article and I think it's missing the point about what's so hard about time tracking.<p>What's hard is: Implementing the trigger on the context switch.<p>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.<p>If someone can solve <i>that</i> problem with a fancy app, I'd be impressed!<p>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.<p>[1] <a href="https://news.ycombinator.com/item?id=15790918" rel="nofollow">https://news.ycombinator.com/item?id=15790918</a>
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:<p>"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."<p>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.<p>I'm reminded on Tom DeMarco's thoughts about Control and what kind of projects need such controls [1]:<p>To understand control’s real role, you need to distinguish between two drastically different kinds of projects:<p>- Project A will eventually cost about a million dollars and produce value of around $1.1 million.<p>- Project B will eventually cost about a million dollars and produce value of more than $50 million.<p>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.<p>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.<p>[1]: <a href="https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf" rel="nofollow">https://www.computer.org/cms/Computer.org/ComputingNow/homep...</a>
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.<p>[0] <a href="https://github.com/ActivityWatch/activitywatch" rel="nofollow">https://github.com/ActivityWatch/activitywatch</a>
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~).
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.<p>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.<p>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.<p>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".<p>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).<p>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 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.
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.<p>I've done this with good success when I was <i>required</i> to track my time. If I'm not required to do it, I find that I just dont bother.
I'm curious if anyone here has had success with more "coarsely grained" time tracking?<p>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).<p>I <i>feel</i> 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 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.<p><pre><code> 2019-01-08
fos.hledger.sup .
adm.email ..
adm.finance .... .... ..
fos.plaintextaccounting .
fos.hledger.issues.941 .... .
has-res ...
biz-res ..
</code></pre>
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].<p>[1] <a href="http://hledger.org/timedot.html" rel="nofollow">http://hledger.org/timedot.html</a><p>[2] <a href="http://hledger.org/Time-planning.html#simons-hledger-time-dashboard-201805" rel="nofollow">http://hledger.org/Time-planning.html#simons-hledger-time-da...</a>
I'm a programmer.
I also sometimes manage others.<p>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.<p>Time tracking is good for accountability. Time tracking should be simple. Time tracking should only loosely be associated with tasks.<p>* Email 0:45
* Meet with customer 1:00
* Program Complete solution and deploy it (TASK045) 0:05<p>I would be very wary of developers who refuse to accurately track their time.
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.
A very smimple approach previously discussed here. <a href="https://news.ycombinator.com/item?id=16519819" rel="nofollow">https://news.ycombinator.com/item?id=16519819</a>
At my last employment they had a time tracking software that said that three tasks @ 20 minutes each are 0.99… hours.<p>Hmm. As a software developer you get really frustrated when you have to deal with this expensive piece of software.
> 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.”<p>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.<p>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.<p>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.)<p>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 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.<p>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.<p>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!<p>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.<p>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.
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.<p>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: <a href="https://doug.pacifico-hammond.co.uk/software/hardware/2018/06/24/the-task-switch.html" rel="nofollow">https://doug.pacifico-hammond.co.uk/software/hardware/2018/0...</a><p>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.
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?.<p>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.<p>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).<p>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<p>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:
<a href="https://www.youtube.com/watch?v=E_F5GxCwizc" rel="nofollow">https://www.youtube.com/watch?v=E_F5GxCwizc</a>
> Click to start. Click to stop.<p>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.<p>[1]: <a href="https://www.7pace.com/timetracker" rel="nofollow">https://www.7pace.com/timetracker</a><p>[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 <i>all</i> time accounted for and they wouldn’t let you add new tasks, <i>management</i> 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.<p>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:<p>"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.<p>Call them into a meeting. Pour over their time entries line by line and pick apart how they spent their week."<p>=> Useless meetings are much worse than useless timetrackers.
I created <a href="https://www.timecamp.com" rel="nofollow">https://www.timecamp.com</a> that can track processes, window titles and url (free). Those informations presented visually can help make better timesheets :)
we are experimentng with timeular<p><a href="https://timeular.com/?gclid=CjwKCAiA767jBRBqEiwAGdAOryNJfX4e6DaIGgOwF1vlpbkEzLcPsXz48jmJcKk17MyWr__I3feUvRoCoBoQAvD_BwE" rel="nofollow">https://timeular.com/?gclid=CjwKCAiA767jBRBqEiwAGdAOryNJfX4e...</a><p>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..
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 <i>why</i> time tracking matters so it doesn't feel so futile.
<i>(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</i> because <i>of this comment pointing out the problem.)</i><p>I'm getting this:<p><pre><code> 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.
</code></pre>
Suggestions? Yes, I've read the article via the Google cache.
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.