Teaching Jujutsu to complete beginners.

[nanoni17728]

I stream coding sessions on Twitch, and I like to spend time explaining programming related stuff to people who are completely outside of the field.

I usually get beginners who ask for guidance. Even though I think sticking with an older gen VCS would be best for them since they are what the vast majority of people use and they force you to think about the structure of your changes upfront, I can’t outlook how forward-thinking JJ is. I mean, that’s why I’m using it in the first place! There will be a tipping point at which JJ get relevant for the masses.

Let’s say we assume we don’t want to try for people to be able to just pick up JJ and be productive with it in real life situations. Instead, we just show JJ as a tiny plus in their experimentation with their first programming language and problem solving. What would be your approach, and did you already think about this topic and/or actually did a teaching session with someone?

I think a no-brainer is the usual jj undo. Did an oopsie? Well don’t worry. JJ got your back ;)

Having ADHD, I spend a good chunk of my time cleaning up the mess JJ snapshotted. So I would try to vulgarize my cleaning tools and workflow I think.

Otherwise, well, it’s a question that I only started asking myself two days ago! So that’s pretty much it. If that tickles your brain too, don’t hesitate to share your thoughts!

Thanks for reading.

[joyously]

I can’t outlook how forward-thinking JJ is.

What does this mean?

we just show JJ as a tiny plus in their experimentation with their first programming language and problem solving.

If you mention a VCS as a side note while discussing something else that requires concentration, it is simply unwanted noise. As a useful tool, version control warrants its own undistracted conversation, especially for collaboration.

On the whole, I think the Bzr Init tutorial has a good approach. (It was modeled on an older Hg Init tutorial that it links to.) They work up from solo repo to shared.

[senekor]

This sounds exactly like what I'm working on at the moment! It's a Jujutsu tutorial for people who have no prior experience with version control. It's structured into levels, where each level is supposed to be the smallest possible package of things to learn to unlock the next "level of productivity".

It's not a secret but I also am not quite ready to "advertise" it more publicly, so please don't share the link for general consumption yet. But I would be very happy to receive early feedback from people who are also thinking about this topic!
https://jj-for-everyone.github.io/

Levels 0 and 1 are content-complete. I've just started writing level 2, the first chapter of which will cover jj undo.

[InCogNiTo124]

What would be your approach, and did you already think about this topic and/or actually did a teaching session with someone?

I've been toying with that idea for a general VCS intro for some time now. I also started writing a codelab once, where people could build a real project by using jj, but life took over 🙃
Everything I say below will be from my experience of tutoring colleagues at uni, and it's likely missing a POV

The majority of complete beginners I encountered don't know why would they use VCSs at all. An ideal training would be a series of situations (of increasing complexity, maybe?) and the explanations of how to handle them with jj, eg trying out new things in the codebase with new changes, or a series of refactors and running tests for each to see the progress, culminating with doing a megamerge and trying out whether or not things work together, fixing everything up, and then jj absorbing everything.

I could see the benefit of learning jj alongside some language, as it could also be a training in good practices (of sorts), as these are rarely discovered by students themselves, they should be shown by a more senior person. For example, editing changes in place is handy and can be done, but it's much cleaner to jj new -> jj squash. But, again, those should be motivated by a concrete need of a curriculum: for example a topic could be readable variable names and the use case could be let's change the variable names at its first appearance, with an emphasis that once the change is uploaded it's a really bad idea to go change retroactively.

Revsets are a super-cool feature to explore, and they could be an entire separate lesson. Like, what are they, how do they work, what are the most commonly used, how to write your own etc. There could be plenty of exercises on revsets alone 😄

Also an important point is that one of the major use cases for VCSs is collaboration, so there should be a non-trivial amount of time spent showing programming beginners how to collaborate with each other, in general, using jj as an implementation. Pushing code to a forge, reviewing the code, providing comments, amending the change, solving conflicts and so on. Plenty of opportunities to showcase SDLC principles.

IMO jj is a tad tricky to teach at this point in time, because the best workflows and some terminology are not yet finalized, which I think is also a friction point for beginners. Do we teach squash or edit workflow? Both are nice, and it depends on the personality, but we do have to teach them, somehow, in some order, as people are unlikely to rediscover them by chance.
Then, are we talking about changes, commits, or revisions? Super confusing to have three terms for seemingly the same concept.

[FWIW I'm all for standardizing on the squash workflow and the term changes, but that's just me]

This is just a braindump of what I've thought about so far, I probably missed some more topics.

[PhilipMetzger]

Do we teach squash or edit workflow?

Or none at all, since the existence of those two doesn't mean that you can't have a mega-commit which you split at some point.

Copying something nice from Discord:

@rue-parfait I think the cool thing about jj is that every workflow basically involves making "incorrect commits" and then using all the tools jj provides to correct those commits into the timeline you want!

The squash workflow creates a bunch of tiny (incorrect) commits that you combine into your final timeine

The edit workflow creates a bunch of incomplete (incorrect) commits that you gradually tweak until it becomes your final timeline

You can invent a new split workflow that creates a bunch of really large (incorrect) commits that you split into your final timeline!