How to Find the Time
28 Apr 2026
How to be realistic about outcomes within time constraints…
In terms of my ability to manage expectations and properly estimate times to complete specific tasks, I largely based all of my initial time constraints off of previous WODs and at-home assignments from this course. Moreover, I look at the initial problem that I was trying to handle within our final project. I would visualize what the UI was meant to look like and how my code was needed to function. From there, I would try to understand the scope of my issue and how my code would interact with the rest of our program. This helped me to better discern the complexity of my work, as well as the amount of time I needed to dedicate to completing my tasks.
When thought is put into practice…
However, where I miscalculated was how I defined my task. Truthfully, I did work that should've been broken up into multiple branches and segments that should have been handled individually. Instead, I decided to lump all the work together. As a result, a seemingly simple and vague task quickly devolved into a 4-hour issue. Where I faltered 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 that there are benefits in having foresight and time management within a major project. For instance, while working on Milestone 2, we had to get the majority of our 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. This saved us time and prevented last-minute roadblocks to completing our milestones. However, I consider this practice to be a hierarchy that manages priorities, rather than practicing time estimation.
Contemplation of efficiency and results…
With that in mind, I did not find the time estimate 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 find is most conducive to my learning outcomes is setting aside a little bit of time every day to handle coding issues. With larger work loads dedicated to longer days or time segments. To put it simply, I work best by not timing my work with a stopwatch. But rather, I perform better when the time is broken up within specific time frames without the pressure of beating the clock. All of this to say, I believe a fresh-eyes and fresh-mind approach maximizes your results.
Reflection on data collection and accuracy…
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 would list an initial estimate within the description section. Before I started my work, I would begin a timer and later use a stopwatch to better reflect actual times. Once I hit a roadblock, I would start a second stopwatch and periodically add to the time as I researched and found solutions. Then, I would comment on the actual time under my GitHub branch once a task was completed. By Milestone 2, I began adding information directly into the table of the effort estimates and would tack on additional time if the task took multiple days to complete.
That being said, I think my times were accurate, though I could have been more structured about how I cataloged my times. Aside from loving a good spread sheet, 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 ChatGPT, GPT-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 “Please fix my toggler on my search bar icon to color: rgb(65, 132, 255)." This would usually steer me in the right direction, with many of my prompts being basic and nonspecific to my project. This resulted in many caveats and UI implementations that would need to be integrated after my initial prompt. My time spent asking for correction to my code or initial scaffolding was dismal in comparison to my actual coding time. I would say only a third of the code generated did not have to be modified in some way.