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.

  1. Are you required to do timesheets, assuming you aren't a contractor? (That is understandable to me).
  2. What is the granularity of timesheets that you would be comfortable with or that you use? (ex: all entries must be under two hours).
  3. Would timesheets ever factor into your reasons for not accepting a job or leaving a current one?
  4. How has management within your organization justified timesheets if you aren't billing to a client?
  • Wow! Thanks for all of the answers everyone! I really appreciate the feedback. It's unfortunate that I can only pick one as the answer.
    – vcsjones
    Commented Nov 8, 2010 at 23:13

25 Answers 25


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:

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

  2. Categories exist for all reasonable "non-work" including mentoring, general technical discussions, support, meetings and so on.

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

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

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

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

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

  • 1
    Don't forget the fear of reprisal as a reason to dislike timesheets. That, however, is an entirely different problem. Commented Nov 8, 2010 at 22:03
  • Excellent, comprehensive response. Commented Nov 8, 2010 at 23:13
  • 3
    +1 for pointing out that flaws in the implementation of an idea do not necessarily mean that the idea itself is flawed.
    – GSto
    Commented Apr 7, 2011 at 19:34
  • indeed, very good. I would add though to the bad implementations is that they stemmed from a need for time tracking without questioning why this need arises. At work here we have a timesheet that works by projects (thus non project related tasks cannot be logged properly) and a ridiculously large amount of possible tasks (50+) of which, as a developer only 3 or 4 are really of consequence. I frankly do not know what information they are getting out of this but I would venture in saying only payroll uses them and they only care about the weekly total !!
    – Newtopian
    Commented Apr 11, 2011 at 11:05
  • 1
    +1 Too many programmers think their job is just coding, and everything else is not their job. Timesheets, working with difficult users, meetings - in my experience, some programmers fail to realize that they need to do these tasks as well as (and to the same quality level as) the actual coding.
    – JDB
    Commented Mar 27, 2013 at 12:20

I don't get the anti-timesheet thing at all. Timesheets are what cause you to get paid. No timesheet, no money. I like getting paid, therefore I like my timesheets. I've never had a timesheet that took more that five minutes a day to fill out. Honestly, there are plenty of much more annoying things in my day than a five-minute timesheet.

  • 41
    Getting the job done is what causes me to get paid, not how long I sat at my desk. I guess I should clock additional hours researching at home, sitting on the can thinking about the problem, or going outside for a walk to mull over the problem. It's not anti-timesheet imo, it's the lack of employer awareness about how the job is done. Commented Nov 8, 2010 at 14:52
  • 1
    From the perspective of the application that porcesses payroll, no time sheet, no employee to pay. We do have a minimum hours we must work even when salaried. The company does need to document when we took vacation or sick leave, etc. The company needs data about how much time is spent on various projects. All employees in most companies fill out timesheets.
    – HLGEM
    Commented Nov 8, 2010 at 15:35
  • Generally speaking if we can't show our clients what work we've put into something we don't get paid and if we don't get paid we tend to struggle to pay our staff. In any case thinking about the problem is work and should be classed as such on your timesheet - if your manager has an issue with that that IS a problem but it's not a problem with timesheets per se, it's a problem with a stupid implementation of timesheets. Commented Nov 8, 2010 at 17:00
  • @SnOrfus, or—you could spend the "additional" hours to do more work at office, take some initiative, and get a raise for a side-project.
    – P Shved
    Commented Apr 7, 2011 at 18:55
  • 1
    I think (speaking for myself at least), being made to do a timesheet demonstrates that the person requesting the timesheet doesn't trust you. I've worked in web development for years. Recently I've been asked by my current employer to start logging timesheets. Whilst it's far from the only thing about my current job I don't like, it's one more item I've added to the list of things that are making me look for a new job.
    – GordonM
    Commented Aug 16, 2012 at 7:12

We don't make programmers fill out time sheets. We do have a task management system that people don't seem to mind using, which gives us pretty much all the data we need as far as accounting goes. It isn't hard to figure out when something ran way over the expected amount of time verses someone just forgetting to mark an item complete.

It also becomes obvious if someone is just not producing.

A few queries in the bug tracker also helps to show where things might be getting clogged.

We'd rather keep programmers away from administrative tasks whenever possible and trust that people are doing their job.

The only time I'd find granular time keeping reasonable is if the client was being billed by the hour for something. But then, the ultimate reason for doing it becomes obvious and a little more comfortable, time has to be accurately tracked because that is how much the client will be paying. That's a little different than feeling micromanaged for the sake of administration.

I'm all for treating adults like adults.

  • Which task management system?
    – user1249
    Commented Nov 8, 2010 at 9:27
  • @Thorbjørn Ravn Andersen One that we developed in house. It ties in with our XMPP server to make using it a little less painful.
    – user131
    Commented Nov 8, 2010 at 9:46
  • 3
    "I'm all for treating adults like adults.", where do I apply!
    – CaffGeek
    Commented Jan 28, 2011 at 18:12

Unless you are charging clients by the hour, or unless you are a contractor paid by the hour, I wouldn't expect to be filling in timesheets. In my experience, they are counter-productive - yes, you need to generally keep track of the amount of resource going into projects, but that can be approximated monthly ("10 days on Project X and 9 days on Project Y etc"). The benefits of anything more granular are often outweighed by the cost of recording them, and if they can be used as a stick to beat the staff with, the staff will simply record what is acceptable rather than what is accurate.

The other unanticipated downside to businesses is that if you start monitoring staff, you might find that you start recording just how much extra the staff are doing! If you are paid for 40 hrs and are tracked for 40hrs, come 40hrs there is an incredible incentive to just go home. Staff will often stop doing that little bit extra that can so often make the difference.

  • 2
    +1. This is very true (the last bit about being tracked). I really don't think of my work as being time based at all. I hang around anywhere from 8 to 12 hours on a given day depending on project requirements and deadlines and such - especially if the work is interesting and there is new and cool technology for me to learn. Start making me punch the clock like a production line worker, however, and I'm liable to start acting like one. Commented Nov 8, 2010 at 21:52

My company tried, but I ignored it or wrote down nonsense times for a few weeks while still getting the job done and they forgot about it.

  • Did the same thing but for another reason: Devs had to fill out timesheets but because we were exempt employees our timesheets weren't allowed to cross 40 hours (otherwise they'd have to pay us overtime...). At that point we had to lie just to appease the managers so I put very little effort into it -- every Monday I did my 8-8-8-8-8 and submitted. Commented Nov 8, 2010 at 15:03
  • 5
    Working - 1 hour; Filling out timesheet - 7 hours. Commented Nov 8, 2010 at 21:54
  • @VirtuosiMedia: They wanted time in|time out|reason - so it looked more like this: 8:55|5:10|"I work too damn hard and don't get paid enough. Now I'm going to go home to study and research." Commented Nov 9, 2010 at 15:40
  • i am prolly gonna get penalised for not doing all my timesheets in 'time' last week. thats how i came across this question and this answer. crazy fuc#ing world. (+1 btw)
    – Chani
    Commented Jul 24, 2011 at 16:53

At my previous job I had to account for each 15 minute block of time. It was a web development company and we were each assingned tasked. Each task had a specific number of hours alloted to it. We divided the total price we charged the customer by $100/per hour to get the total hours available for the project.

If I was given 10 hours to accomplish my tasks and it took me 15 hours, then I owed the company 5 hours overtime. I used a daily planner from Franklin Covey to keep track of time.

  • 1
    That would drive me absolutely bonkers. I feel for you.
    – Eric King
    Commented Nov 8, 2010 at 4:41
  • 1
    How did this approach affect the quality of the product? I could imagine that the incentive is not really there to make sure that the task is completed well!
    – paul
    Commented Nov 8, 2010 at 6:29
  • 12
    If you completed a 15 hour task in 10 hours did they owe you 5 hours? I'm guessing not. Commented Nov 8, 2010 at 12:57
  • 2
    @Jon H - Yes. However, if the entire project was in jeopardy of going over, then we had to kick back our time to the project so it could be reassigned. I hated the whole system Commented Nov 8, 2010 at 17:10
  • 5
    @Brian: You just described a union shop:) You can't be fired for being derelict in your job, but you would certainly be fired for excelling at it. If you are getting the job done too quickly you can be certain of a visit from the shop steward with a friendly warning concerning your health and well-being about how you need to slow down.
    – Dunk
    Commented Apr 11, 2011 at 20:53

I work as a web developer / project manager at a small company (10 people in total) and everyone, including the CEO, has to log what they do. Everything that takes more than 5 minutes has to be logged.

A typical timesheet would look like this:

07:46 - 08:01 : Client A - Project B - Programming - Optional remark
08:01 - 08:38 : Client B - Project C - Fixing - Optional remark
08:38 - 08:46 : Client B - Project D - Project Management - Optional remark
08:46 - 09:00 : Client A - Project B - Customer Support - Optional remark

Since I'm used to working like this, it wouldn't be a reason to refuse a job. The CEO motivates the use of these kind of detailed timesheets as the perfect way to compare estimates to the actual time spent on a project.


I don't do a time sheet. There are specific projects where I track estimates against actual time (I don't use any kind of timer.). This isn't required, but I feel a need to work on my estimation ability.


Timesheets aren't a dealbreaker for me. My last job had them at first for providing transparency for a client, then dropped them. My current job has them and they're kept in case of an audit, since we apply for government research grants.

The software used for timesheets utterly sucks, but it still takes about 5 minutes for me to fill in a timesheet because they're at a very high level: 8 hours a day, mark down vacation/sick days and put in some notes on what was worked on during the week. I take notes every day, so it doesn't take me long to come up with a few lines to type into the timesheet.

  1. Yes, employees are required to do time sheets and this isn't an unusual thing for me to see.
  2. Usually they are broken up into various categories,e.g. support or some big feature like search on a site, with a minimum of 15 minutes per entry, which is .25 of an hour.
  3. No, timesheets are just an administrative feature I've come to accept as part of my job in a way. It can be interesting to break down my work into various buckets like administrative, support and development work.
  4. There are a couple of different justifications that I know for having developers do timesheets:
    1. There are various accounting rules about how some expenses can be capitalized and amortized so that it looks better on the books, or at least that is what I remember from hearing it a couple of times.
    2. Quantifying our time allocation allows management to see how much time is spent in various areas which can be used for strategic planning in a sense. If there are a group of developers spending a large time on support then it may make sense to create a new support team to take that over possibly to give an example here. Another thought is that even though we are internal employees, there is still the question of from which budget do our salaries come. If we are doing mostly project work, then it is out of the project's budget which isn't the same as a support budget possibly.
  • 1
    Regarding point 4.1 there, there are tax breaks and grants for work that can be counted as research in a lot of countries and timesheeting can be a good way of showing that.
    – glenatron
    Commented Nov 8, 2010 at 23:00

I have to fill out multiple timesheets.

First there's the timesheet that goes to HR. That timesheet simply shows worked/not worked, and is used to track PTO and sick days. So it always is filled out in multiples of 8 (out all day or working all day).

Then there's the timesheet that goes to the business. I work software development in a large corporation; most (99%) of our projects are for internal users. These projects are charged to the users on a by-the-hour basis; so a project for, say, the Legal department will be charged to the Legal department's budget. This timesheet is the most politicized; there is pressure from the IT management to charge as much of your time as possible to the projects, and pressure from the project owners to charge as much time as possible to IT (i.e., staff meetings, informal training, etc.). Further, before any work is done on any project, it is 'estimated' and a certain 'budget' of hours is allotted. So in order to stretch the hours, there is pressure from all parties to get creative with the timesheet; marking 8 hours in a given day to the same project sets off a red flag that triggers 3+ managers hitting up your cube. Overtime is NEVER marked, as it serves no purpose (my pay is the same, and it decreases the available hours faster). Accuracy in this timesheet can be detrimental to your career.

Finally, there's the project timesheet. This is the one that goes to the project owners; its not broken down by date, but by hour. So this is the sheet that says "I spent 9 hours on your project this week; tasks A and B were accomplished, and bugs X and Y were corrected.". This timesheet is a work of complete fiction; given that it gets its hours number from the previous timesheet, the tasks-to-time ratio is completely inaccurate. However, this timesheet is really only used to determine whether or not we've reached milestone X by a given hour usage Y, so its more a general gauge of progress than anything else.

  • Ugh, talk about overkill!!
    – ozz
    Commented Jan 28, 2011 at 21:08
  • So what happens when you have a doctor's appointment? Do you have to take off the entire day? Also, what you call creative is also known as illegal for companies that do business with the government.
    – Dunk
    Commented Apr 11, 2011 at 20:57

Two jobs ago I filled out timesheets. They were done in order to record pay (we were paid overtime) and to bill the customer (a lot of work was T&M) and to check assumptions vs. actuals on fixed price projects. I also found them useful for logging some of my own info, rather than keeping a personal log vs. a timesheet log. It worked great.

One job ago, I tried to use timesheets the same way (the conditions were very similar), but in that case the company would question every little thing on the timesheet. I'd have phone conversations arguing about what I put on my timesheet that lasted longer than the amount of time in question. I stopped putting down accurate time, because it was absurd. Other people seemed to be lying on their timesheet too, when questioned.

At this job, my time isn't directly billable to a customer, just to internal projects mostly, but I still do timesheets. They're easy to do, and helpful, not just to myself, but to the company for accounting, etc. Never been questioned about what I put on a timesheet here, so I keep them quite accurate.

I'd say they're great, until they start penalizing you for what you put on them.


Unfortunately, yes.

But not only one timesheet. We have to:

  • Check in and check out on arrival/departure
  • Fill in the timesheet for our parent company at the end of the month
  • Our idiotic government (Croatia) recently added another nuisance: filling in another daily timesheet. Why? So they can send an "inspection" to steal your money if every employee doesn't have it completely filled in.
  • Ok, this goes some way to explain why my parents decided to move to Australia, mainly because of dad citing Croatia as being too bureaucratic and annoying to build a career in. :) Commented Nov 9, 2010 at 3:12
  • @Guzica: I can confirm that - that was a very wise move. Commented Nov 9, 2010 at 9:02

I'm amazed at how much time is wasted on time sheets and how little the organization is getting out of it.

For most groups here, the manager sends out the number of hours budgeted for the time period; per project, per employee in order to match the project plan. All programmers then enter that time for each project they work on; regardless of what time they actually spent per project. Or how useful that work was.

For them, time sheets are totally useless.

On the other hand, I get the build record from Hudson and commit log from VCS. From that I get a good sense on what my team actually worked on without having to ask them to file out more form.

Its more accurate as it tracks what developers have done and not what people said they spent time doing.

  • Ah, that reminds me of the timesheets on my first job. They could have saved some employee time by adding another program to transfer the hours I was assigned to work on each project to the project, and avoided having me copy hours and somebody else keypunch it. (Yes, that was a while ago.) Commented Nov 10, 2010 at 21:59

I hate filling them out at work, hate with a passion...which could explain why I'm three months behind at the moment. I have my emails, calendar, tasks in our task tracking software, projects to put in, in our 'larger' project tracking software. And yet, they still insist upon filling in a timesheet which references the projects/tasks in the other programs. It's all just a mess.

It's then used to determine efficiency, speed, etc, which is used when calculating your bonus. The fact that you were technically doing 60 hours worth of work, in 40 hours, isn't really noticed, but what is noticed, is that everything was late... despite the fact that had I followed the estimated time on each, and worked my 8 hours, some would have been on time... but gradually later, eventually with things not even being started before they were due.

However, freelancing, I have no issue filling them out. I keep an excel file with a simple "date, comment, hours". It's simple, it's quick, and it works so much better.

I'm not trying to meet deadlines that are set by a manager and so ridiculously random that it looks like dice were rolled since I wasn't consulted. Task A, I get with 2 hours allotted... yet I know will take a day. Task B I'll get with 20 hours allotted... yet I know I can knock it off in 15 minutes.


The concept of timesheets is not bad. For individuals, once they can keep track of time it takes to perform a task, they can

  1. estimate similar tasks more precisely
  2. plan tasks well to keep themselves busy during the week, and
  3. know beforehand if they will miss any deadlines

Also, a project's cost can be tracked.

However, invariably always, one problem quickly appears. Here is the template of the sequence of events:

  1. The management gets a scent of 'measurability'. They imagine this to be a management tool.
  2. The hours logged will be questioned, explanations asked for any number larger than some number (let us say, 6) all in a sense of false control and management.
  3. Next, the team will be compared and pitted against each other as to who is logging more hours. The output will be monitored in terms of hours spent.
  4. They will hire a time-sheet-coordinator or some such role to aid this process.
  5. This person will, to prove a point, add a few more fields to the template and augment the process. Now, the time required to spend on timesheet suddenly quadruples.

Thus, a system that was once envisaged to be aiding programmers becomes a bottleneck.


Yes. But at a fairly coarse level for management reports weekly. This gets reported by the PMO all the way up from senior management to director level at an appropriate granularity. For individual projects it is at project task level for tracking progress but that doesn't feed into the timesheet but more for project management.


The only time I didn't resent having to fill in timesheets was when I worked in a team using XP. I suppose that was because

  1. those cards were filled in as part of the stand-up meeting every morning (which was the first time I could actually see meetings having a high result/time ration)
  2. I could actually see the results of the effort being used (for calculating the time needed to implement future tasks)

OTOH, I have been using a home-made Excel sheet to track my overtime state (and what I've done each day) for more than ten years. So currently I usually fill in the timesheet on Friday before I leave the company, copying from my Excel sheet.


No, and I'd refuse job/contract offers that would make me fill out time sheets. I will never understand the ignorance of managers who think that the infamous time sheet is some sort of a great tool for keeping programmers disciplined as well as for measuring performance.

For all that he/she knows, I might have just copy/pasted a chunk of code from a blog that solves a hard problem in the first ten minutes and spent rest of my recorded time reading interesting discussions on P.SE.

We're not cotton plantation workers, and should not be treated as such.

  • 4
    What about managers who think that the infamous time sheet is some sort of a great tool for billing clients? Or to provide a feedback loop to improve accuracy of estimates? Commented Nov 9, 2010 at 2:28
  • This is actually a great way to exploit the naivete of non-technical clients. Errrr, not that I've ever done that. ;) Commented Nov 9, 2010 at 3:06

I used to have to fill out time sheets at all previous companies, but not in my current gig.

Mostly it seemed like a pointless exercise except in one case: a company I worked for where we were directly billing clients for our developers' time. This was understandable.

The problem with timesheets in typical software work is that the work is too dynamic to fit into nice little bundles. For example, in my current gig: in a typical hour I might spend 17 minutes responding to emails from Marketing, 11 minutes answering questions from Helpdesk regarding some client issue, 12 minutes helping out a newbie colleague with something, and 20 minutes actually working on an official CR issue that can be clearly timesheeted. Mix these intervals up randomly, and there you have a typical senior developer's hour.

Not every hour of every day is like this of course, but it's like this often enough to make timesheets pretty well pointless around here. Unless you're trying to measure how much time is being spent on a particular billable task (which is never the case here), they're basically a waste of time (both developer time and payroll time).


Several jobs ago, in a different country to the one I now live in, we didn't do time sheets. We got paid a salary. If the work was getting done, then that was the end of it.

When I moved to Australia, time sheets everywhere. Paid what was called a "salary", but with time sheets, and hours recorded. Not quite my commonwealth understanding of a salaried position vs a waged one.


I'll fill out timesheets if necessary (like we have billable hours that a client needs to know about), but in general I dislike the whole idea for a few reasons:

  1. I forget them. Nine times out of ten, I end up forgetting for a couple of days and then go back and fill it in with mostly inaccurate info.
  2. I'm an adult who is very capable of allocating my own time. If I'm spending too much time on something, I'll let my manager know. I don't need them to tell me when I'm spending too much time on something.

Our timesheet application is also used to track vacation and expense reports.

Entering time is done to a granularity of 1/2 hour. This is done for reporting purposes to senior managers. Some of the developers refuse to do it and thus end up getting tasked about quarterly to stop working and get their time up to date. I try to remind the guys if they spend 12 hour days, and they write 8 hours, the idiots up top will get the idea we don't need any new developers at all - we can handle the load. We had a death march that involved 7-day workweeks for many months over last winter. Half the devs wrote 40hr/week in the reporting app, while several of us reported actual numbers. By federal law, programmers are "exempt" (which means exempt from overtime in the absence of a union contract to the contrary), so reporting overtime won't get us paid overtime, but the numbers will still show up in reports.

Time spent working on bugs and new code is tracked (sort of) in Team Foundation Server and we only track it with a granularity of 1 whole day. This we're trying to do in order to get better at estimating how much time it will take to do things, as our estimation process is off by -25% to +1000%. At the moment, throwing darts at a calendar across the room is about as accurate as our estimating processes.

The previous place used timesheets to bill clients, so if you spent 45 minutes working on a client's bug, then the client got billed for 45min.


I have filled out time sheets, both as a full time employee as well as a contractor, for nearly a decade, in 4 different jobs, so find little friction in using then, however I don't believe in getting too caught up in the minutia of tasks. The most granular I will ever go is 1/4 hr, and that's rare.

Recently, however, I have been using Grindstone to keep track of what I am doing (thankfully my current position allows me to submit my own timesheet, rather than being forced to fill in a home grown intranet based system).

I would recommend it to anyone finding their timesheet maintenance is either taking too long or is irritating


I've never had to fill out a timesheet and don't think I'd join a company that would require me to. At all the companies where I have worked, I've always been judged based on what I got done and not how long it took. Results and performance are far more important than how long it took to get them. In fact, the former includes the latter: if I got as much done in a year as another developer in a similar position got done in a month, my evaluation probably wouldn't be very good. The other way around doesn't work as well: knowing that one person spent 60 hours at work this week and another spent 40 is not enough to make any meaningful judgement. Some of the most effective developers spend the least time at work precisely because they are efficient.

Moreover, I've been a salaried employee at each job, so I didn't get paid any more or less because I put in more or less hours. So the info on a timesheet would never be to my advantage. Finally, what business is it of yours what I spend my time doing to get a project done? If I produce the best software in the company but you discover that I surf the web 4 hours a day, would you fire me? How do you know that the web surfing isn't essential to my mental process? Moreover, even if I did surf the web 4 hours a day, I probably wouldn't put it on my timesheet, which means the info is fairly useless anyway. I think I'd be tempted to fill it out with BS and hand it in with my TPS report at the end of the week...

Not the answer you're looking for? Browse other questions tagged or ask your own question.