Fuck everything about these breathless, one-sentence-per-paragraph articles. It's infuriating to read.
How Not to Do Time Tracking for Software Developers
91–100 of 136 posts
Re: How Not to Do Time Tracking for Software Developers
#92Tracking time is part and parcel of being a consultant, at least if you have multiple clients and overlapping work. After doing it for 15+ years, I've tried it all - everything from the spreadsheet, to the apps, to forgetting and having to go back and reconstruct. I read this article and I think it's missing the point about what's so hard about time tracking. What's hard is: Implementing the trigger on the context sw…
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.
Re: How Not to Do Time Tracking for Software Developers
#93Earlier quoted context omitted.
I wouldn’t boast about writing software that “falls apart” by merely not having you around. Not exactly a high quality bar.
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 rep…
Re: How Not to Do Time Tracking for Software Developers
#94Earlier quoted context omitted.
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.
That model doesn't even make sense to me. Some of the most productive hours are LOC removed . Counting keystrokes ? That sounds nightmarish, man.
Re: How Not to Do Time Tracking for Software Developers
#95Earlier quoted context omitted.
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 no…
Minor bug, but it looks like all your call-to-actions on the features page are too large. (FF on Pixel 1)
Re: How Not to Do Time Tracking for Software Developers
#96The 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 t…
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.
Re: How Not to Do Time Tracking for Software Developers
#97Time 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.
Re: How Not to Do Time Tracking for Software Developers
#98Fuck everything about these breathless, one-sentence-per-paragraph articles. It's infuriating to read.
Re: How Not to Do Time Tracking for Software Developers
#99I'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 t…
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.
Re: How Not to Do Time Tracking for Software Developers
#100I 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.