I think his point is that engineers tend to favor complicated solutions, and that they shouldn't do that. Every line of code you write or modify is potential technical debt that you'll have to own. The author appears to indicate that this is bad, and also appears to recommend making wider use of pre-existing solutions to prevent it. That's fine as far as it goes, but it's a simplification.

The piece does feel incomplete in that it doesn't discuss the incentives behind the decision to "write code" or not.

The simple fact that we always seem to come back to is that once you learn the basics, good engineering just comes down to good judgment, which is only gained through years of dedicated trial and error. Is it better to write some glue code to bounce data between 8 different extant programs and make final transformations or to write your own program that handles the process soup-to-nuts? The answer is now and will always be "it depends" (and quite frequently, it involves elements of both). We need to make sure that the social incentive structures align with the engineering goals (i.e., don't tell someone that if they make something stable and low-maintenance, they'll unemploy themselves) and then we can trust people to do good, iterative work.