I feel the friction. I'll toss another perspective your way though. I'm a software engineer that primarily works in infrastructure and systems engineering. I en

I feel the friction. I'll toss another perspective your way though. I'm a software engineer that primarily works in infrastructure and systems engineering. I end up writing tools that users mostly use in their shell. Sounds pretty uncomplicated right? Write a command, include some flags, produce some output. Not quite! Some notable demands I've received over the years: - Backwards compatibility between incompatible CLI's - Roaming profiles and persistence - Command/flag/value auto-completion - Hierarchical consumption of defaults/profile/flags/environment variables - CLI's generated from backends There's lots of interesting frameworks and tools you can use to design all these and more, however, as users add demand I found myself having to integrate all of them quite curiously, then they all became bespoke projects. The only consistent way that I have to manage this level of uncertainty is through testing. I have very finely scoped and defined unit, integration, and E2E tests that all run various functionality and ensure my contracts so that while I'm writing a feature I don't need to be constantly worrying I have broken some behavior by rewiring all of these components again. The only other tool I have against the chaos is inline documentation. I rarely use consolidated documentation sources anymore, because it always turns into another task that has to be done as an after-thought with this level of complexity. I do also work on big infra products, and these run into many of the same problems the author described.