I had both coding and non-coding issues, and I tried my best to make accurate estimates by giving myself more time than I actually expected to need. I made my coding effort estimates by looking at some of the experience WODs we had previously worked on. I thought those would be most similar to what we were doing for the final project, since both could be done at home without too much time pressure. But I had a lot of issues that were not related to coding, such as deployment to Vercel for the team. For those assignments, since I had no prior experience, I just had to make my best guess about how long they might take.
Yes, it is true that many of my estimates were not very accurate, since this was my first time working on software development. However, I believe that making effort estimates was very helpful because it made me think about how long tasks might actually take before starting. I’m personally really bad at managing my time, so this actually helped me to make somewhat better plans. It also forced me to give myself at least the amount of time I estimated to work on the project, regardless of how long it would actually take. So it is important to give yourself enough time when estimating tasks, just like my professor mentioned in class.
Tracking time while working on issues definitely helped me because I was able to compare it with my estimates and make better estimations for the next milestone. For example, I realized that coding issues usually take much more time than expected, since you might encounter a lot of errors. On the other hand, non-coding issues were more straightforward, as long as you understood how things work, like the Supabase database system. At first, I was really annoyed and felt like I was doing extra things that were unnecessary. But I quickly realized how important this is for myself and for the sake of the project, and I could even get extra credit by doing so, which is a win-win.
I used Google Timer to track my work, which was really simple. I just had to use the stopwatch function, clicking it when I started working and clicking it again when I was done. I could also pause it when taking a break and keep the tab open, which was more convenient for me than downloading tools in VS Code. I think my tracking was pretty accurate since I used a stopwatch, but for some issues, I tried to spend at least as much time as I had estimated and make my project even better. But I definitely did not provide incorrect results, since it was the actual time I spent on each issue.
Tracking my time using a stopwatch did not take extra time, since I just had to open a new tab and search for Google Timer. However, if I had to download something in VS Code to track my time, then it would have taken more time. I would also need to learn how to use that application and figure out which one is best for tracking time. I think it did distract me a little bit, but in a good way, because it made me feel that if I spent less time than I estimated, I could always work on it a bit longer, since I had already planned that much time for the issue. So in conclusion, IDPM effort estimation and tracking was something very valuable, and I learned that I should try to do it by myself next time I work on a project, not necessarily only in software engineering but in any field.