How to Find the Time
28 Apr 2026
Throughout the course of our ICS 314 final project, there were a number of time constraints and deadlines that we had to meet. Setting aside enough time was critical to complete our project and ensure quality work. For these reasons, we were asked to catalog our coding times, called "Effort Estimates," and manage issues within GitHub project workflows.
In terms of my ability to manage expectations and properly estimate times to complete specific tasks, I largely based all of my initial time estimates off of previous timed quizzes and at-home assignments throughout the 314 course. When I thought of the amount of time to dedicate to a task, I would look at the initial problem and try to visualize what the UI was meant to look like and how my code needed to function. From there, I would try to understand the scope of my issue and how my program would interact with the rest of our team's work, pages, and database. This helped me discern the complexity of my issues and the time needed to complete my tasks.
When thought is put into practice…
However, I faltered in defining how much work needed to be done to complete my issues. Truthfully, I created tasks that should have been broken up into multiple branches and dealt with individually. Instead, I lumped everything together during our early development. As a result, a seemingly simple and vague task quickly devolved into a 4-hour issue. My greatest shortcoming was not in the time allotted to handle an issue but in using a single branch to host a number of issues that overtook my time and workload.
Moreover, I think there are benefits in having the foresight to manage your time within a major project. For instance, while working on Milestone 2, we had to get the majority of issues and code completed before we could create our Playwright script. If we ran into issues, we had our foundation in place and could refine our work. Saving us time and preventing last-minute roadblocks to completing our deadlines. However, I consider this practice to be more of a hierarchy that manages priorities rather than the practice of time estimation.
Contemplation of efficiency and results…
With that in mind, I did not find time estimates to be useful. This is not to say that the tenets of time management and meeting expectations are not great practices. Just that the timed constraints are not conducive to my work outcomes. I felt that adding timers to my coding did not aid in understanding and rushed my learning process. Moreover, these timers made me feel inadequate as a programmer for not meeting arbitrary timelines.
What I found was most conducive to my learning outcomes is setting aside a little bit of time every day to handle coding issues. With larger workloads dedicated to longer days. To put it simply, I work best by not timing my work with a stopwatch. But rather than trying to beat the clock, I work better when the work is broken up without specific time frames. All of this to say, I believe a set of fresh eyes and a fresh mind maximizes your results.
Reflection on data collection and accuracy…
Documenting our recorded times was hosted on our GitHub project boards. In order to reach deadlines or "milestones," we created workflows that detailed information about our application and its requirements. We listed out our recorded times by the categories of initial effort estimates, actual coding times, and non-coding times. In terms of how I kept track of my coding times, I had used the timer and stopwatch built into my iPhone. As I would create issues, I listed an initial estimate within the description section of GitHub issue boards. Before starting my work, I would set a timer to see if I could perform a task before the alarm went off. Later, I would use a stopwatch to better reflect my actual coding times and not to beat the buzzer. Once I hit a roadblock, I started a second stopwatch and periodically added to my non-coding time as I researched and found solutions. After a task was completed, I would comment on the actual time under my GitHub branch. By Milestone 3, I began adding information directly into the effort estimates table board and would tack on additional time for tasks that spanned multiple days.
That being said, I think my times were accurate, though I could have been more structured about how I cataloged my hours. Aside from loving a spreadsheet, I believe that I should have thought through the complexity of my task and broken it up into smaller segments. This would have better reflected my initial coding time estimates and saved on non-coding time.
Implementing AI throughout the coding process…
As for my use of AI throughout this project, I used the ChatGPT-5.5 series to aid in my coding process. I prompted the model with instances such as “Help adjust the border coloring on my modal cards." Or requests like “Please fix the toggler on my search bar icon to color: rgb(65, 132, 255)." This would steer me in the right direction, with many of my prompts being basic and nonspecific to my project. Resulting in many more prompts needed to be asked to achieve my desired UI implementations before integrating my code into our main branch. My time spent asking for correction to my code or initial scaffolding was dismal in comparison to my actual coding time. Only about a third of the code generated did not have to be modified in some way.