As a requirement for this project, I wanted to share and establish a clear picture of how I estimated how my time was used and how that time was tracked. By estimating and then tracking both coding and non-coding efforts, I tried to find a good balance between the planning and coding phases. Throughout this essay, I’ll outline how I approached these estimates, what I benefited from doing this, and the tools that I used to record my actual effort.
I decided to estimate both coding and non-coding effort hours based on similar experiences (if applicable). I treated these estimates as rough benchmarks, though at the end, I noticed how off I was. At first, I decided to underestimate my time because I thought that I’ll be able to focus more to try and meet the deadline, but I soon noticed that overestimating was a better approach. I will explain that in the next section.
The benefits of estimating the issues in advance, and specifically to overestimate, are so that you’ll be able to plan and distribute your time throughout the week. You can calculate how many hours to put in every day to comfortably complete the task within the due date. This prevents procrastination and last-minute rushes. It also gives your team members an idea of how long your task will take to complete. For example, if my issue takes hours longer than that of my group members, they could take on additional issues when they finish early.
The only upside I can think of to recording my actual effort hours is to get a good sense of how long each task will take when I encounter a similar task in the future. As I describe in 1., my effort estimate was based on prior experience, so recording the time it took on new tasks will give me a good idea of how long similar tasks will take in the future. So for example, if the actual time recorded was a good epsilon amount of time away from the estimate, then that means I had a good grasp on how long the task took based off prior experience. However, if the time was either significantly less or over the estimated time, then that implies I didn’t really have a good understanding beforehand of how easy/complicated the task is. There weren’t necessarily any downsides, it was just tedious.
My actual effort was tracked using WakaTime and my personal clock/timer for non-coding efforts. I believe the software worked pretty well; it’s nice that it’s an extension to VSCode, so I didn’t need to download something entirely separately.
Since Wakatime is automatic, there wasn’t really any overhead in tracking my effort. I just let it run while I code. However, manually tracking non-coding effort was not the best experience. There were many instances in which I tabbed out of VsCode to browse and back into VsCode, hence I had to look at the clock a lot and record it each time I was tabbed out. Yes, it was tedious, but it didn’t entirely prohibit me from working on the project.