Ship Something Every Day

If you're a full time developer I don't know why you wouldn't.

Commits are communication. If we're making them often and correctly, there's that much less fluffing around with reports and status updates and meetings that we need to do.

The merits of CI/CD notwithstanding I definitely do NOT want my reports feeling like they need to deploy every day. That will lead to rushed work and errors on production.

But commit, why not? I don't care if it's in a private branch, behind a feature flag, or even some notes/pseudocode in a comment, commit it. Write an actual decent commit message while you're at it. That way as your manager, I can call up your commit history before our 1:1, and by the time the meeting starts it's already 80% finished because I was able to update myself on what you've been doing.

Most of the time I only start to see the real shape of the solution after a few days of work.

Those iterations each day have value as they propel me toward a solution. But it’s more of an internal type of shipping. I’m shipping to myself.

I'd go as far as to claim that you cannot, at least at a level close to a highly available system updated with full CD without any gating or manual intervention.

Weekly deployments implicitly lead to merge trains and large PRs and team members sitting on their ass to approve changes. Each deployment is huge and introduces larger changes which have a larger risk profile. As deployments are a rare occurrence, teams don't have incentives to invest in automated tests or mechanisms to revert changes, which leads you to a brittle system and pressure to be conservative with the changes you do. As deployments are rare, breaking deployments becomes a major issue and a source of pressure.

To understand this, we only need to think about the work that it takes to support frequent deployments. You need to catch breaking changes early, so you feel the need to increase test coverage and invest in TDD or TDD-like development approaches. You also feel the need to have sandbox deployments available and easy to pull off. You feel the need to gate deployments between stages if any automated test set breaks. You feel the need to improve testing so that prod does not break as often. If prod breaks often,you also feel the need to automate how deployments are rolled back and changes are reverted. You also feel the need to improve troubleshooting and observability and alarming to know if and hoe things break, and improve development workflows and testing to the ensure those failures don't happen again.

You get none of this if your project deploys at best 3 or 4 times a month.

Another problem that infrequent deployments causes is team impedance. You need more meetings to prepare for things which would otherwise be automated away. You have meetings for deployments for specific non-prod stages, you have meetings to plan rollback strategies, you have meetings to keep changelogs, you have meetings to finalize release versions, you have meetings to discuss if a change should go on this or that release cycle, etc. bullshit all around.

Does my manager? No, but what if they leave and I have a new manager right before performance reviews? I’d hope they don’t care about it, but I assume they’ll see it. May as well make it look nice.

Does the random recruiter looking at your resume care?

At some point in your career you might be able to afford to not care about this. Most people don’t have that luxury.