Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don’t completely agree.

> My job isn’t to use git, it’s to write specialist software.

I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!).

So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest.

In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it.

Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted.

(edit: added IMHO)



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)


How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ )




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: