~/blog $ ls -lt
~/blog $ cat microservices.md

Why I Stopped Writing Microservices for Everything

2026-03-20 · #architecture

Three years ago, I was the person who wanted to split every bounded context into its own service, its own repo, its own deploy pipeline. It felt clean. It felt right.

Then I spent six months debugging distributed transactions, fighting with service mesh configs, and explaining to my team why a simple feature now required changes in four repos.

The turning point

We had an incident where a request touched 7 services. The latency was fine, but the cognitive overhead of tracing it was not. Our P95 debug time had doubled since the migration.

What I do now

Start with a well-structured monolith. Extract only when you have a proven scaling bottleneck or a genuinely independent domain. The modularity should live in your code, not necessarily in your infrastructure.

A monolith with good boundaries beats microservices with bad ones. Every time.
~/blog $ cat one-on-one.md

The 1:1 Template That Actually Works

2026-03-10 · #leadership

I've tried every 1:1 format out there. Structured agendas, completely freeform, shared docs. Here's what I've settled on after leading teams for 5+ years.

The format

1. How are you doing? (not about work)
2. What's blocking you right now?
3. What should I know that I probably don't?
4. One thing I can do better as your lead?

That's it. Four questions. The magic is in question 3 — it surfaces problems before they become incidents, and it signals that you genuinely want to hear the uncomfortable stuff.

The rules

  • Never cancel the 1:1. Reschedule if you must, but never cancel.
  • Take notes. Follow up. Nothing erodes trust faster than forgotten promises.
  • If they say "everything's fine" every week, something's wrong.
~/blog $ cat edge-deploy.md

Deploying at the Edge with Cloudflare Workers

2026-02-28 · #devops

I've been running a multi-tenant platform on Cloudflare Workers for a while now. Here's what surprised me.

What's great

  • Cold start? What cold start. Sub-millisecond boot times.
  • D1 for SQLite at the edge is genuinely useful for read-heavy workloads
  • R2 for assets with custom domains works better than I expected

What to watch out for

  • CPU time limits are real. Heavy computation needs a different approach.
  • Debugging distributed state across D1 databases requires tooling you'll build yourself
  • The ecosystem is still young — expect some rough edges

Overall verdict: for the right use case, it's the best developer experience I've had for deploying web services. The "it just works globally" factor is hard to beat.

~/blog $ cat code-review.md

Code Review Is a Conversation, Not a Gate

2026-02-15 · #culture

The worst code review culture I've ever seen treated PRs like exams. Reviewers looking for gotchas. Authors dreading the red marks. Everyone miserable.

The best code review culture I've built treated PRs like pair programming, asynchronously. Here's the difference:

Gate mentality

  • "You should have used X instead of Y"
  • Nitpicking style in a codebase without a formatter
  • Blocking on opinions, not problems

Conversation mentality

  • "Have you considered X? It might help with [specific thing]"
  • Asking questions to understand intent before suggesting changes
  • Approving with suggestions, not blocking with demands

Set up auto-formatting and linting so humans never argue about tabs vs spaces again. Use review time for architecture, correctness, and knowledge sharing. That's where the real value is.