Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
scroll top