Category: Uncategorized

These aren’t just “recommended reading” — they’re books that fundamentally altered my approach to software. I re-read most of them annually.

Clean Code — Robert C. Martin

The book that made me realize code is written for humans first, machines second. Every function should tell a story. Every variable name should reveal intent. I was two years into my career when I read it, and it felt like putting on glasses for the first time.

Designing Data-Intensive Applications — Martin Kleppmann

If you build anything that stores or processes data (so, everything), this book is essential. It doesn’t teach you a specific technology — it teaches you how to think about data systems. Replication, partitioning, consistency models, stream processing — all explained with a depth and clarity I haven’t found anywhere else.

The Phoenix Project — Gene Kim

A novel about DevOps. Sounds strange, works brilliantly. It reframed how I think about the flow of work through an organization. After reading it, I pushed for value stream mapping in our team and discovered we were spending 60% of our time on handoffs and approvals, not actual development.

Thinking, Fast and Slow — Daniel Kahneman

Not a tech book, but arguably the most important one on this list. Understanding cognitive biases — anchoring, availability heuristic, sunk cost fallacy — makes you better at code reviews, architectural decisions, and estimating project timelines. Every “this should take two days” that turned into two weeks is a cognitive bias in action.

Site Reliability Engineering — Google

The SRE Bible. Error budgets, SLOs, toil reduction — these concepts transformed how our team thinks about reliability. The key insight: 100% uptime is the wrong goal. The right goal is “reliable enough that users don’t notice, cheap enough that the business can sustain it.”

I used to check Slack before my feet hit the floor. Emails during breakfast, PRs during coffee. Then I burned out. Here’s the morning routine that brought me back.

5:30 AM — No Screens

The first 30 minutes are screen-free. I make pour-over coffee (currently obsessed with Ethiopian Yirgacheffe), stretch, and write three pages in a journal. It’s not profound prose — it’s brain garbage collection. Like running VACUUM on a Postgres database, but for your mind.

6:00 AM — Deep Work Block

This is my golden hour. No meetings, no Slack, no emails. I work on the hardest problem of the day — the one that requires actual thinking, not just typing. Architecture decisions, complex debugging, writing documentation that future-me will be grateful for.

7:00 AM — Exercise

A 30-minute run or bodyweight workout. Non-negotiable. The research on exercise and cognitive performance is overwhelming. I solve more bugs per hour on days I exercise than days I don’t. The ROI is absurd.

7:45 AM — Connect

Now I check Slack, review PRs, scan emails. But by this point, I’ve already accomplished the most important work of the day. Everything else is incremental. The anxiety of an overflowing inbox hits different when you’ve already shipped something meaningful.

Protect your mornings. They set the trajectory for everything that follows.

Last year, I took a three-week solo trip through Japan. No itinerary, no companions, just a backpack and a JR pass. It changed how I think about problem-solving, empathy, and building software.

Comfort Zones Are Overrated

Navigating Tokyo’s subway system in a language you don’t speak is surprisingly similar to debugging a system you didn’t build. You learn to read patterns, follow signals, and become comfortable with uncertainty. That comfort with ambiguity is the most underrated skill in software engineering.

Simplicity Is Universal

Japanese design philosophy — whether in a temple garden, a train station, or a bowl of ramen — obsesses over removing the unnecessary. There’s a direct parallel to writing clean code. Every element earns its place, or it doesn’t exist. I came back and deleted 3,000 lines of code from our codebase. Nobody noticed, except the build got 40% faster.

Alone Time Is Thinking Time

Without the social obligation to fill silence, you actually process ideas. Some of my best architectural decisions were made sitting in a quiet Kyoto café, watching rain fall on a rock garden. The key insight for our event-driven migration came to me on a bench in Nara, surrounded by deer.

Empathy Through Experience

Being the person who doesn’t understand the interface — who can’t read the labels, who doesn’t know the conventions — gives you profound empathy for your users. Every confusing error message, every assumption about “obvious” UI patterns, every undocumented API endpoint: someone is staring at it the way I stared at a Japanese train ticket machine at midnight.

Travel solo at least once. You’ll come back a better developer, and more importantly, a better human.

Three years ago, we migrated our first workload to Kubernetes. Today, we run 200+ microservices across multiple clusters. Here are the five lessons that would have saved us countless sleepless nights.

1. Set Resource Limits on Everything

The single most impactful thing you can do is set memory and CPU limits on every container. Without them, one runaway process can take down an entire node through OOM kills, cascading failures across unrelated services. We learned this during a holiday weekend incident that took down our payment processing for 47 minutes.

2. Pod Disruption Budgets Are Non-Negotiable

Node upgrades and spot instance reclaims will happen. Without PDBs, Kubernetes might evict all your pods simultaneously. Set minAvailable to at least 1 for every production deployment. Your on-call engineers will thank you.

3. Network Policies Are Your Best Friend

By default, every pod can talk to every other pod. In a 200-service mesh, that’s a security nightmare. We implemented deny-all default policies and explicit allow rules. It took two weeks to roll out and caught three misconfigured services that were accidentally calling production databases from staging.

4. Don’t Trust the HPA Defaults

The Horizontal Pod Autoscaler’s default settings are too aggressive for most workloads. A 15-second cooldown means your cluster will thrash during normal traffic spikes. We settled on 3-minute scale-up and 10-minute scale-down windows. Test your HPA with realistic load patterns, not synthetic benchmarks.

5. Observability Before Optimization

Before optimizing anything, make sure you can see what’s happening. Prometheus metrics, structured logging, and distributed tracing form the three pillars. We invested six weeks in observability infrastructure before touching a single service, and it paid for itself within the first month when we identified a memory leak that had been silently degrading performance for months.

The best infrastructure is the kind you don’t have to think about — until it fails. Then you need to understand it deeply, quickly.