Reflection 2024-02-23 Day 2 by Richel¶
This was the schedule taken from my lesson plan:
When | What | Status |
---|---|---|
TU 13:00-14:00 | Pair programming 1 | Draft of content, draft of exercises |
TU 14:00-14:45 | Pair programming 2 | Draft of content, draft of exercises |
TU 15:00-15:45 | TDD 1 | [1] Draft of content, draft of exercises |
I started at 13:00 sharp with 7 students. There would be 2 more learners
in a couple of minutes. I started by showing the 'Who is Richel'
presentation on my teaching
repo. I think it is dull, yet it felt useful
enough. I asked for questions and I did get one, that I rejected, as
it was unrelated to teaching. I regret that I had to reject it,
so next time I will ask 'Are there question on this way of teaching?',
as this is more precisely what I mean.
I felt it would be a good to start with a course overview, to remind the learners of the big picture. This felt useful.
The pair programming session started with a 'Prior Knowledge', which was unavoidably shallow. I still feel it was useful to stick to a Mike Bell teaching cycle. A quick poll showed none had ever pair programmed (however, I think my question was too vague, as some stated to have pair programmed in the past).
The 'Present' was short, describing they why. I did a literature check in the early morning and added the doubt surrounding the effectiveness of pair programming in developing code. I feel it made it stronger that it is such a great tool for teaching.
The 'Challenge' was a literature read: I felt that is more useful then me reading out loud the literature. During the description of the exercise, I had mixed feelings when one learner said it was the first clear exercise in this course, but hey, my exercise came across as clear :-) The timing of that exercise was perfect!
In the 'Feedback' phase I was struggling a bit with picking from options. I fumbled with asking again the same questions as in the 'Prior' to see a difference. I quickly went to the answers I'd written down, which seemed to be a good idea.
In general, I think the 'Feedback' phase is now my weakest.
As I want to prepare the next sessions, I'll speed up a bit now:
Pair programming exercises 1 and 2 felt unnatural, as these had no logical cycles. Next time, do TDD in isolation first, then in pairs!
- [ ] Next course iteration, do TDD in isolation first for at least 3 cycles, then start pair programming
Learners still struggled with git. I feel this should be dealt with on day 1.
- [ ] Next course iteration, strongly encourage the git teacher to discuss and cause merge conflicts, as they do happen in the basic git workflow when duos work on one file
Creating empty classes should be done in isolation, ideally during the basic git workflow session.
- [ ] Next course iteration, encourage the git teacher to create empty classes
I discussed the code for TDD, including exceptions. Exceptions are part of function design. TDD and function design go hand-in-hand, yet I wonder if I can improve the flow.