I’m More Interested in Why Things Break Than Why They Work

I don’t think I became interested in technology because I wanted to build apps.

I think I became interested because I wanted to understand things.

There’s a difference.

When something works exactly as expected, there usually isn’t much mystery left.

You press a button, something happens, and you move on.

But when something breaks, everything becomes more interesting.

Why did it fail?

Was the assumption wrong?

Was the system badly designed?

Did someone trust something they shouldn’t have?

Was the problem in the interface, the network, the database, the user, or somewhere deeper?

That way of thinking has probably shaped most of what I build.

I Like the Parts People Usually Ignore

A lot of software is designed to hide complexity.

That is normally a good thing.

Most people do not care how a request is routed, how authentication is validated, how a database transaction is handled or how an AI model receives context.

They just want the thing to work.

I tend to get interested in the hidden part.

I want to know what happens between clicking a button and getting a result.

I want to know what happens when that process is interrupted.

I want to know what assumptions the developer made and what happens if those assumptions are wrong.

That is part of why cybersecurity became interesting to me.

Security often lives in the gap between what a system appears to do and what it actually allows.

Building Things Is Mostly Discovering What You Don’t Know

One of the strangest things about programming is that the more I learn, the less I feel like I know.

When I started building websites, a website felt fairly simple.

Frontend.

Backend.

Database.

Done.

Then you start learning about authentication, caching, queues, rate limits, browser behaviour, network failures, accessibility, search engines, deployment, monitoring, observability and security.

Suddenly a “simple website” doesn’t seem simple anymore.

The same thing happened when I started experimenting with AI.

At first, the interesting part was the model.

Which one is smarter?

Which one is faster?

Which one can run locally?

Eventually the model became only one small part of the problem.

A model can be extremely intelligent and still be useless if the system around it is badly designed.

It needs context.

It needs tools.

It needs boundaries.

It needs a way to fail safely.

It needs to know what it is allowed to do.

That is where things get much more interesting.

I Don’t Really Separate Learning From Building

I’ve never been very good at learning something just because I’m supposed to know it.

I understand things much better when I need them.

If I need a database for a project, I learn about databases.

If authentication breaks, I learn more about authentication.

If a website is slow, I start learning about performance.

If a deployment fails, I learn what the infrastructure is actually doing.

That process is sometimes inefficient.

I’ll probably make mistakes that someone with more experience would avoid immediately.

But those mistakes normally stick with me.

There is a big difference between reading that something is a bad idea and spending six hours discovering why it is a bad idea.

Zenith Is Really an Excuse to Learn

My main project, Zenith, is technically a website monitoring and improvement platform.

But for me, it is also an excuse to keep exploring problems.

Security.

Performance.

Accessibility.

SEO.

Infrastructure.

Automation.

AI.

Databases.

Product design.

They all meet in one project.

I could probably make Zenith much smaller and easier to build.

That would also make it less interesting.

I like projects that slowly force me outside what I already know.

Open Source Changed How I See Programming

Building your own projects gives you complete control.

That is both useful and dangerous.

If something is badly designed, you can always rewrite everything around it.

Open source removes that freedom.

When you contribute to someone else’s project, the question is not:

“How would I build this?”

It is:

“Why did they build it this way?”

You have to understand before changing.

You have to work with existing conventions.

You have to think about the people who already depend on the code.

I like that.

It makes programming feel less like writing instructions for a computer and more like working inside a system built by people.

I’m Still Figuring Out What I Want to Become

I’m interested in computer science, cybersecurity, AI and systems engineering.

That is a fairly wide answer.

For now, I’m okay with that.

I don’t think I need to decide exactly what I want to specialise in yet.

I would rather keep following the problems that make me curious.

The common theme seems to be systems.

Not just how to build them, but how they behave when something unexpected happens.

That could mean security.

It could mean infrastructure.

It could mean AI systems.

It could end up being something I haven’t discovered yet.

The Goal Isn’t to Know Everything

I used to think being good at technology meant knowing the answer.

Now I think it is more about knowing what to do when you don’t.

Can you break a problem apart?

Can you find the part you don’t understand?

Can you test your assumptions?

Can you admit when an idea was wrong?

Can you keep going when the first solution doesn’t work?

That matters more to me now than memorising every framework or programming language.

Technology changes too quickly for that anyway.

There will always be another tool.

Another language.

Another model.

Another platform.

The useful part is learning how to learn.

And preferably building something interesting while doing it.

---

I’m Marceli Pawliński.

I build software, experiment with AI, contribute to open source and spend an unreasonable amount of time trying to understand why things behave the way they do.

Most of the time, the best place to start is when something breaks.