BROKEN
Projects That Didn't Work.
I don't think I've always been afraid of breaking things.
Actually, I've done it intentionally.
Not just projects.
Windows itself.
There were times when I deliberately broke my own system because I wanted to try something new.
Install another operating system.
Try Linux.
Change something I probably shouldn't have touched.
See what happens.
And then, when everything eventually stopped working—
I'd look at the mess and think:
Yep. Let's go.
Because now I had something else to figure out.
How do I fix it?
MAYBE THAT'S HOW I LEARNED
I've always had a strange relationship with broken things.
Most people see something broken and want to get it working again as quickly as possible.
I sometimes want to know why it broke first.
That's probably one of the reasons cybersecurity attracted me.
Breaking something exposes what was hidden when everything was working.
A system can look perfect from the outside.
Then one thing goes wrong.
And suddenly you can see the assumptions holding everything together.
“A system doesn't reveal all of its weaknesses when it works. Sometimes you have to watch what happens when it doesn't.”
I didn't understand that in the beginning.
I learned it by breaking things.
THE SCHOOL PROJECT
One of the projects that taught me the most was the school project I wrote about earlier.
I had spent weeks building it.
I had an idea.
I knew what I wanted it to become.
I worked on it.
And eventually, I realized something uncomfortable.
The idea wasn't as good as I thought it was.
That realization is different from a technical error.
A technical error says:
Something is wrong. Fix it.
A bad idea says:
Even if you fix everything, you might still end up with the wrong thing.
And that's much harder to accept after you've already invested time into it.
There was also the problem of time.
Development was slower than I wanted.
Things took longer.
The project became more complicated.
And eventually, I had to confront something I didn't particularly enjoy confronting:
Effort doesn't automatically make an idea worth finishing.
“The amount of work you've invested in something does not determine how much more work it deserves.”
That lesson stayed.
I BROKE MY OWN SYSTEM
Then there were the times I broke Windows.
Intentionally.
Not because I hated Windows.
Because I wanted to experiment.
I wanted to install an operating system.
Try Linux.
Change things.
See what would happen.
And sometimes, unsurprisingly, something went wrong.
But my reaction wasn't really:
“Oh no.”
It was more like:
“Okay. Let's fix it.”
And while fixing it, I'd already be thinking about what I wanted to try next.
There was something strangely satisfying about that.
Breaking the system removed the fear of breaking the system.
Once you've already seen something completely stop working and you've managed to bring it back, the next problem feels slightly less terrifying.
“Every system you learn to recover from makes the next failure a little less frightening.”
Maybe that is where some of my resilience came from.
Not from never breaking things.
From learning that broken doesn't necessarily mean finished.
THE LOCAL DATABASE MISTAKE
One of my more embarrassing mistakes happened while building a workload balancer for my school.
The system had different users.
Teachers.
An administrator.
People who needed to interact with the same underlying information.
And I made a fundamental architectural mistake.
I stored the data in the browser's local database.
At first, everything worked.
That was the dangerous part.
It worked.
So I kept going.
Only later did I realize the obvious problem:
If the data lives inside one browser, how exactly is everyone else supposed to share it?
I had built something that worked perfectly—
for the wrong architecture.
I had to fix it later through an update.
And that mistake taught me something that a tutorial never could.
A feature working is not the same thing as a system being correctly designed.
“A working implementation can still be a broken system if the architecture doesn't match the problem.”
That one hurt.
But it was useful.
Because after that, I started thinking differently.
Not just:
Can I make this work?
But:
Where does this data live?
Who needs it?
How does it move?
What happens when there are more users?
What assumptions am I making?
The questions became bigger.
I TORE ONE APART
There was also a web application I was building.
I got frustrated.
Really frustrated.
And instead of continuing to patch it, I took it apart.
I broke the thing I had already built.
Deleted pieces.
Pulled it apart.
Started looking at it differently.
At the time, it probably felt like I was destroying progress.
But looking back, I think I needed to.
Sometimes you're too close to something to see what's wrong with it.
You keep fixing symptoms.
Changing one thing.
Breaking another.
Adding another layer.
And eventually the project becomes a pile of decisions you don't even remember making.
At some point, you have two choices:
Keep repairing the mess.
Or:
Take it apart and understand it again.
“Sometimes rebuilding is not starting over. It is refusing to keep carrying mistakes you now know how to avoid.”
WHEN THE IDEA CHANGES
Not every broken project is broken because the code failed.
Sometimes the idea itself changes.
That happened with Arvexa.
The original intention was to build something around sellers who create custom printed T-shirts and similar products.
But as I explored the idea, it changed.
Eventually, it moved toward a marketplace where designers could sell their designs and people could buy those designs on custom clothing.
The original idea didn't exactly survive.
But the project did.
It became something else.
And I think that's an important difference.
Sometimes changing the idea isn't failure.
Sometimes it's what happens when you understand the problem better.
“The first version of an idea is a hypothesis, not a commitment.”
You start with what you know.
Then reality gives you more information.
And the idea evolves.
THE REAL PROBLEM WAS ME
There is a pattern behind some of my mistakes.
I get an idea.
I want it to exist.
And sometimes that urgency becomes stronger than the planning.
I want to build it now.
So I start.
Architecture?
I'll figure it out.
Planning?
I'll figure it out.
Scaling?
I'll figure it out.
The problem is that sometimes figuring it out later becomes much more expensive than thinking about it earlier.
The urge to make something real is powerful.
But it can also make you impatient.
“Passion can make you start quickly. Discipline is what prevents you from rebuilding everything later.”
That is something I'm still learning.
Because I don't want to lose the instinct to build.
I just want to build with better judgment.
WHAT BREAKING TAUGHT ME
Breaking things taught me things building alone couldn't.
It taught me about architecture.
Because eventually, poor architecture breaks.
It taught me about planning.
Because the absence of planning eventually becomes someone else's problem—or your future problem.
It taught me patience.
Because fixing something rarely happens as quickly as breaking it.
It taught me professionalism.
Because a project isn't just about whether it works on your machine.
It has to work for the people who depend on it.
It taught me to think about users.
It taught me to think about systems.
And maybe most importantly—
it taught me something about myself.
I can get frustrated.
I can rush.
I can make bad technical decisions.
I can underestimate complexity.
I can build something the wrong way.
I can completely mess something up.
And then I can sit down and work through it.
That's important.
Because resilience isn't the absence of frustration.
It's what happens after frustration.
BROKEN DOESN'T MEAN DEAD
I used to think that if a project broke badly enough, the answer was simple:
Delete it.
Start from scratch.
Now I see it differently.
Sometimes you should delete it.
Sometimes you should rebuild it.
Sometimes you should fix it.
Sometimes you should abandon it.
Sometimes you should change the entire idea.
There isn't one correct response to something breaking.
The important part is what you take from it.
A broken project can leave you with better architecture.
A failed idea can leave you with better judgment.
A technical mistake can leave you with a question you'll never forget again.
And a system you managed to recover from can make you less afraid of the next one.
“The value of a failure isn't measured by what it destroyed. It is measured by what it taught you to build differently.”
I'M NOT AFRAID OF BREAKING THINGS
I still break things.
Sometimes accidentally.
Sometimes intentionally.
Sometimes because I'm experimenting.
Sometimes because I made a stupid decision.
Sometimes because the thing I built wasn't good enough.
And honestly?
I'm okay with that.
Because I don't want to become someone who is so afraid of breaking things that I never tries anything difficult.
I want to experiment.
I want to push things.
I want to understand systems deeply enough to know where they fail.
But I also want to become better at building things that don't need to be broken to teach me their weaknesses.
That's the next level.
Not just knowing how to fix what breaks.
Knowing how to build better in the first place.
BROKEN
Projects That Didn't Work.
I've broken Windows.
I've broken projects.
I've broken architectures.
I've broken things because I was frustrated.
I've broken things because I wanted to understand them.
And sometimes I've broken things because I simply didn't know what I was doing.
But every time something broke, I got another piece of information.
Another question.
Another lesson.
Another reason to think differently.
I don't look at a broken project the same way anymore.
I don't immediately see:
failure.
I see:
information.
I see something that needs to be understood.
Something that needs to be fixed.
Something that needs to be rebuilt.
Or sometimes—
something that needs to be left behind.
And maybe that's what breaking things has really taught me.
Not how to destroy.
But how to recover.
How to rethink.
How to rebuild.
How to become harder to break myself.
Because the project might be broken.
The architecture might be wrong.
The idea might fail.
The system might go down.
But I don't have to break with it.