I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all t

I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all three. As a project accumulates people working on it and, crucially, as existing code is modified and added to, the probability that you'll introduce a bug approaches 1. I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).