Working hours for a newbie

Question

This is not a very related software / hardware question, but it's too related to the Tech world.

I started a work 3 months before, and I am about to finish this week, and my boss asked me to do a planning of what I've done so far, I think this is totally ok, but he is asking for what I did each day with the hours I spent in these days.

This is a sample of what I sent him

                                            M       T      W        T       F 
week 29/06 to 03/07 				
compréhension et analyse du problématique   *      *			
architecture de l'application   	                   *       *	   *

which translates to first task, I spent Monday + Tuesday on, and the last W, T, and Friday.

What he is asking for, is what I've done in each day, with the timing I spent on (obviously, I don't think I remember, and because for a programmer, there are no sequence tasks, I mean I change code in a class, then change it in another to fit with the new one and so far)

So my question is: is what he asking normal? and if so how can I detail the planning for the 3 months.

[update]

I used the email account we use to test our software with the extern servers, and I got a good view of what I was doing in every day :), a generic view but it helped too much (PS: The boss doesn't know anything about programming, for him, it's like writing lines and get results back nothing more )

Answer 1

Well, I saw your table. "comprehension et analyse du problematique" is probably dangerous to put in - I mean, your boss is going to see it and say "What? you took two days to understand and analyze the problem"?

Since your boss is a non-programmer, I strongly recommend you break up your work into separate areas : e.g

• User Interface
• Refinement of Layout
• Running UX tests

• Linking of UI to program code

• Function HELLO WORLD

• Code optimization
• Troubleshooting Bugs
• Harden logic
• Code robustness improvement
• Code documentation

Remember, a non-programmer will never understand what you are doing, and will always think that programming is easy-peasy. When you draft out a work review, always periodically take a step back, switch to a non-programmer way of thinking, and ask yourself "Do I understand what is going on"? Best is if you could get your wife or friend who is a non-programmer to test if they understood.

Also - it is quite normal to ask for a work review. However, it is not normal to ask for a daily breakdown - your boss might turn out to be a micro-manager, or he just wants an affirmation that he hired the right person.

Good luck!

Answer 2

It's incredibly hard to give a breakdown of what you've done days ago if you didn't record it at the time.

Here's an idea I have used in the past... If you used source code control AND did regular checkins AND used useful comments, then you can generate a fairly accurate list of what you did and when by exporting the change logs. I had a job where I was required to detail everything I did in a weekly report and summarize those monthly. I wrote a little perl script to format the SCM logs (VSS at the time) into bullet points for my weekly report. It was then a simple matter of runnign the script weekly and cleaning up the results.

Also if you work via tickets/tasks assigned to you in a tracking system a simple report of "what tickets did I close last week" will prime your memory nicely.

Unfortunately, much of programming is sitting at the computer (or eating or taking a shower) staring off into space while working out a problem. This translates into "worked on _" on a time sheet but doesn't sit well with a PHB who's never coded.

Answer 3

Yes, it's fairly normal, but not necessarily after the fact. It will be impossible for you to remember what a few hours of your day was spent on a month ago.

In my work, when I log my hours on my timesheet, I write in what specific tasks I had worked within those hours. This way, when my boss prints out the invoice to our clients at the end of the month, this information is available on a daily basis. This is something you have to plan ahead for, and trying to gather this information after the fact will be nothing but guesswork and useless.

Answer 4

Yes, it is normal for managers to expect you to report past activities and plan future activities.

,,compréhension et analyse du problématique'' and ,,architecture de l'application'' might be to vague. There's no way to measure how much you've comprehended or analyzed in half a week of work. Concentrate on tangible deliverables

• Monday, Tuesday - designed 2 dialog GUI
• Wednesday, Thursday - wrote database mock-up for testing
• Friday - wrote networking protocol documentation

Managers usually can comprehend this level of technical detail. It shows them the real value that you give to the business.

Answer 5

Seriously! Just tell him what you've asked us! He should understand.

Answer 6

tell him resource/time allocation planning usually happens BEFORE coding starts; planning out the use of time resources is part of the technical/software specification of the code changes. you should have these specs somewhere at some point in time.

that way you can easily recall and say "hey, this part took longer than we planned" or "this other part was completed quickly"

as a technical person working for a non-tech, you'll find a lot of challenges that you need to skirt around or overcome.

Answer 7

It sounds like your boss expected you to keep track of exactly how you spent your time. This is "normal" for some work, but only when time tracking is explicitly part of the contract or job responsibilities.

I think what he wants is more like: Monday - 9-11am - problem analysis for part 1 of problem - 1-4pm -- problem analysis for part 2 of problem Tuesday - 9-11am - problem analysis for part 3 of problem - 1-4pm -- problem analysis for part 4 of problem Wednesday 9 - 4pm - application architecture design

etcetera

This is VERY hard to do after you are done the job. You must track the time while you are doing the job.

If you are already done, you are going to have to tell the boss that you did not realize you were expected to keep detailed time logs.

If your boss wanted a detailed plan of how you spent your time, he should have told you at the beginning of the project, not at the end.

Answer 8

The boss may know nothing about programming, but I would still expect them to know something about project management, assuming the 'boss' is a 'manager'. The questions you are being asked sound as if they are coming from someone who suddenly needs to justify how your time / money was spent. You say you'll finish this week, but when was the project due?

I agree with most posters (@Chris Nava, @Guard, @lo_fye) that reconstructing this accurately will be difficult and that you should have known what the reporting requirements were before you started. Questions:

1. Were you given a plan that you were expected to follow?
2. Were there defined project milestones?
3. Did you have written requirements to work from?

Ask your boss to see the project plan. Even if not to a daily or hourly level of detail, providing feedback on when each requirement was coded / tested may be more useful than providing lots of details about your daily work that he won't understand anyways. Too much 'jargon' in your status may do more harm than good.

Answer 9

Yes, it's normal to have to do this kind of thing. What's abnormal is that you've been asked to do this for something you started three months ago! I would expect a timesheet (or whatever formal or informal system is in place) to be weekly or, at most, monthly. And when asked to do a monthly timesheet I tend to fill it in every week anyway but then I have a poor memory...

As for your current predicament, you don't really get much choice but to guess. I wouldn't go much less than a day because you're really not going to remember in that much detail!

Answer 10

Like tkadlubo said "Yes, it is normal for managers to expect you to report past activities and plan future activities."

Take it as a compliment that your manager is interested in your work. Once a week is a reasonable time period for reporting. Use the opportunity to also add what you have planned for next week. That way if you're working on the wrong things, the manager can get you back on the right track.