What helps you ship confidently?
I've been thinking about this as I take lead on a project that needs help. What are the prerequisites we have to ensure 🤔
Right now we have Code That Works. We know it works because the business keeps running. But it's brittle and hard to work with. Sneeze wrong and you might break everything. I've gotten close.
One time all my code stopped working from one change to the next. Like broken no response stopped working. Then next morning the same code was fine. I never quite figured out what was wrong. Must've been the gremlins ...
Here's what I've come up with so far:
- observability so we can investigate and debug production issues
- alerting so we know quickly when a major fire breaks out in production
- good DORA metrics so inevitable failures are quick to recover from
- type safety so we can move code around and refactor things
- modularization so we can reduce architectural complexity, increase ownership, and isolate failures
- canary deploys so we can ship new features to a subset of users first
You'll notice I didn't say tests.
That's because in 15 years of writing production code I've never seen a test catch a bug that engineers didn't expect to happen. But observability and canary deploys have saved my ass on countless occasions.
Not sure though if DORA metrics (deploy frequency, lead time to changes, change failure rate, time to fix) are leading or trailing indicators. 🤔
What have you found helps you ship with confidence [name|]? Hit reply
Cheers,
~Swizec
Continue reading about What helps you ship confidently?
Semantically similar articles hand-picked by GPT-4
- Make mistakes easy to fix
- Why you need observability more than tests
- Why great engineers hack The Process
- Let small fires burn
- The mistake that strangles engineering teams
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️