Measuring Effort

Purpose of Putting in the Effort

Team coordination has always been proven to benefit teams if each member does their part in their timeframe. Hence, the tasks of efficiently managing the amount of time spent working on each task, and communicating with team members prove to be challenging yet engaging as it helps build experience towards my career afterwards. But how much time does one really need to spend on a task? Will it take short enough for me if the task is an “easy” task, or long enough if it is more difficult? How can I evaluate such results? Throughout my time working on this project, I started to realize the true value of estimations.

Tracking Efforts

Early on, I didn’t care whether I got over or under my time estimate because I really wanted to get the job done. But soon, I realized the meaning behind doing this: it sets up as an activity or an event on my calendar of events, navigating me on what needs to be done before I turn my attention away from them for my other classes, and what still remains undone. The most difficult part is to precisely know how much time is possible for me to do such a task: I can’t accumulate the time based on what I do and do not know. And so most of the time, my estimations are based on my heart.

Consequently, when compared to that on a stopwatch, the difference is clear: I was pretty much off. Tracking the actual effort may cost me some time, but over time, it felt like a normal chore to easily get done. Yet, sometimes, I found myself forgetting to stop the clock to record my time, and the results once again, are deducted based on what I was feeling.

Better Estimation Methods

In the future, I aim to use an extension or an app that can actually record my time writing code in real time. They would help me the best to be able to keep track of when I code and when I do something else, relating to my task or not, and to simplify the process of navigating between multiple tabs, or doing mental calculations with a clock. Also, to better prepare for my career afterwards, I should handle my time spent on tasks better. For example, issue-31 had an estimation of around 1 hour to be done, but due to various distractions I was unable to get out of, I wasted a big chunk of time, ending up with close to 2-3 hours of total work. And it can repeatedly be seen in some other tasks I worked on. As an experience, I will try to handle my time better, starting the day after I’m done writing this.

Use of AI

I alternate my use of AI between Gemini 3 Fast and Claude Haiku 4.5 models. For Gemini, I request it more so on fixing a short snippet of code, or from this error I’m having, fix it for me, or teach me what route.ts is and how can I manipulate this file. Like this one time from the beginning of making the project, to recall the commands I have to do to update the Prisma and migrate it to the application, from the error I had here because I didn’t know to migrate it beforehand (silly me!).

Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 20260421223420_add_request_table

Database error code: 42701

Database error:
ERROR: column "username" of relation "Profile" already exists

​ For Claude, I mainly use it for tasks like rebuilding this page my application has currently, with certain modifications in order to serve the correct purposes of that page. To limit your time spent reading this, I will skip this section. If I count everything correctly, the total time I spent on prompt engineering in general should vibrate between 3-4 hours. Approximately, 75% of Claude codes are used, while Gemini’s model is much lower, because I used it for smaller tasks as mentioned above. AI was helpful for the most part, but there’s no need to remove the value of manual work: prompting, reviewing, testing, and integrating AI output still counted as real effort.