 Thank you very much. Thank you very much for coming. How do you all like Berlin? Great? Slides don't advance, shit. Now, how do you like Berlin? Yeah, great, cool. So I've been to a workshop last week of the Open Tech School, that's where I'm a member. And the Open Tech School does workshops for teaching absolute beginners to programming, programming how to program in Python and other languages. How we do this is we gather a bunch of people, among them coaches who are knowledgeable Python programmers who know how to program, and learners who want to learn how to program. They have very different backgrounds, mostly non-technical people. Then we give them material in digital form mostly, so websites they can browse. And two hours of time to browse and work on the material and the exercises. So last week I was on such a workshop and was walking down the streets afterwards. And after the workshop I reached some kind of funky place in Berlin, and I saw this. And said, I was like, what? Why would anyone, I mean, this is one style guide we all love and adhere to. And yeah, you can take pictures, I can show you afterwards where it is. Maybe. So somebody apparently was very set up about Python style guides and adhering to coding style. So I took a look at the Python material we currently have, like the tutorials and stuff. If you look at the very official Python tutorial, it starts off with talking about calculations and stuff, and how do you add two integers to each other, how to do a basic algebra. It stops with some funky stuff about weak references, and that's pretty advanced for a tutorial, but okay. So I scrolled through it, and what do you guys think, where does it talk about the immutability of strings, for example? Just random guesses. To the end, to the middle, beginning? Middle, I hear middle. No, wrong, wrong. It's at the very beginning. It's the third chapter, actually. Right after talking about how do we add two integers, they go about talking about text and strings, and how do I do raw strings and escapes, and how do I repeat literals of strings, like some arcane features not even experienced Python programmers ever use, and the Python tutorial just goes about and talks about that in length and very detailed. It gets even worse at the beginning of the tutorials. The very first sentence you read in the Python tutorial is, hey, you can start the Python interpreter with dash m to import a module, or dash c to invoke the command line, or dash i to do interactive sessions. And if I gave that to a beginner in our workshops, they would be like, dash what? Nobody would understand that. I had a look at Stack Overflow, so there was some guy asking, hey, I'm trying to teach my brother or sister or someone how to program, and he wanted to use Python, and he asked about what is the best example project, example thing I can give them. So what do you think? Where would you start with a beginner? Any guesses? What? Turtle graphics, pretty good. Anybody else? Databases, yeah, just shout out loud. Yeah, for kids, that's pretty good, yeah. Do you know what Stack Overflow is like? Yeah, just teach them FizzBuzz. FizzBuzz is a nice interview question, but why would anyone teach a beginner how to do FizzBuzz? I mean, having Hello World or FizzBuzz on your command line is pretty nice, but not the best thing to learn programming, right? And the trend continues. If you look at the Python books which are out there, like the material universities have, for example, the MIT starts with object-oriented programming. This is the MIT SICP 6001 course. It's very beginning to programmers, and they start talking about objects and inheritance and stuff. So that's pretty funky. So what you can observe is that the general trend in the Python community is to write references. So everybody wants to be a reference. Like everything needs to be correct and very, very right and very Pythonic and stuff. And I understand that some people react very badly on this. So if you take anything out of the session today, they said references are not tutorials. These are two very different and distinct concepts. I would even say they are disjoint. And do not intermix them. These are very different and require a different approach. So everybody speaks up for me. References are not tutorials. Very good, very good. Great. You're doing great. Best audience I have ever had today. So I tried to come up with some points like what would I say is a reference and what would I say is a tutorial. So in a reference, you try to be very correct. Like every single thing you say should be correct. There should be nothing where somebody could come and say, no, this is wrong. Like this is clearly not true. Also in a reference, you would always try to be complete. So I can well understand why the Python tutorial went about and talked about strings in depth, because it was a reference, right? It tried to examine strings and it tried to tell you everything. It knows about strings. You can slice and dice them and you can count how long they are and all that kind of stuff. And also most Python references try to be idiomatic. So for example, if you wanted to introduce loops to a beginner, then you would not want to introduce while loops and with index variables and stuff, but you would want to use the for loop with a range function. I think this is the wrong approach for tutorials. For tutorials, you want to do a very different approach. You want to be comprehensible so that people can actually understand what you're talking about. You want to be coherent so that there's a fine thread woven through the whole tutorial. And sometimes you want to be idiotic. That might sound strange right now, but I'll come to this in a second. So let's talk about these points in depth and you'll maybe understand where the distinction comes from and how it makes sense. So I said tutorials need to be comprehensible. So one point I always try to make in tutorials is that it needs to be graphical or it needs to be hands-on. You need to see something. You need to feel something. In the open-text school, we use turtle for that. So somebody suggests a turtle for teaching Python already. That's a great tool. Use it. You can, I mean, most of you know turtle, right? Quick show of hands who knows turtle. That's about 90% of the room, I would say, on 99 or something. So turtle is a very nice tool for teaching Python because you can instantly see stuff and you can get instant feedback, which is very great. Now, some people come to me when I suggest using turtle and they say, oh, Robert, listen up. I know turtle is pretty nice and it's very old and people know how to use it, but it's so childish. Nobody wants to use it. This is for little children. Why would I want to teach this to adults? Which is always when I say, no, it's not. So experience has shown that when we show the turtle or turtle material to adults, they react like this. They go, yeah, it's pretty childish, but let me play with it. So they spend two hours playing with it and instantly forget it's for children. It's very funny. Another thing to be comprehensible is using their language. This applies to any tutorial, not only Python tutorials, of course. So that you don't speak about objects in the very beginning, but maybe you want to use things instead because people can understand what the thing is. The thing is maybe a car or a person, but an object. This is a very abstract concept. Try to use their language, not your concept of the world. Another thing is to use their language. So in the Open Tech School, we translate our material and this might come very obvious to most of you, but very few people actually do it. Like translating tutorials is still something I would say very few people do. And it's pretty important because you can do a lot of things wrong with it. So the one time example about translations I always have is culturally. So when you talk about, let's say, buying something for US dollars, then it might not be obvious what that means to Chinese people, or to European people, for example. So you want to translate that as well. It's not like only one-to-one translations. Other things you have to watch out for is that using markup in translations is very hard. I can only recommend things for that, but disclaimer, I'm involved with that. So use whatever you want. And the last thing about translations I want to say is try to have one master set of translations. We've had translations where we had like a German version and an English version and they kind of diverged and we had two different versions and we didn't know, okay, this fix was applied to the German one, but was it applied to the English one? I don't know. So try to have the English or whatever language you prefer as a master set of translations and always apply fixes to that and then translate them back into the other material. So we've spoken about how to make material comprehensible, like the individual units, but how do I make it so that it's a whole different story, like one thing. So very much like in music, you need to have something which is the main voice of it, right? So you need some kind of story which you wrote through it. So that is not only in the material itself but also in the process of making the material. We've had material where we had a lot of people contributing to it, so to say a lot of voices, and it kind of got very noisy. So the material diverged into very many directions and tried to have one main voice who says, okay, this material goes into that direction and this is out of scope, this is in scope. One thing we program as very rarely think about that is when we write Hello World or when we write any example in programming, we very often have a big context of concepts around it which we program as don't think about because we know it, but other people have to be told what to do, like which editor do I use, which encoding do I use. This is not obvious. This is also very easy, like you can tell them use whatever editor, but when it comes to other questions like which version do I use, people tend to say, yeah, just use free or Python 2 or whatever makes a decision. You are the informed person who can make the decision, not the learner. The very critical thing I have seen learners struggle with is the distinction between files and the shell. So when you have the interactive shell, it's pretty nice for trying things out, but you want to have one point in the teaching process where you tell them, okay, this was nice, let's go to files because it's much better to maintain that stuff, but have that one point. In our material in the Open Text School, we made the error that we kind of left it open for the learner to decide at which point in time they want to switch to files. So you never knew, does that learner already know about files? Why does he use them? Does he use them? You never know. So pay attention for that. It's a very critical distinction which we intuitively make, but normal people, so to say, don't. The last point is probably the most confusing and surprising one, but I think tutorials sometimes need to be idiotic. So when you think about, I use this idiom and this style guide and whatever, and the one true right way to do it, forget about it. It's all bullshit. I've seen people suggest very true stuff in the sense that it is sane for a programmer but not for a learner. For example, take this suggestion. We had one material which was about data processing and it needed to open and close files to read from them, and somebody came along and said, huh, well, using the Open function for files is not the best way to handle it because you can leak resources and stuff, so let's use the with construct, which is a very true objection but is not helpful in the context of learning how to process data because opening files was not the main context, like it was not the main goal. People wanted to learn about data processing, not the with construct. This was not the objective. My favorite exercise I always do with beginners is this one. I give them the exercise draw a rectangle and they will happily oblige by writing code like this. You move the throttle forward, you move it to the right and do that four times and then you have a rectangle. And then I tell them, okay, that was great. Now draw three rectangles. So they will go and copy and paste that code so they now have three rectangles, which is very good. And then I come, I'm being very mean here and tell them, okay, now resize the rectangles, make them twice as large or twice as small as they are. So the learners having copy-pasted this code need to go in and adjust every single orange integer you see over there. That's about 4, 8, 12 integers, if I'm correct, which is very painful and not a nice experience for a beginner, which is the best moment you have in the teaching process to introduce the false statements because you can tell them, yeah, you would not have that pain if you used the false statement. It's pretty great, use it. I always call that the no pain, no gain strategy to teaching because if you try to let them go through that little pain, you can adequately teach them how to use the abstractions and to value the abstractions you're actually trying to convey. I hope I got across the point that tutorials are not references to you and that you need to be comprehensible, coherent and sometimes a little bit idiotic when trying to teach people Python or any programming language. Thank you for your attention and I'm open for questions. Okay, thank you so far. There's one microphone over there. Oh, wow. At which point do you explain the difference between the reference model of Python and the way C does it for variables? So, because most of our audience is non-programmers, we don't have to explain the difference. We can just explain the bare concept of references, right? And the metaphor I always use is using sticky labels so that you put a sticky label on an object and then it has that name. The point where we do that is pretty early on in the material when we talk about variables and variable assignment. So that's the third chapter or something, it's pretty early. Because if you don't have to compare it to C and like this is a memory slot or something, then it's pretty easy to get across because you only say it's a sticky note. Very good question. Next? Yes, thank you for your talk. I was curious about the problem I'm faced with in general. That's the self-learned helplessness problem I think in teaching in general. But software development in particular, that there's a lot of fear for the, oh, I can't do this. This is only for the beta guys, the geeks. And now it's popularizing and what's your opinion about this? And maybe it's a general discussion within the teacher environment of software and development to overcome that problem of the scariness of people. Yeah, very good point. I'm afraid I don't have a very good answer for you because people just sign up for our courses and apparently those people are already motivated enough to do that. And they seem to have a non-technical background, so I'm not sure I know what is the reason for that. But if you, so I've had people, I've talked to people and told them just try it. Just give me this two hour workshop to try it. And then most people will come out of the workshop and be motivated enough to do it. Which is also a very critical point because I've seen people like, when people prepare a workshop, most people are like, I need to explain them objects and loops and inheritance and everything. Don't try to do that if you want to motivate them. Like, only explain the very basic stuff you need to spark some inspiration in them. That's something we always do. Like, the beginner course does not go into objects at all, I guess. Because we just want to spark motivation in the audience. If that is an answer to a question. Yeah, thank you very much for the nice talk. I think it's super fun to teach Python. So I do it myself and I have two questions. The first one is, do you have any personal experience with using IPython notebooks for teaching purposes? The answer is no. Okay. Good. Because I think it's a great... Let me, so some people in the Open Tech School use IPython and apparently they are pretty successful with that. But I can't say anything personally because I've not used it for teaching, so sorry. Okay. And the second one is, how much time do you actually spend on explaining syntax? Because Python is very simple, like syntactically. But in my experience, when people have never programmed before and depending on what language they actually speak, it is a very difficult thing to explain that now everything really matters. You can't just switch things around, right? In some languages, the sentence structure is completely flexible. And in English, it's often quite flexible. So people think that if I turn things around, it should still work. But in Python, it's really important that, yes, if you initiate a forelook, you need this colon at the end, right? And there need to be brackets around functions, these things. That's an excellent question. So we don't actually do any syntax explanations to them, like going through all the syntax at once or something. We just tell them you need to write that in order to do that. So let's, for example, take the for loop, right? We show them a very simple for loop and then we tell them, okay, now do the rectangle example or something. And my guess would be that most people are, if afraid enough of computers, that they will just write what you told them to write in the beginning so that they know, okay, every single character was important. When they miss a character, they will just get a syntax error, right? So that's not too bad because then they will either fix it by just seeing the syntax error or they will ask one of the coaches and we can tell them, okay, listen up. This is a computer. He needs to understand you. You need the colon. Like everyone said, thank you for the talk. I had a question about, because I organized a couple of Python tutorials and some went really well and some went catastrophically bad. And the one which went really bad was because I got asked a question and I kind of was stuck between a very easy answer and a very comprehensive answer. And the question was, okay, you've introduced us with this for loops and if, but what do I want to do software designed for? Because I don't need a for loop. I want to do HTML. So I was basically stuck with having no answer to this person who was attending a software development seminar without knowing why she was doing it. So in these kind of events, you basically sometimes have to convince people that you have to explain to them why they need or why they might want to learn software design and software development. Sometimes they don't even know why they're here. And I feel that a lot of beginner tutorials do not even cover the, like, why would you even do Python or software development? And so I don't know if you have an idea about that or... Yeah, that's a good point. The one reason I would say people don't ask that in our workshops is total. Total is the single best teaching tool ever because they instantly see what they are doing and they are intrigued enough by that kind of graphic, graphical feedback that they will stick to it. So total seems to be very powerful in getting people to actually wanting to do that stuff. So maybe you just try total and see if that gives any... Immediate feedback. Exactly. So just for the recording, he said that immediate feedback is important. And yes, immediate feedback is the one single best thing I would say you can use in teaching. Yeah, so talking about error messages and reading errors when you have a syntax error, what I see from a lot of users they don't know, if you're new users, how to read an error message and you talk about translating, it's not just that it is in English but there are words in there, this error message that they don't understand like attribute, method, function, whatever. So how do you approach this problem? The simple answer is just ask them. Very often I see the interpreter explode in front of people's faces and they're like, oh, wow, crap, this did not work. I'm out of here. And then I just go to them and ask them, hey, do you have any clue what just happened? What does it say? And then people will start actually reading the error message if you ask them what just happened. And that usually helps to get them trying to understand what the error means. And if you then ask them to explain to you what just happened then they will kind of dig into it and try to understand the errors at hand. Do you take people past turtle? So turtle is a great teaching tool that teaches the syntax of the language and it's fun. But at some point somebody's going to want to apply that to a real-world problem and I wondered how you bridge that barrier between drawing pictures and searching file systems and that kind of thing. So I think, did I understand the question correctly that you were talking about real-world problems and turtle? Moving from turtle to real-world problems. Yeah, sure, sure. So the question was how do you move from turtle to real-world problems? And that's indeed a hard topic. So I spoke about motivation, right? So what we use turtle for is mainly the motivational part. So to get people to like this programming thing. And you are right that turtle is very limited in what it can do in a real-world use case. We sometimes use very simple drawing problems like you want to draw a nice, let's call it animation, right? Very contrived geometrical figures. But this is where turtle stops you, right? So turtle is useful in getting people to understand the concepts. It's, I would say, not too useful in getting them to work on a project. That's very true, yeah. Thank you. Okay, one more question because we have to switch rooms and stuff and you can meet the speaker, I guess. Yeah, sure. Hi, sometimes I have to teach people, of course, the programming or stuff close to that and there is one guy who has this model of thinking that he's learning that way, sees a solution and he tries to repeat it. But of course, in this particular case, abstract thinking is really important so this kind of behavior is not successful. But it's really hard for him to overcome this model of thinking. Have you ever met such a person and if you did, how did you help him to overcome this very settled model of just repeating solutions instead of finding analogies and thinking abstract? So the question was how do you help people who have a very different model of thinking to adopt a new one? So there's one story. I once met a guy whose brain worked like functional programming, which was pretty amazing to me, but... Well, and I don't think there's a good solution to that. Let them do enough exercises which are well suited to the model of thinking you want them to adopt and that usually helps. Using exercises gets people into the right mood for critical thinking. So hands-on is pretty important. Okay, thank you very much again.