The 10x striver: A short story, about you.

Chapter 1 – Planning

You’re a programmer, you’re in the middle of sprint planning with your team. A new feature has been requested by a customer and you’ve been given the go-ahead. The feature seems pretty simple: add a nice popup to tell the user they’re being a silly bugger putting a string in the age picker. You think of the app, you know there are places popups have been used, you’ve not seen the code, but you know its there.

You take a momentary glance at the other developers who are watching expectantly, waiting for the question. “So, how long do you think this will take you?”. This is your moment, this is your time to shine, nothing can stop you, you’re a 10x. You let out a loud sigh to ensure you have everyone’s undivided attention. “Half a day”.

Chapter 2 – Half a day

Half a day, half a day, half a day. This is now your mantra.

It has been a week since you uttered those words. Every morning you have had to drag yourself to your morning stand up and repeat, “I’m still working on…”. You make up excuses about the code in the area being hard to understand, unreadable or an insufficient amount of tests. You wish you could rewind time and give a more reasonable estimation.

It is not YOUR fault

So many of us have been there, we’ve completely underestimated a task we thought was trivial and it took far longer than we could ever have expected. This is not your fault, this is something humans are inherently bad at.

It is fortune-telling.

This is commonly known as the planning fallacy which is a phenomenon where predictions on how much time a particular task will take to complete are exceedingly optimistic, often disregarding the knowledge of prior, similar tasks.

The planning fallacy only occurs when planning for our own tasks, interestingly, us humans take a much more pessimistic approach when estimating for other people.

And also, the more knowledge you have around a certain area the smaller that optimism bias gets. So that explains why the senior developer who has been working on the app since the beginning was shaking his head at you when you said half a day.

We want to impress

Everyone wants to be decent at what they do, everyone wants to be an asset to the team. You want to be the developer who can get sh*t done.

And in our want to impress we only increase the amount we underestimate tasks (As shown by the brilliant story above🤣). Unfortunately, as programmers, a lot of our sprint-planning meetings are done in groups so that need to impress is often multiplied.

Pressure from above

Often it is not just the need to impress which can skew our estimations, it could also come from your team leader, or your project manager, or the CEO of the bloody company.

We all love Elon Musk, but blimey does he make some crazy deadlines. I can only imagine the pressure the engineers must feel working for him!

It’s not all bad (Parkinson’s Law)

Parkinson’s law is the notion that work expands so as to fill the time available for its completion. So basically, you know that time when you had to finish a school assignment in 2 days and you managed to get your shit together and get it done? That’s Parkinson’s Law.

You underestimating the time it’s going to take you to implement a feature may make you work harder at hitting the deadline, but that’s only if you place a high degree of importance on getting it done. If you aren’t all that bothered if your work takes longer than estimated then Parkinsons Law probably won’t have much of an effect.

This is likely why Elon Musk makes crazy deadlines for his engineers, putting them in a perpetual state of Parkinsons Law forcing them to work their asses off.

So how do I get better at estimating?

In Software Estimation by Steve McConnell he recommends:

• Breaking the problem into sub-problems or sub-tasks
• Estimate using ranges rather than giving an explicit date (This depends on how your company estimates)
• Find similar completed tasks, so how long it took you to implement a feature in the same area. Essentially use your prior knowledge.
• Understand your margins – if you’re estimating something completely new you might need to take a 100% or even 400% factor.
• Communicate with the appropriate people about your estimation as you refine it.

Finally

I wrote this blog because as I said, humans are inherently bad at estimating, but I myself am probably even worse than the average human. Even just this week I’ve underestimated a ticket I thought would take me a couple hours, probably prompting me to write this blog.

The moral of the story:
if you’re shit at estimating, don’t worry about it, we all are.

I’d love to hear your thoughts and or stories of times you’ve underestimated a task or even your own tips for making estimations. Equally, I’d like to hear from the 10x developers who estimate bang on every time 😄.