Forem: Joana Nicolaas Ponder

Lets get technical...and hormonal?

Joana Nicolaas Ponder — Mon, 10 Nov 2025 10:21:20 +0000

I’ve been trying to continue building the AI features for Backlog Explorer this week, but honestly? I’ve been distracted.

Not in the ‘I’m procrastinating’ kind of way — more like my brain just didn’t want to build. It wanted to analyze. Why? Because, hi, I’m a woman with a menstrual cycle. And that means I move through different phases each month — creative, energetic phases, and more introspective, inward ones.

Right now, I’m in my inner autumn (aka luteal phase), and I always feel a bit slower, more analytical, and way more likely to deep-dive into something I want to fix.

So today, when I felt that inner pull to go deep instead of build, I remembered Martin Fowler’s Refactoring book sitting on my desk — and thought, “Okay. Let’s actually try this.”

I opened up my HomePage.tsx file and said:
“You know what? I’m gonna refactor this mess.”

I didn’t realize it at first, but I was about to invent my own flavor of Test Driven Development — Cycle Driven Development™.

Intimidated by refactoring — but ready to try

The component was a tangled web — a giant useEffect trying to juggle too many tasks at once.
It fetched the user, set state, checked onboarding, fetched games, formatted them, managed loading logic… all bundled into one block. I wrote the code, then never looked back because, well, it worked (yay!). But reading it afterward? Total gibberish.

I was intimidated by the idea of refactoring it. What if I broke something? What if I made it worse? The code was messy, sure, but it was working. That felt like enough — or at least, that’s what I told myself.

useEffect(() => {
    const fetchCurrentGames = async () => {
      try {
        const {
          data: { user },
        } = await supabase.auth.getUser()
        if (!user) {
          navigate('/login')
          return
        }

        const firstName = user.user_metadata?.full_name?.split(' ')[0] || ''
        setUserName(firstName)

        const { count: totalGames } = await supabase
          .from('user_games')
          .select('*', { count: 'exact', head: true })
          .eq('user_id', user.id)

        setShowOnboarding(totalGames === 0)

        const { data: games, error } = await supabase
          .from('currently_playing_with_latest_note')
          .select('*')
          .eq('user_id', user.id)
          .order('note_created_at', { ascending: false, nullsFirst: false })

        if (error) throw error

        const formattedGames =
          games?.map((g) => ({
            id: g.game_id,
            title: g.title,
            image: g.image || g.background_image,
            progress: g.progress,
            platforms: g.platforms || [],
            genres: [],
            status: g.status,
            nextIntent: g.next_session_plan?.intent || '',
            nextNote: g.next_session_plan?.note || '',
          })) || []

        setCurrentGames(formattedGames)
      } catch (error) {
        console.error('Error fetching current games:', error)
      } finally {
        setLoading(false)
      }
    }

    fetchCurrentGames()
  }, [navigate])

Technically, it functioned. But it felt fragile, like it could break with the slightest touch. I was hesitant to change it because I didn’t want to risk breaking what was already working.
Honestly, my code wasn’t pretty - it was like a cluttered closet (don’t open the door!). But it got the job done.

Testing — a mystery until I tried it

I remembered how in bootcamp we learned testing, TDD, and writing clean code—and I was like:

“YES, I’m going to test all the things and build things the right way!!”

But… I never really got it.

I didn’t understand what tests were for, beyond just checking if the code worked.
I didn’t feel confident writing them.
And when I started working on Backlog Explorer, I skipped them completely.
I told myself I’d go back and add them later.

Besides, I thought, Why do I need tests? I can just open the app and visually check if it works.

So I never wrote them.

Leaning into menstrual cycle awareness — inner autumn focus

This time, I wrote tests before refactoring.
Why? Because Martin Fowler told me to. So I did. I trusted the book. 🙃

I wrote just a few:

one for the onboarding state
one for the loading spinner
one for rendering currently playing games
one for handling errors

Nothing fancy.

And suddenly… it felt like the beast got a makeover.

If I messed something up? The tests would catch it.
If I renamed something wrong? The tests would tell me.
If I broke onboarding logic? The tests would scream at me.

It was honestly wild. I finally understood. Like — ohhh, this is why people love tests. This is why TDD exists. This is why you don’t just visually check everything every time like a dummy.

It’s so cool.
I love seeing all the green check marks.
It’s actually… fun??
I’m enjoying refactoring. A lot.

The “great big scary” refactor — turning messy into maintainable

I created a helper file:
/src/pages/helpers/homePageHelpers.ts

And started pulling logic out into focused little functions:

getUserOrRedirect(navigate)
extractFirstName(user)
isNewUser(userId)
fetchFormattedCurrentGames(userId)

Each one does one thing.
Each one reads clearly.
Each one makes the useEffect feel tameable.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler

The Result

Now my HomePage’s useEffect looks like this:

useEffect(() => {
  const loadUserHomepage = async () => {
    try {
      const user = await getUserOrRedirect(navigate)
      if (!user) return

      setUserName(extractFirstName(user))
      setShowOnboarding(await isNewUser(user.id))
      setCurrentGames(await fetchFormattedCurrentGames(user.id))
    } catch (error) {
      console.error('Error fetching current games:', error)
    } finally {
      setLoading(false)
    }
  }

  loadUserHomepage()
}, [navigate])

As Martin Fowler describes in the very first chapter of the book, “…with good names, I don’t have to read the body of the function to see what it does.”

It breathes.
It flows.
This is the kind of code I want to come back to.

Is this real refactoring? Yes, it absolutely is.

I had a moment where I wondered, Is this really refactoring? It felt small, not flashy, not a big rewrite or a shiny new feature. But that’s the thing — refactoring isn’t about grand gestures. It’s about thoughtful, incremental improvements that make the code clearer and easier to work with.

This process reminded me that refactoring is a form of care — care for the code, and care for my future self (and anyone else who might read this code later).

It’s not just technical cleanup. It’s about reducing friction. Creating ease. Making space. And honestly, that mirrors what I’m learning to do for myself during my inner autumn, too — to reduce friction, slow down, and tend to what needs support. There’s something beautifully aligned about doing that in my code at the same time I’m doing it in my body.

Refactoring + Inner Autumn = Perfect Combo

This kind of work felt so aligned with my cycle.
It wasn’t fast or flashy.
It was quiet. Focused. Intentional.

I wasn’t building something new — I was tending to something that already existed. Making it stronger. Clearer. Easier to understand and easier to change or update in the future.

It also just… fit the kind of energy I had this week. I didn’t want to rush. I wanted to investigate deeply. I wanted to problem-solve meaningfully. And I wanted to make something that already existed feel better to work with—not just for me, but for future me too.

🧠 What I Learned

Refactoring is creative too — just in a quieter, more grounded way
Testing makes me feel more confident
My cycle isn’t a blocker
Recognizing when and how to improve messy but working code is a huge part of becoming a better developer
Refactoring isn’t punishment for messy code — it’s care work. Care for your code, your future self, and your team.

✨ Final Thought

Progress doesn’t always look like shipping new features or building something big.

Sometimes, it’s cleaning up what you’ve already made.
Sometimes, it’s learning to enjoy the parts that used to scare you.
And sometimes — especially for those of us with menstrual cycles — it’s about trusting the natural rhythms of our energy.

There are parts of the month when I feel wildly creative and inspired, and parts like now when I feel slower, more inward, more focused on fixing things. And that’s not a flaw — it’s a feature.

This week reminded me that I don’t have to fight my cycle. I can work with it. I like to call it Cycle Driven Development™ ☺️
And honestly? My code — and my nervous system — are better for it.

My App Died When a Real User Showed Up

Joana Nicolaas Ponder — Wed, 10 Sep 2025 09:39:28 +0000

Cover image by David Pupăză on Unsplash

If you've been following along with my journey, you know that I have been busy building Backlog Explorer. It's a way for gamers to manage their backlogs of unplayed games. As a notorious gamer who constantly buys new games without finishing the ones they already own, I thought this was a great product and would help me play games I already owned.

I took my time to really think about what I wanted this app to be and do. I wanted users to be able to add games, mark them as complete, filter by genre, by mood, and all the good stuff. My app would stand out from others because it would be more about you rediscovering what you already owned rather than spending all your money. My MVP was working really great for me, and the handful of friends I roped into testing it.

Until...this one user came along and wrecked it all.

Not with bad intent or anything. They just used it as it was meant to be used. Except...they had a lot of games. Like, over 1000 games in their library. And when they tried to load their dashboard, my poor little app just...died. Loading times went from snappy to "is this thing working?" The stats dashboard would timeout. Filtering became laggy. It was honestly embarrassing.
And when I received their feedback in my email, while on vacation in Spain, I was horrified. I couldn't even clock in to attempt to fix anything until a week later. I immediately emailed them back and apologized and told them I would be looking into it as soon as possible and would keep them posted. I was really worried that this was it for Backlog Explorer. That I clearly was not meant to be a developer and develop things for real people (because apparently...I'm not a real person? 🤷)

But actually, this was the best thing that could have happened to me as a developer.

The Reality Check

You see, I made the assumption that I was the norm. That a BIG backlog meant 50-100 games. That's what I had. I had a big backlog and it seemed like a lot to me. I tested with a small dataset because that's what I had. But this user showed me what real-world usage looks like. And real-world usage broke my assumptions pretty quickly.

So when I got home from vacation, and my son was back at daycare, I dug in. And the problems were pretty clear once I started digging:

I was loading ALL games at once instead of paginating
My database queries weren't optimized for larger datasets
Dashboard stats were calculating on the frontend instead of the database

Basically, I had built something that worked great in my controlled environment of small datasets, but fell apart when it met actual users. Also, all the problems were things I had not learned at bootcamp. So I had to learn this fast in order to make it work for this user (they wrote how excited they were to use my app so I felt very personally attached to making this work for them). And I don't blame my bootcamp for this. There is only so much they can teach in such a short time. I got the basics, but now it was up to me to level up.

Learning Pagination the Hard Way

The biggest issue was that I was fetching every single game from the database every time someone loaded their library. For 50 games? No problem. For 1000 games...yeah that's not going to work.

I had to learn about pagination, and not just a "show 10 results per page" kind. I needed server-side pagination that would work with all the complex filtering I had built (more on that in another post).

Here is what I ended up with in my useLibraryGames hook:

const [page, setPage] = useState(1)
const pageSize = 30
const [totalCount, setTotalCount] = useState(0)

const fetchGames = useCallback(async () => {
  if (!userId) return

  const from = (page - 1) * pageSize
  const to = from + pageSize - 1

  let query = supabase
    .from('user_games')
    .select(`
      id,
      status,
      progress,
      platforms,
      image,
      updated_at,
      game:games!user_games_game_id_fkey (
        id,
        title,
        background_image,
      )
    `, { count: 'exact' })
    .eq('user_id', userId)
    .range(from, to) 

  const { data: userGames, count, error } = await query
  setGames(userGames || [])
  setTotalCount(count || 0)
}, [userId, page, /* other dependencies */])

The key breakthrough was using Supabase's range(from, to) method combined with { count: 'exact' }. This meant:

Server-side pagination: Only fetch the 30 games needed for the current page, not all 1000+
Accurate totals: Get the exact count for pagination controls without loading all records
Performance: Page loads went from 10+ seconds back to milliseconds

Then in the UI component, I added simple pagination controls:

<div className="flex justify-center items-center gap-2 mt-6">
  <button
    className="btn btn-outline"
    disabled={page === 1}
    onClick={() => setPage(page - 1)}
  >
    Previous
  </button>
  <span>
    Page {page} of {Math.max(1, Math.ceil(totalCount / pageSize))}
  </span>
  <button
    className="btn btn-outline"
    disabled={page * pageSize >= totalCount}
    onClick={() => setPage(page + 1)}
  >
    Next
  </button>
</div>

The Filtering Challenge (Coming Next)

But here's where it got tricky - I had all these filters (by status, genre, mood, platform, year, search query) that users loved. With client-side pagination, filters just worked. With server-side pagination, I had to be more thoughtful about where filtering happened.

Solving this required building a complex system with 16 interdependent filter states that work together through React's dependency system - but that's a whole technical deep-dive for my next post.

The Database Design That Saved My Butt

When I first started building Backlog Explorer, I spent a lot of time thinking about the database schema. At the time, it felt like maybe I was overthinking it. I mean, I was just storing games and user progress, right? How complicated could it be? But I'm really glad I took the time to design it properly from the beginning, because it's what saved me when everything started breaking.

Here's how I structured it:

games table: This holds all the basic game information - title, cover art, description, release date, genres, platforms. Stuff that's the same for everyone.
user_games table: This is where all the personal stuff lives - whether a user owns the game, what status it's in (not started, playing, completed), their progress percentage, personal notes, when they added it.
genres and platforms tables: Normalized lookup tables that multiple games can reference.

The key insight was separating shared data from personal data. When 20 users all have "The Witcher 3" in their libraries, there's still only one record in the games table. All the user-specific stuff (status, progress, notes) lives in separate user_games records that reference the shared game.

This meant a couple of really important things:

No data duplication. I wasn't storing "The Witcher 3" information 20 times.
Easy optimization. When I needed to add database indexes for performance, I could target specific tables without affecting user data.
Consistent game information. If I update a game's cover art or genre information, it updates for everyone automatically.

When that power user with 1000+ games joined and broke my app, this design is what let me fix the performance issues without having to restructure everything. I could add indexes, create optimized views, and improve queries because the data was already organized properly.

What I Actually Learned

Building Backlog Explorer has been this weird mix of "I'm so proud of this thing I built" and "oh god, I have no idea what I'm doing."But here's what I've figured out:

Start simple, but think ahead. I'm glad I designed a normalized database schema from the beginning, even when I was only thinking about small use cases. It made scaling up so much easier.
Real users will break your assumptions. I thought 100 games was a lot. Some people have thousands. Design for edge cases, or at least make sure your app fails gracefully.
Performance matters, even for side projects. Nobody wants to wait 10 seconds for their library to load, even if it's "just" a personal project.

The coolest part? After fixing all these issues, Backlog Explorer actually works really well now. Users with massive libraries can browse their games smoothly, filtering is snappy, and the dashboard stats load quickly It's not perfect - there's still so much I want to add and improve. But it's a real thing that real people use, and that feels pretty amazing.

Breaking things and fixing them taught me more than any tutorial ever could. Now I know what happens when your database queries get slow, when your state management gets complicated, when external APIs fail. That's the kind of experience you can't get from following along with a course. You have to build something real, let it break, and figure out how to fix it. I can put "performance optimization," "state management," and "API integration" on my resume now. But more than that, I know I can figure stuff out when things go wrong. And in development, things go wrong a lot.

If you want to check out Backlog Explorer, it's live at backlogexplorer.com. Feel free to break it - It'll give me more learning opportunities 😅