Am I guessing or am I estimating? How long does it take to write code?

This week we unpack how we can tackle estimates and empower ourselves to negotiate better when something eventually does go wrong!

Welcome to the everyday nightmare of anyone who works in a corporate environment and has a boss of some sort asking them the impossible question “How long will it take?”.

Photo by 愚木混株 cdd20 on Unsplash

Fear and panic are common responses to this question and most people buckle under the pressure, shouting out the first number that comes to their mind. “12 days” you shout out loud while being interrogated under the cold stares of your new boss.

Panic kicked in, and the number 12 was given without you having taken the time to consider the first few obvious faults in the coerced response. Firstly, what are you estimating? Is it a simple code change or a whole new feature? Did you take the time to ask?

Second, what do 12 days even mean? Are we talking about twelve physical days in a row, including the weekends, and you working 24 hours a day? Is this 12 days for the entire team all working in parallel on the same topic? Or is it just for you, working on your own, without testing or anyone else being involved?

Time to STOP!

The acronym simply spells out the old mantra of Sit down, Think, Organise and Plan, which is never a bad thing to do when you are asked to give an opinion. In the case of an estimate of time needed to complete a task, without some type of formula, is merely an opinion.

Dividing up a piece of string

The focus of today's article is to help you with the art of estimating or better put, making an estimated guess.

First, we can start by defining the parameters of what we think a day of work actually means. Now this is a hard truth and it will be different for each individual, but it is safe to say that no one works 8 hours, straight. It is just not possible. You can be at work for 8 hours of course, but focusing on work assignments for 8 hours is close to impossible, or someone is lying to someone else.

On a standard day, and I’m going to make a few assumptions here like, you work 8 hours a day, not less, you have lunch and tea breaks and probably will answer the call of nature a few times. So on these assumptions, we can say that you probably work about 6 hours a day.

I’m not accounting for you messing around, or not focussing, or your work buddies distracting you with cat pictures, or that strange accountant that keeps coming to talk to you about recycling your napkins.

The second part we need to unpack is a little more difficult, as you are going to have to be honest with yourself about what all the parts of your development workflow are. If you are asked daily to ONLY write code, you will have to admit that you will have to still set up your project and environment and check out your code, and read your emails (maybe). Then you need to understand what needs to be done and deal with all the other admin.

Writing stuff down can be a good idea

Now that we have a few basics settled down, let’s get into the next part of just recording how long things truly take you. This part you never have to show your boss (no promises) but it will allow you to get better at understanding that nothing in life takes ‘just 5 minutes’.