Ship Ship Hooray!
Let’s say you open your team’s Trello board in the morning and see your face on three cards. The first one is for a feature you’re currently working on. On the second one, a colleague is asking you to review a feature she’s finished developing. On the third card, another colleague is asking you to help him QA and release his feature. Which card do you address first?
The first card represents creative work that is owned by you. The allure of that is easy to see. The second card requires reading and, more importantly, understanding someone else’s code, then giving them constructive feedback. The third card requires understanding how a new feature will be used in the real world, diligently testing different scenarios, then pre-empting anything that could go wrong after the release.
The first card can feel like something you do for yourself, while the other two feel like something you do for somebody else.
What I believe you should normally do first is the third card. Then the second one. But not because you’re a good Samaritan who puts others before self, no. You should do it because that establishes a useful behavioural pattern in your team: whenever you see something close to the edge, push it.
Few things are as psychologically rewarding to a development team as shipping. Even when it’s not yours, seeing code go into production will often give you a dopamine hit. By the time you get back to your card, you will be inspired. You have tasted victory and are hungry for more.
The act of shipping is the essence of our work. The point of software development is found in the Git history, rather than the code itself. Because each change that gets shipped to the users is a sign we are still learning about their world and trying to make it a better place.
