I broke phones before I learned to code — and unknowingly trained my debugging instincts.
Long before I knew what 'development' meant, I was already wrestling with systems.
Before I even knew what “development” meant, I was already trying to take systems apart.
I bricked my first phone when I was just a kid — around 10 years old.
It was an old Nokia running Symbian OS — a pre-smartphone-era system that relied on stylus input. You couldn’t even tap with your finger; you needed your nail or a stylus to interact with the screen.
I had zero technical knowledge at the time. I just thought, “Maybe updating the system will make it faster.”
So I tried to update it.
And, of course — it failed.
The phone wouldn't boot. The screen froze on the logo.
I was scared.
But more than that, I was curious:
"Why did it break? Could I actually fix it?"
No knowledge, no tools — just curiosity and trial and error.
I started digging through forums, reading random threads, and copying whatever instructions I could find.
Somehow, I managed to bring that phone back to life.
That was my first real taste of:
Problem → Hypothesis → Testing → Fix → Success
Every step made me want to understand the system more — not through textbooks, but through mistakes and hands-on experience.
Then came high school. And a secondhand HTC HD2.
A legendary phone of its time.
It originally ran Windows Mobile OS, but its hardware was so good, people found ways to install Android, Windows Phone — even dual boot.
That’s where I really started diving into the world of custom ROMs and OS experiments.
What I cared about wasn’t just “hacking for fun.”
I wanted to know:
- How does UI smoothness actually differ across systems?
- Does fewer pre-installed apps really improve performance?
- How much does memory usage affect actual UX?
I wasn’t looking to break boundaries. I just wanted to understand what made one system feel better than another.
Bricking a phone became my first debug playground.
Every failed boot, every crash, every freeze — I’d:
- Re-enter the bootloader
- Flash a new kernel
- Start all over again
I didn’t know the theory. I just kept testing.
Eventually, I started noticing patterns.
I could feel when something was about to go wrong, even if I couldn’t explain it technically.
Each failure became part of a personal “recovery pattern” that I slowly developed through repetition.
It wasn’t just about fixing the phone anymore —
It became about understanding how the system broke in the first place.
The more things broke, the more I wanted to understand them.
Perfectly running systems teach you very little.
But broken ones?
They show you everything.
From all those failed flashes, I learned:
- Not all UX is created equal — you feel the difference
- No system is unbreakable — every architecture has a limit
- Debugging isn’t just about fixing — it’s about reverse-engineering the logic
I didn’t come from a Computer Science degree.
But I did study Game Design at higher diploma level, where I learned Unity and some basic programming.
What really shaped my ability, though, was everything I did outside the classroom — the testing, breaking, rebuilding, and reflecting.
Most of the tools I learned came from trial and error.
I didn’t study from books. I built, tested, broke things, and fixed them until they made sense.
My code may not always follow textbook structure,
But I make sure it works, holds up, and can be restructured when needed.
I’ve realized I’m especially good at breaking things down, and I naturally use prototypes to explore ideas.
Because to me, every time I debug something, I don’t just fix a problem —
I understand the system better than before.