This sounds a bit like "the computer is meant to serve the user; the user is not meant to serve the computer." It's a valid sentiment, and one I use on my peers

This sounds a bit like "the computer is meant to serve the user; the user is not meant to serve the computer." It's a valid sentiment, and one I use on my peers often, especially when dealing with end-user-facing software and systems. But when it comes to Software Engineering Workflows, I've learned in my decades of experience that the progenitors of a process or workflow had no idea how to do it, made the assumption that no one had done it before (or that buying a solution would be too expensive), and then just cobbled something together to get the product built and out the door. They start hiring more employees who spend an inordinate amount of time just understanding the existing workflow and soon lapse into "well, it's not my problem - it produces output, and I just need to fix bugs / add features to the product." Before you know it, you're ten years in, with a couple dozen white-labeling clients, and that build system can't scale. What I feel like we need is an encyclopedia of workflows. So you wanna make an app: make several decisions now, and here's the recommended design workflow, engineering workflow, testing/staging/release workflows ... BRB, I think I just found a consulting idea...