A Time Was Had
24 Dec 2025Estimating or Best Guess?
For effort estimates, I mostly relied on breaking an issue down into steps and using my own recent experience as a benchmark. It was mainly how similar tasks felt earlier in the semester and at a later time. If it appeared to be a simple UI change that I had previously completed, I usually estimated an hour. If it involved wiring logic, tracking state, or anything that could lead to debugging, I tried to estimate higher, but I remained optimistic because I assumed the first approach would work. In retrospect, that assumption was the primary reason my estimates were inaccurate.
Even when my estimates were incorrect, estimating ahead of time was beneficial because it forced me to consider everything before beginning. For example, I estimated that “Create a mockup of add RIO page” would take one hour, but it actually took two. I underestimated because it involved more than just putting elements on a page; it also required matching the project’s layout, making it look consistent, and cleaning up details. Another example was “Adding Image to RIO cards,” where I estimated 1 hour but ended up spending 1.5 hours. On the other hand, estimating helped me identify when something was likely to be smaller. “Updating project home page (M2)” was estimated to take an hour, but it actually took closer to 0.8 hours in total (0.5 hours coding, 0.3 hours non-coding). Having a planned estimate made it easier to fit the work into an hour of my schedule without disrupting it. Also, tracking actual effort was useful because it revealed why my estimates were incorrect.
Technique Technique
I tracked time for each issue in our effort spreadsheet, categorizing it as coding or non-coding. The non-coding column was important because it recorded time spent reading the source code, testing behavior, and diagnosing problems, rather than just typing. “Fix Google Form” demonstrates this well, as it was 0.5 hours non-coding and 0 coding. My tracking wasn’t perfect because I logged in chunks (often 0.5 hours) and context switching can make things blurry, but it was good enough to show which types of tasks were consistently underestimated.
Next time, instead of providing a single number, I’d estimate in parts and use ranges for anything with uncertainty. Something simple like “Make bookmark button clickable in RIO card” can easily double in time once debugging begins. I also did not use AI for effort estimation or tracking, because those figures were determined by my own pace and the amount of debugging required. Overall, estimation helped me plan and hold myself accountable, while tracking helped me be more realistic about budgeting time for testing and debugging, which is where my estimates frequently fell short.