Learning
Outside of shipping features, this is where my curiosity actually goes — new papers, new tools, and the occasional deep rabbit hole.
Learning as Leverage
The rate at which you can learn directly affects the rate at which you can architect. Understanding consensus algorithms, database internals, or distributed tracing isn’t just theoretical—it changes what you build and how you build it.
Most of my learning isn’t “learning a new language” (that’s table stakes). It’s:
- Papers: CRDT, Raft, Google’s Bigtable—the foundational work that informed every major system.
- Systems: How does PostgreSQL actually handle concurrent writes? Why is Kafka fast? What does Kubernetes do under the hood?
- Trade-offs: Every tool made different bets. Understanding why a tool chose performance over consistency (or vice versa) tells you when to use it.
The Practice
Learning without application is memorization. I learn by building:
- Small experiments with new tools (does gRPC actually cut network overhead?)
- Writing (this site, blog posts—forces you to think clearly about what you know)
- Teaching (explaining architecture decisions to junior engineers reveals gaps in your own thinking)
Always-Learning Culture
The best engineering teams I’ve seen treat learning as a first-class activity, not something you do on your own time. Time to experiment, read papers, try new patterns—it compounds into a team that can adapt faster when the constraints change.
The worst teams treat learning as “nice to have,” then wonder why they’re stuck on a legacy stack that nobody understands.