Skip to content

Reflection Day 4

  • Author: Richel

  • Date: 2026-05-07

  • Working with multiple branches: 2 hours

  • Continuous integration: 2 hours include project
  • Modular programming: 2 hours include project

What would help:

  • Someone checking the submitted code to give more guided feedback: I do not have the time to do this
  • At the start: someone checking if all learners can use version control I still had to help learners do so on this day

What helped us learn

  • I enjoyed Richéls explanations. I think the real in depth understanding happened when we worked on these topics together.

Great! That is exactly the whole why we use a project!

  • Guided by an expert trully inspired a lot as a low leverl python user

I am happy to see our learners help each other so well.

  • Pairing up with really knowledgable and helpful people helped learn new thing or solutions to complicated problems. Also when we did not know anything, we tried together and came to the outcome.

I am happy to see our learners help each other so well, as well as that they dared experiment.

  • Repeating pair programming today was super useful when having some strange errors.

Great, my instincts were right!

  • Maybe out of the scope, but it would've been nice to dig a bit deeper in how to set up some basic CI.

Yes! There was no time :-/

  • Today was great. A lot of practical examples and coding.

Yay!

  • exercises, theory

Great!

  • Good, friendly, helpful, loose, informal atmosphere

I agree!

  • making errors

Great that our learners are comfortable to do so.

  • Working with different people is helpful, it is good to switch from being more or less knowledgable than your partner
  • Having all the people merging at the same time
  • Working with branches, commits, merges, and GitHub Actions helped us learn how collaborative programming works.
  • The hands-on exercises that allowed us to also incorporate some of the stuff we learned during the last days
  • the changing of partners was really good
  • Working in pairs!
  • Teacher's explanation before the practical teamwork.
  • The teamwork itself.
  • The clarofication that follows the teamwork in the main room.
  • Having coding buddies made everything more fun.
  • Having time to work in groups was nice.
  • being in group with the same person
  • the practical exercises
  • the changing of partners was really good
  • Given time to work on the problems with a friend.
  • Nothing in particular.
  • Reminders for the breaks are veeeeeery nice.
  • Some more step-by-step instructions for the whole merging procedure would have been helpful, to have as a reference.
  • This is already good enough, even swapping partners after two breakout room sessions.
  • The 'call for help' function was used a lot and indeed helped!

What held us back

  • I think some of the questions in the course material were a but vague. I think that Richels instructions were clear in a majority of cases, but the were a bit vague in e cases

I agree! They definitely need to be sharpened!

  • A bit nervous with some function i'm not familiar with but need to generate a module

I understand.

  • Mostly technical knowledge gaps was holding me back but was lucky to have helps from experienced colleagues who helped.

Kudos to our learners.

  • The prodecure with pulling and pushing could be reiterated better, especially when pushing on main.

I agree.

  • I guess working with data and plotting requires some basic knowledge of some packages, e.g. pandas to work with the tables or matplotlid, and their APIs, and this slowed me down a bit.

I agree. Maybe I should emphasize clearer that this functionality is best suitable for people that already know such modules

  • Sometimes a little chaotic and challangin with merging for a novice with 20 people contributing at the same time. More support needed sometimes.

I agree (see above in my reflection)

  • being in group with the same person

I agree, ideally the learner should have switched.

  • Technical problems with VS Code and git

Yes, I've seen it too...

  • people were in very different stages.

I agree: it is a challenge for me as a teacher to deal with that ...

  • Sometimes I felt lost on what do to. Was I supposed to focus on merging any woring code into dev an? or on actually writing fuctional code for the do_analysis()?

I agree: I even did not put this in the exercises! Add it!

  • I think explaining the main vs development branch vs our own branches a bit would be helpful. Also reminding to pull before pushing. I didn't push to main enough because I was working locally

I agree and this was my bad!

  • Having all the people merging at the same time (sometimes it was confusing when in dev files appear and disappear)

This is a feature of a bigger team. I think it holds one back from learning other things.

  • What held us back was confusion with Git branches, pull/push synchronization, merge conflicts, and understanding GitHub Actions errors.

It seems to remain vague to some. I wondered if I should keep making teams of git experts and git novices. I think I should.

  • Not much

Great!

  • I think the Formal testing framework needed a bit more time than it was given

I agree: it was not discussed at all.

  • Perhaps a guide to some of the more common error messages that come up in vscode.

Unsure.

  • The possibility of having another job after we were done did not occurr to me, so maybe next time could be made explicit :)

I agree.

  • Did not understand how to work on analysis.py

My bad.

what can we improve to help us learn better

  • In some cases improve the clarity of question and tasks. "What exactly are we supposed to do" Some examples could be projects not being pushed to main, and some uncertainty regarding the wether proje

  • I think the time kept for day4's exercise are very adequate. People need this time, specially who are not very experienced. I would keep the time for exercises and code development as is.

  • Maybe to improve the commits to main, people could be divided in two random teams and then at the end of the day/the session the team commits could be summed and the team with most commits wins!

  • Focus on coding that does not require experience with specific packages. For example, reading a file line by line, extract some information into a list, and then write to file.

  • For someone that has never contributed to main before. I would be nice to see the process in a short demo. feature branch-->develop-->main in vscode to get more confident.

  • more theory

  • More clear instructions for the pratical exercises. Perhaps more back into the big room together and reflecting on what was happening.

  • Explain where to develop before telling us to start working on it. own branchs vs devolpment vs main

  • Idk, maybe just having some time between each day to each student to have the learners repository cleaner

  • I think the system works well.

  • Some more real-life examples. I feel like this course gives a good introduction but it might be difficult to incorporate into a science project

  • I think there should be a lot more formal questionnaires later every task complete.

I agree: my Feedback (teaching) phase is weakest!

  • Similar to the answer 'I don't know', everyone should be forced to push on main, even if a picture or empty file.

Interesting idea! You are right! I even think this is in the course materials ...

  • I think the teaching pace is constructive.

Great!