Day 2: Debugging
Closed this issue · 1 comments
How clear is the material? What’s confusing?
I really liked this one last year. I do think we can add some thing so that the lesson makes sense without the explaining someone has to do synchronously. That is, maybe we can add notes or a link to a video that explain the code and related debugging so that people can preview/review the lesson on their own time.
Are we assuming any knowledge that we shouldn’t be? Where should we add background info?
Perhaps useful to explain what all these numpy or plt functions do, when introducing the code in class.
Is the structure of the lesson engaging? Are there any parts that are unnecessary/boring/too long?
The lesson is nicely designed. I do think that there is any part that is unnecessary.
how much time did it take you to complete the assignments? Keeping in mind that most participants will likely take more time than you, how much time should we suggest that participants spend on each activity?
It took me 15 minutes to read through the plan and understand the code and the bug. I think more time can be devoted in interactions with the audience, like asking them what they think a particular thing does or is.
Thanks! I refactored all the debugging stuff out of the README and put it in a separate markdown. When we have a public video, then we can link that in the debugging demo section. I also updated the comments in the debug_matrix.py
file which I realized are terribly out of date.