Estimating the Unknown: Time, Tracking, and Teamwork
10 May 2025Estimating the Unknown: Time, Tracking, and Teamwork
.jpg)
Picture this: you’re gearing up to fix a bug or build a new feature. You think, “Yeah, this should take maybe two hours max.”
Fast forward five hours, two VSCode crashes, a full Wakatime session, and three snacks later… you’re still fine-tuning that one flexbox alignment or refactoring a database query you thought you understood.
That’s what effort estimation felt like throughout our project. Not a science—more like weather forecasting. You guess based on patterns, but reality always adds surprises.
How We Made Our Estimates
Most of our estimates were what I’d call “calculated guesses.” Sometimes we based them on experience—if I’d done something similar in a past WOD, I’d ballpark that as a 2-hour job. Other times, especially early in the milestones, it was more gut feeling than logic. We looked at the issue, talked it out, shrugged, and said something like, “Let’s just call it 3 hours?”
Were we right? Rarely. Were we better off making the estimate anyway? Definitely.
The Unexpected Benefits of Being Wrong
Even when our estimates were off (sometimes way off), having them gave structure to the chaos. It forced us to think ahead—What will this task really involve? Where might we get stuck?
Those conversations led to better communication and more realistic expectations.
Estimates also helped us prioritize. If something looked small on paper, we’d try to knock it out early. If something seemed like a black hole of unknowns, we mentally prepared for the long haul—and sometimes paired up. Even guessing wrong taught us something: like how UI styling often takes longer than backend logic, or how a “quick schema change” can spiral into hours of debugging Prisma errors.
Why Tracking Our Time Mattered
.jpg)
Now here’s where things got interesting. Actually tracking our coding time—using tools like Wakatime, Code Time, or a simple stopwatch—turned our assumptions into data.
Suddenly, we weren’t just saying “That felt like a lot of work.” We could prove it.
We could see that something estimated at 1.5 hours actually took 5 hours and multiple commits. It also showed who was getting buried in certain issues, which helped us shift workloads fairly in later milestones.
In short, tracking helped us reflect, redistribute, and rebalance.
Downsides? Barely Any.
Was there a downside to estimating and tracking? Maybe just this: it sometimes made time feel like a scoreboard.
When you spent 6 hours on something you thought would take 2, it felt like a loss—even if the final product worked perfectly.
But that’s a mindset issue, not a tracking problem. Once we realized that effort ≠ failure, the data became something to learn from, not stress over.
How We Actually Tracked It
For me, I used a mix. Wakatime ran in the background, tracking my real-time coding in VSCode. When I was on short bursts or switching between tasks, I used a stopwatch to be more intentional.
When I forgot to track? I made an educated estimate based on memory and GitHub commit timestamps.
I’d say my tracking was around 85–90% accurate. Good enough to notice trends. Not perfect, but definitely useful.
Did Tracking Take Up Time?
Barely. If anything, it saved time by helping us plan better in future milestones.
Tools like Wakatime and Code Time were seamless. Even stopwatch tracking, which was more manual, never got in the way of the work. At most, it added a few extra seconds to start or stop a timer.
Final Takeaway
Tracking and estimating effort wasn’t just about logging hours—it was about getting to know our team’s rhythm.
It taught us where we underestimated complexity, where we overestimated confidence, and how to better support each other as developers.
Even if we were wrong about the “how long,” we were right to ask the question in the first place. That curiosity, that reflection—that’s what turned our team from a group of coders into a collaborative unit that could learn, adjust, and improve as we built something real.
And really, isn’t that what engineering is all about?