Delivery

Why do software teams push continuous deployment so strongly? One of the most important and least discussed reasons is engineer morale. Engineers Want to Build Engineers want to build. They’d much rather ship an experiment that proves or disproves a theory than discuss the theory. When you hire engineers who know how to ship, that’s what they want to be doing. Continuous deployment allows that itch to be scratched by eliminating barriers to building. That makes engineers happy. ...

Today I gave a talk to my team about the Twelve-Factor App Methodology. The Twelve-Factor app is an important methodology for building software-as-a-service drafted by developers at Heroku in 2011. It outlines best practices for app setup, portability, deployment, and scalability. I chose to share this because I think it’s relevant to all software engineers, and part of our shared language and conventions. And, I want the teams I work with to follow it, and for each of us to be a champion of its conventions. ...

I recently calculated that I merge 0.8 pull requests every day into my team repo. Let’s round up and say I merge about one PR every day, delivering one or more features to production. I like this velocity, and in this post, I’ll explain how you can achieve it yourself. My ideal day as an IC goes like this: Morning: start a ticket Early morning/early afternoon: open a PR Early afternoon: respond to comments and merge PR Afternoon: deliver work to a QA environment Late afternoon: deploy to production This doesn’t happen by accident. It’s the result of processes— mine and my team’s. These are the ingredients of those processes. ...

I’ve been lucky to have worked with some great engineers, and one thing that they tend to do exceptionally well is reporting about their work at meetings. Today I’d like to summarize what I think makes a great standup report. My goal is a report that’s informative, impromptu, and actionable. Informative I try to consistently bring the expected information to my standup report. Time is limited and valuable. On some teams, this is “yesterday, today, blockers.” I often omit yesterday’s work; it’s the past and likely less relevant. Same with blockers, or obstacles in my path; I try to resolve them before the meeting and avoid situations where I’m frequently blocked. ...