Over Optimistic Daily Productivity

Question

I'm a junior developer and have been working since I graduated last summer so coming up to a year now. I have this issue that is starting to get to me. Every night I think back to what I did that day, feel bad that I didn't get as much done as I would have liked and then tick off in my head all the things I'll get done the following day. Come the end of the following day I end haven't gotten through half of what I wanted to.

This over optimism that I'm suffering from. Might it be just because I'm relatively new to the profession and aren't aware of how long things will actually take me. The work might be quick to think through in my head but all sorts of time sync's involved can bleed away the hours. If not that then perhaps it's the technology stack that I'm working on. SharePoint isn't the easiest thing to develop for and it's certainly something I came into not knowing a whole lot about.

If it's because I'm not yet skilled enough to predict how long things will take me, is this trait of over optimistic predictions universal to the profession? I'd appreciate any input from those experienced with working with younger developers and those that might have suffered from this themselves.

[EDIT] Perhaps I worded the question badly. I'm interested in just general day to day work rather than overall project completion estimation.

Answer 1

Please see this question.

Answer 2

My (non-technical) manager always says IT people in general and not just programmers, are overly optimistic, especially when it comes to agreeing to or setting deadlines. He tends to allow for this in his project plans, and so far, he's been spot on!

In my experience, it is always the unanticipated hiccups, usually minor ones, that can make things take longer than expected or hoped. The good news is, making a mistake once gifts you with the power to not repeat it.

Answer 3

fogbugz.com provides an adaptive estimation environment which learns how incorrect you are in your judgement and provides you with probabilistic estimates.

you should give it a try - you will learn your pace while using this system and your estimates will become more accurate with time

Answer 4

My suggestion is to keep a list of everything you accomplish in a day and approximately how long you spend on it, broken down to individual tasks. I find this helps me in couple of ways:

1. You can see what time and activities are not contributing to your productivity and work to eliminate those inefficiencies.
2. You can get a better idea of how long things took in the past and use this to gauge how long a similar task might take the next time.

Answer 5

I'm going to say that unfortunately; this is normal ... not pleasant, but normal.

I would also say that it goes beyond just optimistic estimates, unknown technology risks, or even programming ... I'd almost say it's an inherent business condition.

It increases with communication and interpersonal relationships. When I started tracking my time, I couldn't believe how many weeks I'd end with a bunch of simple tasks which were not completed due to the necessity to rely on others who didn't have the same priority as me. It was really frustrating and an incredible eye opener.

Answer 6

Almost finishing my 3rd year as a full-time professional developer.

The days where I actually get done everything that I desired to at the start, those are few and far between. I get, at best, one or two of those a month. There are hosts of reasons for things going this way, but the primary one that I have discovered (and this is applicable to any professional field) is the time it takes you to learn or recall the knowledge which is immediately relevant to your current task. Doing anything for a few years, there are some things that you can recall off the top of your head; decades more experience allows you to accumulate ridiculous amounts of information in that part of your brain with low-latency access (your short-term memory).

Also, keep track of your distractions, and try to eliminate them - it's very easy for us relatively young ones to get sidetracked online, very difficult to maintain task discipline. Remember, we are the first kids raised with the Internet, and our attention spans are incredibly low compared with our seniors, making it very easy for us to lose time.

Speaking of which, I need to put down this distraction called Stack Overflow and get back to writing code...

Answer 7

The saying "There aren't enough hours in the day. . ." existed long before computers did. Learning not to underestimate how long something will take is something you'll have to learn.

Underestimating how long something will take is certainly a problem for those in the computer industry, but I'm not sure whether it's much worse than for a lot of other types of work. There's a universal tendency to be overoptimistic regarding time. It's easy to do that when the first (i.e., the easily visible) 90% of a project takes 10% of the time and the final 10% takes 90% of the time. The devil is in the details.

In short yes, accurate estimation is something you learn (or should learn) only through experience. You'll get familiar with your own tendencies regarding estimation of time and (hopefully) learn to compensate to correct your natural tendency to underestimate. Making accurate estimates is not necessarily something that will ever feel natural. It's a matter of acknowledging that application of rational rules (e.g., multiply my initial estimate by 2.5) yields more accurate estimates than simply going with your natural tendency to say, e.g., "Yeah, I should be able to knock that off in six hours."

Answer 8

I would suggest you get on some sort of evidence based estimation system. classify your work assignments into categories such as:

• Requires new tecniquie - base estimate x3
• routine work - base estimate x1
• bug fix code i wrote - base estimate X .5
• bug fix code someone else wrote - base estimate * 1.5
• bug fix on threaded code - base estimate * 4

etc. etc.

after a bit of tracking you will get a baseline number and categories and be able to project/predict your work effort accordingly. there are some good tools (Fogbugz) that do this for you, but your shop might not be in a position to adopt this toolset.

extra credit : if you miss your estimate - do an AAR and figure out why you missed and recategorize the work or create a new category if necessary.

Answer 9

This doesn't exactly answer your question - but it'd be better if you didn't worry about exactly what you got done in a single day - think in terms the particular project(s) you're working on and how far along you got on them. You're right in thinking that it's just that you're a little new to the craft - part of the art of software is getting a good feel for the progress that you are making, regardless any concrete deliverables. I've found that some days I deliver a ton of stuff because it just so happens that I'm able to finish off whatever I happen to be working on - other days I just take the best bite out of the current project that I can - the trick is to choose to feel productive in both cases.

Answer 10

Too detailed a todo list can be counterproductive. Too many things change midstream on a project or even in the day. I'm a fan of the work queue approach. Concentrate on the next thing and don't worry about what you will do after that till you are done. Then at the end of the day you look back and see how much you got done and not how much you didn't get done.

It boosts the morale and also more accurately reflects what needs to be worked on versus what you thought you needed to work on.

Answer 11

No developer working an 8 hour day actually codes for 8 hours. Don't feel bad!! Meetings, process and planning, context switching, etc. all contribute to a normal work day even if you feel it isn't 'real work'

The best way to avoid getting stung is by using a percentage multiplier when calculating your 'real capacity.' Also, keep it simple to avoid spending more time then necessary on this type of planning.

We use a simple system that uses a standard multiplier for most developers and a lower multiplier for more junior or new developers (learning, training, slow, etc).

This is used for capacity planning, but there is no reason you can't use something similar just for yourself.

75% seems to be about the 'sweet spot' for the average developer, 65% for junior, but this will vary depending on your environment / process.

For example how many 'real coding hours' will you put in a week?

assuming a 40h work week, 40 *.75 = 30h

Or how long will it take you to do a '20 ideal hour coding' task?

20/.75 = 26.66 or roughly 3.5 days.

This simple system helps you plan, and you will be able determine your optimal multiplier by keeping track of your actual 'coding hours' in a week over a few weeks.

Answer 12

I worry about this stuff too. So does everyone I work with. I've found that

• I can only have one project that is the most important.

• It is critical to move my most important project forward every day---but often just 60 to 90 minutes can be enough.

• I am happiest when I give myself permission to accomplish just a small amount some days. There is always tomorrow.

It is actually quite surprising what can be accomplished in relatively short working sessions, as long as there is a working session every single day.

Answer 13

It takes a little time to get better at estimating. Work on it! Thomas & Hunt advise to keep track of your estimating so that you improve at it. Scrum makes it a daily routine. Practice makes perfect.

Answer 14

i've found thinking in terms of "a day" isn't very useful. i equate "a day" with "a long time" so i should be able to get "a lot done" ... pretty airy-fairy sort of a measure.

so alot your time in smaller chunks - less than four hours at a time. so instead of "today i'm going to do A,B,C,D,X,Y, and Z", you get "A=1,B=2,C=3,D=1,X=4... crap no way i'm getting all of this done".

and that's fine. having a good hold of the situation is far more valuable than constantly failing optimism.