Indirectly related... I am the one-man team for the CLI (Command-Line Interface) for a new cloud computing PaaS. This is a small project (10+ employees, mostl

Indirectly related... I am the one-man team for the CLI (Command-Line Interface) for a new cloud computing PaaS. This is a small project (10+ employees, mostly software engineers) on a more extensive company (500+ employees). Sometimes I have a [really] hard time dealing with management and co-workers because they expect me to mimic the behavior of our GUI console (web-based) with a high fidelity level that many times is just inappropriate for the CLI or not what you want on a CLI. Most of this is caused by lack of experience on both using and writing CLI tools (I happen to have way more experience than them in this field because I am a long-term heavy Unix user - since a kid, besides having a greater understanding of Unix programming in general). I wish they at least read "The Art of Unix Programming" by Eric Raymond to better respect some design decisions I made. I am very open to criticism and even enjoyed the unexpected help I received from the project UX / UI designer, that was enlisted to help me out (except for things I clearly decided against but were kind of forced on me). Here is an incomplete list of things I had to deal with related to performance/usability: * (lesser problem) backlash against language: Go was my language of choice for this, many of the team would instead use Node.JS * lack of understanding that I have to support a vast amount of configurations: BSD/macOS/Linux/Windows + different shells + terminals (and it gets worse / weird when you talk about Windows), and that somethings that look nice in one system, might not look the same in most terminals. Also, many times it is difficult to predict with accuracy what terminal is in use (I am looking at you Windows Subsystem for Linux, that pretends it is xterm-2565, while not supporting most things of it). * colors, colors, colors. The designer wanted colors everywhere. Foreground, background, Alpha-RGB. You can not imagine how hard it was to convince that we better stick with ASCII standard 16 colors and that alpha channel didn't even make much sense, at least while I am alone * Explaining why we better stay away from new UTF-8 icons "that only renders nice on macOS iTerm" * Explaining why colors look different in other terminals (say, Hyper) * Explaining that I have no control over the screen background of the user whatsoever and can't even detect it appropriately / would not be nice to do so * Animations, animations, animations. Why do they expect animations everywhere? How do I explain to them that if I try to open an URL on the browser it opens kind instantenously, and it needs no animation because the user wouldn't even see it (and then being told to just put a small delay before opening for it to appear to happen... fast)? * Decorations, decorations, decorations. I lost this battle and the error handling mechanism prints a weird symbol on every line of error. I am actually stripping the decorations a few pieces at a time and intend to eventually get rid of it just by being a rebel and removing it kind of "accidentally" (especially when it gets in the way). * Lack of understanding of Unix software programming patterns (filter program, pipes, redirections, etc -- see The Art of Unix programming) [and why I don't accept passwords to be passed as an argument as this is... soooo easy to use™!] * No respect for spacing on a listing of entries: hard to defend that tabular data must be presented as tabular (even though it might get repetitive) or at least have easily parsable separations. One example is a proposal of listing services while showing their projects, and only print the project name on the first line of service [and assume the project above for all others]. This is a deal breaker for pipping or filtering out data most times, and people just want me to ignore it and feel disappointed with me when I do the right thing (ignore their opinion instead). * I was demanded to add heuristics to a status system due to lack of proper feedback about remote actions such as deploying/restarting/stopping services. This would never work very well because of many things, such as concurrent calls, eventually request just took longer or happened in practice in 'the wrong order', and so on. Took more than six months until I got a decent API change where I could trust the status and more six months for a more CLI-like approach of not doing more than one thing at once to be agreed upon (instead of always trying to replicate the GUI [blocking] behavior). Many of these things above I managed to ignore, did in a way that was easily revertable, or just accepted for the sake of my well-being [and wished/planned/plan to move to a more sane approach soon].