The Inability to Estimate

Photo by nikko macaspac

I have this glaring problem. I keep looking at things in a way that is drastically simplified. What is this? Am I lacking the skills to view things at a higher granularity? Am I always stuck in this cycle of ‘I should be able to do this’ but ended up not being able to do it on time? I hate that.

In my head, there is a certain way that I adopt. This has actually proven to not work for me time and time again. I always seem to fall short when it comes to deadlines. Unfortunately, as of this writing, this is my biggest weakness. Or is it a potentially strong character?

Efficiency is doing things right. Effectiveness is doing the right things. - Peter Drucker

What I have in me is potentially efficiency. I do things right, but am I doing the right things? That is one deep question to think about.

Estimating and why it is so hard

As a software engineer, I have to provide timelines of my estimates to the product manager(PM). The weird thing is this, the PM does not really rush me. The PM does not tell me that I am taking too long on my own estimates. The PM respects my supposedly educated estimate. But why is it so hard to be on time?

My guess is this: Effectiveness trumps efficiency. When I think about it, the code I submit are usually altering things that might not matter to the current feature that I am working on. It might be a refactor that I think would better the codebase. The downside of this behaviour is: it takes too damn long.

The Boy Scout Rule

Robert C. Martin, aka Uncle Bob, wrote about a principle in his book, Clean Code. This chapter touches on the idea of being a professional in the art of software engineering. The notion of leaving the lines of code that you were interacting with better than when you first saw it. I consciously practice this at my workplace.

I take pride in knowing that my work is not just about pushing features. It is also about the betterment of the codebase as a whole. Unfortunately, the downside is that I sometimes push features later than promised and that could potential trump the need for the Boy Scout Rule. I once received an advice from a fellow colleague.

Focus on the things that will deliver value to the customer.

I used to work in a place where I was allowed to just be creative. I was working on projects that had no similarities to the outside world. They were all new ventures in solving problems. Maybe I have some wiring in my head still stuck from when I was working there. I have to deliver value to the customer. Whatever I do, should in one way or another bring value to the customer.

Improving the codebase in a way that improves the experience for the developers is important. It makes them more productive and it helps if you make the tools work you very well. Things like these are easily justifiable to spend time on. They can even be significant amounts of time! For as long as it delivers value to the customer.

## Next Steps There are a few things that I can adopt when providing timeline estimations. Namely, I can preliminarily break down the task into smaller chunks from a more at-first-glance kinda perspective. It does not have to be ultra accurate, but at the same time, the experience that I have should provide lower margins from the actual timeline. I should read up more on the betterment of breaking down big problems into small ones. Easier said that done, really.

Till next time.