Initiating Stats Screen Logic & Navigating Team Burnout

A lighter week after heavy coursework

After a marathon month juggling this project with a demanding Historical Archetypes and Mythology class, our whole team agreed to take a breather. Everyone was feeling the strain, so we intentionally kept our workload light. I won’t re‑hash all the reading and writing struggles here — those have already been documented in previous entries — but stepping back for a moment helped us reset and return with fresh eyes.

Kickstarting CRUD for the stats screen

My main focus was to start implementing CRUD logic for the stats screen. I initially sketched out a plan to build an entirely new stats model and then link it to our existing Firestore project. However, when we merged new functionality into the codebase, I realized that my plan would duplicate logic. Rather than forcing two competing models to co‑exist, I pivoted.

We resolved the naming conflicts by standardizing naming conventions across files and by adding a StatsScreenRoute composable to the end of our existing StatsScreen. This route now pulls data from the Firestore instead of TestUser.kt, which houses our mock user along with the fields expected by the front‑end team. Reusing the existing User and Stats structures meant less redundant code and better alignment with the rest of the app.

Fixing the sign‑out button

One piece of housekeeping I almost forgot to mention was repairing the sign‑out button. When we refactored authentication flows earlier, the button had broken and the dedicated branch for it fell about 95 commits behind the dev branch. This week I rebased and updated that branch, merged in the latest changes, and then pushed a small fix so the button once again properly logs users out. Keeping long‑lived branches current prevented merge conflicts and ensured that small regression didn’t linger.

Quality of life updates and refactoring

During the week I took time to revisit our own authentication patterns to guide my design decisions. I noticed that the login and registration routines in our app were already separated into dedicated functions and that each function should do one thing well. Applying that same single‑responsibility principle to the stats screen, I refactored the getUser wrapper to return a well‑typed Stats object and moved Firestore side‑effects into their own helper. These small quality of life tweaks make the code easier to read and maintain.

Team dynamics and next steps

By the end of the week there was a bit of friction within our team. Some of us were fighting head colds, others were overwhelmed by personal commitments, and stress levels were high. I’m hopeful this was just a one‑off rough patch. I’m genuinely grateful for everything each member contributes, and I know we’ll find our rhythm again. Next week I plan to flesh out the stats screen UI and connect it to the live Firestore collection once we’re confident in our data model.

Gallery