ICS 414 Reflection - Building FreshKeep UH and Growing as a Developer
19 Dec 2025
This semester in ICS 414 pushed me past the idea of just “knowing concepts” and into actually building something real. Through FreshKeep UH, our web app, I had to think like a developer on a team instead of a student turning in isolated assignments. That shift changed everything. Suddenly, my work wasn’t just about whether the code ran on my machine; it was about whether a feature fit the rest of the application, whether it made sense to a user, and whether my teammates could understand it, build on it, and trust it.
FreshKeep UH forced me to make constant tradeoffs. Sometimes the “best” technical solution wasn’t realistic within the time we had. Other times, a quick approach would work now but create problems later when features expanded. I had to balance user experience, technical constraints, deadlines, and code quality in a way I hadn’t experienced before. I also learned that building a product means paying attention to the full flow: how a user gets from one step to the next, what happens when they make mistakes, and how the app responds when data is missing or unexpected.
It wasn’t just about getting features to work, it was about building them in a way that someone else can read, test, and maintain. That meant writing clearer code, keeping components organized, being consistent with patterns, and thinking about how changes ripple through the project. It also meant learning to be more patient and methodical when things broke, because debugging and refinement weren’t side tasks; they were the core of the process. In this reflection, I’ll cover what I learned, what challenged me the most, and what improved the most over the semester. More importantly, I’ll explain what I’m taking forward into future projects: the habits, mindset, and confidence that come from building something collaboratively and seeing it evolve over time.
From Assignments to an Actual Product
This project revolved around taking input from a sponsor and building features based on that feedback, which gave the course a different kind of pressure. When you’re building a product, even a class project every small choice affects other parts of the system. A simple change to a form can ripple into validation rules, database fields, UI state, and testing. That forced me to stop thinking in isolated “homework” tasks and start thinking in systems. I also learned quickly that software is never truly “done.” There’s always another improvement, another edge case, or another user flow that needs polish.
React, State, and Building UI That Doesn’t Fight You
A big part of my growth came from getting more comfortable with React patterns: state management, derived values, conditional rendering, and keeping components readable. Early on, it was easy to end up with messy state logic that worked once but became hard to extend. Over time, I got better at organizing UI into smaller components, separating display from logic, and keeping state predictable. I also started to pay more attention to user flow. If something felt confusing to me while testing, it would probably feel confusing to a user too. That mindset changed how I approached UI decisions: not “What’s easiest to code?” but “What’s easiest to use?”
Data and Structure: Thinking Beyond the Front End
Working on FreshKeep UH also forced me to respect the back end and the data model. It’s one thing to make a page look correct; it’s another thing to make sure the data is structured cleanly and supports features you haven’t even built yet. I learned how important naming is, how relationships between entities impact queries, and how a good schema can make future features easier. This was also where I started appreciating consistency: consistent types, consistent validation, and consistent patterns in how the app handles data. Those details are easy to ignore until the project grows.
Debugging and Tooling: Getting Comfortable With the “Real Work”
One of the most realistic parts of this class was how often debugging became the main task. Whether it was ESLint complaints, component issues, or something breaking after a change, I learned that debugging is not a failure, it’s part of the job.
Over the semester, I got faster at narrowing down problems by:
- Reproducing issues consistently
- Checking logs and error messages carefully
- Making small, controlled changes instead of random guesses
- Using tooling (linting, type checks, tests) as guidance instead of “annoyances”
The biggest mindset shift was accepting that friction is normal. Instead of getting stuck, I learned to keep moving and solve problems one piece at a time.
Closing Thoughts
ICS 414 made me a better developer because it made me build like one. FreshKeep UH wasn’t just a project, it was a semester-long exercise in real-world habits: making design choices with tradeoffs, debugging when nothing made sense at first, coordinating work with other people, and iterating until the experience felt cohesive. I learned that most progress doesn’t come from one “big breakthrough,” but from dozens of small decisions done consistently: tightening a user flow, refactoring a messy component, fixing an edge case, or cleaning up naming so the codebase stays readable.
I’m also leaving with a clearer understanding that software development is more process than perfection. There were plenty of moments where something worked in isolation but broke in the full app, or where a “quick fix” created a new problem later. Over time, I got better at slowing down, reading errors carefully, reproducing bugs, and making controlled changes instead of guessing. That shift made me more confident not because I suddenly know everything, but because I trust my ability to figure things out when I don’t. The biggest win for me is that FreshKeep UH feels like my proof: a proof that I contributed to a real project, operated inside a shared codebase, and kept improving through feedback and iteration. I’m taking those habits into whatever I build next, designing with the user in mind, keeping my code maintainable, communicating clearly with teammates, and staying comfortable in the uncomfortable parts of development, because that’s where most of the growth happens.
Note: ChatGPT assisted in writing this essay with sentence structure and grammar.