Skip to content

Reflection 2024-02-24 Day 3 by Richel

Looking at the course material I see things that add fluff to the course in my opinion.

Only discuss theory that ...

- is (and can be) checked by an exercise
- is needed for the shared project

When in doubt, remove.
  • creating an own local GitHub repo: not needed for shared project
  • Forking: not needed for shared project

I add to the rule:

Only discuss theory that ...

- is (and can be) checked by an exercise
- is needed for the shared project

When in doubt, remove.

If there are two ways to do something,
pick the way which involves the least amount of new concepts.
  • git init: not needed for shared project, can be done on GitHub
  • git branch -c: can be done on GitHub
  • git graph: can be done on GitHub
  • git diff: can be done on GitHub
  • git show: no exercise
  • git log: no exercise, can be done on GitHub
  • git mv: no exercise
  • git rm: no exercise
  • big code examples: can be simplified to a 'Hello world' program
  • use multiple files: can be simplified to one file
  • use big files: can be simplified to short files
  • use complex commit graphs: can be simplified to simple commit graphs
  • using more repos: can be simplified to only use the shared repo
  • using git plugin: can be simplified by using GitHub view
  • using GitHub templates: not needed for shared project
  • using protected branches: not needed for shared project
  • add using Issues: we do use these in the shared project!
  • using command-line: if possible with GitHub

I add to the rule some green and red flags

Only discuss theory that ...

- is (and can be) checked by an exercise
- is needed for the shared project

When in doubt, remove.

If there are two ways to do something,
pick the way which involves the least amount of new concepts.

Green flags:
- 'You need this'

Red flags:
- 'maybe this is useful'
- 'if you have the time, you may want to take a look at ...'
  • [x] Settle on git switch and git checkout: which one is better? git checkout as there was one learner that could not use the alternative, as he had an older git version

Regarding my teaching:

  • I am happy with how it went: I spoke little, I think I never spoke longer than 20 minutes, adapted to the needs/pace of the learners, had interactions with all of them, with some minor teaching in the BO rooms. I think the exercises were clear, as never was I asked for clarification.
  • Even though I have a lot of time for exercises, it still feels to short. I wish earlier in the course, the learners had already practiced basic git things such as merging; I had to adapt to what the learners could do

  • Judging from the git commits, I see the pair programming and TDD has watered down. I will need to practice this tomorrow again

  • [ ] Next course iteration, schedule 3 hours for TDD

For the earlier hours, me and a colleague teamed up: the colleague would theory for one session, after which I would do an exercise. I did expect the colleague to also have exercises in his part. This turned out to be false. Next course iteration, I will suggest to split up differently: within one session, the colleague talks for maximally 20 minutes, after which I will do the exercise. BAD IDEA, as the exercise determines the teaching content. I predict a setup like that will never work.