Skip to content

Reflection Day 5

Previous Retrospect

I've taken a look at the retrospect of this same day of previous course:

  • [x] Update the session on creating a package. Done 👍
  • [x] Explain better the TOML file. Done 👍
  • [x] Explain better what a 'build' is: Done 👍
  • [/] Suggest to add MkDocs website at deployment. Not discussed.
  • [/] Distribute the different fields over the examples examples, especially add a simulation. Not done, examples were as simple as possible
  • [/] Read up on the literature, regarding how to deal with people that prefer to work alone versus people that prefer to work in groups. Rejected. Instead put people in a group and tell why this is important.

Before teaching

I notice that we use VS Code, so that people can 'just click through version control', however, that we use the terminal anyways, as that one we understand.

I want to try out a course iteration with using the terminal commands instead.

I should remember:

  • [ ] On Day 1, tell about the 'Ask for help' button in Zoom and this it will be used together with teachers going around the Zoom rooms
  • [x] Go through older reflections: I did not take the time to listen to these in this case, as I had to be picky on how to spend my time
  • [ ] Rename 'Modularity' to 'Using Python modules'

During teaching

In the schedule, there were two subjects scheduled. I never believed we'd reach the second subject. We didn't. I think this is a feature of learner-centered teaching and I think this is the right thing.

Day Time Teacher Scheduled subject Actually taught
Friday 09:00-10:00 Richèl Bilderbeek Implement the project as a package Implement the project as a package
. 10:00-10:15 . Break .
. 10:15-11:00 Richèl Bilderbeek Runtime speed profile Implement the project as a package
. 11:00-11:15 . Break .

Todo

  • [ ] Suggest to add MkDocs website at deployment

Retrospect

What helped us learn

  • Looking at the GitHub workflows and reflecting over how we worked before and now.
  • A lot of interesting colleagues, great exercise design and good discussion and peer review helped.
  • The break down in theory and practice sessions was very helpful. It helps refocusing and not getting too distracted.
  • Working together, have discussions and Q&A. I think it helps to keep attention and engage participants.
  • I think short intensive readthroughs+demos combined with hands on exercises worked really well.
  • Richèl

:-)

  • The good atmosphere on the course. Both teacher and student were vey nice and friendly and it felt like a safe environment to make mistakes and really ask questions. It made me learn a lot!
  • Teachers' explanation of concepts before breakout room labs
  • breakout room labs
  • Wrap-ups after breakout room labs
  • Breakout room labs themselves
  • Switching partners in teams.
  • Listening through the lectures today; For the entire week, from some lectures and some discussions in the breakout rooms. Overall the documentation of the course is good and I'll be relooking it!
  • I like working in breakout rooms! Changing partners was helpful. I like the quick overview together and then working on it independently/in pairs. Detailed and clear exercises were great to work on
  • Little groups
  • What helped us learn was the practical work in VS Code, the step-by-step exercises, and the support from teachers and classmates.
  • The interactive exercises were most helpful (entire week)
  • Again, the pair sessions were great.
  • The small groups were helpful to meet other people and get different good practices from different people, to then teach them to the next person!
  • interacting with different people
  • Working in pairs
  • Have a general idea of how the package should be from the beginning
  • The interaction with other students (entire week)
  • The teachers were very nice!
  • Interactive exercises with reflexions after that.
  • Little theory, lots of hands on
  • The slow pace

What held us back

  • Not sure today.
  • It was not hindering but it was more perceptive. A large bunch working on the same repository helped us see the challenges. of git.
  • Long lectures in the afternoon tend to me a bit heavy (on a full stomach)
  • Some sessions today were a bit too dense with concepts, and I reckon some people were a bit lost at the end.
  • I think the frequent schedule changes made it a little hard to follow the course timeline. Especially if one missed an hour or two somewhere.

I agree that with a learner-centered approach, a schedule becomes unreliable.

  • time
  • Too much theory material on the second part of today (Friday). It was not interactive. We did not have time in the breakout rooms.
  • Everything is part of learning. So, nothing to say here.
  • It's from the discussions in break out rooms with some consistent partners; I guess for the course it could be set as two groups - one want to work independently and two in groups; Then it'd be good
  • Lectures going on too long without breakout rooms or asking questions of the studies. Also switching to lectures to the final bit on friday slowed a lot of the momentum working on the project
  • Sometimes not clear the concrete goal of an exercise
  • What held us back was that many concepts were completely new, especially Python packages, virtual environments, GitHub, branches, and dependencies
  • Today was a bit too much lecturing (in slow pace) and too little interactive exercises (especially after lunch)
  • Fear of breaking main? XD

I hope this is a tongue-in-cheek remark. And if yes: I am happy the fear of breaking main is felt :-)

  • Sticking to the schedule would have helped
  • Björns session was good, but a little too theory heavy...?
  • Dev branch still was very far away from main. It would have been good to fix it. And laern how to bring back everything together. The last exercise did not really work a
  • Some lectures are maybe too theoretical
  • Generally, the pace of the course could be a bit faster for me
  • I did not quite understand how the CI can be integrated into a github repository

what can we improve to help us learn better

  • Have more interaction or exercises on the last part of this day.
  • As a student take this course early on in career to understand the nooks of being a computer scientist.
  • Maybe switching the teachers earlier in the course could be helpful, so that a 'new face' does not come in at the end of the course :)
  • Less concepts, but possibly digging into them a bit deeper. For this, it might be good to ask participants what would they like to learn before the course, so that you can put more emphasis on that.
  • Update Schedule if we are skipping parts/jumping ahead/changing order.
  • maybe less or shorter breaks
  • Last day is too much info. Maybe first day could be a bit faste and give more time for the rest.
  • Maybe increase the breakout room time a bit. However, it's good enough as is.
  • I'd pack myself with the foundation. And relooking this course would be good source! Thanks to all the teachers!
  • Having all of the exercises be clear. An overview of how to work on the project earlier in the course would've been good. I would have been more confident working on main earlier!
  • The last session can be more interesting if the theory part is a little bit sorter and let more time to make the documentation
  • It would also be useful to have more time to practice, either in groups or individually, in VS Code. This would help us feel more confident and better understand the workflow.
  • Include interactive exercises during the last day with documentation
  • I might be easier if the sessions follow more similar format. E.g. 10 min theory + 10 min demo + 25 min exercise (+45 min exercise part 2 if needed) ..._
  • more theory
  • have a second part of the course.... more time to keep development the project would be great
  • Maybe requiring to all of us merge branches or whether having a directory for day analysis "Temp_learners" which is deleted at the end of the day and other like "Final_learners"
  • The course was understandable and dynamic, even for people like us who had little or no previous programming experience. The practical exercises and group support helped us follow the process better.
  • More structuring who work on what during the project implementation in the main folder

How strict should we teachers be with the prerequisites? Any ideas on how to enforce your suggestion?

  • It it hard to be strict I think. But perhaps have some requirements that participants should be able to do x and y with tool z. ei. Perhaps be able to use git pul and push and know what merges are
  • Maybe a questionnaire on git to understand if the participant is ready.
  • There is no need to enforce very strict prerequisites, but maybe in the introductory email there could be a couple of videos to watch if people are unsure that their level in something is high enough.
  • I think it is fine to be more lax with the prerequisites, as long as this does not slow down the schedule. I think having the exercises timed was a good strategy.
  • I think one could be wery strict with basic prerequisities like having vscode, python and git installed, having GitHub account (even PyPi account before course?) Maybe less so with experience
  • I think not to strict. It was fine. I think people had different strengths. Maybe tell the participant to practice a bit before the course. A few exercises before would bring people to the same page.
  • The flexibility helps in asking and answering some practical questions, as long we are learning how to write and organise a project and its code in a more professional and formal manner.
  • With prerequisites, you might send some short tutorials and if we feel comfortable with to work on that e.g. git
  • I would have an exercise of git push/pull in the requirements! It was very clear how to set up the git account but I think having everyone make their first doc in read me for example would be good!
  • Language requirements maybe?
  • I think the prerequisites should be clear but not too strict. Some participants may be new to programming, but they can still learn if the course includes basic support at the beginning.
  • I did not feel that any students lacked knowledge such that they held back the course. One could have a 'test myself' with 10-20 questions ensuring that all students share the same knowledege
  • From my experience the students were able to follow along with the programming for the most part, so the prerequisites were good.
  • As for the how to enforce. Maybe every student could be required to reply in issue with their username, create a file in ./learners and commit to it. That should still be managable before course...?
  • I program mostly in R and python code was not so easy but still think I did not miss anything important on the course. It is not really about writing a "weather" package but about the process.
  • I think everyone fulfilled the requirements (to my knowledge)! I think having one more task would not take too long.
  • I think the form when applying to the course, asking about previous programming experience is a good tool.

Which session(s)/topic(s) should get more time at the cost of which session(s)/topic(s)?

  • I liked the idea of registered reports. But since we did not use them it might have stuck less compared to other sessions. Perhaps remove it to discuss how to work with git and branches

I agree, I used registered reports as a tool to do an informal design, to prepare for the more formal design.

  • development

  • I don't have a suggestion on it. Maybe peer testing of code between different groups to see if the packages are working.

  • I think the formal testing part which we did get to would have been interesting. Maybe there could be a number of core subjects and then people vote on the additional ones at the start of the course?

  • TDD (creating tests in general) and CI, at the expense of documentation (it is something that one can achieve with a bit of common sense) and packaging (this might be too specific to Python)

  • I would allocate more time to Formal testing framework, building a new project (what files and folders should be included and why, what is a good structure of data science project, ...)

  • development at the cost of the design document

  • I think it was good. Last day felt really long.

  • The first day theoretical sessions time could be reduced and spread over the more practical session, such testing, git workflow, and module/package building.

  • Development session should get more time at the cost of design may be!

  • we skipped runtime/speed profile and i think that was okay

  • The first two days compared to the 3 final ones. Maybe registered report and Risks. Documentation could be usefull. Maybe a practical on containers?

  • I think more time should be given to the sessions on VS Code, GitHub, virtual environments, dependencies, and packaging, because these topics are difficult for beginners but very important.

  • Unittests could have more time and less time on how to use git on the first day (since it is a per-requisit)

  • I would love to have more time to practice TDD.

  • Maybe the modularity session was not as helpful, since it was mostly about functions. Maybe skip it and get more testing in? Or more pair programming?

  • I think the contents were good. Less lectures specially on Friday. More exercises and discussion in breakout rooms.

  • I really like how much time we spent on TDD and pair-programming! It was the most fun and we were also able to implement the habits we had learned earlier!

  • IDE is a prerrequisite so maybe is not so useful that part
  • How to use an IDE or Vscode was also quite long, I think that could be a self-learning module before the course starts for those that need to refresh
  • I think the more "check this out" or point out interesting thing to research on your own parts can be trimmed down. For example the wiki feature is interesting, but not essential learning.
  • Maybe pair programming for every lecture and not as long lectures. Also maybe a Q&A time at the end could be useful, in case something is still unclear?
  • Function design maybe it is already implicit in the other previous classes? idk

Here is an overview from the points above:

Less More
Registered report git and branches
. Development
. Peer testing
Last day .
Documentation and packaging TDD and CI
Design document Development
Theory day 1 testing, git workflow, module and package building
Design Development
First 2 days Last 3 days
Registered report, Risk Containers?
. VS Code, GitHub, virtual environments, dependencies, packaging
git Unittest
modularity testing or pair programming
Lectures Exercises and discussion
. TDD and pair-programming!
IDE .
'Check it out things', e.g. wiki .
Long lectures Pair programming, Q&A time
Function design .