5 ms·

> 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 fo

> 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.

uryga 9y ago
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.
- stochastastic 9y ago
  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.
- a_tractor 9y ago
  >why Git should be treated differently well for starters, git is free, while Photoshop is made by a for-profit corporation that has always charged quite a lot of money for it. >a desire to understand every program's internals You don't need to know its "internals," but you should understand how it works. That is not a lot to ask. Just like with Photoshop you need to know how to use the lasso tool, how layer masking works, how the difference color tools can be used, how to change image sizes and the limits of what you would want to do, how to preserve source images and work as lossless as possible, or 1 or 2 of the 5 different ways that you can accomplish a specific task with the program, etc, etc... to use git you need to know what its commands do. Photoshop is more equivalent to an IDE, which is usually paid for and usually comes with robust tools for managing a VCS like git, anyway. >how Photoshop stores the 30-layer document Yeah, and a lot of terrible designers don't care enough about the benefits of working with layers to bother with that either. No, you care about the opportunity for a massively improved workflow efficiency, so you bothered to figure it out. That is the equivalence with Git. >being a programmer implies having a desire to understand what does being a programmer imply, then? Anyway, starting from 0 familiarity, Git is just as easy to start using as Photoshop, and both can be just as complicated as you need it to be.
- jogjayr 9y ago
  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.
  - lemming 9y ago
    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.
    - 9y ago
sidlls 9y ago
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?
- fyi1183 9y ago
  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.
- wokwokwok 9y ago
  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.
  - sidlls 9y ago
    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.
RussianCow 9y ago
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.
- jogjayr 9y ago
  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.
  - RussianCow 9y ago
    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.
    - cf498 9y ago
      >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.

uryga 9y ago

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.

stochastastic 9y ago
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.
a_tractor 9y ago
>why Git should be treated differently well for starters, git is free, while Photoshop is made by a for-profit corporation that has always charged quite a lot of money for it. >a desire to understand every program's internals You don't need to know its "internals," but you should understand how it works. That is not a lot to ask. Just like with Photoshop you need to know how to use the lasso tool, how layer masking works, how the difference color tools can be used, how to change image sizes and the limits of what you would want to do, how to preserve source images and work as lossless as possible, or 1 or 2 of the 5 different ways that you can accomplish a specific task with the program, etc, etc... to use git you need to know what its commands do. Photoshop is more equivalent to an IDE, which is usually paid for and usually comes with robust tools for managing a VCS like git, anyway. >how Photoshop stores the 30-layer document Yeah, and a lot of terrible designers don't care enough about the benefits of working with layers to bother with that either. No, you care about the opportunity for a massively improved workflow efficiency, so you bothered to figure it out. That is the equivalence with Git. >being a programmer implies having a desire to understand what does being a programmer imply, then? Anyway, starting from 0 familiarity, Git is just as easy to start using as Photoshop, and both can be just as complicated as you need it to be.
jogjayr 9y ago
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.
- lemming 9y ago
  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.
  - 9y ago

sidlls 9y ago

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?

fyi1183 9y ago
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.
wokwokwok 9y ago
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.
- sidlls 9y ago
  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.

RussianCow 9y ago

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.

jogjayr 9y ago
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.
- RussianCow 9y ago
  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.
  - cf498 9y ago
    >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.