For example, you're building a web application that has a signup process and the sales team uses an external CRM service to collect sales pipeline information. The programmer who shows up and does their four hours pulls out the usual libraries and writes the code to make it happen. The view fires up a few requests in an asynchronous task that updates some models and everyone is happy. However the sales team decides to change CRM services -- there's a shiny new kid on the block with features that would improve their sales process. The work-horse programmer gets the story and hunkers down. Four hours later there are a new set of tasks, a signup function, and hopefully a few tests.
The missed opportunity is that CRM software isn't terribly interesting and it should matter little when the web application signs up a new user whether you're talking to CRM A or B. I often find little scenarios like this that just add up over time. They're often missed because the focus is on getting something done for the next four hours/for the next sprint planning session/whatever. There's no real planning done beyond the next little bump in the road.
And so our solution is to use the same old tools and practices but simply hire more people to be work-horses.
I'd much rather engineer more robust RPC frameworks that can negotiate the protocols on their own so that a valid business decision to use a competing service doesn't cost me a couple of days of boring, tedious work. I'd rather just change a configuration line or two and sip an americano while reading the latest Vanity Fair in my garden.
So.. while a great article in many respects I would add that in order to become a great developer, in my opinion, you must refine your instincts towards laziness. You must become a connoisseur in methods by which you can avoid doing work. Being busy is not a virtue.