I have a crazy theory about developing apps. Sometimes, the best way to fix a massive, tangled codebase has nothing to do with writing better code. It has to do with changing your perspective.
Let me explain. I’ll be the first to admit I am not exactly a "syntax wizard." Like many developers who learn by doing, my early focus was purely on getting my app to work. The result? I recently found myself wrestling with the creeping dread of what the industry quietly calls "God Documents."
If you've ever built an app, you know exactly what I mean. These are massive, sprawling files where logic, layout, and styling are all mashed together. I had colors, blocks, and cards hardcoded all over the place. Nothing was syncing. If I wanted to update the look of a specific card, I had to hunt down individual lines of code across dozens of massive files, praying I didn't miss one.
It was tedious, fragile, and exhausting.
Then, I decided to step away from fixing my code to focus on something more human: accessibility.
I'm currently working a patient focus app, and I wanted to add a colorblind mode to help them navigate and enjoy my app without frustration. I thought I was just doing a good deed. I had no idea I was about to stumble upon the greatest debugging trick of my development journey.
Here is my crazy theory on how building for empathy accidentally cured my messy code—and how you can use the exact same trick to bulletproof your own apps.
The "Aha!" Moment: Inventing the Visual Blacklight
To make a colorblind mode work, I couldn't just have color: #FF0000 or background: green typed randomly in a hundred different files anymore. I had to create a centralized theme—a master switchboard that could swap out the entire color palette dynamically when the accessibility toggle was activated.
After wiring up the new system, I hit refresh and flipped the switch to test it.
Click.
Most of the app beautifully shifted into the new, high-contrast accessible palette. But right there on the screen, a few rogue blocks, cards, and text elements stubbornly stayed in their original colors.
Instantly, the clouds parted. I had accidentally invented a visual blacklight for bad code.
I didn't have to read through thousands of lines of syntax to find my mistakes anymore. Every element that didn't change color was instantly exposed as a hardcoded imposter. Because I had forced a global visual change, my app essentially drew a glowing circle around every piece of sloppy code I had written with AI.
Instead of painstakingly using Ctrl + F to search through my massive God documents for rogue hex codes, I could just look at the screen, spot the stubborn card, jump straight to it, and swap it for a dynamic variable. I hunted them down one by one, super speedy.
The "Curb-Cut Effect" of Software Architecture
In urban planning, there is a famous concept called the Curb-Cut Effect. Decades ago, cities started cutting dips into sidewalk curbs specifically to help people in wheelchairs. But soon, planners noticed something unexpected: everyone benefited. Parents pushing strollers, travelers with wheeled luggage, and delivery workers all found the city infinitely easier to navigate.
I realized I had just experienced the software version of the Curb-Cut Effect.
By building a feature specifically to help colorblind patients, I created a massive secondary benefit for myself. Making the app accessible forced me to abandon my "God documents" and adopt what elite engineers call Separation of Concerns.
I had to extract all my messy, hardcoded colors and centralize them into what UI designers call Design Tokens. My app stopped saying, "Make this button red," and started saying, "Make this button the Primary Warning Color."
My code became modular, scalable, and beautifully synced—all because I wanted to help someone see the screen a little better.
3 More Tricks to "Blacklight" Your Own Code
Once you realize that accessibility toggles double as the ultimate architectural stress tests, you can use this trick to clean up almost any messy codebase. If you want to hunt down your own bad code visually, try building these three features:
1. The "Pirate Language" Trick (To find hardcoded text)
Want to know if you properly centralized your text, or if you lazily hardcoded paragraphs directly into your UI? Add a language toggle. You don't even need a real language—just translate your central dictionary file into "Pirate English" or ALL CAPS. Flip the toggle. Any text on your screen that stays in normal English is hardcoded. Boom. Found it in seconds.
2. The Dark Mode Trick (To find broken backgrounds)
Adding a Dark Mode toggle is the fastest way to expose where you accidentally hardcoded a solid white background instead of using a transparent one. Flip to dark mode, and any logo, icon, or container that looks like a glaring white box is your culprit.
3. The 200% Font Size Trick (To find rigid layouts)
Add an accessibility mode that dramatically increases the font size for visually impaired users. When you flip this switch, watch your UI closely. Any box, card, or container that clips the text, overflows, or breaks entirely instantly exposes where you hardcoded a specific, rigid height (like height: 50px) instead of letting the layout be flexible and responsive.
Systems Over Syntax
There is a myth in tech that being a great developer means memorizing perfect syntax. It doesn't. You can Google syntax. You can ask AI to write syntax.
Being a great developer is about Systems Architecture—identifying a structural mess, stepping back, and building a centralized system to solve a real human problem.
If you are struggling with a messy codebase, don't just stare at the code. Change the environment. Build an accessibility feature. Not only will you make your app a more inclusive place for your users, but your code will practically debug itself.
Have you ever stumbled into an accidental coding hack like this? Thanks as always for reading ramonrios.net!
The "Visual Blacklight"