 Hi folks. Thanks. And so welcome to the Diaz Silent, Challenges in Teaching Django. My name is Caleb Smith. I've programmed in a handful of various languages including Python and more recently I'm doing a lot of Clojure development and I've studied music education and I recently taught as an adjunct professor for the School of Journalism at the University of North Carolina Chapel Hill. Thanks. Go Heels. Yeah. So we taught Django and that was a great time. So I wanted to take this talk to reflect on some of those ideas, some of the mistakes and successes that I had with figuring out how to teach this thing so that hopefully it will help you for when you're helping teach. Okay. So the first challenge, the Diaz Silent, right? Okay. That's kind of an easy one. So it is pronounced Django. Okay. Now what I think really is the challenge, we really can't possibly see this, right? Like no matter how big the projector is. Now this chart is actually made, somebody made it for Ruby on Rails. I pulled it from the Code Fellows blog. But this is all of the different skills involved, right? So, you know, replace Ruby with Python, replace Rails with Django and it's all the same, right? So this has what you can imagine, right? It has Unix command line and text editors or IDEs and version control and test-driven development and, you know, the list goes on, right? And this is only expanding from my perspective, right? So you see rich clients and all these things on the front end that are expanding. But the back end isn't always shrinking, right? Like isn't it hard to build a microservice effectively even if the back end is small, right? There's a lot involved. There's a lot of monitoring, right? And this is always changing. I don't think this chart, I mean this chart is only a year old. I don't think it even has, you know, search indexes or message cues or, you know, many of these other pieces that we're finding that we're adding to our back ends, right? So this is only growing. And so I think honestly this is what presents the biggest challenge to teaching Django or whatever the framework is, right? It's just there's a lot involved. So you kind of have to unpack it. So stepping back from that a little bit, what are sort of the core aspects of the design of Django and, you know, I want to say, like, what does that imply in terms of when you're teaching or learning Django? How does it help or how does it maybe present a challenge? So I think that Django maximizes for the 90% case very well, but it tries to be extensible for uncommon cases. Also there's, you know, a high emphasis on documentation and testing. There's sort of this batteries included approach. And you hear a lot configuration over convention, right? Or as stated in the Zen of Python, explicit is better than implicit, right? So I think that's overall like a good overview of Django's design. So what are sort of the benefits of these choices, right? Good documentation is a clear benefit. I think that Django has excellent topic level documentation. And I think it serves as a model for a lot of other free and open source software. And that's great. I think that the tutorial, the official tutorial is actually a great tutorial, but I think it's not a perfect intro, right? If you've ever set someone in front of it and said, learn Django, here's the official tutorial. It's kind of dense and meandering and it's not the best first tutorial. I would assert that the Django Girls tutorial is the best first tutorial. It's excellent. So thanks to the community for helping create that. It's amazing. Okay, so another piece is this easy access to quality libraries, right? With some of the other frameworks, smaller frameworks, Flask and such, there are great libraries there, right? But I think that the batteries included part of Django does mean that if you've helped someone install Django, they already have a lot of great libraries, right? So at first they probably don't need, let's say, caching. But in a few months, when they do, it's right there, right? And you kind of just help steer them there. So that's, I think, a benefit to batteries included. There's kind of less integration work, right? The JavaScript pieces are flexible because Django is pretty hands off with respect to JavaScript. And not all back end frameworks are. I'm often kind of surprised as a Django developer when I look at certain frameworks and see, you know, how much it gets into the front end, right? How much it kind of bleeds into it. And I think also Django makes reuse fairly simple in terms of you add a third party app and it can make a lot of assumptions about your project knowing that it's a Django project, right? So I can add a third party app and it knows that it has the access to the ORM, right? And it's not always true with some other choices. I think that the configuration over convention has this great benefit that, at least to me, it's always felt like an invitation to explore. It means that as a beginner, I'm not ready to learn all of the configuration. There's a lot, right? And there's different ways you can do layouts. But it means that when I'm ready to sort of tackle that, I can dig. And even if the rabbit hole gets kind of deep, I can go look and say, you know, what is static root? What does that do? What is it set to? And I can look it up, right? And I think if you privilege convention over configuration, that piece can get a little harder, right? It's kind of harder to know what the framework is doing. It's more implicit. Okay, so that said, what are some of the challenges, right? So there are some challenges. I think one of them is JavaScript integration. While I appreciate the way that Django is hands off, many beginners find it kind of challenging because there's not a lot of structure, right? If you come to Django, and you've done some front end, and you say, well, how do I do Ajax, right? Or how do I do these other pieces of sort of integration with Django? And it's a little bit open, right? So that's one challenge that I think falls out of that design. Another is that because it's batteries included, you often come across this, you know, I'm just making a small app. Do I really need all of Django, right? It comes with all these things. And to that, you know, I would say, well, just because you're not using it, right, it's fine, right? You installed it, it's sitting on a disk somewhere, no big deal. But I think it does mean that you have to focus, right? You have to kind of focus your instruction when someone's starting with Django. You don't want to look at all of the pieces yet, right? If they only want to make a couple of views, they only need a couple models with one relation. There's a lot of other stuff in the sort of periphery of Django that maybe they don't really need to focus on yet. Okay. And lastly, I think that the configuration over convention, while it's what I prefer, some people find that frustrating, right? And with, if you privilege convention, it's a little more easily to sort of hand wave that away, right? And just say, well, this is the way the framework does it and don't worry about it. Some learners find that frustrating. I feel like I do, you know, I say, well, just show me how it works. I got to know how it works, right? But understand that some people appreciate that, right? And they say this allows me to focus on what I need to do because the convention is sort of taken care of. So there's kind of a trade off there's what I'm saying. And so bearing that in mind, you know, given these various challenges, what are some of the mistakes, right, that I've made or that you often see when people are teaching Django. Some of these mistakes are it's easy to teach everything at once, right? Because there are all these different pieces. And so it's important to kind of think about what's important first, right? You can, I think, learn Django effectively with not knowing a whole lot of Python just yet. And you learn a lot of Python along the way, right? Just like many of us learned JavaScript and didn't know what we were doing and just threw jQuery at stuff until after a while we finally learned the actual programming language, right? So that's okay. You don't have to work through an entire you know, series of Python books to just start with Django. The other piece is sort of related, you know, going too deep too soon, right? So if you get into the depths of like this is everything you'd ever want to know about SQL, right? Like you don't have to go there first, right? And then the other piece, I think this falls out of the privileging configuration because we're familiar with that and because it's an important part of a Django project there's often this early focus on like layout and boilerplate pieces and sort of the configuration end of things. And this always makes me hesitate. Like I kind of want to say, okay, here's a working project, here's a layout that works, here's all the configuration you're going to need, and let's leave it alone and like not touch, talk about it for a while, right? And then when it's relevant we'll look at that again and say here's the configuration and what it does, right? It's easy to just really get stuck in the details and say let's talk about exactly what static URL does, right, for an hour and you'll get people sort of lost very easily that way. Okay, so you know, sort of this grass is always a greener thing I guess. I kind of wanted to think about, you know, what are the other sort of popular web frameworks and how does their design differ from Django and how does that reflect in how you would teach those, right? How does it make them either easier or harder to teach in various ways? So firstly, Flask, you know, it's within the Python ecosystem, it's a good place to start. I think it is fair to say that it is easier to start with something that's just completely dead simple, right? Because they've really focused on we're going to make one file, we're going to make one function and it's just going to do a thing, right? And a lot of beginners are attracted to that. However, I would say that as you move along you start to structure out the thing and it eventually looks kind of like a Python project, right, in terms of the layout. And it is possible to use Django in this way, right? So if you look at Lightweight Django, the single file app that they have as an example of how to do a single file project in Django is shorter than the Flask app. It's actually less code. I don't think that less code is like the war anyone is trying to win with their framework necessarily, right? But just bearing that in mind, I think that one of the challenges it presents, that Flask presents, is that you do have a little more package integration work and you kind of have to pick the right packages, right? What ORM do I need? And what templating engine do I need? And if you're a programmer that's been doing this a while, you might really appreciate that design. I'm not saying that's a poor design at all. But if you're new, it's easy to see how that could be frustrating, right? It's like just give me the stuff I need. I don't know what these things do, right? Okay. So next node. Well, it's not really a framework. I know it's a runtime. But ExpressJS, you know, pick your framework. So I think, you know, one of the common sort of arguments you hear is that you're going to need to learn JavaScript on the front end. So you might as well use it on the back end. Less complexity, boom, we're done. And, okay, there is an argument there. However, I think that learning Python is not a serious barrier, right, to doing Django, right? Like I think Python is by design a much simpler language to learn, right? When you learn JavaScript, there are good pieces. But there's a whole lot of anti-patterns that you kind of have to learn about, right? So as a first language, it's a little dicey, right? And more important than that, though, I think is that this, the evented model that node gives you, while you may or may not, you know, appreciate it for your own sort of engineering team, as a learner, it means all of a sudden that I get stuck in callback hell and someone sees that and says, oh, what you need is promises. And someone else says, no, you need concurrent futures. And the learner says, what are you talking about, right? This is like way too advanced for what I'm trying to do, which is build just my first basic web app, right? And so hopefully I don't need to worry about concurrent futures for that, right? Okay. One thing that I think is very beneficial to node's approach is something that I see people stumble on a lot as they're learning Django, which is sort of marshalling JSON and that sort of thing, right? So typically you have these big objects as an internal representation on the server, you've got to figure out a way to serialize it and do kind of all this work. It is a much simpler mental model to just say I pulled JSON out of the database and I throw JSON across the wire and I'm done, right? Now you can decide for yourself if you think that's a good approach or not, right? But in terms of the mental model of learning it, I think that that's actually a lot simpler than what we typically do with Django. So Rails, as I was saying, it's kind of easier to hand wave away convention. There are certain benefits there and there are drawbacks. I think it's, there's more emphasis later on in sort of how do I work around Rails conventions when they don't help me? Which is kind of difficult, right? I think that Rails by design is naturally a bit more opaque. So in my opinion it's sort of less of an invitation to learn, which to me is kind of an important facet. But understand that some people that are beginning with Rails do appreciate that design. DHH sort of summarized what he thought the design of Rails was by this blog post where he says that Rails is omicase. And if you're not super familiar with that because I had to look it up, he's talking about if you go to a sushi restaurant and you pay like a hundred dollars or something, the master chef will come and give you all this sushi and they pick what they know you will like. And that very much is I think the sort of design of Rails. The framework picks the conventions and they know you're just going to like it. And if you don't like it then you'll eventually acquire the taste for it. I mean that's kind of the argument I think they're trying to make. Okay so I'll bite. If that's true then I encourage you to think of all of these different things on a spectrum in terms of their design and in terms of what falls out of them, in terms of how you teach them. So if Rails is omicase, I think that node is fondue. So this is where you pick all the small little tiny ingredients and you pay extra because you get to be the one that dips it in the cheese. So what I mean is you pick all these small modules and then you get to tie them all together. And so as a teacher or learner there's a lot of time spent like how do I put this thing together. I've got this piece that handles multi-part of some uploads. How do I tie this in? That's the cheese. Flask is a la carte. You look at the menu, you pick your own RM, you pick your templating engine. It's kind of further along in the spectrum. You do have to make those choices. I think one of the things that falls out of that is package management is still very important and you have to teach it early on. And I think it makes reuse a little harder. If I have some third-party app it might say I'm a Flask third-party app and I also need this RM and I need this templating engine. So I encourage you to think of Django as a lunch special. So if I order vegetarian special number seven and I know it comes with two burritos and an enchilada, what I'm thinking here is I get an RM, I get a templating engine by default. I know it comes with that lunch special. I don't know I have to know that much about how to make a burrito or what kind of enchilada I want. It's part of the lunch special. However when I'm ready, when I'm familiar with these things, and I'm ready to start kind of ordering things a la carte, I can make substitutions in the special. I want number seven, but I want a cheese enchilada instead. So I can add sequel alchemy to my Django app or I can add ginger templates or I can add this other piece. So I think that's where it falls on the spectrum. And lastly as I said, Rails is a macassee so this means that it's I think more opaque, a little harder to dig, but it does mean that you come in and it's kind of taken care of for you, so to speak. It's just here's your sushi, you don't even have to choose, you're done. I do want to encourage you to think each of these approaches has merit. You just kind of focus on different core aspects of what do you really need to teach or learn to excel at using that tool. Okay, so bearing all these tools in mind, it's important to think about like the different theories of learning and how this can help with effective teaching. And in the 20th century, the two kind of major schools are behaviorism and constructivism. And behaviorism is more in sort of early 20th century. And constructivism is very common across different disciplines these days. And one of the people that sort of brought this into the four in North America was Jerome Brunner. And in his theoretical framework, it's based on this theme that learners construct new ideas based on their existing knowledge, right? So within that, he talks about what he calls the spiral curriculum. And I think this is a very effective way to think about tackling a big topic like back-end programming. So in the constructivist viewpoint, the foundations of any subject can be taught to anybody at any stage if it's in the appropriate form. And with the spiral curriculum, you look at the bottom and this is a learner that's very new to whatever they're doing. As you move around the spiral, you're visiting different topics at a high level. So you're touching just a moment on this is what a SQL database does. And so on. As you move up, you revise their ideas, build on what they already know at that point. You add new content. And as the scope increases and they're learning more different kinds of things, they're moving up and the difficulty increases. And this is how they lead to mastery. So at the bottom, again, is high-level overview. And when you get to the top, that's when you're in the depth so let's talk about what a join is and let's talk about using containers and unicornals and crazy stuff. Okay. And within this framework, Brunner talks about or constructivism more broadly, talks about seeing the instructor's role as scaffolding. So instructors are sort of facilitators for learning. And one of the key ideas is that the learning environment is designed to support but also challenge learners' thinking. So sometimes one of the effective teaching techniques is to ask just the right question to help someone question some of their intuition or assumptions. And lastly with scaffolding, the teacher's role is also to sort of select kind of what's going to be focused on and sort of the scope of everything. And then the sequencing. And we'll talk about sequencing in just a moment. So constructivism, to give you kind of an overview of how this is used in CS, one of the CS education in general, one of the ways this is done is with logo. So how many of you in maybe fourth grade or so looked at logo and played with it a little bit? Right, sorry. But yeah, so it's this cool teaching tool. They kind of based the design on LISP. But what they did was they removed enough stuff to make it really appropriate for fourth grader. And it's something they can understand. It's a turtle. And the turtle represents state in the program. It's this visual representation. And there's multiple ways to do the same thing. So it demonstrates program state and interactive development and eventually you can get to loops and structured programming. But one of the things you might ask to help someone sort of question their own intuition would be, can the turtle move backward if you don't have a backward command? And the solution to that is you turn the angle, move forward and then turn the angle back. So with constructivism, you're sort of always thinking about what is their current level of knowledge and what are their current assumptions and how do I help them move past those and sort of question the ones that they need to. So one of your core skills as a teacher within using constructivism is cognitive modeling. And so modeling more broadly is where you just kind of do something to demonstrate how it's done. But cognitive modeling means showing how you're thinking about something. Which can be very challenging because it's internal. So one of the ways to do pair programming. And if you're helping someone learn in the process of pair programming, it's a bit different than working directly with a colleague and pair programming. And so when you pair program with someone that you're trying to mentor, I encourage you to think about verbalizing your thinking and sort of talk about the problem solving steps. Decompose the problem and sort of explain how you're thinking about each piece and invite them to kind of follow along or question you along the way. And this will help model for them the cognitive process that you're going through. So another piece is called sequencing. And really this is putting structuring instruction into a logical order. Starting with one thing that's sort of a simpler piece and then sort of slowly moving on. And you'll hear people argue about this kind of stuff sometimes and say things that I think are a little silly like they'll say you should really learn C before you learn a high level language. I don't think that's true. But sequencing more specifically is you want to decontextualize and then contextualize. So when you decontextualize you practice or learn a particular piece in isolation. So you might say let's look at the Django ORM in a Python shell and practice making different kinds of queries and looking at the data that we get back. And then contextualizing is then putting it back into a larger project or a larger piece. And you say okay seeing what we did with the ORM now let's do that in our view so that we get the data we need. And along the way with sequencing I encourage you to really think hard about the appropriate balance of structure and flexibility. And this can be a difficult balance. The more structured the learning it's harder for learners to construct meaning based on their own conceptual understanding and to then extend their meaning into other contexts. In other words if your instruction is incredibly structured it's harder for someone to leave that class workshop whatever and apply all those skills. However if you don't have enough structure there's not really any clear guidance. And people find that frustrating. Well just tell me what's the best practice? How do I do XYZ? So there's a balance there. To serve as sort of an example of inflexibility I don't mean Java specifically but it serves as an example of inflexibility in your instruction. Many of us have attended or witnessed sort of a freshman CS class where the approach is we're going to focus on a given language be it Java or it could be Python. And the approach is something like in this session we're going to learn everything you ever wanted to know about anonymous interclasses. So what's the problem with that? Well we have so much structure here and we're kind of going on each topic really deeply instead of following that spiral curriculum. And at this point the learner probably hasn't had an opportunity to see why an anonymous interclass would ever help them. So instead the constructive approach that I would recommend would be to start with just the basic concepts in isolations. You say these are strings, these are arrays and so on. And then as soon as you can contextualize them and say let's work on a simple project that just does this small thing. And what you'll find is that as they work on more projects and you increase the scope and you add more concepts as they gain mastery they will find these language features and things on their own. They'll eventually say oh you know I'm trying to do this and they'll explain their problem and you don't even need to say okay then we need to have a lecture about anonymous interclasses. All you have to say is it looks like you need the decorator pattern. Maybe Google that and look for interclasses and that's all you need to say. Now the learner has enough context and enough meaning that they can go research that and empower themselves and learn that. So in Python that might mean something more like decorators or generators or something like that. That's a fairly advanced concept. It's not that effective to say I'm going to tell you everything you want to know about the yield statement. But instead as they encounter that problem naturally I'm processing this huge Apache log and it can't fit in RAM. You say oh you need a generator. Then it'll fit in RAM. Go look it up and then help them if they need it. I think it's important to keep that flexibility going. People often ask about various prescriptions. I don't always honestly feel that I know enough to say these are the resources because there are so many great resources. It's really hard to order them too. A lot of them address different things but if I'm helping someone the order that I kind of think about is that I think the Django Girls tutorial again is the best first intro to Django. After that I think with some coaching the official Django tutorial is good again with some help. After that I think someone's ready to kind of do a small self-guided project on their own. Maybe just a couple views, a couple models and that sort of thing and encourage them to kind of look up the Django documentation and kind of do that. After that, TDD and Python by Henry Percival is a great book for them to sort of self-study and kind of moving on from there. By the time they're ready to collaborate with folks on a sort of moderate-sized project that's when it's really great. Let's get this person hired as a junior developer somewhere. Because then they're going to need to learn Git and GitHub and all these kinds of things and that's really hard to do by yourself. These are some of my ideas about some good learning tools and a roughly good order. But again, I kind of hesitate to say this is one size fits all and the end all be all of how you structure Django learning. I did want to specifically thank the creators, contributors of Django and also authors of documentation and tutorials and stuff because you make Django really a joy to teach. I've talked about what some of the challenges are and some of the pain points and some things that maybe could be better. But really teaching Django is great and it's because of many of you including community organizers. I also wanted to thank my mentors at Cactus that taught me Django. Thank you for listening. If there's time, we can do some Q&A. I think he's asking if people are learning at different rates. That's the idea, right? Okay, right. So the people that are ahead, it's kind of harder to catch the other people up I think is what he's saying. So yeah, I don't know. I feel like one of the things certainly is while I was at Cactus, the culture was always very much a mentoring culture of the people that were further ahead spending some time sort of helping. And so I don't know exactly where all that's coming from within your organization, but I would say it's good if you can sort of privilege the idea of lead developers and stuff taking some time to kind of help people. And maybe that's pair programming and maybe that is different kinds of things. I don't know. Maybe it's lunch talks. I don't know. But yeah, I think we want to sort of foster a community in which the people that are naturally sort of further ahead or something are willing and able to sort of take the time and sort of foster growth in other people. Sure, so she's asking if you're encouraging people to run into their own problems and then find the solution instead of being prescriptive and saying here's anonymous interclasses or whatever it is. Then how do you help them identify when that's a need? And one of the things that's kind of tricky with this is I think that there's a bit of internal, there has to be some motivation. So one of the issues is I've seen people before that they're doing some let's just say jQuery spaghetti and someone says you really need to do backbone. This is going to help you structure everything, but they're lost in the weeds of what they're doing and they're saying oh this works. This is fine. And so it is difficult sometimes, but I think that the way that I kind of try to do it is let them use the hammer for a little while to screw in a nail. Let them feel the pain a little bit because that is a really good teacher itself. Once they've gotten deep into whatever jQuery soup they've made, they can eventually say oh this is why you're trying to show me another way to do it. So I hope that addresses the question well. Feel free to ask me out in the hall and that sort of thing. Thank you.