> why would you disobey a direct instruction from you super?
Because the instruction was stupid, based on marketing instead of utility, or otherwise given without any thought to how it impacts the actual day-to-day work of their subordinates.
Why WOULDN'T you disobey a stupid instruction? What's the difference between "stop using this tool you're productive in and switch to this one that you're demonstrably LESS productive in for no reason other than I heard it was a good idea", and "Go strap some rocks onto your ankles and swim the English channel. I heard that was a good idea."?
> Their argument is that all team members should use the same tools, and I guess that is a valid point
No. That's only a valid point if something about the tool must be shared between users, rather than just the output. Emacs is a text editor. It reads, modifies, and produces text. The correct tool for each team member to use is the one they're most productive with, full stop.
Jesus fucking Shiva while Odin watches, but I hate corporate management "thinking". It's just become more and more brain-dead over the decades.
I think that's a pretty reductive stance to take. Keyboard nagivation is more productive _if_ the primary use of the tool is text-based. In a word processor, an IDE, a file manager, or anything else where the primary mode of interaction is reading, typing, and processing the things you've read and typed, keyboard navigation can be demonstrated to be faster and more natural _only if_ the user has taken the time to learn the shortcuts.
For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.
Absolutely not, since it's the same price as their cheapest hosted option. If all they're doing is orchestration, why the hell are they charging per-minute instead of per-action or some other measure that recognizes the difference in their cost between self-hosted and github-hosted?
This concept has been around for ages. I remember way back in a previous life as a Java dev having a framework where you could annotate methods with permission requirements, and the framework would add runtime instrumentation to ensure the proper context was created in the current thread and had the proper permissions to invoke that method any time it was called.
I think you've missed the core thesis of the article. That post _wasn't_ technical writing. It was marketing disguised as technical writing.