About
I write about the bugs that were worth the afternoon
I am Benjamin Fazli, a principal engineer based in Skopje, North Macedonia. I solve engineering problems, build products people actually use, and write down what I learn on the way through.
Skopje, North Macedonia
The short version
Most of my work sits in the unglamorous middle of a product. The request that fails for exactly one customer. The query that got slow a week after a schema change nobody flagged. The build that only breaks on the build server. None of it demos well, and all of it decides whether a product feels trustworthy.
Over the years I have kept notes on those problems, mostly for myself, because the same shapes keep coming back in new frameworks. This site is that notebook, cleaned up and made public. It is the thing I wish I had found on the second page of results while I was pasting an error message into a search box at eleven at night.
Outside the write-ups I work with teams on reliability, performance, and the kind of technical debt that is cheaper to name than to keep paying for. If that sounds like your situation, the contact form is the right place to start.
Mission
Turn a lost afternoon into a ten minute read.
Engineering knowledge is mostly locked inside private incident channels and forgotten pull request threads. Every post here takes one of those problems, explains it in the open, and leaves behind enough detail that the next person can act on it in an afternoon instead of losing one.
No gated downloads, no signup wall, no fifteen paragraphs of preamble before the fix.
What you will find here
Five things every post gives you
This is the standard I hold each write-up to before it goes out.
- Debugging write-ups that quote the real error message, so the search that brought you here actually works.
- The reasoning, not only the answer. How a cause was isolated is far more reusable than the line that fixed it.
- Code you can paste, with enough surrounding context that pasting it is safe.
- The dead ends. Knowing which three ideas did not work saves you from spending an hour on them.
- Honest limits. When a tool is the wrong fit for the job, I say so rather than forcing it to fit.
How each post is put together
Three rules that keep it useful
Written the same week
Posts get drafted while the details are still exact. That is the only way the commands and the code samples stay honest.
Reproduced before published
Every fix here ran against a case I could break on demand. If I could not reproduce it, the post did not go out.
Symptom first, always
Each post opens with what you would actually see in a console or a log, because that is what you searched for.
Topics
What gets written about here
Every post sits in one of these areas. Pick the one closest to the problem you are staring at right now.
Next.js
Rendering, routing, and the hydration traps in between.
2 postsDatabases
Query plans, locks, and the migrations nobody reviewed.
2 postsEdge and Serverless
Small runtimes with surprisingly sharp edges.
2 postsNode.js
Streams, event loops, and memory that will not come back.
1 postFrontend
The layer your users actually argue with.
1 postTooling
Builds that pass locally and fail everywhere else.
1 postSecurity
Small mistakes with expensive consequences.
1 post
Stuck on something similar?
If a post got you most of the way there but not all of it, send over the details. I read every message, and the good questions frequently turn into the next write-up.
Prefer email? Write to hello@bfzli.com