Week 15: Debugging Myself (Not Just the Code)

This week was a humbling one. Since most of my Flutter front-end tasks were wrapping up, my supervisor decided it was time for me to try something new, the React Admin project, which uses CouchDB as its backend. It sounded exciting at first, but once I actually sat down to work on it, I realized how different (and honestly, how challenging) it was compared to what I was used to.

At this point, I’ve come to understand that the language doesn’t really matter anymore, whether it’s Dart, TypeScript, or JavaScript. What truly matters is learning how to think like a programmer. If I can understand the logic, patterns, and problem-solving process behind the code, then learning a new language becomes just another step, not a setback.

Entering a Different World

As usual, I started by exploring the project structure, analyzing how everything fit together, and familiarizing myself with the new stack. My first real task was to upgrade React Admin from version 5.8.3 to 5.12.2 and as expected, the update broke quite a few things.

I spent the first few days fixing every break it caused:

• Updated the Jest config for ESM dependencies
• Adjusted the delete-button test for the new label
• Cleaned up React imports in tests
• Reordered the useDefaultTitle hook in the Dashboard
• Added missing key props to resource filters

After some patient debugging and manual verification, I finally got all the tests, type-checks, and builds to pass. It felt like a small but meaningful victory.

My First “Real” Task and First Big Mistake

After that, I moved on to my first major issue: adding sorting to the list views using CouchDB’s partition API. The goal was to make list sorting more reliable and consistent than what PouchDB alone could offer.

I was proud of how much I managed to figure out — mapping sort parameters, creating indexes, running queries in parallel, and caching them for performance. It felt good to finally make something work.

But later, I realized that in my excitement, I had broken a few important rules.

Instead of using the existing PouchDB instance (cdb), I bypassed it and called PouchDB.fetch() directly, manually constructing URLs and headers instead of letting the data provider handle them. At the time, it seemed logical, but it turned out to be a bad idea.

The Meeting That Brought Me Back Down to Earth

During our weekly meeting, my supervisor explained the problems my approach caused.

By using a global variable to store the current partition, I had introduced concurrency issues, meaning multiple operations could overlap and return wrong or inconsistent data.
And because I used client-side counting through cdb.find(), I made the process slower and more wasteful in terms of network usage and performance.

His main advice was straightforward but hit hard:

• Don’t rely on global state; pass context properly.
• Don’t use find() for counting, use CouchDB views (cdb.query) instead.
• Stay within the PouchDB API, don’t take shortcuts.

That meeting was honestly a bit of a wake-up call. I realized I had been focusing too much on getting things to work, rather than making sure they were done the right way.

Taking a Step Back

So this week ended with me going back to the basics — reading documentation, tracing through the code, and trying to really understand how everything is meant to work together.

I’m currently refactoring the logic to remove the global variable, pass partition context explicitly to each request, and replace client-side counting with more efficient Map/Reduce-based queries using views.

It’s not the kind of week where I can say I finished something, but it’s the kind of week where I learned something important, that quick fixes can create bigger problems later, and sometimes progress means slowing down to think properly.

Reflections

• Every new framework makes you feel like a beginner again and that’s okay.
• Getting something to work isn’t the same as doing it right.
• The hardest lessons are usually the ones that teach the most.
• Reading documentation slowly is better than rushing through it.
• The language doesn’t define you — your understanding of programming does.

What’s Next

Next week, I’ll continue refactoring the sorting and counting logic to make it cleaner, safer, and more maintainable. Once that’s done, I’ll move on to writing proper tests to make sure everything works as expected.

This week might not have been filled with “big wins,” but it taught me something far more valuable — that real growth happens when you step out of your comfort zone, question your own code, and start thinking like a true developer.