If I was teaching anybody programming I would teach them to copy the folder over every time they added a new feature, rather than teach them git at the same time.
With some C++ libraries or node_modules that can run up fast.
It's not teaching them the wrong way. It's teaching them a simple version of the right way.
You can't do everything at once and git is counter-productive on day one, and the most important thing was they find programming remotely interesting at all.
The next most important thing is always working on a new copy.
How exactly you make those new copies barely matters at all compared to just having them at all.
Using something arcane and unforgiving and inscrutable and complex like git to accomplish those copies is way way down on the list.
The new student is barely interested in the actual coding to make a game if you're lucky. They would rather mow lawns than learn administriva like git.
It could even be argued as irresponsible to hand git to babies and expect everything to be fine. Just because we all have about 5 git commands we use 99.9% of the time, and have no problem 99% of the time because we learned how to "hold it right" and just always carefully do things in the right order, does not mean git can actually be made safe and simple. Those 5 or so commands aren't actually enough.
I thought about it more, and I'd say we actually agree on the principle of teaching simple and building up. It's more a question of how different teaching techniques present the value of source control.
The hard thing about source control is not the how — using the git CLI is only slightly more complicated than copying a folder. Git turns that into a very straightforward directed graph, and the CLI gives you a few commands to move around the graph, sprinkling some more edges and nodes wherever you like. It takes about an afternoon to figure out once you're onboard with the why.
The why of source control is the thing — and our industry is already full of people who don't understand it. That's how we get people who treat git as a "save" mechanism to be invoked whenever it's been a while since the last commit, or branches with one sloppy commit message after another [1], or entire repos that are just spaghettified carelessly-merged hairballs of commits.
Mastering the why of source control means learning when to cut a commit, what shape that commit should be, and why that is.
And I think that's more my objection to the teaching approach outlined here — without any other context, it reads to me like it's not quite focusing on the right things. At worst, it's inducting the student into the industry-standard cargo-cult approach to source control. [2] If the why isn't learned, then it doesn't really matter whether the specific motion is copying folders or typing in git CLI commands.
Ideally I think source-control techniques could be introduced right when they're going to be interesting or fun — when it's time to build something together with someone else. Then that set of lessons could start by copying folders and eventually building up to git — and each lesson could show how good, disciplined use of source control concretely improves the collaboration process.
i don't entirely agree with not teaching git to a new programmer, but if we look at the extreme it makes more sense. how would i teach a nine year old? exactly like that: copy the project.
actually, a good way to think of it is releases. even with git, i keep a copy of each project release, that itself is not stored in git.
A new programmer can just use a git UI like the Github app. It abstracts everything away and leaves you with the obvious benefit of being able to commit a succession of snapshots that represent logical groupings of changes.
I haven’t used cli git since uni. GUI is better for basically everything except for a few rare and advanced commands.
Yet that is still just one more impediment to getting someone off the ground. You are already throwing programming concepts (variables, and loops, and conditionals, oh my!) + big scary IDE + likely first-time command line, etc onto their plate. Invoking yet another weirdo program into the paradigm is not helping a beginner.
Jeremy Howard (of Fastai fame) has a good analogy that we do not make people sit in a classroom for a semester to learn all of the theory of baseball. Instead, we give them a bat and a ball, and layer on the instructions of how the game works. You can get a good approximation of the game with just a couple minutes of instruction and refine the understanding from there.
if someone is at that level they are learning the language and do tutorial or student projects where version control doesn't yet matter. which is fine. once they have done a few of those, it's time to introduce basic version control.
I managed to finish college without a real VCS. Would it have made some things easier? Sure, but again, add it to the pile of things I needed to learn and did not have enough time to study.
as far as college is expected to prepare students for work, version control should absolutely be part of that.
i don't expect a fresh graduate to be a skilled git user but if the nature of development at work is substantially different from what the student learned at school, then they will have a much harder time adjusting.
they should at least be familiar with all the concepts that they will encounter in a junior job and not be faced with having to relearn a completely different development process.
You can’t teach all of the things at the same time. People will just freak out, be confused and learn nothing. There’s a lot of the things that you’ll teach “wrong” at the beginning. You’ll never talk about CI/CD at that stage, deployment, packaging, etc. either, despite a lot of this being a requirement for a lot of software engineering projects.
As others have pointed out, it is not teaching others wrong things: copying the directory is (modulo optimization) what Git does. However if you dump people straight into everything at once they will become extremely confused and won't learn anything.
What I want to do is take one step at a time, and build on what they already know.
Then when they can program, you can show them how to use Git and the superpowers that comes with it.
I always like the Odin Project way of teaching - you start with setting up virtual machines, install IDE, learn git before you get to write your first line of code.
This sounds a bit like Lockhart's Lament about how we teach math is why everyone hates math.
The analogy was imagine if we taught music that way, where you spent years learning fundamentals and theory before ever being allowed to touch an instrument.
His idea was to begin with one's voice as a musical instrument, so one would interact with music directly at first, learning the theory and the notation along the way.
The lady quoted in the article agrees with you but also seems to support why I thought of Kodály in the first place:
> "Eleven years of piano lessons taught me something about playing the piano
> but almost nothing about music," she has said. "I was skating on the
> surface. If a child is shown a written crotchet they have no physical
> understanding what’s behind that. Kodály musicianship puts petrol in the
> tank in that it gives them a profound experience of music-making, through
> the voice, building up a repertoire of songs and giving them the
> unconscious knowledge of pitch-matching, walking the pulse, rhythm,
> phrasing and improvising – before making it conscious."
So you will not be touching the piano before all of this takes place and you will be learning the fundamentals and theory, even if in a playful way.
Playing a classical instruction you would normally do that. Maybe you learn how to hold, change reids, do scales first but without theory you can't read notes or understand what to do with them. Without reading notes you can't play songs off of sheet music.
With some C++ libraries or node_modules that can run up fast.