This is why many of us ops types are annoyed at the current popular fad of rejecting the unix philosophy of keeping programs small and task oriented, but able t

This is why many of us ops types are annoyed at the current popular fad of rejecting the unix philosophy of keeping programs small and task oriented, but able to pipe and be piped as part of a greater workflow putting those things together. This is exactly it. I see whole stacks, and theres seems to be always a key app or microservice or two written by a particular team, and it usually: has bad log formatting, doesnt multi-thread or muli-task well (concurrency and parallelism), have some non-standard or extranneous db or rpc/api queries that impact entire flow with locking, etc... If the focus was to make sure the services were rock solid and that was the focus it saves so much future pain and tech debt digging. On note of what the customers want: I think the approach I prefer is to not spend much time on it, and make it fast and intuitive - quick brainstorming brings rawer truths to the surface often if done frankly. Alas, all that said, one can't always manage upwards. The c-suite and the boards are so often high on their own airs they stop listening to engineers or have let the wrong ones become filters, and there is nothing you can do to change that unless you are on the board and can fight at that level, but I don't know many engineers that can. This is the main irony of SV to me.