Scaling Fast Book

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.

*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

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.

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

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

Say no to abstract code

The trick, then, is to keep related code close together to reduce context boundaries and to limit the amount of relevant detail so it fits in your working memory.

re: The Industrialization of IT

I guess if AI is what it takes to finally get people to care about architecture and team structure then mission accomplished?

Always deploy at peak traffic

A hard-won lesson for ya: Always deploy when you've got lots of traffic.

The difference between a product and a project

A project is something you do, a product is something you own.

Sprint vs Shape Up vs Kanban

Whenever I talk about sprints, someone mentions Shape Up. So you have 9 week sprints – what's the difference?

Why sprints

For the past few months I've been introducing sprints into a chaotic startup that's been growing so fast everyone's got whiplash. Since August, 5 engineers turned into 12. I think it's starting to work.

Principles of high output engineering teams

A few engineering principles I aim to instill in every team I join. Lead or not.

Code yourself out of the job

Let go of your legos and let others do the work.

What I learned from Accelerate

Accelerate is the empirical research behind books such as The Phoenix/Unicorn Project and (parts of) Software Engineering at Google. I loved it.

Looking for beta readers

Wanna read my hardest engineering lessons learned? You're in luck!

Atoms, molecules, organisms

Here it is: 20+ years of programming experience distilled into 378 words. From the book I'm writing.

Smart core, thin interfaces

Here's an approach to writing code that I've been using for years and couldn't quite put into words until now. One of those _"This feels wrong but I can't explain why"_. Now I can!

Empirical evidence for code modularity

Few of your engineering decisions matter long-term. Software is soft. You can change your mind. But how you structure your components is here to stay.