Astrid Atkinson from Google speaking about Engineering for the Long Game at O'Reilly Velocity conference.

Here are some points that stuck out to me:

• Your job is not to limit growth. When you're trying to keep complexity in check, one of the worst things you can do is say "You can't launch this, it's too complex, it's going to make things worse"
• You want to be enabling all the growth the product can provide.
• You need to get out of the business of managing machines.
• It's not about the system you are using, it's about getting it so your engineers can run their own services.
• Keep an eye on what's costing time, and consider "cost" broadly
• In a stateless system, doing something is better than doing nothing.
• Somewhere between 1 and 5 identical systems you need to figure out where you are going to take a stand
• If your second system doesn't unlock new capabilities, don't do it
• Move the biggest customer first. "If you want to build a race car, there's no point in starting with a cardboard box"
• Look for what's costing you "trouble"
• There's no finish line, it's an infinite game.
• It's easy to get fixated on little decisions, like where to put the config files. As long as you put them in a roughly organized place, you'll be ok.

Join the discussion on Facebook in Programming Philosophy