Hacker News Reader

Comment by jogjayr | Hacker News Reader

> is like hearing they need to understand the details of how a transmission works before they go and drive an automatic

Which would be a reasonable attitude for your average driver but not for a professional mechanical or automotive engineer.

View on HN

Why?

Unless I'm misunderstanding, you seem to be saying that being a programmer implies having a desire to understand every program's internals. But I don't care how Photoshop stores the 30-layer document I'm editing, and I feel like I shouldn't have to. I can't see why Git should be treated differently.

That's a great question and I had to think a lot about how to answer it. I think there are 2 aspects to consider whether something is worth learning: relevance to your current skills, and use of the knowledge.

We insist, especially when hiring, that programmers know something about the internal design of other software that they use, but don't develop, on a day-to-day basis. Any programmer, depending on programming specialty, that doesn't have some idea about design of their operating system, networking stack, databases, or hardware would flunk out interview processes (and probably rightly so). The reason we insist on this specialized knowledge is because most of the time these things work fine, but when they don't the good software engineer proves their worth by being able to dig deeper.

Version control software is used just as frequently as any of this other software. But somehow there seems to be this feeling that it's not worth learning about and should just be a black box (I think package managers are treated similarly). Understanding git internals and design is a valuable software engineering lesson in and of itself.

The other aspect is having knowledge of Photoshop file formats is of limited utility unless you're an Adobe employee or Gimp developer (I don't know if the spec is open or not). Photoshop itself is closed-source and not so extensible or scriptable as an open-source command-line tool.

That's not true for git - knowing git internals reaps productivity benefits in your other work too. Treating it as a black box robs you of the knowledge to do some really cool stuff.

Broadly speaking this applies to any other software tool used by programmers - the more you know of its internal details, the more proficient you'll be in its use.

So in both respects (practical and from a learning standpoint) I think knowledge of git internals for a git-using programmer is a desirable thing.

While I mostly agree with you, I used linear VCS systems (mostly Perforce and SVN) for decades, and I still have no idea how they actually work. Git is fairly unique in that it basically forces you to understand how it works in order to use it, which I think is a major failing. I mean, it's nice that you can understand it and that that knowledge means that you can be more effective with it, but I don't think it should be compulsory. Currently it is compulsory for anything but the simplest workflows.

This doesn't seem specifically a linear vs distributed VCS thing, as much as it is a unique property of git. I previously used Mercurial, and at no point did I feel I had to understand how the VCS stores its commit graph in order to know what running some set of commands will do.

git is unique in its apparent assumption that it's nothing more than a series of convenience scripts that let you work on the raw filesysten representation a bit more easily. In a way it's more a filesystem-level representation of a DAG with some sugar on top, than it is a DVCS.

> This doesn't seem specifically a linear vs distributed VCS thing, as much as it is a unique property of git. I previously used Mercurial, and at no point did I feel I had to understand how the VCS stores its commit graph in order to know what running some set of commands will do.

Ditto. I've used Darcs, Mercurial and Bazaar, all are distributed, all have various levels of issues, but none of them required that I understand everything from the storage model up in order to actually get a grasp on them. I still have better intuition for Mercurial than Git (and long for a number of its features like GIVE ME FUCKING REVSETS ALREADY) despite not having seriously used Mercurial in years and having no idea whatsoever what goes under the CLI (and not caring a whit).

I think the argument would be that you need to understand what those 30 layers in Photoshop represent and how they interact with each other, not how they are stored.

Specializations exist because nobody can be an expert or even reasonably well informed about how everything works, even their own tools. I don't expect most professional engineers to understand the internals of their text editors or their compilers for that matter. Why should we expect it for something like a source control tool?

The reality is that in basically all profressional domains you are expected to be able to use, at a profressional level, the software required to do your job.

For developers that includes version control and package managers, amongst other things.

Do you need to know how git is implemented? Of course not. No more than you need to know how your compiler converts source code to executables.

...but understanding the basics of the tools (eg. what paths and layer groups are, to compare to photoshop), isn't something you can just wave your hands in the air and say 'not my problem'.

Its your job to know this stuff.

That isn't what I'm arguing; of course we must know how to use our tools. If that requires also understanding implementation details, even trivial ones (e.g., "it's a DAG"), or if the interface and words used to describe the usage are non-standard, awkward, or worse act to obscure what is actually going on, the tool and/or its documentation is poor.

For example: in this case, knowing what a branch is, how to create and delete one, and how to merge with one is necessary. Knowing that the branch identifier is a hash, called a "reference" or similar jargon and what that entails, internally, is superfluous and adds pointless complexity: if that's really required then git isn't good. I have more important things to think about as a developer than what internal machinery operates git.

The fact that commits are organized in a DAG is absolutely not an implementation detail. It's one of the core concepts of distributed version control.

It's also kind of silly to call git's terminology "non-standard". Git was the first truly widely used DVCS, so if anything, git's terminology is the standard terminology by definition.

> I have more important things to think about as a developer than what internal machinery operates git.

That could be extended to other tools like firewall configuration, TLS setup, library details, logging configuratoin, monitoring, etc. But you won't get very far in fixing any problems if you don't read documentation and investigate further.

But git doesn't actually require you to know these internals.

You don't need to know the format of git pack files or the network protocol in order to use git.

You do need to understand the concepts of commits and branches.

But most of us aren't version control engineers; we just use version control as one of many tools in our toolbox. I think a more accurate analogy would be that a taxi driver doesn't need to understand how an engine works.

A taxi driver does not to know how an engine. But I'd be amazed if a professional race car driver didn't understand their car.

We all expect software engineers, regardless of specialization, to understand operating systems, networks, databases and hardware at a better-than-layman level. Try saying "that's just a tool in my toolbox, I don't care how it works" about one of those topics in an interview.

We're stretching the analogy a bit at this point, but assuming there are much fewer race car drivers than other driving professionals (taxi drivers, etc), wouldn't the professional race car driver be equivalent to something like the top 1% of software engineers? In which case, I agree, because I'd expect a software engineer paid in the top percentile to know (at least roughly) how all their tools work. But for everyone else, you can get really far in the industry without knowing how any of that stuff works under the hood (or at least not more than you have to for the work you do).

> Try saying "that's just a tool in my toolbox, I don't care how it works" about one of those topics in an interview.

I've met plenty of engineers who couldn't tell you how any of those things work at a low level, but still manage to maintain high-paying jobs. I've also had plenty of interviews where these topics never got brought up. Maybe that says more about hiring practices than anything else, but I think you're vastly overestimating the worth of that knowledge to most companies and individuals.

>I've met plenty of engineers who couldn't tell you how any of those things work at a low level, but still manage to maintain high-paying jobs. I've also had plenty of interviews where these topics never got brought up. Maybe that says more about hiring practices than anything else, but I think you're vastly overestimating the worth of that knowledge to most companies and individuals.

The question is also simply what you pay for and what is in a job description. To simplify, you have to pay a lot less for someone treating software solutions as blackboxes with known behavior then someone who understands what is done.

You can of course ask in an job interview about everything from compiler optimization to network intrusion detection to image processing, but you better should make sure that is actually what you need.

Reply on news.ycombinator.com