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.
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.
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.
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.
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.
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.
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.
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.
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 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).
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.
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.
(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?
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.
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.
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.
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.
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.
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…
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.
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.
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.
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.
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.
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.
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 wrote once software to do the time tracing in reverse. I feed it with projects and how much I thought I was working on each project, and in generated timetables with accuracy needed by company for the whole week that matched the given project percentages. As a bonus, I had a generic list of comments to attach randomly to each slot.
My manager was using those generated data to figure out the project time percentages I was working on. Circle closed. All happy.
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 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, 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.
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.
135 comments
[ 3.9 ms ] story [ 190 ms ] threadWhere 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.
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.
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.
Some of the most productive hours are LOC removed.
Counting keystrokes?
That sounds nightmarish, man.
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.
Now I think about it - should have been a cron job, maybe that was why it was rejected.
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.
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.
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:
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).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.
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 ;).
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 :).
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.
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.
I'm getting this:
Suggestions? Yes, I've read the article via the Google cache.I removed the s in https and it loaded but redirected to the https version, confusingly.
[0] https://github.com/ActivityWatch/activitywatch
Any other kind of time tracking that is shared with your employer is absolute proof that they don't trust you.
Hmm. As a software developer you get really frustrated when you have to deal with this expensive piece of software.
>if we don't report whole number cap-ex hours on our return, we'll avoid an audit!
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.
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.
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.
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.
* I only have time for bullet points :)
> 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.)
My manager was using those generated data to figure out the project time percentages I was working on. Circle closed. All happy.
> fell apart without me
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.
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.
not only that but, this is not reddit. citing a subreddit means nothing.
and yes, some people are too important for a product.