Anecdote: early in my career, I worked on a dev team that feared software development. They tried to push as much logic as possible into Microsoft SQL Server stored procedures (the average length was around 10 pages). Look at all the code that <i>wasn’t</i> written (because SQL doesn’t count), and less code means less bugs!<p>Where stored procedures wouldn’t do, they put these of the logic into SQL Server Integration Services, which provided a visual programming environment — think Scratch but for visually connecting ETL pipelines. But, invariably, the existing components wouldn’t suffice, so they’d stuff 100s of pages of C# into these components, which would be hidden away behind a little “code block” rectangle in the SSIS flow-diagram-esque interface. Zero code reuse, no way to run unit tests, no strong typing (beyond primitive types mapped 1-to-1 with the underlying SQL queries), no codification of invariants/preconditions/etc. But hey, that C# code hidden away doesn’t <i>count</i> as code, so look at all the code we avoided! And SSIS is from Microsoft, so by using something they bless then we must be on the right track! What’s that you said? Should we consider if this particular tool is appropriate for our particular needs? No way! If SSIS wasn’t the optimal tool for <i>all</i> problems, why would Microsoft develop and market this product?!<p>Anyway. I think the trap people fall into is this: Critical thinking is tiring, and many people are lazy. Putting such people in a position that they <i>must</i> actually weigh the merits of multiple options is a sure fire way to become deeply resented. Also, critical thinking makes you responsible for the consequences of your choices, whereas appealing to authority absolves you of any and all responsibility (the old saying “no one was ever fired for buying IBM”). So many attempt to reduce the amount code as much as possible. But the problem is that many worthwhile endeavors are inherently difficult, and require real, hard, critical thought to arrive at a solution, and for such things code often happens to be the best medium for reifying those thoughts into software solutions. Consequently, countless companies will choose to jump through no-code hoops, and unsurprisingly suffer the consequences. They won’t learn from it though: instead, those responsible will deflect with excuses like “well Zapier is the issue, you see”, or “imagine how much longer it would have taken if we actually coded the solution!”, or “that’s just the nature of software/tech”, etc.