For each GitHub issue assigned to me, I made an effort estimate based on how familiar I was with the feature, how much research or new tooling might be involved, and how similar tasks had gone in the past. For example, when building the “Manage Users” component, I initially estimated 1 hour, assuming it would just involve fetching session data and displaying it. However, once I realized I needed to add editing and deletion logic with access control checks, the task grew closer to 2 hours. In general, my estimates were a combination of intuition, prior experience with similar features, and breaking the issue down into smaller subtasks in my head.
Yes, even when my estimates were inaccurate, there were still clear benefits. Estimating forced me to think critically about the scope of the task before jumping in. It made me ask questions like, “What are the dependencies?”, “Am I reusing a component or starting from scratch?”, and “Will I need to look something up?” This helped prevent under-preparing for tasks and gave the team a rough idea of when things might be done. For example, while working on the Contact Us submission flow, I estimated 1 hour and 30 minutes. It ended up taking longer due to styling and Supabase insert logic, but having the estimate gave both me and my teammates an idea of what to expect during the sprint.
Tracking actual effort helped me better understand where my time was going. For instance, I realized that UI styling tasks often took longer than I expected, while writing backend logic for inserting records (such as session data into Supabase) was quicker than anticipated. This awareness helped me improve future estimates and identify where I might need to speed up or focus. A potential downside was that it added a bit of pressure, I sometimes felt discouraged when I saw how much longer things took than expected, but overall, the tracking gave me insight into my work habits and areas for growth.
I tracked effort manually by noting start and end times whenever I worked on an issue. I used the timer on my phone as well and occasionally cross-referenced commit timestamps or GitHub comments to estimate total duration. While not perfectly precise, I believe my tracking was generally accurate to within 30 minutes for most tasks.
The overhead was minimal. Logging time and effort typically took less than a minute per session and didn’t interrupt my workflow. I made a habit of starting the time when I sat down and stopping it when I finished working. While it required some discipline, it never significantly disrupted my productivity. If anything, it helped me stay focused because I was more conscious of using my time effectively while tracking it.
This essay was written with the help of AI.