Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In-person training revealed major deficiencies #101

Open
5 tasks done
MaybeJustJames opened this issue Nov 24, 2022 · 0 comments
Open
5 tasks done

In-person training revealed major deficiencies #101

MaybeJustJames opened this issue Nov 24, 2022 · 0 comments

Comments

@MaybeJustJames
Copy link
Member

MaybeJustJames commented Nov 24, 2022

This issue is intended as a retrospective on using this material during in-person training where feedback loops are much shorter and clearer than online training.

Use of Hedy:

I started day 1 without any personal or student introductions (I think this still needs to happen online). Instead, I asked for show-of-hands that everyone had downloaded the course materials and installed required software.
I immediately moved on to Hedy (hedy.org), a teaching language designed to gradually introduce Python features to children. The idea being to build confidence quickly. The entire first morning
was spent on the first 4 "levels" of Hedy:

  1. print, ask, echo
  2. is variable assignment, variable interpolation in strings, sleep
  3. lists, add to list, remove from list, at random
  4. quote syntax for strings

Formal feedback 1:

I think the hedycode does not need to be introduced since it tends to 'take care of the rest' during the first introduction (e.g. you don't need to put ' ' sign for printing strings, etc.).
Just give the reality of Python environment directly, it would return an error when you don't put ' ' when printing strings (so, always remember to put them). By this, we can save
about half the time of the first training day so that we can use it to cover difficult parts of the training (notably file handling and plotting) or maybe discussing some projects.

The student above is happy to be contacted so they identified themselves. They are an advanced (top 3) student. My informal perception was that Hedy achieved what I wanted it to achieve:
rapidly build confidence, introduce "computational thinking" as an ordering of precise instructions, motivate placing quote syntax around strings. I did make an attempt to separate self-selected
"advanced" students who would start with the original course materials. In practice all students (except 1?) followed along with Hedy.

The downsides of using Hedy:

  1. It is somewhat all-or-nothing. Integrating it into the existing material is difficult or impossible.
  2. I disagree with the ordering of "levels". I would prefer not to cover "lists" or "at random" in level 3. As a "teacher" I can disable level 3 but this causes a jump from level 2 to level 4.
  3. The "challenge" tabs require some instruction/explanation. Many students did not attempt the challenges but only completed the "intro challenge" for each level.
  4. It can feel somewhat "childish" or "slow".

My opinion is that 1 and 2 are a reasonable price to pay for the advantages. 3 is mitigated by instructions by the teacher. I'm not sure how to handle 4. Advanced students still get a lot out of this
course as a whole, especially in the later stages (so excluding them would be a mistake) and they contribute to helping other students who are struggling (only works in person of course).
In the regular course materials I have "advanced exercises" for students who finish regular exercises quickly.

Formal feedback 2 (under the section what is good about this course):

Start simple and increased the difficult every course

I think this backs up my feelings about the use of Hedy.

Collections and looping:

Only "list" collections were covered during this in-person course due to time constraints. I think this should be maintained in the future since the distinction between tuples and lists in Python
is not obvious and not easy to explain without greater context. As Nina noted, this implies removing coverage of zip() and friends. I agree that these should also be cut.
Despite not explicitly introducing the concept, students quickly grasped that strings can be iterated over in a for-each. I do not think that this idea needs to be explicitly introduced.

Library functions and error messages:

I received some informal feedback that use of library functions is not obvious (how do I know what exists? When should I look for one?). Indeed I believe this is to be expected
and is a skill that primarily comes from experience. However pointing to good documentation is necessary and
should be emphasised more. i.e. help() is often not very useful for a beginner. Even docs.python.org often isn't great.

Reading error messages needs more emphasis. Students will often attempt to guess a problem or ask for help without reading the error message. This comes with the caveat that
Python error messages are mostly useless for beginners. Although the situation is better in CPython 3.11. Mandating CPython 3.11 might help.

Functions and argument passing:

These continue to be a difficult concepts. Some specific issues I noticed:

  • the results of work carried out before applying a function, and passed to the function are left unused, instead the work is repeated inside the function.
  • definitions are unnecessarily repeated.
  • composition is not a useful concept to teach beginners.

It pains me, but I think dropping "composition" as a concept is the right thing to do. I'm not sure how to fix the other points.

Dictionaries:

Unexpectedly, this is a very difficult concept.

Some formal feedback:

The last day of course was too fast. I would be nice if the schedule can be adjusted well so that trainees will have enough time on last day too.

Tatiana and I adapted to this reality by spending the entire morning of day 3 on dictionaries.

Input / Output:

This material is too repetitive. Data cleaning is done individually for global and per-country data, they write basically the same function for loading global data and per-country data.
Only CSV is used, we should also de-mystify other common formats like FASTA. Parsing FASTA received very positive feedback historically.

I think discovering documentation for datetime.strptime() and formatting the string they want to parse is useful and should be kept in some form.

Plotting:

This is a large reason why students take this course (around 25% of students say this is the reason they want to use Python. This is consistently the second largest fraction; data analysis is the largest fraction with ~40%).
3 days does not give us time to cover this topic usefully. Indeed yesterday I simply showed the matplotlib gallery (https://matplotlib.org/stable/gallery/index.html) and the final project
result (the climate data plot). I did not have students run any of the code or install matplotlib.
I believe treating plotting as an "advanced" topic is the right course of action. This would allow us to cover related and pre-requisite topics together (such as installing packages, virtual environments, etc).

Type annotations:

This idea was not used in this in-person course, nor in any previous course. I have floated the idea with Tatiana and Bruna as potentially clarifying in certain situations.
There were a few points when I believe having type annotations on student defined functions would have been useful during this most recent course.

In-person vs. online training:

Being able to see students, especially their faces and screens when they're struggling allowed me to customise the pace of the course to the pace of the students. A major discovery
is that students need far more time to solve exercises than I was giving them online.
I can categorise the students into 3 levels:

  • The top 33% of students were able to understand the problem and apply the "theory" and demonstrations to solve it without assistance.
  • The middle 33% of students required some help understanding the problem or how to structure a solution. They often understood how to apply the "theory" and demonstration code once they understood the problem.
  • The bottom 33% often did not know where to start. They would often stare at their screen for 10 minutes without asking for assistance or would attempt to solve the problem in a "not even wrong" way. These students either
    do not grasp concepts as they are introduced, understand them in a very limited/shallow way, or forget any understanding they have between weeks.

There are significant barriers to asking questions online and in-person. Online students must monitor a chat window and risk interrupting the "lecture" and potentially drawing attention to themselves. In person
students necessarily draw attention to themselves. I attempted to use the "classroomscreen.com" website for polls in-person, this did not work very well because it requires switching the screen away from
whatever materials I am displaying at the time. However I do think there is a technological solution to this problem that would satisfy the requirements of online and in-person environments, this requires some
exploration though.

would suggest one more lectuer assistant

Enough questions were fielded in-person that I believe this is true.

Longer term proposals:

At this point I think it is worth seriously considering the fundamental delivery of this course. An alternative that Janick uses, as I understand it, is to provide video recordings
of "theory" that students can peruse at their own pace/leisure. A period of in-person/online (synchronous) time is allocated to working on exercises and answering questions.
This solves 3 major problems: 1) advanced students feeling like the course is slow, 2) less advanced students being left behind or forgetting concepts, and 3) not enough time dedicated
to specific concepts.
Of course there is a large up-front investment into creating high-quality tutorial videos but this investment should pay for itself after 2-3 courses.

I would also like to experiment with a "hybrid" arrangement. What I have in mind is:

  • Nina online
  • James + Alex/Tatiana/Bruna in-person.
    Students follow "theory" material in their own time and post or vote on questions that can be addressed synchronously during the course time.

Short-term proposals (for Jan 4):

Removal of topics/concepts:

  • "basics" including operators and data types as this is covered enough in Hedy
  • Function composition
  • Tuple and string collections
  • zip()

Addition of concepts/topics:

  • type annotations. These could be introduced in a limited way to test student reactions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant