ICS 414 Reflection
17 Dec 2025
The Beginning
In the beginning of the semester, our team had a really strong start. We also had concrete plans and a continuous flow of new ideas for the project. We completed our tasks early, and everyone contributed to the milestones. I would say this early success in planning was due to the meetings we held every weekend, where each group member discussed current progress and any ideas or concerns they had. I honestly loved these meetings, as I got to see where our project was currently sitting. It also allowed me to discuss my ideas and thoughts about the project and ask for any clarification I had with the whole group. I personally used these meetings as a due date to complete certain tasks, which really helped me stay on track and continue to work on the project in a linear flow.
The Problems I/We Encountered
Reaching about the halfway mark of the semester, the group decided to stop the weekly meetings due to conflicting schedules between members. I think this became the biggest issue we as a group had. It caused a domino effect that could’ve been preventable if we continued to meet weekly. One of the problems that started due to this issue was the lack of production and addition to the project. I myself am guilty of this, as my contribution greatly declined throughout the semester. I would usually wait until the weekend before the milestones were due before I would do my PR requests, which then led to me usually only finishing one issue instead of the two issues per milestone goal.
Another problem that I encountered was not splitting my issues correctly. I worked on a couple of issues with multiple requirements that could’ve been easily split into two or more issues. This was a problem because it slowed down the PR request, as I would modify a huge number of files that the PR reviewer would need to check one by one to ensure that I did not crash the main branch. Doing multiple things in a single issue also slowed me down because I would add more into the requirement instead of creating new issues every time I encountered new things to add.
The Things I Learned
On a good note, I was able to learn a lot of new experiences from the project. One of these new experiences was the PR reviews. I really liked the PR review because it allowed group members to check my code and tell me if there were changes that I needed to make. Due to the requirement of PR reviews to merge, it prevented any major crash in our main branch. I had an experience in ICS 314 where one of my merges crashed our whole main branch and we had issues reverting back to old commits; even with the instructor’s help, it took us about 30 minutes before our main branch worked again.
A goal that I had set for this project and was able to achieve was to communicate better with my group members. I always had an issue with communication, either group members being unwilling to work or me being too introverted to speak to my members. This was also an issue I faced in ICS 314. For this project, I would say I did pretty well on the communication. I was able to respond to all the pings and messages as quickly as I could, none reaching 24 hours before I responded. I also was able to get help from members when I was stuck or needed someone to PR review my request. I was also able to express comments and thoughts, which I typically don’t do in my previous classes. I think this project helped bring me out of my shell and talk to members.
I would say due to this project, I was able to properly learn Next.js, ESLinting, and Playwright tests. Compared to ICS 314, where the instructions were loose and most of these topics were briefly introduced without proper depth, for this class working on a project that revolves around these components exposed me to how they actually worked. For example, comparing my use of Playwright tests in my final project in ICS 314, we had only implemented tests to make sure that certain buttons appeared, nothing else. For FreshKeep, we had tests that go beyond just checking if buttons are visible, like actually logging in and making sure that our pages are functional. The same goes for ESLint; in my previous project for ICS 314, we had multiple pages where ESLint failed and we would just comment out the issue. For this project, with the addition of Prettier, we were forced to follow strict formatting, resulting in code that is uniform and easy to read.
To the Next
Learning from my mistakes and new experiences, I’ve set new goals for my next projects that involve working with multiple people. First, I need to continue implementing PRs from now on, as it helped reduce crashes due to bad merges. I need to set more time to work on things rather than doing work near the deadline, as it will help with production, especially when the code needs a lot of revision. This ensures that the issue does not carry to the next milestone, leaving more time for more issues to work on. I also need to learn how to split my issues properly where it’s enough to ensure linear progress but also for better git history if anything crashes. The most important thing I learned in the end that I wish I was able to implement in this project is a security automation to ensure our code is safe and our users’ information.