Timesheets are something that I've never been fond of, but none the less something that is a requirement within my company. They don't bother me so much, but they seem to really grind some other people's gears. I suppose I have a few questions, and feedback would be great.


Are you required to do timesheets, assuming you aren't a contractor? (That is understandable to me).
What is the granularity of timesheets that you would be comfortable with or that you use? (ex: all entries must be under two hours).
Would timesheets ever factor into your reasons for not accepting a job or leaving a current one?
How has management within your organization justified timesheets if you aren't billing to a client?


As a manager yes I get the team to do timesheets.  Here's why and a few notes on how they're implemented to, hopefully, minimise disruption:


As a business much of our work is done on a time and materials basis.  Without timesheets that obviously doesn't work.  We have 10 clients and a range of different projects and products but we're not a big enough to devote people to clients or projects full time which means that we have to have some way of working out how long things took.
Even if this weren't true to manage a team you still need to understand what takes time and how much. Think that old app the mailroom guys use is taking more time to support than it's worth? What about when someone asks how much work went into feature X on the new website which doubled sales? Or when your developers say you should recruit someone else and you get asked to breakdown what they do to help justify it?
Categories exist for all reasonable "non-work" including mentoring, general technical discussions, support, meetings and so on.  
Bug fixing - we record time against a whole project rather than bug by bug.  This tends to make things a lot easier - spend the day fixing bugs, 7.5 hours bug fixing goes against the project and you're done.  No need to try and work out how it was divided between the 13 bugs you fixed.
When we implemented them I promised that no-one would be penalised / rewarded for what was on their timesheet so long as it was accurate.  So there is no input into reviews based on profitability or utilisation or anything else.  This means that there is no incentive to distort.
By accurate I mean roughly.  People really shouldn't have to spend too much time worrying about what happens when they make a coffee or go to the toilet.  Basically if you make a note on a pad of each thing you worked on during the day, then at the end of the day roughly break it down across the hours you worked and that's it.  If shouldn't take more than 5 minutes max.
If I don't like what I see - for instance someone has spent too long on task X - the investigation is into what we can do to make X faster, rather than anything to do with the timesheet.
Knowing how long you spent doing something is a great way of improving estimates.


The anti-timesheet feeling among many programmers seems to come from two things - (1) badly implemented timesheets which take too long to complete, demand more information than is really needed and encourage lying and distortion so the information is worthless anyway, and (2) a feeling that every single thing that slightly inconveniences a developer should be done away with.

The first one is fair but you should blame the implementation and the rules someone has attached, not the whole idea of timesheets which can be done in ways that don't have these issues.  The second one is just unrealistic - there are many parties involved in projects, both inside and outside the company, each of whom have many demands on them.  Yes we want to do everything we can to make programmers productive, but it has to be balanced with the needs of other parties.
