
How Not to Do Time Tracking for Software Developers - encorekt
https://www.7pace.com/blog/developer-time-tracking-fails
======
bm98
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](https://news.ycombinator.com/item?id=15790918)

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

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

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

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

------
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...](https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf)

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

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

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

~~~
mikekchar
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?

------
jacobtwotwo
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](https://github.com/ActivityWatch/activitywatch)

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

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

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

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

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

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

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

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

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

~~~
welder
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...](https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-activity)

~~~
_bxg1
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

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

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

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

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

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

~~~
TeMPOraL
> _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 :).

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

------
smichael
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](http://hledger.org/timedot.html)

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

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

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

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

~~~
throwmeback
And there I was feeling weird having to manage 2 time trackers at work.

------
jSully24
A very smimple approach previously discussed here.
[https://news.ycombinator.com/item?id=16519819](https://news.ycombinator.com/item?id=16519819)

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

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

~~~
jgust
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!

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

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

~~~
wolco
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?

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

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

------
bradleyankrom
cached version:
[http://webcache.googleusercontent.com/search?q=cache:viP3hB4...](http://webcache.googleusercontent.com/search?q=cache:viP3hB4HPqMJ:https://www.7pace.com/blog/developer-
time-tracking-fails&hl=en&gl=us&strip=1&vwsrc=0)

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

------
wdfx
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...](https://doug.pacifico-
hammond.co.uk/software/hardware/2018/06/24/the-task-switch.html)

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.

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

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

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

------
rspoerri
seems very much like native advertisement:
[https://www.youtube.com/watch?v=E_F5GxCwizc](https://www.youtube.com/watch?v=E_F5GxCwizc)

------
welder
> 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](https://www.7pace.com/timetracker)

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

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

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

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

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

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

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

------
triviatise
we are experimentng with timeular

[https://timeular.com/?gclid=CjwKCAiA767jBRBqEiwAGdAOryNJfX4e...](https://timeular.com/?gclid=CjwKCAiA767jBRBqEiwAGdAOryNJfX4e6DaIGgOwF1vlpbkEzLcPsXz48jmJcKk17MyWr__I3feUvRoCoBoQAvD_BwE)

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

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

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

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

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

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

~~~
WWLink
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!

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

~~~
52-6F-62
That model doesn't even make sense to me.

Some of the most productive hours are LOC _removed_.

Counting _keystrokes_?

That sounds nightmarish, man.

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

------
ColinWright
_(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.

~~~
zeta0134
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?

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

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

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

------
juandazapata
/r/iamverysmart/

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

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

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

