On shipping fast and staying sane

There's a cult of speed in tech. Ship fast. Move fast and break things. Iterate. Deploy. The language is all velocity, all urgency. And honestly? I've been seduced by it too. There's a real high in shipping something before anyone expects it.

But I've also been burned by it. Shipping fast without thinking is just rushing. And rushing produces bugs, tech debt, and — worst of all — designs that don't respect the user. So I've been trying to find a middle path.

Speed vs. velocity

Speed is how fast you move. Velocity is how fast you move in the right direction. You can ship ten features in a week and still be going backwards if none of them solve the actual problem. I'd rather ship one thing that matters than ten things that don't.

The trick is knowing which corners to cut and which corners are load-bearing. You can skip the perfect animation. You can't skip the error state. You can launch with one color theme. You can't launch without accessibility.

My shipping checklist

  • Does it solve the core problem? Ship it
  • Is the happy path smooth? Ship it
  • Are the error states handled? Ship it
  • Is the code I'd want to maintain in six months?
    • If yes — ship it
    • If no — take thirty more minutes, then ship it

Staying sane

The sanity part is harder. I've learned a few things the hard way:

  • Sleep is not optional. Code written at 2am costs you three hours of debugging the next day
  • Taking a walk solves more bugs than console.log
  • The deadline is almost never as hard as you think. Ask for an extra day. You'll be surprised
  • Celebrate shipping. Even the small things. Especially the small things

Related

Ship fast, but ship with intention. The best code is the code you don't have to fix tomorrow.