Ship fast without breaking things

How to be useful as a software architect

Software architects have a weird role: Think about the code _tomorrow_. Today's code is what it is, how do we make it good tomorrow? Without slowing down, losing business, or falling off a cliff.

The one thing every experienced engineer gets wrong

In the last few months every engineer I hired stumbled in exactly the same way: Project management. They learned quickly, but that first big project has become a rite of passage.

Theory of constraints, AI, and code review

Feedback from an expert is how you learn taste. Your code doesn't matter until it's shipped.

You get what you hire

Hiring engineers is like deciding what kind of system you'll have. This seems obvious but surprised me to see first-hand.

Relentlessly focus on the outcomes

AI makes it easy to focus inwards and feel impressed with all the churn and motion and output you're producing. But your users don't care.

Engineering levels aren't about skill anymore

Traditional engineering levels were about skill progression. I think this has changed. Everyone now is a mini staff engineer.

Just fix their PR

You know what's better than a code review comment? A fix.

The best engineers just get shit done, sometimes with AI

The best engineers I know never talk about their AI setup. The worst engineers I know only talk about their AI setup.

Taming chaos is a learnable skill

How you approach software engineering makes it harder or easier to handle interruptions and other chaos. Writing a behavioral interview made me realize this is a learnable skill!

Probably the realest thing I ever wrote

The 3 curves that make a scalable business

You want users and revenue to grow exponentially. Bugs per day to grow linearly. Support work to grow logarithmically. Your goal is to make this happen.

In praise of the stacked pull request

How fast you do code review is how fast you do everything. Your PR queue is the leading indicator of team velocity. Stacked PRs can help.

How you migrate is everything

Your code becomes legacy software when it works. You build something to solve a problem, then the problem changes. Or best practices evolve. Or you hire team members with more experience. Or the world changes. Or you have more people touching the same code and your beautiful architectural vision didn't translate.

The future of software engineering is SRE

When code gets cheap operational excellence wins. Anyone can build a greenfield demo, but it takes engineering to run a service.

Place good startup bets

You can't win every bet. Your goal is to be a little more right than wrong and keep playing

Small projects, clear scope

Minutes of planning save you days of programming. It is shocking how little planning it takes to make a big difference.

How to lead a project

you were asked to lead or own a project. Now what? Here are a few practical steps to help you succeed.

*People* detangle a ball of mud

Ball of mud is the world's most popular software architecture. The one we all use at work. But it sucks to work with. So what do you do?

The unreasonable effectiveness of stack ranking

Stakeholders are silly people. Everything feels important and urgent. Stack ranking helps

The job behind the job [of a high level IC]

Advancing big goals while you stay on top of operational day-to-day fires _is the job_. This is hard. Here are a few tips I've found helpful.

Make sure it works first

Explore the importance of functionality over elegance in Swizec's latest piece. Learn from his experience of tripling an engineering team's size within a year.

Leadership lessons from growing 3x in 1 year

So this talk is my attempt to step back and write down some of the things I've learned. Hope you find something to apply in your team.

Pair programming

Great for learning those little tricks of the trade you forgot you even learned

Yes it's like spinning plates

In a fast-growing company software engineering feels like spinning plates. Nothing ever stays fixed.

Quick update on Scaling Fast, my next book

Your goal is not to write a book, it's to change how your reader thinks

A few more thoughts on mentoring

Wanted to share a few more thoughts on my mentoring philosophy and answer questions that readers asked

My mentoring philosophy

Yesterday I had lunch with a newly promoted lead and realized I have opinions on mentoring engineers. Here they are.

Software architecture IS Conway's Law

Can you even have architecture before there's a team?

Common abstraction traps

Here's a few common abstraction traps that suck you in, look like they improve your code, then turn into bad ideas as your system grows.

DRY – a common source of bad abstractions

The worst and hardest to maintain code that I've seen or written has been in pursuit of DRY