My current team suffers from disgust of Taco Bell programming. I love it, and I push hard to use it for the projects I lead. I've even had other leads scoff at my use of Python because "the GIL will throttle your application!" Possibly, but I understand the performance requirements of my systems and GIL is the last thing I'm worrying about. I'm not going to write my own programming language, or use one that doesn't have a good ecosystem, because an existing language is deficient in some negligible aspect.

Engineers who build things from scratch do not understand a very profound fact about software engineering: a computer performs menial, repetitive tasks so you don't have to. Be lazy and use someone else's solution.

When I was 14 I remember writing bubble sort from scratch dozens of times, as well as input scrubbing methods and binary search trees. I didn't know about the concept of libraries. Granted the internet (sourceforge, github, etc) wasn't around and I was writing everything in BASIC or Pascal. By the time I graduated high school I understood that writing code was painful.

Consequently, it's sometimes alarming that most systems I build rely on thousands of lines of code that I didn't write and rarely ever inspect. But I have to trust other developers in order to get my work done in a reasonable amount of time. I don't even consider myself a good programmer, mostly because I hate writing code. Nevertheless I do deliver useful, valuable systems. I know my problem has already been solved by someone else. I like being lazy. It's my best quality.

This isn't addressed in the article, but avoidance of Taco Bell programming is a symptom of a disease. The disease is ignorance; mostly in managers who are out of touch with the technical landscape in which their teams work. Any time I hear of a team building their own tools or doing significant amounts of de-novo work, I try to limit my dependencies on that team. You're never going to ship that shit, buddy, but I solemnly admire you for trying.