I've only been a year in the industry and I've had some problems making estimates for specific tasks. Before you close this, yes, I've already read this: How to respond when you are asked for an estimate? and that's about the same problem I'm having. But I'm looking for a more specific gauge of experiences, something quantifiable or probably other programmer's average performances which I should aim for and base my estimates. The answers range from weeks, and I was looking more for an answer on the level of a task assigned for a day or so. (Note that this doesn't include submitting for QA or documentations, just the actual development time from writing tests if I used TDD, to making the page, before having it submitted to testing)

My current rate right now is as follows (on ASP.NET webforms):

  • Right now, I'm able to develop a simple data entry page with a grid listing (no complex logic, just Creating and Reading) on an already built architecture, given one full day's (8 hours) time.
  • Adding complex functionality, and Update and Delete pages add another full day to the task.
  • If I have to start the page from scratch (no solution, no existing website) it takes me another full day.
  • (Not always) but if I encounter something new or haven't done yet it takes me another full day.

Whenever I make an estimate that's longer than the expected I feel that others think that I'm lagging a lot behind everyone else. I'm just concerned as there have been expectations that when it's just one page it should take me no more than a full day. Yes, there definitely is more room for improvement. There always is. I have a lot to learn. But I would like to know if my current rate is way too slow, just average, or average for someone no longer than a year in the industry.

closed as not constructive by user8 Nov 16 '11 at 14:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Re-asking a question to narrow it down to your specific use-case is not encouraged, and you are unlikely to receive any better feedback. – user8 Sep 19 '10 at 21:59
  • Sorry. I was trying to look for a more specific answer. I'll keep it in mind next time. – Jonn Sep 20 '10 at 4:40
  • 17
    Why is it not encouraged? If the answer he is looking for doesn't exist in the initial question I think it is better to ask another question narrowed down to a specific case. – Rachel Oct 13 '10 at 19:47
  • 7
    Remember that speed is not the only metric for judging a coder's abilities - quality is also essential. In addition to speed, consider the amount of rework too. – Michael Nov 11 '10 at 14:56
  • @John - it is now almost 4 years on. Do you feel your speed/ability has improved since asking this question? – Chucky Jun 5 '14 at 15:01

If you're programming for a job, and your superiors are happy with the rate you're turning stuff out at, then I'd say you're doing fine. As you've lasted a year, they're clearly not outraged with your output. Also, you've only been there a year, and assuming they've been managing people for more than a day, they know that there's a learning curve when you're still green.

As for estimates... I've been in the industry for 5 years now (certainly not veteran territory, I know!), and my personal estimates still suck. I overestimate almost as often as I underestimate, and I do both far more than I get it right. Something will come up, somewhere, and bite you. Sometimes you'll find a library that does everything you thought you had to do yourself, and a week's work disappears in half a day. Other times a stupid bug will stretch a day's work out to 2, 3, 4...

If you're repeating a lot of the same work over and over, and you feel like you've maxed out your throughput on it, maybe you should ask to be moved to another task. 'Cross-pollination' and other PHB-friendly terms are definitely of benefit to devs. If you spend a month or more on something else, maybe you'll find something you're better suited to. If not, or you're not able to stay away from webforms, the change won't do you any harm, and you might come back with a bit more knowledge and experience that will help you.

  • Not that my managers haven't been understanding but they're expecting more from me and faster results and that's whats making me feel inadequate. – Jonn Sep 19 '10 at 21:05
  • 3
    You could always ask you managers how they think you are doing. That way you'll know, one way or the other. They might have good suggestions on how you could improve. Or they might tell you you're doing brilliantly, and you've got nothing to worry about. Pros: Even if you're doing badly, it shows you're self-aware and proactive. Cons: It might make them realise you're lagging. Alternatively, you might be doing well, and being told that could make you lose your fear, and the desire to prove yourself that fear brings – QWasson Sep 20 '10 at 7:09

Lucky you, if you've managed 1 year as a green programmer. I was moved to another unit after just 9 months (of which 3 months was actually programming), for not being productive enough. And I was learning more and more each day, enjoying the process and delivering things at a steady pace. It was the first time I had been working in corporate programming at all, ah well...

Perhaps it would just be better to do the dirtiest, least reliable code with zero testing that barely stays together with bubblegum when doing the task, so the managers will get enough "producitivity" for their benchmarks.


You might be a little "slow" compared to someone who has been programming for 5 or 10 years, but it all comes with time. You are probably doing things now in 1/10th of the time as when you were first learning, and it will continue to become easier. That's just the way most things in life are... you are slow when you first learn it, and you gradually get better, faster, more efficient. If you practice long enough, you might become "masterful".


If you are doing things that are somewhat unique each time getting down to fine detail tasks or getting a very accurate estimate is always going to be difficult.

I personally like the challenge, but sometimes it can make you look a bit silly if you are just looking at a task list or a time line.

If you are doing tests as you go sometimes I would say that the examples you gave are fairly quick depending on the complexity of what you are doing. I have worked on projects where each item, even some if the items inside your bullet points, had at least a day assigned to them.


Whenever I make an estimate that's longer than the expected I feel that others think that I'm lagging a lot behind everyone else.

This is all to common, if no-one will every give a longer estimate when looking at a problem in detail, then all estimate will tend to be too short.

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