Transcript: Django the Good Parts - James Bennett

I'm Carlton Gibson.

Joined us everybody by Will Vincent.

Hello, Will.

And this week we've got with us James Bennett, who's a longtime Django contributor, been on the Django board, and well, you know, all-round hero of mine.

James, thank you for coming on.

It's really

Um we always talk about um to start off with, like people's backstory and how they how they got into programming, how they got into Django and all the rest.

But am I right in thinking that you did philosophy?

Because I did philosophy, I was yes.

You quit early.

Um, I was a terrible student.

Uh so I did not get into a PhD program.

I didn't actually have a computer at all.

Um, like I had a little bit of experience with an Apple II at at school.

Okay.

I didn't have my own computer until my second year.

And I was taking courses, it was a small college, and so it was a department not just of philosophy, but a combined department of religion, philosophy, theology.

Okay.

You could either write a 15-page research paper on an assigned topic or produce a website with five pages.

That's easy.

And I was a lazy student.

Yeah, good programmer.

Uh I was working as sort of a department assistant.

I was the guy who would go, like when they needed something from the library, I would go pick it up for them, or they needed copies made of things.

And my advisor uh found out that I had learned how to do this and was like, hey, our department's website could use a little refresh.

Would you like to do that?

And we'll pay you for it.

And so I did.

Um and that was kind of the start.

I spent a summer when I was supposed to be doing much more research than I actually did, uh, learning PhP and a couple other things.

Uh, build my own like personal blog engine.

And then I graduated, applied to some PhD programs, didn't get into any, got kind of a boring job at an insurance company, and saved up a little money, and then went into business with a friend of mine who was a designer, because you could do that.

This was like 2004, um, 2005.

You know, you could do that back then.

You could just say, I'm going to go into web stuff, and it would work, and started doing contract work, uh, mostly PHP in Perl.

And I was learning Ruby and Rails shortly after that came out.

I'd bought the Rails book.

Um, I had learned Python from reading Dive into Python uh by Mark Pilgrim.

But at the time, Python web development was basically Zope.

Right.

And then one day this thing called Django came out.

Um, and I read about it.

I decided to play with it, and I really liked it.

And I remember I wrote something on my blog, not the one that I have now, but an older one that thankfully is is gone, um, about how I really like really like this Django thing, and I really wish one of my clients would let me use it.

And I kind of joked about maybe I should go on strike until somebody says I could use Django.

And a little while after that, I got a message from Jacob Kaplan Moss saying, Hey, the journal world is hiring.

Would you like to apply?

That's like, you know, you're there at the Yeah.

Can you offer any you know follow-ups, any anything else that I should study?

Because you were like the webmaster address at the bottom.

I never am going to be.

I was a student who was lazy and trying to avoid writing a 15-page paper.

I mean, it I don't hear quite the same struggle that mul other people seem to have like learning multiple languages.

It seems like it, you know, you obviously had to do the work, but it made a sense to your mind how programming works.

Python has always fit my brain.

Um PHP and Perl, I had to put in some work, JavaScript.

I had to put in some work, HTML kind of clicked easily, but that was the age of view source learning.

Like my first little PHP blogging application was not good, but I was very proud of it.

I mean, any even I was telling someone the other day, like you look at code from a year ago that you know someone else wrote, let alone you wrote, and generally you're like, ugh.

Yeah.

Yeah.

Like PHP, I give a lot of credit to PHP for making web programming so accessible to so many people, like at that point in history, because up to then it was basically you had to learn CGI, which is kind of a complex and tricky programming model, and probably you had to do Perl, which has its own quirks and is kind of complex to learn at first.

And PHP made that so much easier.

Because it was just write this, and you know, you can you can intersperse a little logic with some HTML and just upload it and it works.

Yeah.

I mean that there's that quote um about make solve the web problem quickly.

That was its kind of goal.

Yeah.

Um I st I still hold that in my mind, you know, as you know, whenever I'm thinking about Django and what's good about Django and the strong points, it can try and hold that, you know.

We t Python still hasn't got the deployment story of just stick it up there and it'll work.

But yeah, that solved the web problem quickly.

I you know, I I kind of think that that's something that Django has going forward as well.

But the that general goal, I'm still fought, I still hold it.

And yeah, you know, when you say you give credit to PHP, it's exactly right.

It's like, you know, how did I get in?

I picked up the PHP and MySQL programming book.

I mean, this is true.

I mean, when I joined the software the Django Software Foundation, you were on there.

You were also actively involved with the technical things, and you had you actually drove the development, I believe, of the the technical board, in part because you know you were, I think, the person you were involved, you had your hands in everything.

I mean, from the very beginning with opening up to other people being given commit access to then stepping back, like one of the biggest milestones and potential problems for a project or a community like Django is whether it can survive the loss or the moving on of its founders.

And they set it up to succeed at that, and then they stepped back and they said, We don't need to run this for the rest of our lives, and then we got the technical board.

You know, we still had at that point the technical board and the committers, the core team, as the decision makers, but they deserve a lot of credit for that because they set Django up to succeed and be hopefully sustainable in the long term.

Because there are other projects that never really get over like the the their founder or their kind of like old guard team and just kind of cling to that for as long as they can.

But they Django's was had quite a big contributor base and is was historically open to new contributors.

And do you is that cultural or do you is that

Um they they were very open to feedback.

Uh I mean, even before Django was publicly released, they were kind of showing it around to people and asking opinions.

Um, you can hear stories of like Ian Bicking being asked about the thing that became Django and offering his opinions on it, and kind of you know the the ORM used to be a code generator, and there was feedback to yeah, maybe maybe don't do that.

Like yeah, I think they really set the tone for that by by being open to feedback to other people jumping in and helping out and being willing to not be gatekeepers of Django forever, but saying, oh well, this person's doing good work.

Let's give them a

commit bit.

And one one thing I've always liked is the um the approach for consensus, looking for consensus, and that you know, it's like, well, you know, actually there's there's not a consensus for agreement, so we'll just hold off here or we'll we'll carry on the discussion to until we see if we can find that.

I think that you know it's a real strength.

Um it's not just one person going, no, I think that's

Year after year it slowly moves forward, and yeah, you know, one way to speed it up is you know, I'd say one way to speed that up is to join in, but you know, the the reality is that Django's a slow-moving beast, you know?

Yeah.

Um when I when I did my ORM tutorials at Django Con, I I mentioned this.

I would take like the uh the actual blog model that's used on the Django project weblog, and go through different stages in its history and be like, doesn't this look awfully familiar every single time?

Yeah, okay, nice.

The the the kind of pace and the kind of well, let's do it right, even if it takes a little bit longer, has helped Django maintain that integrity over time of this feels like Django, even as new features get added, even as things get rewritten.

So you could say, well, another framework could have thrown black in earlier, but you know, there was a process, there were all these extra steps, people committed to that process, and it will be in there.

And when it's done, it's done the right way.

People can see the discussion, you know.

So I think, as you said, taking a little bit longer, having a process wins out in the end, even and people can always just use it themselves, too.

I mean, that's the thing with the ecosystem and third-party packages channels.

Yeah, there's there's like an off-ramp for I really want to do this.

Um frustration has an avenue.

And then bring it into Django.

Yeah, so that happened with migrations, that happened with channels, you know.

Yeah, SC stuff.

Yeah.

Yeah.

You will.

I was gonna say, even just the the community part, the the DSF, you know, that we had Anna on recently, last week, um, who's the current president, and she's been on the board for five years, and I've been on now three years, and there's a natural cycling of people on the board, but there is the sort of passion and knowledge hopefully gets passed along.

I mean, you were secretary, James.

Um, it's you can't assume that someone is going to volunteer for 10 years on the board or as a core committer, though you've you've managed to do it a long time, James.

So there's a healthiness in terms of having that model and you know, do what you can.

When you have to step away, you can, and that keeps the goodwill in the community.

Um, right.

I mean, I know for you, right?

Like you had a whole spike spike of work stuff on top of all the Django things you were doing a couple years back, which made you need to step away, but you know, you're still here you are, right?

You haven't rage quit, hopefully.

So well, I've

Um yeah, I used to be on the DSF board, I served some terms on the technical board, I used to be a lot more active on the developers list.

Um these days, the only thing I really do in the Django project is I'm still on the security team.

And not super active there, but every once in a while I'll jump in

I hope so.

And I I think again that goes back to like Jacob and Adrian setting things up that way, but they're healthy enough at the moment that people can step back, and other people are stepping up to do things.

Yeah, coffee.

roles like this, and then the technical board taking that role.

That was depth depth, right?

Yeah.

One one thing that I was worried about, and that I've you know I've got you here, was that the the the kind of knowledge base, the sort of the old knowledge, the old, you know, the the established knowledge to sort of just disappearing as you know you know I looked at I looked through the old list of the core committers and they're all like all the people that built all the features, and if they're not there anymore, I was just worried that we'd lose that that kind of tribal knowledge slightly.

I wonder what you think now.

Um I I've joked with uh Russell Keith McGee a couple times that that my role in Django now is to be a grumpy old man who remembers what happened.

Yeah, yeah.

But at the same time, there are plenty of other people filling that role.

Like I saw um you know Tim just recently uh in

So, yeah, there are other people stepping up, and and like Carlton, you know, you you've been around long enough that you are you have a lot of that context now.

You've seen

That's that's where I've you know m deepened my knowledge massively.

So okay, I was working on REST Framework, and then, but to come in and and have to go through track, and when an issue report comes in and have to find the history and exactly why it was, and yeah, uh you know, you do that for a while, and it's like okay, yeah, I can I can my knowledge Tim's knowledge of the issues is amazing.

But I used to like 10 10 years ago or more, I used to every once in a while just go through every open ticket in in Django's track and read all of them, see if any of them could be closed, see if any of them needed to be bumped.

Like, is there anything like any easy like documentation tickets or things that can be promoted as let's get this one done for the next release?

Yeah.

It's like, oh yeah, I remember there was a ticket about that.

I can't remember the exact details, but Claude was like, Are you talking about this ticket?

And then you know, a

10-year-old ticket.

I'm like, Yes, Claude, thank you.

So yeah, I mean, so I guess the history is still there.

And what's in you know, what's interesting, you talk about um Jacob and Adrian, you see a 10-year-old discussion or a 12-year-old discussion or 15-year-old discussion where they're you know handling it in a very gracious and open way, and it's exactly right.

Super.

And um I wonder if I could ask you about so this was from PyCon 2014, Django the Good Parts.

Okay.

I don't know if you recall your thoughts there, but I thought that was a really I probably still have interesting one.

Yeah, you but that that idea, I mean, there was, you know, Java, I guess that was when what's his name?

There was JavaScript the good parts, right?

Yeah, that that was the thing.

And but it is what one of my favorite talks is Jacob's from I think PyCon 2017, which is a three-hour build your own web framework where he basically goes through these are the decisions you make.

And you know, do you write your own templating language?

Do you use something else?

And what do you use for the web server?

And it sort of distills uh a top architect level view of of these things.

And anyways, if you recall that, you know, your the good parts talk.

I I watched that a couple years ago, and it might be interesting to see if it still holds up uh eight years later.

So let's see.

Um I'm sure they're online.

So let's see.

What did I suggest?

Um HTTP abstractions, the request response cycle, the slow and steady approach to features, and apps as the good parts of Django.

I'm sure there are more good parts.

Those are just kind of the ones that I that I focused on.

Um I think that still holds up.

Like I think Django's you know, request response cycle and HTTP abstractions are still quite good, especially and this was in comparison to doing like your own raw WISGI type programming.

And for people who've never done that, like WISGI is kind of CGI adapted to be a Python thing.

Like it is, it is literally the CGI programming model, just kind of lightly adapted for Python.

So there's all this, like the the way for people who've never done CGI, the way that it worked was you would have your script and the server would put information about the incoming request into environment variables and the body of the request into the standard input stream, because it was a Unix programming model, and then start your script.

And then you would do your processing and send your response, you know, headers and response body out on the standard output stream.

And so you had to do all of that processing in the script of knowing which magic environment variables have which things and how am I supposed to parse them and how am I supposed to handle them.

And WISGI is similar in that it passes you a dictionary of the environment, and the keys, in fact, in that dictionary match up to the traditional CGI variable names.

Um, and then you know you return.

And WISGI is a little more composable, but every single step, like if you have you know one WISGI app wrapping another, both of them have to parse that environment dictionary.

Um like the the response API is kind of complicated because you have like this thing that you call to start the response and then you return the response.

And so it's I really do think that Django's abstractions are are pretty good.

It's you know so we've been able to put in a totally different um request handling sort of application layer.

And Django's untouched virtually.

Virtually.

But that bit was pretty rock solid.

I just think that Django that's one of the things that Django got right.

And I'm sure there are other good implementations, but I think Django's is really good too.

Um we talked about like the the slow approach to features, so I think that still holds up.

Um apps, absolutely.

Um I I've been I've been a fan of Django apps.

Like I gave a talk at the very first Django Con, uh, which is 2008, and hosted at Google about like designing what I thought were good Django apps, and I've talked about that a lot before and since.

That the app abstraction of you can build sort of a self-contained unit of functionality and then compose and reuse uh so things like you can build a contact form, you can build a blog, you can build like all of these different types of features and functionality and compose them together to build a Django site.

And I think that's really, really crucial because just providing that abstraction at the level of not like a database model or a view, but at the level of a whole interconnected unit of functionality for a website has been really, really crucial to Django's success because it gives you that level to think about and it gives you the ability to package those things up

and distribute them, or even if they're internal, you know, reuse them across different projects and saves you a lot of time, makes it a lot easier to reason about these things.

And so I've always felt like apps were kind of like the secret weapon that made Django so good.

Well, I just wanted to say something quick, which is that apps, uh when I people who are new to Django, so e especially people coming from another framework, apps is actually something that trips them up or they they're a little not angry about, but they kind of like, well, this is stupid.

Why do why does Django have apps?

I want it to be a certain way.

And I see this various discussions, it's like, well, you can the whole point is you can do it however you want.

You can have one app for your entire site, or you can rely on abstraction, and then you can also rely on these third parties.

But that concept, maybe it's coming from different frameworks, but that's something that someone coming from another web framework, I find, trips them up initially.

Yeah.

Because there's confusion over what it means.

And it's

But you know, the app is kind of the atomic unit of functionality.

It's like, well, there's guidelines, but that's so I think that's you know, that's the piece that is unsettling to to to those folks.

It's like, okay, but but how?

Yes.

It it's not something that there is a single rule you can follow that always gives you the right answer.

Well, that's kind of what I tell these people is say, well, yeah, maybe it's an extra step or thing to think about, but Django on that balance of customizable, Django is actually quite customizable considering it has guardrails.

And that comes at the cost of the apps and some other configs where it could be rails, it could just go boom one way, but it makes it easier to be malleable within a construct.

It lets you have you know different configurations of features that you can kind of toggle.

Um I think it also helps that Django it that Django itself has that approach.

So like the apps in Django contrib, uh things like the wall admin and sessions, that you can see that you are composing these things together to get it.

Just one more, right?

Yeah.

It's that people get kind of addicted.

And what I've seen as a working Django programmer for many years is you could go to a company and they're stuck on the the old LTS and it's just about to go end of life, and they they're struggling to update because they've got you know 30 third-party apps, and 29 of them aren't really um aren't really maintained properly, and uh then they're in a kind of bind.

And so over the years I kind of developed a kind of um very conservative approach to taking on a new app, and you've got to be you know, you must be cautious here.

You mustn't you must check it's properly maintained.

You must that's the counter, that's the counterpoint, I guess, is that you can

If you're gonna take on a dependency, like the and then you you find yourself kind of stuck.

So I I I tend not to use the LTS myself, but I asked on Twitter recently, why you know, if you use the LTS, why do why do you use it?

And the one of the biggest responses was, well, you know, by the time all our third-party apps are are updated to be compatible, you know, we go LTS to LTS, and that can serve us better than you know, trying to I think

ise that if you're running on this LTS and you have no deprecation warnings, you can safely upgrade to the next LTS.

Yeah, yeah.

Now, you know, you you would want to test any third-party stuff you're using.

But that gives a very nice upgrade path.

And and I've dealt with setting up dependency management workflows at at several companies and and how to how to keep things up to date, and that is a perennial issue.

And it was just like, you know, and I didn't bother with the intermediate ones because I, you know, Ramad warnings clear those up, and it was it was that was lovely, to be honest.

Much yeah, better than the old days.

Yeah.

Yeah, so that's that's a fun thing to do.

And testing is something we love to ask practitioners about since there's quite a variety of ways it's done in the wild.

Um so we will link to that article, but I wonder just again, you've you've worked at a number of companies using Django.

With how do you think about, you know, practically speaking, proper testing?

You know, what are the tools you like to use in terms of the hierarchy of priorities that you like to see on in a code base?

Like any tests are better than no tests.

I'm not particularly like a test-driven development person.

I'm kind of I'm skeptical on most like capital letter methodologies for building and managing software projects.

Like you know, I I I understand that a lot of these methodologies, there's some essential insight that somebody caught once and then tried to propagate that, but it's the everything else that grows up around it and kind of all the rituals and practices that because because so often like the the things that make a project successful or not are not really you can't replicate them to the

next team, the next project, the next thing.

Like it's it's nobody's figured out how to do that yet in software.

So um, but yeah, I do like tests.

Um I for my own personal stuff, I write tests.

I use Tox as my test runner because typically I'm um like I'm testing against a bunch of versions of Python and Django for like Django apps.

Sounds like Carlton.

Um I use I prefer the Python standard library's unit test module over PyTest.

Um left two places I think.

That's interesting have been PyTest shops, but I I prefer the unit test module.

Um can I tell what that is?

I'm not the biggest fan of dependency injection in Python.

Um and the particular way PyTest does it, I just feel like I at least I kind of struggle with it because I feel like fixtures can be getting injected and and found and loaded from so many different places that it's hard for me to know what's available.

Wait, where where did that one come from?

What does that one do?

It it just I have a harder time reasoning about everything that's going on versus like a unit test style uh where everything is right there on that class and I can see all the things it's doing, or if it's from a parent class, I can see what it inherited from and I can follow the import chain.

Like Carlton, I saw there's you know, you were waiting to Twitter.

Someone had

oh, I foolishly got on that, and I foolishly got so

It's just I like

Um I I think I think Django's built-in ones could have been done differently, but I understand why they were done the way they were.

But in general, I'm a fan.

And I think the issue is that we don't teach, we teach here's one line and you've got a list view, and that's kind of deeply mysterious.

Whereas if we taught, you know, a class with a get handler and then you declare your view, then it's just it's exactly the same as a function-based view at that point.

Um, but it's just got a bit more structure if you need to break your your you know, if you need to break it up.

And I think, well, yeah, that was my point.

Is that hang on, what are we what are we arguing about here?

Are we comparing function-based views to Django's generic class-based views?

Or are we comparing it?

And I remember how much more difficult it was to like add functionality.

It's like, okay, now I need another keyword argument, and I need another, you know, conditional in the body of the function to handle that keyword argument, and I need to account for it everywhere.

And if you if you ever go back and look, like maybe you know, link one of the old Django documentation uh versions with like the argument signatures of the old generic views back when they were functions.

Like it's it's a gigantic list of stuff.

Like we we wanted the functionality before and after to be the same, and so that's why they were written the way they were.

That's why, you know, if you wonder about like choices that seem weird in terms of what's broken out into a mix-in and what's inherited into the it's because there was a deliberate attempt to preserve exactly the set of options you had with the old ones, so that you could just go straight from one to the other.

And for those, they they're kind of you know at 1.8 time they were sort of feature equivalent, but they're just a more direct style without the mix-ins.

And so I always recommend people because there's only like four files in that package, I always recommend people to go and read the source code of Django Vanilla views because it kind of it it's really eye-opening.

It's like, oh yeah, actually, what's going on here is just turning requests into responses, and you know, there's not too much to it, and then yeah, you go back to classy class-based views and the Django ones, you know, ah, the same thing's happening, and it's that's a nice learning.

No.

I mean our our our USP is we don't break stuff, right?

Yeah like and we can't we can't change the generic class-based views that we ship.

Uh I you know, maybe, but no.

If you ask you,

So, you know, Django.new generic.

Yeah.

Oh Carlton.

How's that?

It's great code, it's well documented, it's well tested, it's got everything going about it, it's just there's a learning curve, and it's not perhaps as clear as we'd lay out if we started fresh.

Yeah, yeah.

But that's okay.

Well, you meant

That you know, when the class-based generic views were introduced, they had to be uh exactly equivalent feature set.

Yeah.

So Gornwell, did you want to

So Yeah,

Like it it's it's really good, it's really well

written, and I do

It's just for for me personally, it doesn't quite fit my brain, and I find it a little harder to reason about.

Like that's why I prefer the unit test style.

Okay.

How did here's a question I'd like to ask ORM contributors.

How do we make how if you're if you've got a young contributor who wants to come along and they want to get into contributing to the ORM, how do they approach that?

How what's the the route in to grokking the ORM?

Because it's it's big and scary and multifaceted.

Yeah.

Tim Craig.

Yeah.

I was like, where are you where are you not rock solid?

And he's like, well, the

ing out what was going on and that yeah, this is the right solution.

And she just kind of like tossed that off in the course of a sprint.

And we we we've always kind of relied on the the kind of genius level.

I don't I don't know how she understands the ORM that well.

The MIT.

Um we we've we we need to do better with that.

Like the ORM, I would say first try to understand the different abstractions, like start with you know, models and managers and query sets, and then you know, maybe look a little bit at query, look at database backends, look at the like the query object, um, look at the SQL compiler, like learn to think of you know, query.

I actually think a good analogy is to learn how the template system works, and learn how the template system like parses into a tree of nodes and then walks through rendering all of them because what the ORM does effectively is build a tree of expressions and walk through with a SQL compiler, turning them into SQL, uh, and kind of understanding that pattern and what the major abstractions are, and then you can start reading like some of the scary source

code in you know query logic and I haven't looked at that in a while.

But it it it is

That reminds me, we we had Carson Gross who who wrote HTMX, and uh he's a big fan of writing uh programming language from scratch and teaches them now.

And he was he had some line, he's like, Oh yeah, you know, I just wrote a programming language for this problem, it's easier than you think.

I was like, for you.

Okay, and just go through like okay, here's where we're gonna parse it.

It because the the Django template language is incredibly simple.

And the implementation is not that hard.

Like if you have if you're if you're really motivated, you can probably read through it and work it out yourself.

And and if not, like a little bit of guidance, I think, will get you there.

Um like just introducing the concepts and what's going on.

Um, and then it when it all kind of fits together in your head and you understand, oh, that's how it does that.

And now you're ready to learn how to do that.

Yeah, yeah.

I need to decide.

I've thought about turning that ORM tutorial into a book, but I don't know if I'm ever gonna get around to it.

Well, you wrote a book.

You wrote a I have your you wrote yeah, I have that.

Uh that was you built a blog in it, I believe, right?

I had a copy of it somewhere.

Yeah, OG.

Don't taunt me.

No, you're not mi you're not missing out.

It's Will's just teasing me.

Okay.

And then recently there was a go on, it was recently you wrote there was a um few articles on um using Django's or the ORM versus service layers and things.

And I think that's really interesting because like why Django, why the ORM, like versus other approaches.

That's I think that's a massively interesting topic.

We can link to those blog posts, but it'd be nice to

Actually, we okay looked at those.

So here's an expert, here's an OG expert out in the wilderness saying, giving opinion on Django that's like I mean I feel like

It's the thing that if you're not using it, why are you using Django at all?

Um like the the request response abstractions are nice, but there are other libraries that will give you request response abstractions in Python.

So basically it's if you're not using the ORM, why Django at all?

Is kind of the question.

And I'm not sure the answer at that point is to use Django.

Um, like maybe you want some of the abstractions, you want uh like the concept of apps, but you want to use another ORM with it, or you

you're not using a

And you can do the kind of minimal Django.

Like uh I I think some people have even put together examples of how to do a very minimal Django.

Um, some people want to like hide the data access logic and you know have separate representations of like business objects and business logic.

And there are design patterns for that.

Like I mentioned in the blog post several times, like if you really want that, and if you really believe you want, you know, data objects and business objects and explicit logic mapping between them, you want the data mapper pattern and you want to use SQL Alchemy.

Um, and you want to use a data mapper ORM.

Um, but Django is not a data mapper ORM, it's an active record ORM.

And you're you're trying to take this design pattern that works fundamentally very differently from how Django's ORM works and push it onto Django, and that's not going to go well, and you're going to end up having to rewrite large chunks of the ORM to simulate ORM functionality in your service layer and introduce a whole bunch of complexity.

Like, I think in a lot of cases, the problem is, and I touched on this, I think, in the first blog post on that, is people trying to untangle interdependent code.

Like these really complex code bases where it's like everything does everything.

Like I worked on code bases where um like there were some models that had a policy that you always had to do um save with explicit field list because you didn't know what else might be modifying that model at the same time.

And so, you know, make sure to only actually um save the fields you're changing to the database.

Um, like and I tried to give what I think are some good guidelines for how to have models as the API of your app and what kind of access from other apps and other code into a set of models to allow.

Um and basically like things like you shouldn't ever reach into another app's model and start tweaking its fields directly and saving it.

Like, like don't do that.

Um, instead, you know, expose logical methods.

Like the joke that I've used a few times that I've always heard is you know, if you want to walk the dog, you don't reach down and pick up its leg and put it down and pick up the next leg and put it down.

You ask the dog to walk because the dog knows how to walk.

And building models that know how to do things rather than having to reach in and grab this field and set it to this, and grab this field and set it to this.

Um minimizing the amount of internal structural knowledge you need about those models because their public API, their list of methods that they expose gives you the operations you need.

But yeah, I think that's it's hard to do.

I I've advocated for it.

I've never seen it completely pulled off successfully.

I I don't know that I've ever personally managed to completely pull it off successfully, but at least putting in the effort and trying to do it gets you a little better results.

Um and and then the rest of it was kind of like, well, what do I do with these really complex things?

Like, you know, somebody's canceling their subscription, and there's like six different models that need to be updated when they cancel their subscription, and it's like, well, if you put that in a service layer, like saying, Well, it doesn't make sense for this thing to be on one model, well, it also doesn't make sense for it to be in one service method because it's doing all these different things.

Like that that's moving it around while keeping it that complex doesn't actually help.

Um, so that that's the other kind of issue there.

And there are patterns for that, but that's just a matter of like familiarity and experience, and sometimes it's going and looking things up and being like, how how do people do this?

There there are I think Brandon Rhodes has been trying to do like design patterns for Python, his Python patterns repository.

I don't know if he covers like anything other than like the the original design patterns book, but there's a lot of stuff out there on how to like how to handle these kinds of like complex cross-cutting concerns in code and how to break it down so that you don't end up with like the one method that does everything and touches everything.

Is there sp any more specific ones you had, Carlton?

Just James?

And most times if you're trying to do the web problem quickly, you don't need these extra complex constructions around it.

You just need to make sure that as you grow you you maintain hygiene because

yeah, it

But that happens to every project, no matter what architecture you use.

Yeah um I've

Is that home-baked bread behind you?

I see.

Yes.

Right, okay.

But I

was not the one

Yeah, right.

Nice.

Like you've worked at small companies, large companies, you've tackled all sorts of web Django problems.

What, you know, where you're at now, what kind of things would be interesting?

I don't I don't know.

I feel like you've been more on the code side, but I don't know.

Like what so anyways, what what are you looking for?

What would what's interesting now to you?

I don't really have interest in being a manager.

Um, I've been like sort of climbing the individual contributor ladder.

My last job, I was my official job title was staff software engineer.

Like I I put up a blog post about it where I said that I like working someplace where I can use my Django experience and be a resource to a team that perhaps is using Django and Python, but not being defined by it.

Um being able to do more than just be the Django guy at at a particular company.

And it's like it doesn't have to be any single particular thing, but just getting to branch out, getting to learn stuff.

Like I spent the last year, I didn't set out saying, I really want to get good at Docker, um, and I'm not really good at Docker, but I I s ended up doing a project that involved learning, you know, quite a bit about Docker, how to do Docker files, Docker compose, orchestrate, you know, Docker-based projects.

And that was really interesting.

And because they were Django services, they were being Dockerized, like there was an opportunity to use the Django specific knowledge.

But it wasn't just, oh, we're we've got a Django person, let's have him go do Django things.

Yeah, it it's that that that's the kind of thing that I look for is I don't necessarily know what's going to be interesting to learn, but having the opportunity to branch out and learn other things and do other things that aren't just being defined by Django.

Um, because it is important to me that like Django is important to me, and the things I've done with Django are important to me, but it's also important that I'm to me that I'm not one-dimensional.

That's not the only thing I can do, that's not the only thing I know, it's not the only thing I can learn.

Because the tech industry isn't great around ice in you know individual contributors.

There's there's a sense that trees only grow so high.

Um other other fields don't have that, but in tech there is a little bit of that.

Um, but I don't know how many companies actually succeed at that and how many teams actually succeed at wanting that, because getting getting to a level of of specialization with something, you can like it, but that doesn't necessarily mean you want it to be the only thing you do for the rest of your career.

Is that what you're so

I believe I was officially hired to be their JavaScript guy.

Um you you can see how well that worked out.

Uh like at the time I was like I knew Python, but most of what I did professionally was like a little bit of back-end work and then like front-end, like HTML, CSS, JavaScript translating, you know, ideas and designs into actual implementation.

And you know, 2005, 2006 era front end was a whole different thing.

I'm sort of curious, you know, where you're at now, which which of those two problems would be more interesting?

I actually did talk to a company that was hiring for um their fourth person and first to dedicated back end person.

Um, and that sounded really interesting, like the the chance to kind of like start from scratch and and have a hand in building everything.

Like we you know, we we're programmers, we always love the idea of just starting with that clean sheet of paper and saying we're gonna do it right this time.

Yeah.

And then that's that seems like that seems really good to me.

That seems like where I want to be.

Um like maybe one day I'll do the you know first backend person process and and start everything from scratch, but I don't think it's gonna be this time around.

Because I feel like a lot of it is somebody who doesn't have a uh the wisdom who might say, This is how we're thinking about doing it, and in a couple hours you can save them so much time, but you don't necessarily have to do it yourself.

I've I've done I've done contracting.

Contracting is expensive.

Uh it's expensive to be a contractor in the US at least.

Like, because there's so much overhead that people don't think about from being full-time contracting.

Like healthcare.

Uh you pay an extra 15% tax for being a contractor.

Yeah.

So it can be

Carlton too.

It can be tricky.

So I have one more question I'd like to ask you, and then we'll let you go.

But what what do you think it's something that I'm always thinking about?

What does it take to mentor somebody well, do you think?

The challenge I find is people come and they say, Oh, we want to mentor, but they don't bring anything to the table.

And how do you how do you find that balance?

Um, in in my professional career, like working for companies, I've had a little bit of success getting people from kind of like post-beginner intermediate into like advanced intermediate to senior.

Um, like working with people who already had some basics under their belt and getting them kind of to the next level there.

I've had some success with that.

Um, I have never felt particularly great about my ability to start someone like from scratch and get them, you know, zero to at least kind of like a reasonable like beginner-junior, you know, first job level of knowledge.

So I don't know exactly um how to answer that.

Like the things that I've been successful with have mostly been like pointing people at resources that are kind of interesting and kind of showing, like, here's a pattern that you might not have run into, but we can do that for this thing.

Um like not necessarily telling them, oh, do it this way, just kind of showing them what options are out there.

Yeah.

Because I I think that is the kind of thing that's one of those things that as far as technical knowledge, as as you grow, um, is kind of your mental library of patterns and possibilities and options that you at least know are out there, even if you don't consider all of them for every single thing you're gonna do.

And so I've had some success with that, but I I don't know I don't know how to replicate that necessarily, and I I don't feel like I've had great success with um with people just starting out.

Okay.

Uh the one the one time I did

Yeah.

Yeah, yeah.

So you Yannis being like Django's second biggest contributor of all time.

So yeah.

Yeah.

More or less, yes.

Super.

James, thank you so much for coming on and just sure sure sharing your opinions.

Oh, thank you.

Check out James's talks if folks haven't seen them already.

And we are at Django Chat, chat Django on Twitter, and we'll see everyone next time.

Join us next time.

Bye bye.