How I operate

These are the principles I've learned (often the hard way) over 13 years of building software and leading teams. They're not rules - they're guidelines that keep me grounded.

The non-negotiables

👨‍👩‍👧
Family first

No deadline, no client, no opportunity is worth sacrificing time with my family.

💪
Health first

Can't build anything great if you're burned out. Sleep, exercise, mental health - they come before the code.

🤝
Human first

Behind every ticket is a person. Behind every metric is a user. Never forget that.

On shipping software

Ship fast, fix issues

Perfect is the enemy of shipped. Get it in front of users, learn from their feedback, iterate. You'll never know what's actually broken until real people use it. The best code I never wrote was the code I didn't need because I shipped early and learned the feature wasn't wanted.

As simple as possible

Every line of code is a liability. Every abstraction is complexity you'll pay for later. I've seen so many projects collapse under their own cleverness. The best solution is usually the boring one. Make it work, make it clear, make it fast - in that order.

Manual first, automate later

For early-stage products: manual testing is fine. You don't need 100% test coverage for something 50 people use. But once you have real users and real traction? That's when you invest in automation. For medium and large projects, I aim for 85%+ coverage and feature flags for safe rollouts.

Code every single day

Even if it's just 30 minutes. Even if it's a tiny fix. The compound effect of daily practice is real. Some of my best ideas came from "quick" morning sessions that turned into breakthroughs.

On architecture & infrastructure

Hexagonal architecture

Keep your business logic pure. Adapters for everything external - databases, APIs, frameworks. When Rails 8 becomes Rails 9 or PostgreSQL becomes something else, your core domain shouldn't care. I've migrated too many tangled codebases to ignore this.

Blue-green deployments, canary releases

Zero-downtime deploys aren't optional - they're expected. Blue-green lets you switch instantly if something goes wrong. Canary releases let you test with 1% of users before everyone gets the new code. Sleep better at night.

Simplify your stack

I've seen companies with 50+ microservices, 20 different AWS products, and a team of 10 just to manage the infrastructure. That's not engineering - that's complexity theater. Use DigitalOcean App Platform, keep services minimal, prefer open source over vendor lock-in. You don't need 1,000 services - you need the right 5.

Open source over vendor lock-in

PostgreSQL over proprietary databases. Redis over managed-only solutions. Standard containers over platform-specific magic. When you need to move (and you will), you'll thank yourself.

On leading teams

I've led teams of 5 and teams of 89. The principles don't change much with scale.

Be radically open. Share context. Share the why. Share the constraints. People do better work when they understand the full picture, not just their ticket.

Set clear goals. Ambiguity kills momentum. If your team doesn't know what success looks like, they can't achieve it. I'd rather have a wrong goal that we can correct than no goal at all.

Human first, always. Your engineer having a rough week? That matters more than the sprint. People aren't resources to be optimized - they're humans to be supported. The best retention strategy is actually giving a damn about your people.

On working with AI

I'm all in on AI-assisted development. 100%. This isn't a gimmick - it's how I work now.

But here's the thing: I always read what the AI is doing. Every line. Every decision. AI is a collaborator, not a replacement for thinking. I'm genuinely impressed by what it can do - and I stay impressed by staying engaged with the output.

The developers who treat AI as a magic "do my work" button will fall behind. The ones who learn to collaborate with it - guiding, reviewing, iterating - will build things that weren't possible before.

On continuous growth

Build on the shoulders of giants. I read constantly - books, blogs, Paul Graham essays, 37signals. I listen to podcasts while walking. Every good idea I've had was built on someone else's foundation.

Know your weaknesses. I'm a builder. I love making things. But selling? Marketing? That's where I struggle the most. I'm actively learning it - reading $100M Offers, studying how others do it. Admitting what you're bad at is the first step to getting better.

Never stop being a student. 13 years in and I'm learning Elixir. Still figuring out how to sell. Still reading about leadership. The day you think you know enough is the day you start falling behind.

The short version

01 Family, health, humans - in that order
02 Ship fast, learn faster
03 Simple beats clever every time
04 Automate when it matters
05 Keep your stack boring
06 Lead with openness and clarity
07 Embrace AI, but stay engaged
08 Never stop learning

Principles are easy to write. Living them is the hard part.

These evolve as I do. Check back.

← Back to home