Eight strategies you can use to give better estimations as a software engineer.

Franco Fernando is a software engineer and technology enthusiast known for his expertise in web development and mobile applications. Readers can learn about coding best practices, software architecture patterns, and emerging technologies. With articles, tutorials, and code samples, Franco Fernando shares  insights and expertise for building modern and scalable software solutions.

The Polymathic Engineer

Eight practical strategies help software engineers provide accurate task estimates across different scenarios. The guide covers leveraging past experience, consulting colleagues, timeboxing refactoring work, clarifying requirements for new features, prototyping unfamiliar integrations, learning mature technologies, evaluating cutting-edge tools, and breaking down complex projects with multiple unknowns. Key principles include documenting completed work for future reference, adding buffer time for learning curves, building proofs-of-concept before committing to estimates, and being transparent about risks and uncertainties.

How to Estimate the Duration of a Task

4. Building from scratch using well-known technology

6. Simple Task with an unfamiliar Mature Technology

I’m a self taught developer, and I find this is something I struggle with more than some classically trained devs because often I’m either seeing a problem for the first time and need to figure out which tools are best for the job, and I’ve also not had the experience with assignments in courses that I can build a basis for estimates off of by thinking about how long those took.
This is an interesting article with some good advice. Timeboxing is a really really great strategy, and often those asking for estimates are more than willing to give you a day or two to dive in and provide an estimate when you don’t have experience with a tool or codebase. However some of these are a little silly. How practical is it really to keep track of all the tasks I do and how long they took me? What happens when my skillset becomes so diverse that I have 30 notebooks full of tasks I’ve done and I’m supposed to reference to give an estimate, at that point I’d argue that’s a task that needs an estimate itself. The advice to pair up with someone who knows the unknown tool is also not always practical. What if you’re the only developer on the project, or what if the other dev that knows the unknown is too busy to teach. Colleague’s are a valuable resource, but it’s not always their job to handhold you while you learn.
All-in-all, I think the takeaway here is to find strategies that work for you. Estimation is a skill that needs to be trained and practiced like any other. The more you do it the better you’ll get, and there are tools (like timeboxing) we can use to increase our accuracy. At the end of the day though, I think we need to remember that these are exactly what we call them… estimates, and not tie our value to their accuracy when things happen.