[returningfory2]

Your read lines up with another point in the article that I found to be stated in strangely absolute terms:

> you need to be able to deploy your code fast, i.e. within at most an hour of pushing the changes to whatever branch/tag/thing you deploy from.

This sweeps under the rug all of the potential issues with fast deploys. I guess it depends on the product. I work on a managed database service, and one category of potential bug is that we accidentally delete or corrupt customer data. We have to be much more careful and can't just deploy what was submitted to mainline in the last hour without doing significant regression and performance testing.

But anyway essentially the main reason they give for fast deploys is:

> being able to see your changes live is nice because you actually get to see and make use of your work.

I think this is true. But, it lines up with this negative interpretation of this article. The author seems to prioritize themselves over the health of the product they're working on.