Dealing with estimates as a junior programmer

Question

I have been working for a couple of months now in a company that estimates (for the general population, not juniors specifically) tasks and then we are given the task, solve it, it goes through two tests and at the end the estimate should be somewhat met.

I am beyond stressed because some of the estimates are simply impossible for me to meet. I still don't know the entire system(because it is quite substantial) so sometimes half the time is spent finding out what i need to do and where and by the time I finish sometimes the estimate is over and there is still testing to be done (and correcting mistakes if they were any).

The second time I have to deal with a similar functionality it all works much faster, but so far I feel like I am just bad at programming.

Is there anything you did when you were just beginning that helped you get over this stage? I get so stressed when I see how little time there is to code that sometimes I can't even focus properly at what I'm doing which makes it even worse.

Answer 1

• Many developers with little management experience estimate tasks using their own velocity or velocity of a "best" developer in a team.

• Velocity varies with experience. Senior developer can take 3 hours to solve something, when it'll take you 2 working days to solve the same problem.

• Stress can be rarely avoided when you take up a new job. After few months it normally gets better, assuming you put in enough work and ask lots of relevant questions.

• Your seniors might not be aware of how you feel about estimates, therefore it's important you ask them what do they expect of you.

From my experience:

• I think that senior developer or a manager should be able to estimate a user story (business requirement) in terms of t-shirt sizes (XL, L, M, S, XS).

• It is developers job to break the user story into smaller tasks and estimate those. Large task might take senior developer a day to solve, when it might take you an entire week.

• It is very important to record how long it actually took you to complete the task.

• Good project manager or senior developer would constantly gather this statistics. When your productivity improves, they will be aware of it and they will send more work your way.

This will not only make your life less stressful, but it will also allow the department to manage their resources effectively.

Answer 2

Bring this up with your team lead, project manager and/or whomever does your estimation; not us. People understand that things don't take the same amount of effort for everyone, and they can work to either adjust the estimates when the task is assigned or at the very least allay any fears you have about the review period.

This is, in my opinion, the reason that estimates should be done by the people assigned the task (with input/collaboration from the lead/peers). You get more accurate estimates for how long the work will actually take people to do.

Answer 3

I can't imagine a worse position to put a junior developer in than to set an expectation that they can't keep, unless of course they're doing it to challenge you. Have you had any real repercussions to not meeting the estimates?

I'd say first, it's important that you learned to estimate on your own. When you're given a task, immediately estimate it at what you think it would take, and then start finding the delta between the two. I can almost bet that quality is being sacrificed in the initial short estimate. If it's simply that they're expecting you to design and develop items faster than you can, you may need to have a chat with someone to resolve the issue.

Second, understand that quality is a feature that stake holders, your boss, get to decide to pay for. It may be something that you'll have to either sacrifice doing a bit to satisfy the requirements in the time you have.

Either way, eliminate the stress, it's no fun continuing feeling like you're always behind writing bad code. Hope this helps.

Answer 4

This is common.

In general, it's better to give bigger estimates, than smaller (Most of the time you'll go over the estimate anyway). I'd advice you to cut the task into smallest possible subtasks and estimate these with each task no longer than 4 hours.

If a task may take more than 4 hours break it down into another set of subtasks. Also add a percentual buffer for tasks you can't foresee now (my personal preference is 1 unexpected task for every 2 estimated tasks with each unexpected task taking 2 - 4h depending on the system you're working with).

After that add the time you'd think it would take for testing, communication, analysis etc.

Answer 5

First up: If you get faster with each attempt at a problem, you are probably not a bad programmer. So let's get that thought out of the way.

I would suggest this is your managers' failing, but it is and always will be your job to manage expectations.

Rather than beating yourself up for not being able to meet unrealistic deadlines, measure how many days' work you can actually do in a week. Then explain to your team lead that you're new to the business and software development and you can only be expected to get n days senior-developer work into a standard week. They should at least understand this, even if they don't like it.

Tell them that you expect to keep improving and show them how you can measure that improvement. And agree with them that you don't expect a senior's wage until you can do 5 days of senior-developer work in a week. But likewise you don't expect the same responsibilities as a senior when you're not paid nearly as much.

To take this further, this is why I'm a strong proponent of using story points instead of hours for estimation. ie. Each job gets a number of points, and the team estimates how many points they can achieve in a given period of time. The following period, the estimate is the same as the actual from the previous period, adjusted for known factors like a heavy holiday month or a developer leaving.

As a manager, when a new developer comes in (junior or senior), I make it clear to the business that we will not increase the estimate in the first instance. That developer is expected to take up as much time from other developers as they save. The new developer will probably do better than that, but under-promise and over-deliver is the mantra.

The developer will improve over time, a senior quicker than a junior, and the team's "velocity" - the estimate month on month - will improve along with it.

Answer 6

Keep calm and carry on. If the issue of your not meeting the estimates is ever brought up, just tell them the same things what you wrote in your post, or if you're feeling insecure, talk about it with your mentor/team lead on your own.

Estimates are just that, estimates. They can and will be off, more-so when you're learning the ropes. And as a junior, it's likely the case you're learning the ropes as a team member on that particular project, as a programmer using whatever technology you're using and as an employee at your company. And if you're working with sensible people, they are expecting that you'll be off with the estimates.

You're likely looking at the tasks you're getting "from the bottom up". Your tasks are more important to you than the big picture of the project you're working on - that's understandable. You see the estimates as restrictions placed upon you and obviously are getting anxious when you're not meeting them.

But when you look at the big picture, you'll see that estimates, even more than 'targets' for developers, are 'signals' for leads/project managers. Breaking work into tasks and estimating them is a way to decrease the complexity of managing and estimating the entire project. Keeping track of actual work done vs the estimates is a means of keeping track of how's the project doing, but it's only one of the metrics that can be applied. When estimates are not met on a regular basis, it's a signal for the manager that there's something wrong with the project. But in any reasonable project, it won't be the fact that there's a junior developer on the team not meeting the estimations.

Answer 7

Let me introduce you to my two friends, WAG and SWAG

Ie, the 'Wild Assed Guess' and the 'Scientific Wild Assed Guess'

Believe it or not, I didn't make these up. They're actually pretty common in business. Take a look at this article to see what I mean.

Ideally, it's best to come up with a firm estimate but if you can't, it's better to state that the estimate is rough due to incomplete data than it is to lie.

The key is, business is not computer programming. Managing expectations is more important than precision. It's important to assess the time you think it would take plus 10% as a contingency to make up for any unforeseeable problems.

If you overestimate, they will be happy when you finish with time to spare. If you underestimate, they will be either not disappointed if you meet the deadline or extremely disappointed if something goes wrong.

Business is a grey area that some people acquire an intuitive feel for over time. The fact that they're asking a junior developer to make these sorts of decisions independently says one thing. Either they don't have anyone available who is more capable of making those sort of decisions or the managers don't want to take responsibility for failures.

I'd put my money on the latter if you're working for a large organization. When a hierarchical business model grows large enough, the top is so far removed from the bottom that the higher-ups can only measure progress by what they receive on paper. It's a terrible environment because promotions are generally given for not making mistakes. But the people who get the promotions avoid failure by pushing their responsibilities on others (ie blind incompetence) and taking credit for the successes of people lower on the chain.

Unfortunately, programmers are easy targets to throw 'under the bus' because no matter how large the problem, we will try to find a solution. The key is, don't spend more time determining how to estimate the problem than you do implementing the solution.

Answer 8

That's a tough place. Sounds like you're stuck in the "just have to deliver" stage of that pipeline.

Over the years I've noticed the following about estimation: The quality of an estimate can be determined by answering (with a proper name) the following three questions.

• Who made the design?
• Who made the estimate?
• Who is doing the implementation?

The quality of the estimate is inversely proportional to the number of distinct individuals named. For example: the best estimate is when the same person has done all three of the above tasks, a weak estimate is when one person did design/estimate and another will do implementation, and the worst estimate is one where all three questions are answered with a unique name.