Highly Recommended Software Engineer: Get really good at estimating your time


Highly Recommended - Be the person everyone wants to work with(This is a sub-topic of the series Highly Recommended: Be the person everyone wants to work with.)

If programmer A takes 5 hours to complete a task and programmer B takes 5 hours to complete a task, why would one be a hero and one be heading for disciplinary action.  It all comes down to their estimates.

You need to understand and embrace the fact that you will always be asked to estimate how long it will take you to write some code, even when it involves inventing something new that’s never been done by you or your team before.

If you say something will be done in 1 hour, it better be done in 1 hour and not 5 hours.  Blowing past your estimates makes you look bad and will make people stop trust your estimates.  Meanwhile, the engineer who estimates 6 hours to do something and comes in at 5 hours will become a valued and celebrated part of the team.

Estimating how long it will take to complete various tasks is not easy.  It takes practice.  So go practice.

Also, I highly recommend learning the difference between “ideal time” and time spent in the work place actually working.  For example, “ideally, the new XYZ system will take 3 days.”  Great!  Is that in 8-hour days or 6-hour days (please don’t be 10-hour days)?  It’s important to realize that most people don’t get to focus on their work for 8 straight hours a day.  People ask questions, email comes in, some code you wrote last week has a bug in it, someone needs your help, a meeting gets call, etc.

As the estimating engineer and as the manager receiving the estimates, I find the best thing to do is to be open and honest with your estimates.  Don’t say “3 days”, say something like “If I had 3 uninterrupted days I could get it done, but I think 4 days with normal office interruptions is probably about right.  Do we have any meetings this week?  That’s right, we do.  Okay then, I can get it to you in 5 days knowing we have meetings and daily interruptions this week.”  This might sound long winded but it gets everyone on the same page and you are clearly setting expectations.

What if you simply don’t know?  What if you have to use a system you’ve never seen?  What if you have to write something you know nothing about?  In cases like this, I highly advice you don’t attempt to guess.  Don’t even throw out a number because it will get written down.  Instead cost the amount of time you need to investigate it.    Don’t flatly say, “I don’t know,” or “I didn’t write that.”  That makes you look unhelpful or adversarial.  Instead, proactively offer to go find the answer if you can be given the time you need to investigate and then let whoever sets the team’s priorities prioritize it accordingly.  It is reasonable to say something like, “I don’t know anything about this system yet.  I’ll need 3 hours to walk through the code and see how it works.  After that, I can give you an estimate.  How soon do you need me to investigate?”

When it comes down to it, a lot of your job is all about clearly setting expectations before you start writing code.  The better you get at it, the more highly regarded you will be by engineers and non-engineers.

Be the engineer other people want to work with by proactively setting clear expectations regarding how long it takes to implement specific code before you start working on it.

(This is a sub-topic of the series Highly Recommended: Be the person everyone wants to work with.)