Skip to content

Evaluation Day 4

We used a Retrospect to evaluate.

What helped us learn

  • I enjoyed Richéls explanations. I think the real in depth understanding happened when we worked on these topics together.
  • Guided by an expert trully inspired a lot as a low leverl python user
  • 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.
  • Repeating pair programming today was super useful when having some strange errors.
  • Maybe out of the scope, but it would've been nice to dig a bit deeper in how to set up some basic CI.
  • Today was great. A lot of practical examples and coding.
  • exercises, theory
  • Good, friendly, helpful, loose, informal atmosphere
  • making errors
  • 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 Ricgéls instructions were clear in a majority of cases, but the were a bit vague in e cases
  • A bit nerous with some function i'm not familiar with but need to generate a module
  • Mostly technical knowledge gaps was holding me back but was lucky to have helps from experienced colleagues who helped.
  • The prodecure with pulling and pushing could be reiterated better, especially when pushing on main.
  • 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.
  • Sometimes a little chaotic and challangin with merging for a novice with 20 people contributing at the same time. More support needed sometimes.
  • being in group with the same person
  • Technical problems with VS Code and git
  • people were in very different stages. 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 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
  • Having all the people merging at the same time (sometimes it was confusing when in dev files appear and disappear)
  • What held us back was confusion with Git branches, pull/push synchronization, merge conflicts, and understanding GitHub Actions errors.
  • Not much
  • I think the Formal testing framework needed a bit more time than it was given
  • Perhaps a guide to some of the more common error messages that come up in vscode.
  • The possibility of having another job after we were done did not occurr to me, so maybe next time could be made explicit :)
  • Did not understand how to work on analysis.py

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.
  • Similar to the answer 'I don't know', everyone should be forced to push on main, even if a picture or empty file.

  • I think the teaching pace is constructive.