The D is Silent: Challenges in Teaching Django by Caleb Smith

Hi folks, thanks. Uh and uh so welcome to the D is Silent, Challenges in Teaching Django. Uh my name is Caleb Smith. Um I've programmed in a handful of uh various languages, and including Python. And more recently I'm doing a lot of closure 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 Well thanks, go heals. And uh yeah, and uh yeah, so we we taught Django and uh that was a great time. So I wanted to sort of take this talk to sort of reflect on some of those ideas Some of the mistakes and successes that I had with with

figuring out how to teach this thing. So that hopefully it will help you for when when you're helping teach. Okay, so uh the first challenge, um the D is silent, right? Uh okay, that's that's kind of an easy one. Uh 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 I pulled it from the CodeFellows blog. Um but this is all of the different skills involved, right? So you know replace Ruby with Python, replace Rails with Django, and it 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 Um this is only expanding uh from my perspective, right? So um you see rich clients and and all these things on the front end that that are expanding, um 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? Um and this is always changing. I 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 queues or 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? Is just there's a lot involved. So you kind of have to unpack it. So stepping back from that a little bit, what what are sort of the core aspects of the design of Django? And and you know I want to say like w 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. Um 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.

So I I think that's overall like a good overview of Django 's design. So what are sort of the the benefits of these choices, right? Good documentation is a clear benefit. I 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 the 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 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, micro uh you know smaller frameworks, Flask and such, um there there is 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 it's right there, right? And 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 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 uh I I I think also Django makes reuse um 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. So I can add a third-party app and it knows that it has the access to the ORM. And that's not always true with with some other choices. Uh I think that the configuration over convention has this great benefit that to 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 I can look it up. And I think if you privilege convention over configuration That piece can get a little harder, right? It's kind of harder to know how uh uh 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?

You 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 of of sort of integration with Django? And it's it's a little bit open, right? So uh that 's one challenge uh that I think falls out of that design. Another is that because it's batteries included, you you often come across this, you know, I'm I'm just making a small app. Do I really need all of Django? Right? Django 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. 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 views, they only need a couple models with one relation. There's a lot of other stuff in the sort of the periphery of Django that maybe they don't really need to focus on yet. Okay, and uh lastly, I I think that the configuration over convention, uh while wh while it's what I prefer, uh some people find that frustrating, right? And with can if you privilege convention It's a little more easy to sort of hand wave that away, right? And just say, oh, 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 gotta know how it works, right? Um but understand that some people appreciate that, right?

And they say this allows me to focus on what I need to do. um because the convention is sort of taken care of. So there's kind of a trade-off there is what I'm saying. And so bearing that in mind You know, given these various challenges, what are some of the mistakes 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 there are all these different pieces. Um 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. So that's okay. You don't have to work through an entire 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 um 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 and sort of the configuration end of things.

Um and and this always makes me hesitate. Like I 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 gonna need, and let's leave it alone and like not touch it 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 let's talk about exactly what static Earl does, right, for an hour. Um and and you'll get people sort of lost very easily that way. Okay, so you know, sort of this grass is always greener thing, I guess. I kind of wanted to think about, you know, what are the other um sort of popular web frameworks and how does their design

um differ from Django and how does that reflect in how you 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. 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. 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 um it is possible to use Django in this way, right?

So if you look at Lightweight Django, um 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 um just you know 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? And 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 that's a poor design at all. Um but if you're new, uh 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 uh next uh node. Well it's not really a framework. I I know it's a runtime, but Express. js, you know, pick your framework. So I think 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 there is an argument there. However, I think that learning Python is not a serious barrier, right, to to doing Django, right? Like Um 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? Um so as a first language, it's a little it's a little dicey, right? And m more important than that though, I think, is that this the invented model uh that Node gives you uh while you may or may not you know appreciate it for your own sort of engineering team, as a learner, um 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.

One thing that I think is uh very beneficial to Node's approach. is something that I I see people stumble on a lot uh as they're learning Django, which is sort of marshalling JSON. uh and that sort of thing, right? So typically um you know you have these big objects as an internal representation on the server. You've got to figure out a way to serialize it, you know, 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 I think that that's that's actually a lot simpler than than what we typically do.

with Django. So uh Rails. Uh 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? Um which is kind of difficult, right? I think that Rails by design is 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 omakase.

Uh and if you're not super familiar with that because I had to look it up, uh he's he's talking about if you go to a sushi restaurant and you pay like $100 or something. The master chef will come and give you all this sushi and they pick what they know you will like. Okay? And that very much is, I think, the sort of design of Rails. The the framework picks, you know, the conventions And they know you're just gonna like it, right? And if you don't like it, then you'll eventually acquire the taste for it, right? I mean that's 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 how you teach them.

So if Rails is omakase, I think that node is fondue. So this is where you 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? Right? Uh I've got this piece that handles multi-part uh param uploads. How do I tie this in? Right? That's the cheese. Um Flask is a la carte. You look at the menu, you pick your own RM, you pick your templating engine. 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, right? If I have some third-party app, it might say, I'm a Flask third-party app, and I also need this ORM and I need this templating engine, right? Okay, so I encourage you to think of Django as a lunch special. And 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 ORM, I get a templating engine by default, right? I know what comes with that lunch special. I don't 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, right? I want number seven, but I want a cheese angelata instead. So I can add SQL Alchemy to my Django app, or I can add Jinja templates, or I can add this other piece, right? So I think that's where it falls on the spectrum. And uh lastly, as I said, you know, Rails is a micase, and so uh this means that you know it's uh I think more opaque, a little harder to dig, um, but it does mean that you you 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, you know, each of these approaches has merit. You just kind of focus on different core aspects of what you know 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 the 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 fore in North America was Jerome Brunner. And In his theoretical framework, um, 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 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 HTTP verbs are. You're touching just a moment on this is generally 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 depths of let's talk about what a join is and let's talk about using containers and unikernels and crazy stuff. Okay. And within this framework, Bruner 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. um and then the sequencing and and we'll talk about sequencing in just a moment. So constructivism to give you kind of a overview of how this is used in CS one of the uh in you know CS education in general, one of the ways this is done is uh with logo, right?

So how many how many of you in maybe fourth grade or so like looked at logo and played with it a little bit and Right, sorry. Um but yeah, so it's this cool teaching tool. It's uh roughly they kind of based the design on Lisp, but what they did was they removed enough stuff, right, to make it really appropriate for a fourth grader. And it's something they can understand. You know, it's a turtle, right? And the turtle represents state in the program, right? 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 you know, 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? Right? And the solution to that is, you know, you turn the angle, right, move forward, and then turn the angle back. So With constructivism, you're sort of always thinking about what 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 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, right? Because it's internal.

So one of the ways to do this is with pair programming. And if you're helping someone learn in the process of pair programming. It's a bit different than you know working directly with a colleague and and pair programming, right? 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, right? 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 uh structuring instruction into a logical order, right? Starting with one thing that's

that's sort you know, sort of a simpler piece and then sort of slowly moving on, right? And you'll hear people argue about this kind of stuff sometimes and 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.

Right? 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 that meaning into other contexts. In other words, if 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, right? And people find that frustrating. Well just tell me, you know, 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, and I don't mean Java specifically, but uh It serves as an example of inflexibility in in your instruction. Many of us have have attended or or witnessed sort of a freshman sort of 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, okay, in this session, we're going to learn everything you ever wanted to know about anonymous inner classes. Okay, so what's the problem with that, right? Well, we have so much structure here, and we're kind of going on each topic really deeply instead of following that spiral curriculum Right?

And at this point the learner probably hasn't had an opportunity to see why an anonymous inner class would ever help them, right? So instead the constructive appro constructivist approach that I would recommend would be to start with just the basic concepts. in isolation, so 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, right, as they gain mastery, they will find these language features and things on their own, right? 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 inner classes. All you have to say is, it looks like you need the decorator pattern. Maybe Google that and look for inner classes. And that's all you needed to say, right? 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 uh you know a fairly advanced concept, right? Um it's not that effective to say, I'm gonna tell you everything you want to know about the yield statement, right? But instead as they encounter that problem naturally, I'm 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. Right? And then help them, you know, if they need it. But I think it's important to kind of keep that flexibility going. Okay, so um people often ask about sort of various prescriptions. I don't always honestly feel that I know enough to say these these are the resources, because there are so many great resources, right? And it's really hard to to order them too, right? A lot of them address kind of different things. Um but if if I'm helping someone, the 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 's great book for them to sort of self-study and and kind of and you know and moving on from there. By the time they're ready to collaborate uh with folks uh um on a on a sort of moderate size project That's when it's really great, like let's get this person hired as a junior developer somewhere, right? Um, because then they're gonna need to learn Git and GitHub and all these kinds of things, and that's really hard to do by yourself, right? Okay, so these are some of my ideas about some good some good learning tools in a roughly good order.

But again, I I kind of hesitate to say this is one size fits all and the end all be all of uh you know, how you structure Django learning. So I did want to specifically thank the uh creators, contributors of Django, and also authors of documentation and tutorials and stuff because You make Django really a joy to teach. You know, I 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 but really teaching Django is great. And it's because of many of you, including community organizers. And I also wanted to thank my mint mentors at Cactus that taught me Django. And thank you for listening.

So if there's time we can do some uh QA? Sure. So I think he's asking um if people are learning at different rates and uh is that's that's the idea, right? Okay, right. So the people that are ahead, it it's kind of harder to to catch the other people up, I think is what he's saying. And so um Yeah, I don't know. I I feel like uh one of the things certainly is w while I was at Cactus the culture was always very much uh a mentoring culture of of the people that were further ahead, you know, spending some time sort of helping And so I don't know exactly where all that's that's coming from within your organization, but I would say it's it's good if you can sort of privilege the idea of you know, lead developers and stuff

take taking some time to kind of help people. And maybe that's pair programming and maybe that you know is is different kinds of things. I don't know, maybe it's lunch talks. I don't know, but um yeah, I I think we want to sort of foster a community in which um the the people that are are n naturally sort of further ahead or something. um are are willing and able to to s sort of take the time and and sort of foster growth in other people. Sure. So she's she's asking If you're encouraging people to run into their own problems and then find the solution, right, instead of being prescriptive and saying, here's anonymous interclasses or whatever it is, right? Then how do you help them identify when that's a need? And one of the things is that's kind of tricky with this is I I think that there's a bit of uh

internal um There has to be some motivation. So what one of the issues is I I've seen people before that, you know, they're they're doing some uh let's just say jQuery spaghetti and someone says, you really need to do backbone. Like this is gonna help you, you know, structure everything Um but they're lost in the weeds of what they're doing and they're saying, oh this works, like this is fine, right? Um and so yeah, it it it is difficult sometimes, but I I think that um the the way that I I kind of try to do it is Let them use the hammer for a little while to screw in a nail, right? Let them feel the pain a little bit. You know? Because that is is a really good teacher itself, right? Like once they've once they've gotten deep into you know whatever jQuery

soup they've made, right, 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. Okay, feel free to ask me uh out in the hall and that sort of thing. Thank you.