@dev.zilahi.fi

Working in the edge-cutting VR/XR industry, leading teams to success. Also, living in Finland, and enjoying it. Engineering Lead @ Varjo, Helsinki also at @richie.zilahi.fi, and I am behind bettertori.fi too.

We used to get fired for shipping non-deterministic code. Now we build entire companies on it. The real issue isn't that the models lie, but that engineers decided good enough is the new standard. That isn't innovation, it's negligence.

I can say with certainty: organizing code by technical pattern (hooks, utils, components) instead of feature is a guaranteed way to make refactoring hell. The second something stops being a hook, you realize the entire structure was wrong from day one.

Dominik 🔮@tkdodo.eu · 4mo ago

Now that I’m moving a lot of “useFoo” hooks to “fooApiOptions”, it’s even more apparent that a “hooks” directory is just wrong grouping. explore/hooks/useTraces becomes explore/hooks/tracesApiOptions (not a hook) unless I move it somewhere else. When will we stop this horizontal project structure?

Stock compensation is golden handcuffs, not a generous gift. They're betting you'll tolerate abuse for unvested shares. I've seen this playbook: they always push until people break. The real compensation is your life. Leave before you're too burned out to interview well.

The code you don't write is code you can't debug at 3am when production is on fire. I've shipped enough features to know: understanding beats velocity every single time. You can't maintain what you don't own, and you can't own what you didn't architect.

After 10 years, I'm convinced we've been solving the wrong problem. Over-engineering gets all the attention, but every failed project I've seen died from under-engineering. We're so afraid of doing too much that we've normalized doing too little.

After watching these AI-native juniors, I realized something: we're not hiring developers anymore, we're hiring AI prompt writers who can't code. The interview passed them because we test for working code, not understanding. We built this problem ourselves.

I've seen too many devs waste years chasing "clean architecture" when their startup needed shipping speed. Perfect abstraction layers don't matter if you're out of business. Sometimes the right answer is a well-organized monolith, not microservices.

Trace context propagation costs you ~3 lines per layer. Structure your logs, sample intelligently, and you're done. This isn't a philosophy problem. Add an APM, ship it, tune later based on actual pain.

The hardest lesson from scaling systems to millions of RPS: premature optimisation kills more startups than underperformance. Start with a monolith, measure everything, scale what actually breaks. Your imaginary traffic problems aren't worth solving yet.

I can tell you the biggest unlock isn't more contributors—it's control over who creates PRs. Read-only access for discussion with write-only PR creation is actually the governance model most mature projects need.

New repository settings for configuring pull request access - GitHub Changelog

Maintainers now have more control over how repositories accept contributions. Two new settings let you manage pull requests to better match your project’s needs. Disable pull requests entirely You can...

github.blog

Stop testing your buttons. Seriously. 100% test coverage is a vanity metric for insecure engineers. If you are writing unit tests for trivial components you aren't being careful, you are wasting time that should be spent on actual business logic.

Startups don't move fast. They just waste time fixing preventable disasters. The burnout comes from watching someone with 9 months experience pretend to be a CTO. Give me a slow process and someone who actually knows what they are doing.

If your production deploy stops when GitHub hiccups, you failed at architecture. Relying on a SaaS for your entire SDLC is lazy engineering. You built a single point of failure on purpose. Stop blaming the platform and fix your infrastructure.

I do not respect the switch to boring tech. You are not pragmatic, you are just tired. Real engineering is mastering complexity, not hiding behind the safety of the old stack.

I treat sprint planning as mandatory theater to soothe management anxiety. We pretend to predict the future for two weeks then scramble when it falls apart in two days. If your plan actually survives the sprint you probably are not moving fast enough.

Stop acting like "invisible" work is noble. If you spent a month removing risk and didn't scream about it to stakeholders, that is a failure on your part. It is your job to translate stability into dollars. Invisible work is just bad marketing.

I told my team to start migrating our Postman collections today. When a simple client tries to become an entire platform, it stops being a tool and starts being a trap. Relying on proprietary bloat for core infrastructure is engineering negligence.