We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Community teaching practices

00:00

Formal Metadata

Title
Community teaching practices
Title of Series
Number of Parts
160
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Community teaching practices [EuroPython 2017 - Panel - 2017-07-13 - PyCharm Room] [Rimini, Italy] In the last five years we saw many groups dedicated to teach people how to program but any volunteer that is going to start a new teaching group could have hundreds of questions related with concepts order, examples, exercises, libraries and text editor/IDE. Panellists will share their experience when teaching Python to newcomers from different backgrounds as part of their volunteer work for some organisations such as PyLadies, DjangoGirls, Code for Life, Software Carpentry, Data Carpentry, etc. Among the panellists we will have Mateusz Kuzak, from the Netherlands eScience Center and volunteer for Software Carpentry and Data Carpentry; Alice Harpole, from the University of Southampton; Celine Boudier, from Code for Life; Raniere Silva (as moderator), from the Software Sustainability Institute. All questions from the audience are welcomed
SoftwareMathematicsStudent's t-testExplosionData modelSocial classField (computer science)Computer configurationProjective planeTouch typingSoftwareOffice suiteMathematicianComputer programmingFreewareStudent's t-testExplosionMereologyPhysicistComputer scienceDifferent (Kate Ryan album)Line (geometry)Numerical analysisMixed realityCausalityAstrophysicsTwitterComputerMathematicsLecture/ConferenceComputer animation
CloningMIDISoftwareRobotCodeVideo gameSource codeCoding theoryGame theorySoftwareSoftware design patternSoftware engineeringLibrary (computing)Process (computing)Computer programmingNetwork topologyData miningRoboticsWebsiteProjective planeComputerMereologyCalculationRandomizationGame theoryPoint (geometry)Computer scienceMobile appInstance (computer science)CodeVideo gameWordOnline helpMachine codeOnline gameLecture/Conference
Extreme programmingDifferent (Kate Ryan album)Array data structureContent (media)Stress (mechanics)Error messageObject (grammar)BitPhysicistDigital rights managementCodeTerm (mathematics)Video gameStructural loadStudent's t-testMultiplication signCommunications protocolInstance (computer science)Electronic mailing listSoftwareWave packetPlotterUniverse (mathematics)Formal languageNumberLibrary (computing)Pairwise comparisonWeb applicationData structureComputer programmingSocial classMessage passingData dictionaryRight angleLogicAreaFunctional (mathematics)Ideal (ethics)Slide ruleSystem callSoftware developerDisk read-and-write headComputer iconIntegerOpen setMoment (mathematics)Group actionCuboidGradientLinear programmingObject-oriented programmingAlgorithmMathematical optimizationLevel (video gaming)Avatar (2009 film)Lecture/Conference
Musical ensembleDiffuser (automotive)Instance (computer science)Mobile appComputer programmingValue-added networkStandard deviationRoboticsLevel (video gaming)RepetitionSocial classVideo gameProgrammschleifeContent (media)Figurate numberMultiplication signProgrammer (hardware)Point (geometry)Decision theoryRight angleKey (cryptography)ComputerMoment (mathematics)MathematicianError messageHand fanBitElectronic mailing listOffice suiteAreaLaptopSoftwareSummierbarkeitInsertion lossWave packetGame theoryNear-ringEvent horizonMereologyWritingoutputCodeStudent's t-testPhysicistVideoconferencingMeeting/Interview
StapeldateiMultiplication signGroup actionInstance (computer science)Game theoryFigurate numberCycle (graph theory)Forcing (mathematics)HypermediaDifferent (Kate Ryan album)Level (video gaming)Formal languageSocial classEvent horizonLogic gateContrast (vision)Visualization (computer graphics)Pattern languageIntegrated development environmentGoodness of fitBitTheoryWhiteboardCASE <Informatik>Speech synthesisTablet computerOnline helpVapor barrierStatic random-access memoryTerm (mathematics)Moment (mathematics)ComputerReading (process)Type theorySoftwareError messageMaterialization (paranormal)Latent heatMeeting/Interview
Multiplication signInsertion lossUniverse (mathematics)Chemical equationMoment (mathematics)Process (computing)Order (biology)1 (number)Student's t-testLevel (video gaming)Reading (process)Different (Kate Ryan album)Numbering schemeOnline helpMereologyTask (computing)QuicksortMathematicsKey (cryptography)Point (geometry)Group actionSystem callSoftwareType theoryError messageMaterialization (paranormal)Meeting/Interview
CASE <Informatik>Multiplication signType theoryFerry CorstenParameter (computer programming)Meeting/Interview
Metropolitan area networkComputer scienceKeyboard shortcutConfidence intervalLevel (video gaming)Computer-assisted translationSpeech synthesisMoment (mathematics)Group actionOnline helpStudent's t-testDistanceWritingInstance (computer science)PhysicistFirst-person shooterPlastikkarteSheaf (mathematics)SpeciesPattern languageArithmetic meanSpacetimeUniverse (mathematics)Power (physics)Revision controlUniform resource locatorCASE <Informatik>Dependent and independent variablesPoint (geometry)DemosceneGoodness of fitDisk read-and-write headLecture/ConferenceMeeting/Interview
Online helpWordForcing (mathematics)Point (geometry)AreaOrder (biology)Beta functionComputerMusical ensembleComputer programmingNetwork topologyVideo gameGame theoryTheoryProgrammer (hardware)Thread (computing)Different (Kate Ryan album)Instance (computer science)BitReal numberSupersonic speedSeries (mathematics)WebsiteTerm (mathematics)Lecture/ConferenceMeeting/Interview
Distribution (mathematics)Level (video gaming)Formal languageArchaeological field surveyBitCartesian coordinate systemDirection (geometry)File formatStudent's t-testQuicksortoutputGoodness of fitState of matterGroup actionParameter (computer programming)Computer programmingRow (database)AdditionLecture/ConferenceMeeting/Interview
AdditionExpected valueInstance (computer science)Term (mathematics)Statement (computer science)WindowWeightCategory of beingDifferent (Kate Ryan album)Latent heatRadical (chemistry)Router (computing)Drop (liquid)Lecture/ConferenceMeeting/Interview
Different (Kate Ryan album)Multiplication signFeedbackTheory of relativitySoftwareMixed realityBookmark (World Wide Web)Wave packetBitInstance (computer science)Student's t-testSocial classComputerSource codeProof theoryArithmetic meanSet (mathematics)Physical lawLevel (video gaming)Perspective (visual)Group actionBuildingTwitterLecture/ConferenceMeeting/Interview
Right angleLecture/Conference
Student's t-testLevel (video gaming)Core dumpComputer fileComputer programmingEmailRevision controlLine (geometry)Inheritance (object-oriented programming)Logic gateDigital photographyProjective planeArithmetic meanMoment (mathematics)Formal languageWordParticle systemActive contour modelCollaborative softwareSummierbarkeitScripting language1 (number)Vector graphicsUser interfaceView (database)Insertion lossPoint (geometry)WebsiteClique problemCodePerturbation theoryMultiplication signRootDifferent (Kate Ryan album)CASE <Informatik>Graphical user interfaceSoftwareRouter (computing)CryptographyRadical (chemistry)HypothesisMeeting/Interview
Programmer (hardware)Software developerCellular automatonWordStudent's t-testSemiconductor memoryError messageMathematicsFood energyBeta functionWeb crawlerVisualization (computer graphics)ComputerObservational studyAreaComputer programmingPlotterInstance (computer science)Formal languageMultiplication signTheoryOpen setComputer scienceSystem callGraphics softwareProof theoryData miningReading (process)CollaborationismCausalityExplosionHand fanCopula (linguistics)Theory of everythingString (computer science)Physical lawCASE <Informatik>CodeMaterialization (paranormal)Stack (abstract data type)CalculusSupercomputerRouter (computing)Level (video gaming)Game theoryMeeting/Interview
Form (programming)Right angleTelecommunicationPhysical lawRule of inferenceSpeech synthesisMeeting/Interview
QuicksortPoint (geometry)DigitizingFront and back endsProgramming languageAreaFeedbackForm (programming)NumberComputer programmingGame theoryNetwork topologyOnline helpGroup actionProgrammer (hardware)Error messageOpen setConcordance (publishing)Position operatorRight angleOrder (biology)Goodness of fitBuffer overflowCASE <Informatik>Subject indexingKey (cryptography)Speech synthesisProjective planeSoftwareExpert systemMachine codeTerm (mathematics)Instance (computer science)Escape characterStack (abstract data type)Lecture/ConferenceMeeting/Interview
Point (geometry)FeedbackOnline gameComputer programmingSoftwareMaterialization (paranormal)Multiplication signLetterpress printingType theoryForm (programming)Shared memoryMereologyReal numberNumber1 (number)Open setBitGroup actionDiffuser (automotive)Negative numberSound powerSoftware developerLine (geometry)Fitness functionTerm (mathematics)Shape (magazine)Game theoryTwitterGradientAngleGoodness of fitFormal languageKey (cryptography)WordMeeting/Interview
Analytic continuationWhiteboardRoundness (object)Musical ensembleFigurate numberLecture/Conference
Transcript: English(auto-generated)
My name is Hanyal de Silva and with all the other three speakers we're going to have this panel. We're going to start with a few introductions. So, as I said, my name is Hanyal de Silva. I'm from Brazil and I have a bachelor's as an applied mathematician.
I now work as a community officer for the Software Assembly Institute in Manchester, UK. I contribute to and volunteer for some projects that teach people how to program, including Software Carpentry, Data Carpentry. I went to a workshop from the Jungle School of Seizea in Manchester. And if you want to keep in touch with me online, it's R-G-A-I-A-C-S, most of the places.
So I go to hand out to Alice. Okay, so I'm a PhD student at the University of Southampton. So I'm an astrophysicist, so in my day-to-day work I model explosions on neutron stars.
So I kind of wanted to take part in this because I'm a fairly recent learner. So I only started programming at the beginning of my undergraduate course. And I've experienced lots of different programming courses. So I've had courses from computer scientists, which were kind of okay but very fast-paced and I really struggle with them.
But I also had courses from physicists and they were in general absolutely awful. And it was like, here's some code, change a few lines, now you can program. So I have a mix of experiences there. And then more recently, during my PhD, I've been a demonstrator in both Software Carpentry courses and undergraduate programming courses.
So numerical methods for mathematicians. And yeah, if you want to see me on Twitter, I'm up there. Thank you, Alice. So we're going to hand out to Matheus. Okay, my name is Matheus Cusak, I work at the Netherlands eScience Center.
So in my day job, I'm involved in writing research software. But I work a lot with researchers and I got involved in teaching researchers, teaching them best programming practices. Because I think it's really needed. I got involved in Software Carpentry and I teach Software Carpentry, Data Carpentry workshops, recently also Library Carpentry.
So we teach librarians about programming, mostly research librarians. And I also train instructors now and I mentor new instructors and I'm involved in the steering committee of Software Carpentry. So if you want to ask me anything about Carpentries.
Thanks, Matheus. Celine? So hello everyone. So I'm trained as a software engineer from InstaPariTech in France. But I think I learnt my first computing concept by myself when I realised I could program my calculator. Because else nobody was teaching me anything else than PowerPoint or Word.
Since then I've been working in robotics and computer science. So I was for instance part of the Ask Now project at Aldebaran. We were programming apps on robots and websites to help children with autism.
Now I'm involved in Code for Life. So I'm the team lead at Ocado for Code for Life. A project where we create online coding games to teach all children computing. So it's a different but interesting challenge not to be on site but to program online games for people that you don't really see.
And also that's not about programming but I'm also a volunteer to teach children creative writing at the Ministry of Story in London. But that's also an interesting teaching experience. Thank you. So I'm going to join our speakers.
So let's start with this question. If you could send a letter to your past self one month before you have your first teaching experience. And by teaching experience I mean if you go for a workshop or if you're trying to write a tutorial online. Or if you're trying to write a course, a book, anything that's related to teaching.
What you would write on that letter for you one month before your first experience? Do you want to start Celine? Yeah so I think I would probably write myself to first never take anything for granted.
We tend to assume a lot of things and none of them are real. So expect the unexpected. Just, you know, can happen. So I would say for instance I had some interesting experiences in schools for the autism project. When we realized that the teachers couldn't use our web applications. Because of all the protocols that were in the school and preventing them from accessing our website.
Oh we should have checked before but that was a while ago. Also that some trainings that we are creating right now from Code for Life. And that we thought were really like five to eleven. We realized that they were also used a lot in secondary schools because there's also a lack of skills there.
So there are a lot of unexpected things happening and you have to be prepared to literally everything. So when I started teaching actually I didn't teach programming. I've been teaching at the university to biologists.
But I think like something that I did next. I started teaching because I had to do teaching during my PhD training. And I didn't expect that I will actually enjoy it that much. So that would be maybe like in the letter that is actually fun and I shouldn't worry too much about it.
I think that's the main message. And I really like that if something can go wrong it will go wrong. Yeah just like don't stress too much about it. I think that for me so I very recently I ran the first course where I'd written the material for the course myself. And I was like the leader of the course rather than just a demonstrator.
And something that would have been very useful to think a bit more about in advance is having loads of examples and loads of exercises for the students. Because to really get people to interact with things exercises are just that it's just so much better than just standing and sharing people things.
And we ended up having to like make up exercises on the fly which is really not great. So just having loads of exercises prepared would have been very helpful. Thank you Alice and everyone. I really enjoyed as you say like including lots of exercises and examples in your first workshop.
But as anyone that has any experience teaching you probably know that's lots and lots of things that you want to include on your first material. So this is a little technical but since we are on the PyCon conference. We have the documentation the Python documentation where there is like the reference for the language and so on.
So if you're going to prepare teaching material or teaching a workshop. What do you do included like what is never never going to remove from your course or something. And one extra thing that you're probably going to skip from the Python library or something that you're on material.
Do you want to start Alice? Yes. So I teach coding to scientists. And for them the most important thing is to get really using NumPy and doing plotting very early on. Because then they can relate it back to their work. And suddenly less important for them is learning about classes and object oriented programming.
Because this is a completely alien concept to them. I mean they can write perfectly good scientific programs without ever having to do any classes. And we suddenly found when we were teaching this is just a step too far for them. And they found it just way too confusing.
Yes. So in Code for Life it's interesting because since we were mostly for children. First we have to follow the UK curriculum because it's mostly a UK based program at first. And we realized soon that the most important things for teachers is to teach logical thinking.
And to help the kids understand that rather than actual syntax. So we put more emphasis on the coding concept. So that's why actually we start with Blockly and then we teach Python. So there are a lot of things obviously that we don't teach from Python. So not a lot of I would say most complicated data structures like dictionaries or even arrays are kept out of the loop.
Because it's not for the 5 to 11 yet. We don't really teach object oriented yet. But we do teach functions. We don't teach the other details like error management or things like that. So it's just about the algorithm, the logical thinking and how you can do that in Python in a very simple way.
So when I teach to life scientists or to research librarians I think it's like something between physicists and a child. So I think the physicists are much more advanced in terms of they have been introduced to programming before and they know something.
And life scientists are afraid to approach it. But they also, because they're researchers, they're really focused on what they will take away. They're investing time in it so they have to get something back. And that's why you can't start with introducing, I don't know, this is integer, this is boolean, this is the list.
They won't buy it. You have to start with something which is really eye-opening and like the wow moment. Show them amazing plots. Show them how you can very efficiently do something. And then maybe introduce a little bit of basics.
But actually just hope that they will come home and they will be so motivated they will start learning by themselves. I've tried in various ways doing it. But if you start with introducing, don't show them the Python reference. That's number one, I think, advice.
But show them amazing things that they can do and then they will learn from there. Thank you. I really enjoyed that you could make the comparison about life science and teaching to kids. So if you could go a little deep on that, it would be nice. So what do you think is like a big difference when you need to approach people in different ages and backgrounds?
Like kids or undergrad students, Ph.D. students, software developers? Any suggestions like motivate people of different backgrounds? Which approach do you think is interesting for motivate and explain better some of the concepts?
I think depending on who you're approaching, you really have to target your content. How do you deliver the content? You're teaching children, you want to make it fun. With researchers, the time is the most important thing they have.
They drive the research, publish papers, so they have to see what they get from it. I've never taught programmers or engineers. Actually, my title is eScience Research Engineer.
I've been working as a science research engineer for, I think, five years now. I still don't know what eScience is, and I'm not an engineer, but I do write research software. So I really would like to learn how to teach kids. I've never done it, actually.
Thank you. So yeah, indeed, making it fun is very important, but I think the key moment is probably making me grounded. So grounded to something that they might like, but grounded, I would say, in real life, or with a visual example, or even a sound example, like Sonic Pi is doing with TTGM programming with music. For instance, what we do in Code4Life, they have to program a van to go alongside the road to make deliveries.
The thing is, it makes it fun, because they see, oh, okay, so if I know about programming, maybe later on I can also program games like that, I can actually have fun. It's more like really a game than actually teaching. They just want to solve the challenge. And it works well for actually making them understand the logical thinking and the concept.
As I was saying before, that is more important for them than just the syntax. So for instance, in the first levels of rapid rotor, you only have a very small amount of instructions. They can use it like move forward, turn left, et cetera, and they have to program a very complicated rule.
So later when we introduce repeat loops, it makes sense for them, because they actually know that they need the concept to make their life easier. So we just grounded knowledge, and I think it works really well for kids. Yes, so I think definitely for physicists and mathematicians, they really just want to see that there is going to be some use for these programming skills at some future point.
So last year in Southampton, for the first time, we had a Python course for the first year mathematicians. And the biggest error was that this course was optional. And so after two weeks, the students cottoned onto this, and they just stopped attending the labs full stop,
because they were like, this isn't maths, I'm not going to use this. And the notes were written in such a way that it just didn't relate to their course, and they didn't think that they'd have any future use for this. So really, certainly for mathematicians and physicists, and by the sounds of it, basically everyone,
you need to kind of relate it back to their own experience, and show them that there's going to be some worth to what they're learning. Thank you. This is a panel, so if you feel that you have any questions, you can just come to the front, and then we can listen to your question at any moment.
But continuing this, if you probably remember from the keynote from today, she was recommended a video from a few years ago from PyCon, saying that most of the programs are made with Duke, and I think we as teachers, we also made with Duke,
so do you want to share any teaching experience that was not amazing? I think what is very important, I don't remember very specifically,
I think when I stressed out too much, and I wanted to make it too perfect, then it probably would go wrong. And I think the most important thing is, I don't have a good example of when things went wrong, but one thing, you have to be prepared that things will go wrong.
But also, I feel I'm in the same way as the learners who I teach. I learn so much during teaching, and every workshop, every event that I'm teaching, is the opportunity to learn.
So if the things go wrong, it's just so that I can learn how to do it better. And it's mostly how to troubleshoot things, how to deal with situations that, first you learn how to deal with situations that come up, and then you learn to deal with unexpected, or you get better at handling unexpected things happening.
So, again, relatively new to leading teaching sessions, and I ran a workshop quite recently, and I prepared all the material on my office Linux computer, but I was delivering the workshop on my own Mac laptop. And I was like, oh, all this stuff is going to work.
It did not all work. I tested all the hard stuff, all the stuff that was like live coding, I tested that, but the kind of simple stuff I had not tested, assuming it would work, and that was a massive error on my part. I think that, for me, the most things I took away from,
I would say really failures, but it felt a bit like that at some point. It's about always think about accessibility and what you can do better for the users that are in front of you or behind the computer. So, for instance, we did a lot of user research for our coding games with Code for Life, and we realized it was a good idea
that we were working on an iOS app for our game, because there are some kids that can't really use a mouse, for instance, so all the things that you need to think about. So if you have a real-life workshop, you might want to understand that it might happen. But more important, also when I was working for kids with autism,
with the Now robot, we had set up a big session in a classroom in Birmingham with the robot and all the class, with the kids and the teachers, etc. Of course, everything went wrong for us because of the network, so we were basically SSHing into the robot and trying to do a lot of crazy stuff from there, and we were sweating like hell, but it worked.
However, things we hadn't realized, our robot was speaking in American English, and there was a game where the robot was imitating playing football, and he was asking, which sport am I imitating? And he was listening to the answer from the kids,
and one of the kids answered, football. And the robot was like, no, you're wrong, it was soccer. So the kid is like, but, but, but, yeah, you were right, sorry. And the thing is that kids with autism tend to be very sensitive against social injustice and things like that,
so I really felt awful for having participated in that, so you need to really know that you will have to think about fallback and make the kids feel okay, that it's okay, it's not their fault, or it's fine not to make errors or things feel like too much of a failure, so it's more like, yeah, teaching practice.
Thank you. I really enjoy when you say about accessibility because most of the conference, just, I go back to your question, just one moment. Stephen, Stephen, come back to accessibility.
Most of the conference, they are trying to be inclusive and so on, and here on this stage, we have two vegans, one gluten-free, and one lactose intolerant. So do you have any recommendations for accessibility in terms of workshops or any teaching material, because I remember when I'm teaching,
and some of the things that I'm worried, like, make the font very big enough so everyone in the room can actually read without difficult, and do you want to start, Stephen? So, for instance, online resources or visual games, for instance, that would be pay attention to UX, user experience,
and details such as the contrast, so make sure that if you write something, it's not like dark grey on black, because sometimes it looks cool, but people just can't read it, and people can be visually impaired, et cetera. Also, if you have games with too much sounds
and different sounds and things like that, as well as visual, et cetera, it can be a bit distracting. So, for instance, children with autism might have a hard time not feeling stressed with your game, but sometimes, if they like one of the sounds, as the contrary, they will try, for instance, to fail so they can get the failure sound.
So, you might want to pay attention to that too. So, things like, of course, a mouse or a screen, try to find about different ways that you can engage with your materials. So, there are also other things that you can try, like board games that teach coding, so it not only has to be about computers or tablets, actually.
So, yeah, I would say just pay attention to that, but I will say the real deal is that try to understand what you might encounter, what can happen if you can talk to educators before that deal with, for instance, children. If you want to, or just the group of people you're going to teach
to understand if there are any such requirements and try to just talk with them to see how you can make them feel comfortable and adapt your materials to that. So, when we teach software carpentry, especially when we train new instructors, we want them to make an experiment,
like if they're going to organize the workshop to get from the airport to the venue with the wheelchair and see what is on the way, what all the barriers are on the way. And it's actually, sometimes we think, until we try to actually do it,
we don't realize how many obstacles there are in the way. So, we really have to make more effort, like do this extra work to realize how hard or not hard it actually is. I think it's a very interesting experiment. Actually, I've never done it, actually.
But, I think, just start thinking about it. So, I never did it with actual wheelchair, but just like when you start thinking about it, like how do you get out of this bus and get to the venue, I think it's really interesting. Okay, so this might be, as we have quite an international audience here, this might be slightly more obvious to everyone else,
but when I was an undergrad and before that, I was always in an all native English speaker environment and I just, I'd never really communicated or like mixed much with people from other countries. So, I was completely unaware that I naturally speak very quickly and I use quite a lot of maybe technical
or like less clear vocabulary that for non-native speakers is quite difficult. And I've noticed a lot in classes. There'll be some people, so there'll be people just starting their master's courses and then they've been in Britain for maybe two weeks when they get to their first class. And I start trying to explain things to them and they really struggle.
So, I remember there was one thing and I was telling them to type on them dot, so full stop. And they just didn't understand. I was like, dot. And yeah, so definitely trying to really make sure you use very clear language. And for me, yeah, it was a real eye-opener because I just was completely unaware of this
before I started my PhD, quite how difficult it is in terms of languages. Yeah. Can I add to that? Because that reminds me of one thing. So very often we, like when we try to help people with, so as an example,
we add the subtitles to help people with hearing problems. We're actually, without realizing, we're helping much more people that we targeted because of these cases. We have people giving talks with strange accents or like difficult to understand or with speaking very fast.
We'll help people who just, like, they can't keep up on the way. So I think it's also nice that it's wider impact. I'm sorry, I'm also thinking of something else. I would say also if you organize a workshop because I also participate in some meetups
and the struggle is also always to find a good time, for instance, for the events. So if you organize your events or your workshop at a specific time or day of the week, you might not get the same amount of participation that you might expect depending on who your targets are. So for instance, if you want to make something at like 4 p.m.,
you probably will never reach people that might be working, etc. So just pay attention to that. Thank you. Do you want to ask your question?
Thank you.
Do you want to comment? So I mentioned before that in Southampton we were trialing these first year Python courses. So the demonstrators for these courses were PhD students. And I think I'm probably the only PhD student in the maths department that actually used Python. So you had all the demonstrators for this Python course
and not one of them could actually do Python. So recently they actually ran a course to teach the demonstrators Python so that when these students turn up to the lab and have questions, they actually have someone there who knows what they're doing. Because otherwise they're turning up, they couldn't get any help. They were just so discouraged. I'm not surprised that they all stopped coming after the second week.
Matthew, so Celine, do you want to add something? No, I'm here. Yeah, in the front.
Thank you for the very good question. I think that one of the suggestions that you're going to probably hear from everyone is that I try to pair people that are more experienced with more novice, try to balance, but I go to pass the award for the audience speakers.
Do you want to? Yeah, it works even for children. Some of them will have different types of knowledge or previous knowledge. So if you pair them together, the child which knows more will also feel valued and will work quite well and the other kid will probably also learn a lot through talking to the other one.
So actually that works for heterogeneous levels even with different ages, etc. Yeah, so I also do that and it works really well pairing people the less advanced with more advanced. But also more general advice is you don't want to lose the novices.
So you really have to rather slow down and go faster. But then you're risking that you're going to lose people who are more advanced. You have to make them busy and you have to make them feel important so that they will want to engage.
So one way is making them, like mentoring other people or give them some tasks, like some extra exercises or let them make notes or let them comment or something on the materials that you have. So they have to be busy and they have to have something which is important.
It gives something back. So then they feel like they have a role here. And it's very easy to lose them also because they will get discouraged. There is nothing for them to learn here. So that's my advice.
Yeah, that's kind of what I was going to say. So just having exercises where it's like, oh, you finished this, this was easy. Now try this slightly harder thing. Because it's so easy for the more advanced students to get bored and just completely lose interest. And that's terrible because they're obviously quite talented so you want them to continue and be enthused by this.
So yeah. Just one moment, we have one question there and then we'll go to you. But are you going to comment? I wanted to add to that. So in Carpentries workshops we have helpers. So sometimes if the person is really advanced, just make him a helper.
Yeah, that works great. One thing that I thought Mate was going to say, but in Software and Data Carpents we normally give a pink and a green sticker for each one of the students. And we ask them to put the pink sticker if you have any issue, like, oh, something on this command is not working,
there is an error and I need help to solve that. Or, oh, I still need more time to finish the exercise. And the green sticker is when they are okay, like, oh, I finished the exercise. So this is very useful for us as instructors because we can go to one of the students that finished the exercise and say,
oh, do you want to try to make this other change? Of people that are already finished, they can say, oh, my colleague at my side, he needs some help so he can start talking. Do you want to add something about it?
Nope, so go and show the guy on that. Thank you. We're going to the guy.
Thank you.
Just one thing. I think the thing of who you pair with also depends on the type of the exercises that you're making. So I think, indeed, that's really good if you're doing something
when you know that there might be mistakes, et cetera. But if it's just trying to help someone solve an exercise and thinking about it together, et cetera, I think that actually works better. So it really depends on this type. Thank you. Can I add one more here? So I have a counter argument, actually.
So very often, like, I see it myself, very often if you have to explain, you think you understand something, you think you know well, and you try to explain it to someone and you realize, like, I don't know what I'm talking about. Or, like, I was wrong when I tried to think about it. Because you have to think about it much deeper if you want to explain it.
So that might help. But I agree with you that in some cases that might be, yeah. I'm going back to you. So I have an answer to that, actually.
So one way we try to avoid it, and I'm also guilty of that, yeah? So I have a tendency of, like, trying to overpower. So if I need to show someone something, I will try to take over the keyboard.
This is something that we never allow to take over the keyboard or never take over the keyboard yourself. You sit back and you explain to the person who's learning. And I think that this helps a lot with it. So then you have to adjust to the pace of the novice and you're not allowed to overpower, basically, the person.
Toni? So, yeah, as an undergraduate, I had these supervisions where you'd be put in groups of two or three and then you'd discuss your homework with a PhD student or a tutor. And for one of my computer science courses,
I was paired with a couple of computer scientists. And as a physicist who'd only been coding for a month, I was completely lost. The supervisions were entirely at their pace. I sat there feeling completely stupid, not understanding anything, and it was awful. And I had to go and beg to be paired with someone who was more like my level.
And after that it was so much better, but it was the worst experience ever. So I think that could have been helped a lot if the person who was leading the tutorial had actually encouraged me to speak up because I didn't get everything wrong. I mean, I felt like I did. But if I'd have been encouraged to actually speak up,
because I didn't feel confident speaking in front of these people who I felt knew everything, and I didn't. So really, if I'd have been encouraged a lot more, it would have helped. But yeah, there's definitely dangers of pairing mixed abilities in that way. Just one moment. Celine, do you want to say something? Something which is not related to teaching coding,
but teaching creative writing at the Ministry of Stories. So I was taking care of two children. They were supposed to work on something like creating a poem or a story about their pets or something like that. And one of the little girls was completely unresponsive.
She looked really sad. And I asked her, are you okay? What happened? And she just wouldn't answer. The other kids were not really paying so much attention to her. So it was quite difficult to just not make her work, but just really make her happy and think what was going wrong and what can I do to help her. And at some point, the other kids I was with
just started to literally take over. And since she's also a kid, it actually also made sense that she would do that so she wouldn't feel, indeed, maybe the distance with me, for instance. And she started to sit next to the other little girl and say, okay, it's fine. What did you want to write about? Your cat. Okay, let's start with that sentence. And she literally started the story
and the other kid got engaged into it and actually finished a pretty amazing story by the end of the session. So I was like, yeah, that's awesome. So it happened without me, but yeah, that was quite interesting. Thank you to raise that sometimes it can be dangerous to people when you pet,
especially when you're forced to be working pets. Something that sometimes we suggest is that people attend our workshop in groups, especially like universities or other community workshops because if you have someone that is your friend, maybe you're going to be less scary or more friendly to keep on the same pace
of the other people and enjoy. Do you want to comment on anything else? Who was, okay. Just get out. So the guy on the black T-shirt and the other guy and then you later. Yeah, so I would say for instance,
games and making them understand that they can hike into Minecraft or just help shape the world at some point by either creating website or creating games themselves or just related to something they enjoy. It really make a lot of sense for them
so they just want to go in and create something. Also, sometimes they want to do it because they want to impress their friends, et cetera, but I think it also works better in the long term if you can make understand those real life example. Sonic Pi, I was saying before, is also useful because the example is about music.
So for kids that also like that, they really learn concept and sometimes quite advanced concepts, even like threads and things like that. That actually makes sense when they start to program music with it. So I would say, yeah, things that are really grounded and in areas that they would enjoy.
So you can always ask them, like, what do you like in life? And you can always obviously find an example where programming might be useful and you can just try to explain. For instance, when I was a kid, I didn't know much about computing, but I was really interested in so many different things like archeology or art or also physics.
And I realized later that actually all those areas could be linked with computing because you could be a programmer and work in all those different areas. So it's just all the cross-domain possibility of computing, which is amazing.
So, Sir, your question, please. Great question. So for a workshop that I helped out with recently,
we had a survey beforehand. So it was a very short survey to try and encourage people to actually fill it out. So there were five questions, and it just asked what kind of experience people had, so whether they'd been, like, how often they did programming,
what languages they'd maybe experienced before, and also what they wanted to get out of the course, so kind of what they were interested in learning, because that really meant that we could tailor the course to their needs and requirements. Yeah, so for the Carpentries workshop, the survey is there. You can also just have some kind of questions
and do formative assessment to get an idea. I think it works really well. Now we have these applications with the clickers so that people can answer quickly A, B, C, D, and you look at the distribution of the answers, and you can adjust. So you start the workshop with ten easy questions, and you will have some overview of the levels in the group,
and then you can go from there. In Code4Life, we have something interesting in Rapid Router, which is still online and not seeing people, but actually we have coins that you can win after each level. So you can win a coin if you manage to finish the level, but you can win other coins if you manage to optimize it a bit.
So then all the teachers which are registered to Code4Life can see all the coins that their students have, and it's also easier for them to understand at a quick glance after a first session who's advanced and who's not and try to make that effort later on in the right direction.
Just an addition, I go to her and then... Just an addition is that sometimes it can be very, very difficult to just assess how much people know, because if you have something that's very long, people are not going to fill the survey. And if you have open questions,
like you don't get the answers that you want, for me something that was very useful was like if you have breakfast before the workshop where people come, then you can start to talk with people and at least you ask a few questions and then you can have a better, not 100% better,
but you have idea of what was previous experience from people and so on, so you can prepare a little of yourself, what are your expectations, and what are the expectations of people that are coming for the workshop. Do you have one more thing? So I think one advice is if you have those questions for the assessment at the beginning,
you have to be very specific in those questions. So you ask about specific things, because first people are very bad in judging how good they are and the novices don't know what they don't know. So they really... If you want to get some good idea, it has to be have you ever used the terminal window
or things like that, then they can answer. Sorry, I think it's also like... I don't know if you were at the keynote by Tracy Osborne, but there was some very interesting there also about the fact that it's not just beginner, advanced, et cetera, but it can be a lot of different topics, so I completely agree with that. For instance, in Rapid Router where we teach different concepts
like if statement, for loops, et cetera. I say it's quite easy to see with the coins you earn which concept you might know or not, and it's really like that, a drop down of the concepts and understand which one they understand or not, and then trying to understand how you can really teach that notion. But not just, yeah, are you good at Blockly? Are you good at Python?
The kids are like, I don't know. It's normal. Thank you. So we go to the lady at the back, then we go into you, and then you.
Matheus or Selena, do you want to...
So first I think it really helps if the group... It helps if the more heterogeneous they are, the better, because then you can always fit in to different target audience. And I think the other thing is,
I hope it answers your question, but we try to... We think that the best for teaching are actually people not very advanced. So it has to be people who are not novices anymore, but they still remember how it is to be a novice, and then they don't feel too competent, let's say.
So they have to feel competent, but they still remember, and it's easier for them to put themselves in the shoes of the learners. I think that helps really well. So at the Carpentries workshops, we invite very often people who just did the workshop, and we see that they're more advanced.
We encourage them to go forward and become instructors, or maybe first come as a helper, and then the second time come as the instructor. It's very easy to forget when you get too advanced to forget how it is, and what kind of questions you had, what kind of challenges there are. In the Ministry of Stories,
we also have something that we do at the beginning of a session. We take the exercise that the kids are going to make, and we try to apply ourselves to it very shortly by drawing something in relation to the theme. So, for instance, it's just a nice breaker that we do at the beginning of the session with kids, and we do it also ourselves as the adult volunteers,
and then we show the kids what we have come up with. So that can be, for instance, draw a building, and at each floor you put your favorite books or things that you liked about some books, et cetera. And we all are very actually keen to do the drawings ourselves, and we tend to be pretty dedicated to it. But then, in the end, it's also the kids know
that you have done it too, that you are just not above that, and that it's actually not a dumb exercise, for instance. So it also helps to put yourself in their shoes and try to spark your own creativity before. So I think teaching the teachers is definitely important. So, I mean, Software Carpentry,
before you become an instructor, you have instructor training. And the material from there is like from a more educational perspective, so it's people who know about education and know about education concepts, and they teach you all of these things. And so, yeah, at Southampton, before I did any demonstrating, we had to go and we had to do a course,
and it was taught by education people. And, I mean, I hated it. We all hated it at the time, but it did at least, because we were like, we know how to teach, it's easy. But, no, I mean, it did at least make us think about different things that you wouldn't otherwise think about, so how to deal with like less able students
and mixed abilities and stuff. And so, yeah, definitely at least trying to teach the educators a bit more, I think, helps. So this is something that the Carpentries, we really think like we want teachers to learn from each other. That's why we never teach alone in the class.
There is always other teacher, we learn how to get feedback on the teaching. Every workshop, after the workshop, we sit down and we discuss and we get feedback from helpers, from learners. We collect the feedback from the learners and we try to improve teaching. We believe that teachers are not born, they're made.
Like you have to, everyone sucks at the beginning. Like the first lesson you suck and you just, that's, and you improve and the next workshop you're better, the next workshop you're better. And you learn what you suck the most at and then you try to improve that and you learn from other learners. We try to, I try to teach always, like always with the new people.
So I like going to other places for the workshop so that I can teach with someone else and learn their style. Everyone has his own learning style. There is no one way of learning, of teaching, yeah? So everyone teaches in some other way. They have their style and, yeah? Hi.
Okay, sorry. Not really. I fear blowing up the computer.
If you understand, if you have them, write those down and then let people know how common all of those fears are and let them know you're not gonna blow it up. I'm trying, somebody mentioned that after Tracy's talk and it reminded me. Yeah. It's really helpful for them to be able to get
over those fears and see how common it is so that they can then let go and learn other stuff. Thank you. Okay, so I'd like to get your opinion on
when we talk about the Python programming course, do you introduce version control and at what point do you, what's your experience on that? So I think you can never really introduce it too early. I mean, from my experience,
I didn't learn version control until I started my PhD and at that point, I'd done quite a lot of programming. I'd done a whole master's project in C++ and really suffered from not having used version control. It was awful. I mean, I feel once you explain to people how useful it is, it's really,
it's not that difficult a concept. I mean, understanding how Git works, that is, I mean, I have no idea. But definitely just using basic version control, it's so useful. I really think it should be introduced like lesson one. Did you do that?
I mean, yeah, I don't design the undergraduate courses. If I did, I would introduce it earlier. I don't think it's actually even in the curriculum at the moment, but now you've said that I might have words because I know who writes the courses. No, just that I was actually thinking after you took actually to add some things in rapid router
to teach the basics of version control to the kids because right now the only thing that they can do with their code is save them. So they can save the workspace, which is, for instance, they can start a level and save things, but that's it. It's just the same name, et cetera. But maybe we can find a better way to teach them
and still not being left to drive, but yeah. So version control is in the core curriculum for Software Carpentry. It's not for Data Carpentry. So yeah, we try to teach. I find it very difficult to sell.
One thing that I always show, I don't know how many of you are familiar with the PhD comic. If you have a research background, you probably do. There is one cartoon which is when they send, so there is a PhD student and a supervisor and they send by email the PhD thesis back and forth and it's like version one, version two, version 2.2,
version final one, version final two, and in the end it's like a few lines of title and they ask, is it familiar to you? And then that's why we have version control. But it's super difficult to sell. How I try to do it now,
and I think a lot of people will not agree with me, but I'm really happy that there is GitHub with the user interface where I can show researchers. So GitHub uses Git in the back. You can use it like this, and I sell it as a collaborative tool.
So this is how you can collaborate with your other researchers. You can set up a website with two clicks. You will have your personal website. And once they learn that, I hope that they will start learning what is actually behind the Git. And I know that not everyone agrees
because people think we shouldn't be showing people GUI. Yeah, show them hardcore terminal. But I don't think it works. It just doesn't sell. So this was a personal experience for me. I teach Git a few times. And most of the times I was using just one file,
so I have like one readme file, and that's a markdown file, and we started writing some things, and then we commit, then you go check out, then you send to GitHub, and so on. So learners, they just get usage throughout the Git crypto command line interface.
But there was one student on the last workshop. The student, she asked me, so I still didn't get how useful is Git, or why I suppose to use that. And then after talk with her, I understand what was my mistake. My mistake was that I was only using one file.
Because if I have only one file, probably I don't need to go back to the history. It's just one file. Or I can just save with a different name and it's going to be fine. But then, if you have experience as a Python developer, or just doing program in any other language, you know that's not going to work that way.
Because once you save the file with a different name, then you need to change all your imports. So in case of having import foo, now you have to change all your imports to import foo two, import foo three, and so on. So then I learned my mistake, and the next time I'm going to use at least two files
to make that learning difficult, much more easy for the students to get. But yeah, I think that it would be nice to introduce Git at the very beginning, but still quite challenging, most because as completely novice that someone that never programmed, they don't see the advantage very far or very soon.
Do you still have a question or comment? Yeah.
I'm not sure if I understand your question. Can you rephrase that? I think that it's very difficult to say that
because it's a personal choice, I think. I don't have any design skills. If I need to paint something, I'm very, very bad. But I think that maybe if I want to start to work hard
and improve my code, but it's going to take time, so it's like how much time I want to put that and trying to make it better, but do you want to comment? So yeah, so in first year undergraduate courses, quite often you see people who they really struggle. So in the first term, they're struggling.
You see them every single session. They turn up to every session, and they struggle so much. And you kind of wonder, is this course for them? Should you really maybe talk to them? But I mean, in my experience, in my first year when I did computer science, I struggled so much, and it was just the course was pitched wrong
because I didn't have the same background as other students, and it just all went slightly too fast for me. So I kind of knew that, and I mean, now I write code. I program supercomputers. It wasn't just that I was not a good programmer. It's just the course was wrong for me. So when I have students like that, I really just try to find other materials and other approaches to learning out there
that I can point them to because it might just be the course is not for them, and they need a slightly different approach to learning these things. I agree. I think this also relates to today's keynote. There are so many different ways to it,
and on the other hand, I also think this is not a programming problem. There are people who are very determined to become great cooks, and they will never become great cooks. And first, if they're so determined, probably if you tell them that they shouldn't, they won't listen to it anyways.
But I think in the end, this is so heterogeneous topic, word, and so on. There are so many different ways, and also we have so many stereotypes around it that maybe they just have to find their own way of programming.
They will be amazing at it. Why not? I don't know if you were on my talk on Tuesday, but I was talking about Agat, who is a friend of mine and my boyfriend's best friend. She was taught when she was young that she could never be any good at math or programming,
so someone told her that because she was a woman, but someone else just because she was not any good and nothing would happen because she was bad at theoretical mathematics, and they thought it meant that she could never be a developer. I guess, well, she's a developer now, and it's just also this idea of grounded mathematics or grounded knowledge that works.
for her. So just also remember that the memory works also in different ways. Some people have a visual memory, some more auditory memory or feeling memory, etc. So I think sometimes yeah it's mostly about the different teaching approaches that might work or not work. But I wouldn't dismiss someone as it's not for you right now and also it's awful
when you hear that. So that's just. I got all the hands so we're going to the guy there, then you, then you, then you. Sorry to try to control the room too much. I just want to second Alice and there was on the keynote she was saying I'm a visual learner and sometimes this is the case of your friend.
Most of all the courses they are trying to teach you with videos or audio or just stacks and sometimes you need like more visual things to learn. And this remembers me like when I was on my undergrad doing the introduction to calculus and there was mostly two books
that people was using. There was one book that was calculus almost for dummies and there was another one that was like calculus for PhD students or post graduate students. And like depending on which one of the professors that you have the course, you just pick
one of the books. And even if you have like all other suggestions, readings but that's the course of the book of the course. So like you more or less need to read that and sometimes you struggle because you're not on the extremes, you are on the middle and then you don't know like sometimes is the day that you feel very good because
you did the exercise or sometimes like I spend two hours, three hours almost a day trying this exercise and I see you on the step zero. So yeah. Do you want to comment? Yeah. Just also something that teachers say they like most about our Rapid Router game
is our levels which are pluckly to Python because it's a very visual way for the kids to have next to it the graphical programming of Pluckly and the text programming of Python. So when they add a Pluckly block, they can see directly where it's going, what it looks like in Python. So it's just a way to introduce them to Python without going straight to it for
instance and they can see that it's the same that you just the concept expressed differently in a different language and they have this like this visual thing going on so yeah. Thank you.
I'm still really interested in ways to learn or ways to help more people to learn. There's a very good book called Seven Ways to Learn, Seven Tips for Learners. I can send you other required names later. Yeah so this is one of the things that we try to show is that you can make mistakes
and actually like you learn through mistakes and we so we actually like making mistakes when we teach. We make a mistake and we say oh I have an error now yeah and I explain the error and I take the opportunity to actually teach more through the error but
I also introduce that there is nothing wrong like errors are normal that being like making mistakes is normal like computer doesn't explode, everything is fine and it also applies to others so I think this is the whole topic of like the fears of people. This is like if you want people to learn you have to first challenge
their fears and one of the things that I have with researchers I'm a big fan of open science, open research, collaboration. Researchers are like some at least are very afraid of like making the research open. They're afraid they'll be scooped whatever and or that also translates to like when they start
programming they'll be afraid of putting their code out there on GitHub and then we show them okay so you put your code on GitHub and it's like the word didn't collapse like it's all fine it's not like everyone immediately looked at your
code and got angry about like at you or something no it's it's fine it's okay so I think this is something that you can try just to show that it's not it's fine. Yeah so something that I notice in the undergraduate courses is you get some students and as soon as they're stuck they put up their hand
and like every five minutes I'll put up their hands because they just don't know how to search for answers so I we teach using spider so I really I always try to show them like this is how you find a documentation then I explain to them this is how you read the documentation because if you've never seen it before it's not that great and then I show them how to like
play around with the terminal and like try out different values to really explore how things work so yeah definitely teaching people how to find the answers themselves is definitely a valuable thing to teach and include sorry you and different you had a question go yeah so on the back yeah are
you on the green t-shirt thank you are you and then you on the black one
just yeah yeah okay
it's having a problem maybe he's not the one that's sitting there and
maybe he wants to walk away have a nice dream and then he comes back with the best solution that's what I do
I agree with you sometimes you just need to stop thinking about the problem any comments yes so speaking of which were so so we teach children but we
also have to teach the teachers first rights because we our games are mostly using coding clubs and mostly schools and sometimes the teachers themselves are the one which actually are not confident with their skills they don't
know sometimes why they have to teach coding is just because the UK curriculum says they have to but they don't necessarily see the point themselves I think the kids might be better than them and usually it's actually the case so they actually all their fears they're speaking of fears they have all of them so that's why we're trying to also break down
all the exercises to make it sound like it's not magical I think it's important because this like at the keynote this morning so something like you want to look like you're an expert and bla bla bla at some point if people think that is an area they can never reach into there's a problem so for instance in my team we have a UX designer which actually has some
front-end knowledge but he stopped becoming stopped doing programming because he didn't feel confident at all and also he felt that programmers were people that knew magically about everything and every that they knew all the syntax of every programming languages and they could just code
magically and at some point we were talking about something because we needed someone to help review some front-end and I don't have a lot of front-end skills and say James you do have some front-end skills can you look at that I was like yeah but you know I'm not really confident to say you know more than I do say okay fine but I don't know about that okay sure let's Google it and we say okay you actually just program
using Google yes and he said yeah that's actually a good thing to learn is that it's not like a mystery and we all like to appear like we know everything but that's not true we like to program with Stack Overflow and Google like like everybody and just demystifying it it's also a good way to make people understand that they might not be afraid but yeah this
breaking down for things you also work for for teaching the teachers there is very nice term demagification and this is basically what we want to do we want to show there is no magic behind it yeah like there is
it's it's simple you have to break it down and this is how it works and people who do it are not magicians they're just like humans like everyone else yeah and they learned it through making mistakes yeah so one thing that I find really useful to see is live coding examples because you're gonna make so many errors and so many typos and possibly even just get
completely lost and have to Google something at one point and it's so useful seeing the people who you think are just like magicians and know everything they also make mistakes too so I think that's really helpful to help thank you you okay on tooling okay thank you very much I think for your
second question about the feedback one thing that you tried to do is like
ask people to feel the feedback when they are still on the workshop room because this increase the numbers about the other question I don't have any magic bullet for you but I can't replace if people have any good experience how we gather feedback in this is my with some friends but we
there is something that we use a lot in software carpentry workshops these are the post-it notes and we use them like Raniere mentioned for to see for example if people need help then they put the pink sticky or red
sticky and the helper will come over and without disturbing the whole group will have solved the problem if we want to know if people solved all the exercises or like are up to speed they put the yellow sticky but we also do we ask people to put feedback after the workshop on the house so they
put positive feedback on the yellow one and the negative on the on the big one but the thing that works the best is one up one down we call it and it's we ask everyone in the group for feedback but we ask one person for positive so the good thing and the thing to improve is the next person
but they're not allowed to repeat after them after the previous person so after a while you come up with like more deep things and they can't escape yeah so the like we're not going to let them leave the room before they give some feedback yeah I completely agree with that it works well so in
software teams actually we use things like retrospective after those prints and I did once a thinking hat type of retrospective where at some point you have ten minutes and people are forced to only say negative things about how it happened I could see my team starting to melt down like I don't want to say
negative and actually that's how we get the most useful feedback to to help us grow as a team and work better so yeah completely agree with that just another point on feedback so we are programming online game so it's quite difficult to just see people interacting so we put a lot of emphasis on user experience and
having a user researcher in the team that will talk to teachers to kids to understand how we can make things better so just continuous feedback really but yeah it's quite difficult to do that because sometimes people just won't say bad things to you so you have to say before like even you lie and you
say I didn't program that you can say if it's shit and they were sorry but well they will they will they will not necessarily tell you so you have to pay attention to that so that's why anonymous feedback can also work so if they put their comment on post-it notes at the end of the session without you watching it they might be more honest yeah yeah so I think it also
helps to rephrase it instead of having positive and negative it could be what went well and take a look at for example and it's much easier to say something take a look at then I'm going to be negative now and tell you
yeah and question I just say so for undergraduate lectures they used to hand out feedback forms and it was like at least two sides of paper and I like bring it to the next lecture and hand it in or put it in this pigeonhole on the other side of campus and I never did that it's just like no I think the
only times I filled it in was when I had really awful lectures and you just be like this was terrible I learned nothing you were awful so yeah just making it really easy and having like limiting the number of questions so if you want to find something out kind of prioritize and only put the really important ones because people are lazy and they're not going to tell you
things unless you make it easy for them I know that we have two questions there but we are almost out of time so I'm going to ask you have answer your two questions over lunch after the talk sorry okay yeah when I'm
organizing try to pass all the feedback to anyone that's helping me just to
connect with your question and try to finish this as we know there's many groups worldwide are trying to develop a license to its people but this collaborative part of developing the lesson can be quite challenge so this is going to be my last question to all the panelists if you have a
magical lamp and the genius is going to give you one wish how to solve or improve how people develop and lessons collaborative what are you going to ask for the genius okay so what I what I would ask I would say like stop
people from writing their own lecture materials that they keep in their shelves this is like the most like this is so much time like the time in the
world it's wasted for like you have all those lectures they will prepare the lecture that will get outdated the next year they won't share it they don't yeah like no one can reuse it I think this is super way for me would say also something to help you put your ego away a bit when you're
teaching so some people can without noticing they might sound arrogant etc and that's also we're talking about the fears but this fear can be ingrained if you hear your teacher saying things like oh yeah that's not real programming but we'll do that after or hope we did you do that or sometimes you can't catch yourself doing that but that's good if you try to put
your ego away and to make sure that you don't sound arrogant that you sound inclusive that you don't judge what people have been doing because then that just probably is why people fear of being of looking stupid okay so there is a two announcements what time is your open session today 2 to 2 45 and
then there was another open session for education at what time so if you
want to continue discussion there's two open sessions just look on the board and then how and a round of applause to all you that was our audience and
just make this panel much better thank you very much