In general, logging is a symptom of a non-agile development process that proxies for a project manager's active engagement and situational awareness. It is also often a sign that the project is measuring the wrong thing, since "time consumed" is rarely a valid measure or predictor of results. When not used solely for contractual billing purposes, it is most often improperly-used as an accountability or root-cause analysis tool.
Results-based tracking is generally more effective. For example, in Scrum a story is either "done" or "not done" at the end of a Sprint. How much time was spent doing what task inside the Sprint is largely irrelevant, although blockers and queuing issues are certainly valid topics for a Sprint Retrospective.
The Fallacy of Detailed Time Accounting
Tracking time is useful for billing purposes, and ostensibly for future estimates. In reality, though, time sheets are either a work of fiction or needless overhead.
In manufacturing, it can certainly be worthwhile to document that it takes x minutes to produce y widgets on an assembly line. However, in knowledge work like programming, work rarely breaks down neatly into measurable increments. In addition, programming in particular is often about thinking about the right problem to solve, so overly-granular record keeping that isn't a complete work of fiction might look like:
- Spent 47 minutes thinking about how to optimize the frobnitz.
- Spent 52 minutes writing a spec for an experimental wibble widget.
- Spent 12 minutes coding a new quux object.
- Spent 17 minutes deleting a bunch of code objects, documentation, and references that should be torn out in favor of the quux object.
- Spent 21 minutes waiting for continuous integration to run.
- Spent 3 minutes every quarter hour summarizing the work, and 23 minutes and 15 seconds getting back on track after interrupting my work to log my time.
If the log is kept meticulously and honestly, at the end of the day the time simply won't add up to 8 hours due to task switching, overhead, and (of course) the time spent time-tracking at a granular level. That makes the log less useful than managers might like to think.
Sensible time-keeping tends to be less granular. A sane log entry might say: "I spent 6 hours today working on the foo project, and 2 hours in meetings, time-keeping, and other project overhead." However, this type of high-level logging is often imperfect due to cognitive bias, errors of omission, social filtering, and other factors that make it largely useless as a valid measurement.
Results-Based Project Management
Agile frameworks like Scrum implicitly support a results-only work environment. While ROWE itself is a buzzword and marketing term, the concept of measuring results (e.g. Was a target met or not?) is generally more useful than measuring minutes-per-task. Again, sectors like manufacturing that need to measure throughput may actually need timing data, but rarely do they need timing data of the sort collected by the time sheets you're describing.
Focusing on whether tasks are "done" or "not done" is a significant culture shift in many organizations. It requires trust between upper management and the development team, and a commitment by the team to be transparent about estimates, impediments, and missed targets. Without that trust, and without that culture shift, most organizations simply fall back on useless metrics like time accounting.
If your organization isn't willing to make that cultural shift, and if you find granular logging disruptive or burdensome, then you can try to evangelize a more agile approach. More likely, though, it's simply time to brush up your resume and look for an organization that is less steeped in failure.