Imagine if everyone learning physics came in with an attitude of "I need to learn and use the rocket equation as quickly as possible" (or substitute some other high-level problem for "the rocket equation"). You'd end up with strange backwards tutorials for physics that start out with that specific model, then a handful of related models, then how to abuse that model to handle things it doesn't really apply to, and much later the underlying physics and mathematics to solve arbitrary generalized problems.
Many people start out trying to figure out either "how do I use git exactly like (svn, cvs, vss, ...)" or "how do I commit and push my changes", so tutorials start there. Most people don't approach git by learning its underlying data model. Arguably people should, because it's a rather simple data model, and then all the commands become simple applications of that model.
Most people don't start learning Word by understanding the data structures used to store the text and modifications either.
For 95% of developers, git is a tool that is incidental to their primary task (developing software). Having to have a deep understanding of the underlying data structures in order to use it effectively is the antithesis of how most "utility" software is designed.
When I am in the flow of coding some part of my project, my head is full of the data structures, object models, databases, algorithms, requirements, etc. that are immediately relevant to that task. If I have to do a context switch and pull the git data model front and center into my thinking to know what to do to get my work into the repository, that is a serious break in flow and has always been a problem for me whenever I've had to use git.
> Most people don't start learning Word by understanding the data structures used to store the text and modifications either.
And, there should be a warning when your document gets above 5 pages long that you should learn the structural sides of the program at hand. Unless you like spending your weekend crafting a TOC line by line.
The world would be a much sadder place if that was the case. I do not understand how the infrastructure that powers world trade, banking, public construction etc works. I am grateful that they are packaged into easily understandable interfaces so I can still benefit from them.
The power of technology is compounded when it can empower even non-technologists to use it. The more sophisticated tasks they can accomplish with it, the better.
It's a double edged sword. By crafting interfaces so simple anyone can use it, we forbid them to understand what's really happening. That's how people end up thinking the blue 'e' icon on the screen is Internet.
But is 'forbid' really the right word here? I certainly agree that such interfaces encourage people to "accept without questioning", but it seems that there is no necessary obstacle to making something that's easy to use but also permits you to dive under the hood and see the details. (I think particularly of Mac OS before it started becoming all iOS'd. Even now, when Apple's 'just work'ing settings don't just work for you, you can often fix it by diving into the command line.)
IMO, no actual mainstream OS gives ability to understand anything, even UNIX based. And I don't believe command lines are a way to understand either, or a very low efficiency one (gotta read a lot, understand complex context, try mistakeful commands).
You need virtual, mockable, undo-able environments to understand. You need ways to decode the data and metaphors used by computers.
> For 95% of developers, git is a tool that is incidental to their primary task (developing software).
Ehh, either those 95% of developers are working on small projects, or they're not working as effectively as they could. Version control is just as much a part of software development as your compiler or your text editor. Incidental, sure, but how you use those tools is critical to your final output. Being able to quickly and easily bisect the tree is critical, and this requires that your commits are small and self-contained. Being able to do development and backport patches to older versions of your software is similarly critical, and so it has to be super easy to make a new branch and port the patch across to that branch.
Just like I couldn't do my job without a text editor or without a compiler, I couldn't develop complex software without version control. I know my text editor very well so that I can write efficiently. I know my compiler well enough to use it to build my programs in the various configurations I need. I don't see why the version control software should be any less important to master.
>I know my text editor very well so that I can write efficiently. I know my compiler well enough to use it to build my programs in the various configurations I need.
Aren't these somewhat different details to know tho, compared to knowing the insides of git? Knowing the commands, and options available in an editor is familiarity with an interface. You don't need to know exactly how it stores the buffer so it can stay responsive with large files, you don't need to know the rendering algorithms involved, etc. etc. Just the same, I don't think being able to use a compiler effectively depends on knowing how it does register allocation, or knowing if the parser is LALR or recursive descent.
These are all implementation details. Good interfaces generally abstract over them, and present the user with what they need to use it. Version control being necessary doesn't change how people should approach learning it. At least, no more than we should expect good drivers to understand piston engines. (Though, drivers of manual transmission cars should probably understand clutches. Maybe Git is comparable to that?)
I know it was just an example, but the rocket equation is just one assumption (constant exhaust velocity) and a simple integration away from the force balance coming out of Newton's second law.
All credit to Tsiolkovski though, the guy was a true visionary.
Oh, absolutely. But imagine the effect if almost every physics book and curriculum taught the rocket equation in chapter 1, and either didn't teach Newton's laws or the general equations of motion at all, or only taught them in the last chapter/appendix/advanced class.
Many people start out trying to figure out either "how do I use git exactly like (svn, cvs, vss, ...)" or "how do I commit and push my changes", so tutorials start there. Most people don't approach git by learning its underlying data model. Arguably people should, because it's a rather simple data model, and then all the commands become simple applications of that model.