As a programmer, are you required to do timesheets? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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

Answer 25

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