I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it.
Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table.
It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum.
And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.
I don't understand how "using a GUI to drive this tool" instead of "using a CLI to drive this tool" means someone doesn't understand version control, doesn't care about how their code interacts with their team, or doesn't know how the tool works.
I don't understand how I'm supposed to reply to this given that it claims I said something I didn't even come close to saying and has nothing to do with what either me or the GP post were replying to.
If you want to try again, the central thesis of my post was:
"Using git (or some kind of version control) is, in fact, your job."
With a digression that amounts to:
"The disdain OP's post shows towards people who take the time to understand the tools fundamental to performing their job is extremely unappealing to me in a coworker" (ie. the "they should get a job managing a git repo or something" part)
Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table.
It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum.
And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.