Explanation of how the close reason relates to the question

Question

I just don't see how the close reason presented applies to the question.

Question: Arguing the use of a program that's not the company standard

Question quoted:

I recently joined a new company, and in my previous company, I've been working with my Vim/Tmux workflow. But in new company, they say that I need to follow company standards, and one of the company standards is to use Sublime Text Editor with a few configurations.

Now, I'd really like to continue with my Vim/Tmux workflow, as I'm quite fast at it. So how should I communicate with them to resolve this thing?

Note: Vim can surely be configured like Sublime would have been configured.

The close reason:

"Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, The Wandering Dev Manager, Lego Stormtroopr

My reaction:

?????

"How should I communicate with them to resolve this thing?"

This couldn't be further from the actual content of the question. What's going on here? Is the question bad and our close reasons are just sorely out of sync with our site's standards? Or was this foolishly closed (see: the number of real answers - although high pretty proportional to the question's attention - and the number of upvotes on the question as well as on many of the answers.)

Answer 1

So how should I communicate with them to resolve this thing?

As one of the voters, the issue to me is this. The idea is not to ask advice (we're not agony aunts), but as gnat says:

explain what you want to do to make it better

The poster should write up their intentions, and any advice should be on improving that (or saying why that's a bad idea), which can then be up/down voted by the membership to get a consensus . By just saying "what do I do?" you can end up with multiple answers, none more valid than any other and no help to the poster.

It's important to get the poster involved there will always be subtleties that haven't been included, and the idea is to help the poster reach their own conclusion while providing help to others who may come later in the same position. A blanket "do this" is likely wrong in most people's situation.

Another part of this was that the question was posted as "I want to do things my way, how do I make them see what I want". Like it or loathe it company standards exist for a reason (in a case like this usually for licencing, but also consistency in config management/support etc), and the poster only makes a case of "because I prefer it". For all we know there is good reason why the company uses one tool (setup/working with other tools), and it may be this was reached via a company consensus, in which case it's better for the poster to become proficient in that than continue with what they are used to. Again these facts may come out as part of the poster suggesting an answer, but will become a commentfest otherwise, which is suboptimal.

As it stands the answer would be "tell them why it's worthwhile adding/changing to this tool, what the company/team benefits by doing this and how the poster will mitigate the risks of doing it", all pretty generic, anything about the specific tools would move it back to off topic.