Long-ish, Teaching programming, not code shaming. Non-intuitiveness of Git and PR workflows.
Ok so I did a live code review with my masters student im teaching last week, made changes in a branch in multiple commits, opened a PR so they could read through and digest later, so far so normal.
During lab meeting they said "I got some good feedback from jonny, and ill be working through that, but there are like 15 commits so it might take me a bit" which made me go ??? a little but shrugged it off. I was trying to model committing often with each change having a descriptive commit message, but the PR was relatively small and this is not a live/public project, so I figured they would just merge it to main and keep working on it there. We're still working our way up to a stable main/work on feature branches git flow.
It appears as if they thought they had to go through and manually re-apply the changes I had made in each commit in order, not rebasing or cherry picking, but copy and pasting code in their editor. The idea of merging was new to them, as was the entire PR interface. I had made a guide for code review a few months ago with lots of annotated screenshots and etc., but there were enough strange terms that they couldnt really parse it - what the purpose was, what the start point of work done on a branch and end point of merging meant.
Always a reminder that you need to go back further than you think when teaching. I dont know how to balance allowing for self-exploration with scaffolding well, and teaching git is harder than teaching programming sometimes because it's "invisible" and happens between the code, but the code is something you can look at and see.
describing my teaching methodology, re: Long-ish, Teaching programming, not code shaming. Non-intuitiveness of Git and PR workflows.
@jonny What I tend to do when teaching programming and related things, is to have 'guided self-exploration'.
I make it very clear upfront that there is no penalty for getting things wrong, and that they *will* sometimes get things wrong and that's completely okay, and that's an intentional part of how I teach, and that I will be there to help them out whenever they get stuck.
Then I do usually 1-2 hour sessions at a time, deciding together on a small task (in a real project they want to do, not a sample/demo project!) that lets them practice some aspect of programming or project maintenance, and we go through it together.
Crucially I don't tell them *how* to do it; I give them a pointer on how to reason towards the answer, but don't provide the answer itself, and instead encourage them to 'reason out loud' and try things out (emphasizing that if something goes wrong, I will help them undo it, so they should feel free to try things even if unsure), and constantly ask them questions on "okay, and what would you do next?", incrementally narrowing down the scope of the question until the answer occurs to them.
The idea behind this is that you're always there as a 'support net' for them to fall back on, but they do as much of the "reasoning towards an answer" process as possible by themselves - and this helps them very quickly learn to identify the "meta-process" of working *towards* an answer based on incomplete information and missing background knowledge.
(For this to work, it's important that they work on a project/goal of their own invention - because that means that they already intrinsically know what the end goal is with all of its detail and nuance, and so you only need to teach and communicate the "how to get there" parts, not the "what are you supposed to be doing" parts.)
This approach often takes a bit for students to get into, as it *feels* hard initially and so being supportive is very important, but I've had universally positive feedback to it in the end. It usually only takes 2-3 sessions before they start getting the vast majority of "what to do next" answers right, even on topics they've never worked with before, and usually before they feel confident about their answers.
Interestingly, this has also worked very well with students who self-reported serious learning disabilities, and who had run into walls with everything else.
@cykonot @jonny Pretty much - inspiring confidence to *try* things, especially, and then building up a genuine confidence that derives from understanding (as opposed to 'false confidence').
It's more or less "teaching people to learn". There's remarkably little programming-specific learning involved, really 🙂
addition, re: describing my teaching methodology
@jonny One detail I just realized I forgot: when they're going in the wrong direction, I don't usually tell them "that is wrong", but instead ask them a "self-reflection" question that prompts them to take a moment and think about it more. For example, "and if you did it that way, how would thing X change?"
It's less confrontational, and helps them to learn identifying the 'failure points' early, where they can catch themselves before making a mistake, by making self-reflection a habit early on.
@joepie91 @jonny creating confident coders