Transcript: Django Testing - Jeff Triplett

I'm Carlton Gibson.

Hi, Jeff.

Thanks for having me.

So I'm pleased that we're finally making this happen for episode 20 or what or whatever it is.

So I was trying to think of how to describe your role in the Django community, but I thought I'd punt it to you because you do so many things.

So if someone said, Who are you?

and what is what do you do in Django, where would you start?

So I've been a lot better at saying no for a while.

But um yeah, I I am a Django and Python developer in Lawrence, Kansas, which is the home of Django.

Um I I do a lot for the community, but I am a PSF board of director.

I'm the president of DEFNA which is the nonprofit behind DjangoCon US.

Um, also been the former chair, I'm kind of an advisor organizer for the the conference too now.

Um I'm a Python fellow, which is not the same thing as Carlton's Django Fellowship.

Um I'm also a consultant and a partner at Revolution Systems in uh Lawrence, Kansas, which is what pays my bills.

So all right.

How should we refer to it?

We just kind of say RevSys, you know, shorthand.

So it's kind of like DEFNA, the nonprofit I'm a part of is the Django Events Foundation of North America.

It's just easier to say DEFNA.

So Revsus is the same.

So um given that you are a professional consultant, one of the things uh wanted to ask you about is the testing.

So this is something that Carlton and I are asked frequently by readers, uh excuse me, by listeners.

Um and uh, you know, I think as a consultant you have sort of a unique view because you get to see a lot of different code bases, um existing projects as well as new projects from scratch, whereas most people are kind of working on the same code base for years at a time, and so they don't necessarily have a chance to think about how they do tests.

So I'm curious if maybe the the three of us can just talk about testing, and I don't know where we start, if it's on a new project or an existing one.

Maybe we'll start with an existing one because we've had that conversation where

Let's start there.

That's the archetypal one.

What do you do if you get a little bit of a test?

Yeah, yeah.

What do you do?

So usually we're kind of somewhere in the middle.

Um, and especially like as a consultant, you have a problem and you're coming to us either because you want some, you want to build something, or you know, you've got fires every time you deploy code.

So starting from no tests, the first thing I want to do is basically lay down a simple layer of tests.

And so I want it, I want it to be effective because I do not like writing tests.

I I don't know that many people who really like writing tests.

One of my coworkers, Lacey William Central, um, she loves writing tests for some reason.

And so you open up a test file, you can see thousands of lines of code.

Um, not what I do, but what I will do is I think the most um the most effective way to start is to look at your views in Django.

Um, if you're doing Django Rust framework stuff, you can also do endpoints, which is also with view in Django.

So I'll start there, and what I'll try to do is just a really thin layer of test everything that's a view, record the status codes, and just see what they are.

And so you'll get a lot of 200 status codes, which are gonna tell you that everything is working in some way.

It may not be working 100%, but at least Django is telling you things are fine.

Then I'll go through and and I'll still record like 400 and 500 error tests or status codes, which is gonna tell you that maybe there's a piece of data missing to be able to see that view and to have all the information come up.

And so once we kind of very quickly go through and just get some kind of test coverage, and then that way at least we have a test suite.

So if I go in and delete a bunch of code or I make changes, it'll at least tell me if the status codes are going to be the same.

And then once we have that reassurance, then we'll go back and start looking at, you know, why is there a 400 error on this or a 404 in this particular view?

That may be that like I'm trying to hit a blog article or something and it just doesn't exist.

So then that gives me room to be able then to do like generate some data or use a like a factory library which will, you know, create fake data.

And then I can start testing against that to see, you know, does this view work as it's as expected?

Um, after that, then we'll hit the 500 level code or 500 excuse me, status codes and start making sure that um, you know, we we have the parts of the view that need to be there for the application to not blow up.

So if it's a blog or something, there might be categories, there might be tags, there might be authors, um, there might be some other bits of information there that's needed just to construct that view and to make it make it testable.

Um, once this is done, uh another pass I like to go back and do is Django has a really nice um feature called assert num queries inside the test framework.

And so we'll use that then to start like measuring how many database calls each view has.

And this is usually what's pretty critical.

Like if you call me because your your homepage is slow, when I start looking at how many database queries are on it, you may have 200 database queries or you might have 2,000.

So that's kind of a good place to start.

And if like every view starts to have like a ton of database queries, that may mean that you have like a part of middleware that runs another request that's going to be hitting the database more than it should.

And so, and this one once you kind of have this base level of test and know the status codes are good, you know where the database queries are, then we can start making performance decisions.

So we've had a lot of like nightmare stories where we had a middleware one time where a client was hitting uh their database and pulling up and trying to do a, I think this was like the earlier prefetch related days or something.

Um, or yeah, I think it's prefetch related.

So basically prefetch would load up everything associated with a table.

So it might do like a lookup, early lookup.

And so this was a case where somebody had, let's say, 250,000 categories, and so every single request made to any page on their website was reloading this table and they weren't caching it either.

Yeah, I was gonna say

Yeah, yeah, yeah.

It still would be bad because that's a lot of data that's got to access on every request.

So that was like a pretty blurring, like that was an easy one.

Like, let's just eliminate this one middleware, cache this one request or this access so that it only gets hit one time, and let's limit actually how much data it's pulling in, and then your website's gonna be a whole lot more performant than it was before.

But without tests, without looking at database queries, there's no way you would ever know that that's actually what the problem was.

Is that what you're what you would use?

I think it's a great tool.

Um I just go straight to the test on that because it's gonna tell me more.

And you know, most of the time I'm dealing with back-end code.

So if I'm working on APIs, it doesn't really buy me much.

And I again I think it's a great tool.

It's just where do you spend your time?

And for me, most of it is just running tests.

Yeah, so there's actually sites that I've developed features for and APIs that I have probably maybe looked at the back looked at the actual front end at it maybe once or twice.

It's like, yeah, this is that's quite handy, but that's a template layer rather than what Jeff's talking about.

And where does where does logging fit into all that?

Or does it?

Um, we we've dealt with some pretty big systems where you know we're basically spitting out uh JSON via Django struct log, and that's getting consumed by um like another process.

So especially like in the Docker world, like we're collecting the logs sometimes and aggregating it to um uh like another system where we can go in and and check and see what's going on.

So we can leave clues about metrics of this user logged in or this user did something else.

So it kind of depends on what you mean by logging.

Like fair enough.

Um well so how so what about if you have a a greenfield project?

Um what is how do you how does RevSys think about testing in that capacity?

Do you have an internal um framework that you use on new projects or or what what's different versus an existing project that you get?

So, you know, and again, like I tend to start with views and and part of it really depends on what the clients uh like what's their business objective.

Um like right now we're working with a with a client that's a friend of mine, and it's basically like a a brew pub type service where you can walk into a restaurant, you can order food, uh, they can bring it right out to you, and you can do everything through your phone, which is kind of nice.

Because if the restaurant's busy, you don't have to worry about waiting.

If uh you know five of you sit down and a sixth and seventh person sit down after you've already made your order, then they can come back and bring you food or drinks or whatever.

I think this is like the norm, plus it, yeah, not so much in the US yet yet.

We'll write a little bit of model test for it.

Uh, but we're basically looking at what's the business logic.

You know, is the business logic or is the main core part of the application gonna be inventories or is it gonna be the ordering systems?

And then we try to prioritize like what is the bread and butter of the application that has to work perfectly, and then that's what we're gonna make sure that we have 100% test coverage on.

And so from there we just kind of distill it down.

If you have about pages, you probably don't need anything more than just a simple test to know that this thing doesn't blow up.

And like I was talking about database queries earlier we just want to make sure that somebody doesn't add a template tag to pull in news articles or something and you end up not getting a select related on and all of a sudden you've got a couple of thousand database hits on your homepage because that's really frequent.

I'm wondering what sort of um how how do you think about you know that question of where to put the logic and obviously that can change over the project as you build things out but do you I mean do you subscribe to the fat models slim views approach or

I mean it kind of depends and part of being a consultant is people are very opinionated.

So some people will have thousands of lines of business logic inside of models and I I it it's hard to follow and so I I usually like a mix of in between uh with views especially with endpoints and stuff for doing like rest APIs if you put too much of the business logic in like a traditional Django view then you're gonna lose that whenever you're using um like Django Rest framework.

And so I tend to try to do as little as possible with a web request.

So sometimes that means we're taking the actual logic and maybe putting it in celery so I had an application I worked on a couple of years ago where they would literally get millions of hits um sometimes during really active like news and stuff like that.

And so people might come and do a bunch of donations and so what we would do is batch order those those requests up and we put them in celery to be processed because we don't want like any blocking to go on when you hit a form or when you hit an endpoint.

We want to try to get the request you know we want to try to get a response back to the user as quickly as possible.

So in that case we want the view to not really do much but do a quick validation check, get their information, batch things up, put it inside a celery make the actual request go through and then we can like email them later to give them the you know congratulate or thank them or whatever.

So it really just kind of depends on the application.

I know signals aren't really popular.

I tend to not want to put a lot in signals but I do tend to use signals as an easy way to hook into parts of an application to call celery and that's a pattern that I'm pretty comfortable and happy to use.

But uh Lacey and I, Lacey Williams Hinchel, we uh are coworkers and we worked on DjangoCon together for four or five years.

And um one thing that we get a lot of especially being in business meetings now that we work together is you know there might be four or five guys in a room and then there will be you know one woman and then someone will repeatedly use the term guys over and over and over again.

And it's kind of one of those once you hear it you can't unhear it type of you know statements or phrases.

And it's really common.

And so a lot of people will say like it's okay to use guys because it's gender neutral.

Well you know if I were to just use hey girls or hey gals in a room full of men people would notice and you know it's there's just you know there's there's better ways to speak and so it's an easy uh way to make people feel more inclusive and not make people feel exclusive.

So we wrote a site and I'm gonna have to look it up I think it's heyguys.cc.

And so it just kind of reinforces it.

So once we've started using like y'all um I've had clients thank us after the fact and we don't correct them.

It's like I'm not gonna stop you in a meeting and say it.

It's just kind of through osmosis of the more that we can say this, the the more that you know people will pick up on it after a while.

It's not necessarily that there's a conscious prejudice but there's this kind of cognitive bias and this kind of um paternalistic language that we use and if we just think about it we can start to change it and perhaps we change the attitudes that created it.

be able to debug and look at the code through tests to try to figure out you know what's going on and and PyTest just seems to work well.

It's a pretty good standard.

You can basically just install it and run it.

In most Django apps I've used I really haven't even had to do much to actually just be able to you know install it and run and it just goes so actually I think in a couple dozen projects I've never actually had to change any code to work with it.

Refsest does have an open source project called Django Test Plus and it kind of adds some nice wrappers around the Django test suite.

And I believe the last couple of versions actually has some better PyTest support for it too because PyTest tends to like this very like functional view type where you can make easy test functions and you don't have to have like a class and and stuff and Django test plus actually well Py test kind of has some nice wrappers around not needing like a what would you say like a class based test approach.

And so I I tend to since I learned a class based test approach that's what I tend to do with with Django just because I don't know I've got a pattern that I like but I do plan to spend some more time writing a like a PyTest native looking tests.

But I still like um the unit test style classes because they help me group tests and perhaps that's just because I'm not quite into the PyTest idiom yet but you know I've that's kind of where I'm at with it.

You'll see you know maybe an open source thing just has a a bazillion tests and it's hard to make sense of it yet most people if they just throw something up maybe won't have tests.

So tests are I think of them as they're really confusing until you learn kind of the standard tests that you write every time kind of you were mentioning you have your standard views tests and then they get really boring because you're just kind of tossing them at everything.

So that's sort of the the leap is like you want to get to the point where you go oh okay I can just you know kind of copy these tests that I've written elsewhere to this project.

But until you get to that point it is this feeling of well I don't even know how to get this page to work and now I'm supposed to write tests and oh I'm supposed to do test driven development and write the test first.

It's like well I don't know where I'm trying to go.

That's kind of the mindset I see of beginners.

And so maybe with that said I take it you don't do a pure test driven approach or or how do you think about that?

And so I actually I kind of do a Django admin first approach.

So I'll write the models and then I pop them in Django admin because I feel like everything else in Django kind of derives from that that pattern.

I agree so when I start doing Django um Django Rest framework even a lot of the filter options a lot of the way the data fits together the admin for me kind of models that very well and so I once I can see it and visualize it and it's pretty easy for me sometimes to discuss with other developers like how to make model changes that maybe they're struggling with just because I will go into the admin, I'll create the models and I'll interact with it.

And so it's easier to see like a mini to mini in this situation may not be the best, you know, the best way to model something, especially when you start getting into like Django Rest framework, because dealing with many to minis, especially when you're doing like nested serializers, so you've got you know multiple layers of models deep or you know model references in JSON, it it's it's hard to work with.

And it's really, you know, you've got these really cool rapid design tools with Django and Django Rust Framework.

And as soon as you start getting into nested serializers, it just all kind of falls down and you're doing everything by hand.

So Carlton, you work on Django Rest framework.

Um can you fix that?

Um like it's there's a limit to what's auto-introspectable within you know reasonable effort, unless you know you have to be I'm I'm fairly sure that for some specific framework in a specific setup you can create some code which will introspect much better than what's available in Django Rest framework, but that will only apply to that particular project, right?

And particularly with nested serializers, like that there are different conventions.

Are they meant to be read-only?

Are they meant to be writable?

If they are writable, how do you handle conflicts?

Do you do you abort the whole request?

Do you um write the ones which don't conflict and then report the errors on the one that do?

How does that look?

What's the format of those serializers?

Those are decisions that a framework like Red Django REST framework can't make for you.

Um, not yet, not in this stage in the technology where the technology frontier is.

Um yeah, what else can I say?

I I I you know I'm not at everything you said.

Yeah, it does get complex, especially you know, if you've got a many to meta with the many to many with a through model and you want to serialize some attributes from the through through model on the nested serial, ah, this you've just got to make those decisions.

And yes, I think ultimately you have to write serializers by hand.

In terms of is it do you use it all the time on projects?

Do you try to convince clients of that they should switch to it if they're not?

Where do you fall on that spectrum?

Um, and I say this, you've you've actually taught me a lot about Docker over the last few months, so I know you know how to use it, but I'm curious what your preferences are.

Um I think it's overused, and sometimes people, you know, they see Docker as a hammer and they just try to use Docker to solve everything.

Um Jesse Frizzell, who I'm a huge fan of, um, she's written some really amazing Go code, and I I think she's written pretty much everything.

Like I've seen discussions before Spiral Online where people are saying this part of Kube is broken, and she's like, No, I fixed it, and there's like, well, this is a bug, and this is something that's a bug in Docker, and she'll point to literally her commits in like kube or Docker, or they'll then complain that this is a problem in a particular like Linux library, and she'll point to the code that she fixed also in Linux.

And it's just amazing to see people like that who you know can who have worked on and can work on Go code and and everything.

Um didn't she just have a tweet?

I think I just wanted to plug her because she's awesome.

And so she runs Chrome and Docker on her laptop, and so everything she runs is is Docker based, which is amazing.

Wow.

Um I like Docker.

My clients are kind of mixed on it, but what we can do with containerization is just absolutely amazing.

And I don't mean me as like a consultant, I just mean technology-wise, like when I compile a Docker uh container, when I make an image, I know that that's kind of a contract that it's going to run if I give it the right environment environment variables and link it to the right you know context.

So like if I know this thing needs Postgres and I it needs Redis, as long as I plug the right values in and tell it where to go, uh it's gonna run.

And I've already tested it, so I know how it's gonna perform.

When you start using like some of the container services, and I don't want to plug any particular one because they're all great and crap at the same time.

But it's really powerful to say, like, I can start this running on one node, and if I need a hundred of them, um I can spin that up in a couple of minutes.

And that's amazing.

And you can also, it's more you can take it from one uh provider to another much more easily because it is just containers.

Like once I have a Docker compose set up and I run tests on it, I know as long as you have Docker installed on your machine, it's gonna run.

And that can also run on like GitHub or GitLab, I guess GitLab, since GitHub doesn't have a test runner thing yet.

But you know, I can I can use CI tools to reliably run and test it.

And so that to me is pretty great.

But you know, I can give them a recipe that works, but then it I think it's a little much for them.

But it does, you know, fundamentally it it is the answer, which is a reproducible environment that all team members can have, and you can almost entirely uh mimic production locally too, which is pretty nice to do.

Is that easier?

So I let me just say that I hate deployment.

They're in a company or in an environment where someone else has figured it out or you iterate on it, and you just kind of like hold your breath and get through it, and then it works.

Um it's yeah, it's it's a pain.

I mean, I I tell people I usually recommend Heroku or Python anywhere just because they're pretty straightforward and they have free tiers.

Uh you know, actually with Heroku, so in my book, which should be out by the time this is released, Jenga for Professionals, I'm uh finishing up the deployments chapter.

And a big question I had is we use Docker in the book, do we deploy with Docker as well?

Because Heroku just added this um pretty recently.

And uh I think it's it's simpler when I show you exactly how to do it, um, but I don't know exactly if it's simpler than I think it is than doing it the old procy file way.

Um but there's just a lot of for Heroku, I mean Heroku in particular, uh there's just a lot of steps, right?

I mean, it'd be nice if you know Carlton or someone had a perfect drag and drop deployment for Django, but you know, collect static, you gotta configure static files.

Uh there's just a lot, a lot of things.

It's hard to go from a basic CRUD app to a deployable worthy project without taking a whole ton of short uh shortcuts.

Um allowed hosts, you know, deployment checklist.

So yeah, so that's a that's a rambling way of saying I haven't fully figured out exactly how to handle it, other than I know the two extremes.

Um and as I become more comfortable with Django, I'm less comfortable just sort of waving my hands at stuff and and not covering it for people.

But I am a still a big believer in an iterative uh learning path, and so I don't want to overwhelm folks with proper deployment.

So um it's tricky, but

I'm still a big fan of you know, run a VM.

And if you want to use Docker, just use Docker on the VM.

And if you need to scale it, get a bigger VM for you know to keep a lot of these things simpler, but that only goes so far, and eventually you do need, you know, 100 units, and then you need you know Kubernetes or whatever, because you know, VMs aren't gonna go that far.

What what do you think?

I mean, we actually just just had a whole episode on deployments where I think we we gave some of our thoughts.

I mean, it basically the advice is pick something, learn it, and then move on.

And if you have to focus on it, that's a great problem to have, and then you can take other steps.

But if you try to host your own, because if you have a website that needs to scale at all, you're not gonna use that model.

And so you're gonna go and you're gonna have to install, I don't even know now, Apache, you're gonna install a bunch of libraries and a bunch of stuff, and the average person's not gonna be able to do it.

And so one thing that I like, and I think you could actually do this kind of tutorial.

If you go and fire up a DigitalOcean, and DigitalOcean needs to sponsor you now.

I think we plugged them like four or five times.

But um if you go to DigitalOcean, if you install Docker, um you can actually run your base image on port 80, and you don't have to install really anything else.

And so that to me is pretty powerful to just app git install um Docker, run your image container.

You've got to do some authentication stuff that you have to do anyways, even if you're doing a Git checkout.

And so one thing I've liked is um through like GitLab or through Docker's registry, you can push images from your local machine to that.

You can run another Docker process.

I use one called Watchtower, and all it does is it looks for new images, it pulls it and it restarts the service that's running.

That's about the most simplistic architecture I can think of for how to run something if you're rolling it your own.

Now, that's built upon years of knowing, like, here's how these applications and these parts put together.

And that's really the challenge.

It's not that this stuff is so technical you can't teach somebody.

It's also that, you know, I kind of did all the crappy parts with Linux for a long time and I don't want to do that.

But I also want to know what's running behind the box because I don't know that I want to hand a container to, you know, a cloud provider and trust what's going on behind the scenes, or even know, like, if I'm paying X amount of dollars, how do I why do I get one Docker processor?

How many Docker processes do I get?

And I think that it's been kind of hard for cloud providers to be able to explain and sell that to people in a way they understand it.

What's Heroku's probably done the best job of that?

You know, you don't it's really hard to see how things scale.

And short of like putting them on there and trusting it and then finding you've got a big bill, it's you know, which you often read, you know, I I got $70,000 on Firebase or whatever.

It's like, ah, you know, how do you get it?

Um, you want to have such crazy traffic that you have a huge bill and then you it's worth the time to dive in and and solve it.

And I would add, I mean, this comes from uh even at scale, you know, if you can throw hardware at a problem, any problem you can throw money at, I think that's a good problem to have.

I mean, you know, in a startup setting, like, yeah, you can you need to find the money, but it's so much easier to throw money than some of these trickier problems.

So if it's oh, we just need more machines, okay, like that's that's a good problem, right?

Like you're always gonna have problems.

Um so yeah, you don't want a $70,000 firebase bill, but you kind of gotta blame yourself if you somehow you you rack that up, right?

I mean, were you just sitting there and you didn't see the analytics, you didn't see the millions of traffic?

Like it's solvable.

I mean, I was just going through the Heroku docs yesterday, and I've done Heroku so many times, and I was finding the container part confusing.

Like, I would love to have a simple Django project and just show how to, in I guess my words, deploy it on all these major services, but the challenge is that uh they don't have affiliate fees, so it's just totally giving it away.

It takes a lot of time and they change all the time.

Um but yeah, if anyone wants to wants to

I would love to do that.

I want to talk about the work you've done.

Oh, we're gonna jump right to that?

Yeah, yeah, yeah.

We've done Docker's.

Oh, okay, go on there.

And I would just love any sort of stories you can tell about the mismatch between what clients think and kind of what you see and how you have that conversation where someone comes to you with some outrageous request.

How do you how do you kind of talk them down from that cliff?

And you know, what words do you use when um they think something will happen, you know, can be done in a month, and you know it takes 12 months, right?

Because that that's got to happen all the time.

And I know I started the podcast saying I don't know.

My other

I mean, so let's say a client comes to us and they say, We want this really awesome service, and it's something that you know has taken years, years to build.

So let's say somebody comes to us and they want GitHub or something, we we could say, sure, that's multi, multi-millions of dollars to do.

And you know, we're a small company, so we don't have the man, you know, like the the labor or the the workers to do this thing, but you can't just come in and say, copy every feature of a multi-million dollar or a billion-dollar startup realistically and put it up in two weeks.

Like it's just not going to happen.

So it really depends on can we just evaluate is this even doable?

Part of it is if you come to us with a bad business model, and Frank does more of this than I do, so I can I can make it sound like a better story, but we do discuss it as well.

Um, if you come with us to a really bad business model and we know that you're not going to be able to be successful at it, or it's just a bad idea, then we want to also get paid.

And so if we can't get paid to do the work because of your bad business, then there's no reason for us to do it.

We don't want to be in the collections business, we want to be in the right applications and you know, do what we do.

So for me, it's realistically a you have a feature or you have an MVP.

So the site that we just finished that's been or we it's it's going through like a beta process and stuff where we're doing the brew pubs.

Um, they had a three-month deadline basically, and they knew they have investors and these are the marks they need to hit.

So if they say we need to be able to sit down at a restaurant at 6 p.m.

on a Monday, which is what they did, and order a couple of beers or a cheeseburger, that's that's what we know that the goal is.

So if we need to scrap other features, because the inventory management maybe doesn't matter as much because the order has to go through.

So for us, it's really a matter of prioritizing these are the features.

And when people come to us and say, we want to add this other thing, or an investor or somebody thinks it'd be really cool if we could do XYZ, it's just reminding them of the focus.

And that is, you, you know, this is the idea you have sold, this is what you need to do.

We can do these things, but the more things that you add, the more that deadline's gonna get pushed back.

And so I can do that, I guess, without sounding like I don't know.

I guess I'm I'm being a consultant as long as I have, I can tell people no and they thank me for it.

Where when I was probably eight or ten years ago, they probably didn't thank me.

They thought I was being rude, or maybe I didn't know how to communicate it.

So that you may I don't know.

I'm just sort of extrapolating from my own experience where you you find yourself in scenarios where unrealistic deadline after unrealistic deadline after unrealistic deadline, and you're saying that this can't be done, and here's why, but it's not that that's not necessarily being listened to.

And you know, software estimation is notoriously difficult, and managers notoriously don't listen.

So do you think that the like so I'm thinking specifically about this software estimation problem and like working with clients?

Um I mean, and and I guess the point I started one from was when you said eight or ten years of you know, eight or ten years ago, did you find you were able to make that point, or were you just did you find yourself in a not listened to then?

Um eight or ten years ago, I was at the Lawrence Journal World, and we basically I was working for one of their startups that was um basically so we I worked on Ellington CMS, which was the first Django app, or actually, I think it was technically the second Django app, but it's the biggest at the time.

And so we rolled this thing out to uh hundreds and hundreds of newspapers, and so we kind of got I got used to unrealistic deadlines, I got used to trying to do all-nighters, not because they pushed us to do this thing, but it just was like self-in-induced pressure to do it.

And then at some point I just decided I'm not doing that, I'm not gonna stay super late, I'm not gonna do all-nighters.

I can tell you what I can do realistically because I just don't want to do it.

Like life is too short.

So if a client wants to fire me for not, which never happens, because I won't work the weekend for them, then it's not a good fit.

And it takes a lot of privilege to be in that situation to be able to say that.

But um clients tend to respect us more for that because they don't want to be, they don't want to be stressed out because we're working on a feature an hour before they're supposed to show it, especially if like their income is based on this this demo being successful.

Most of the time, you when we deal with startups, that's a little more normal that you know they're kind of going from like funding round to funding round.

That's probably not most of what we do.

But you know, I think it's kind of a trust too that can we deliver it when we say we're gonna deliver something, we're going to do it, we're gonna deliver.

And it's just a matter of what features do we need to cut out.

I think with working on the projects like you do, you probably understand is it better to uh do the feature wrong or not a hundred percent, or is it better just to land the feature just to say you did it?

It it's got to be a good feature.

There's no point, there's no point putting in a broken feature.

So it if it takes you know longer to get in, that's fine because Django is a an upstream dependency of all these you know end projects.

But in a commercial environment, sometimes it's like no, this feature's got it's just got to ship on this date, and because the marketing department sold it to the client before the estimation was ever done.

Um it

I I mean it's you know, it's not great, obviously.

But it's gonna change based on their feedback and what else they need.

So, but we're pretty upfront about it.

So, kind of it's a if we take a project on and we know it's gonna be three months, can we deliver this in three months?

And you know, we we can whittle that back.

And and I don't know, I don't sit down with any like task tools that measure productivity or try to figure out how to do it.

Uh, when I look at models and kind of know, can I get this MVP up in a couple of weeks?

And if I can get the models done, the rest, you know, the DRF stuff.

It's just the the tools that we deal with are so mature now that it's pretty easy to kind of guesstimate, I guess, in my mind, what it's gonna take to get something at least, you know, plausible and passable.

Is that it's always the there's this idea, this meme, this trope that software timelines aren't estimatable.

But with mature technology that you've and you've done it a lot of times, and yeah, they kind of really are, because you know, oh, it'll take a day or so to put these views wrapped around this.

It's exactly that.

Can you model it, right?

And if you've got the models and that business layer, the views are a known commodity.

And that that's easy and quick for us to do.

If you're a front-end person, that's not the most useful thing.

If you're writing like an admin or something for it, like a JavaScript-based admin, then you know it may be a pain, but technically the job is done and you can hit everything.

And then from there, that's where we go back to that like what's the bread and butter of your application, and we'll start writing like very particular views so you can place an order or so you can get like a full menu with all the nested everything that you want.

And then that way we can work on optimizing those views.

But by default, I do push back on front-end people sometimes to say this isn't a very performant way of doing things.

So if you just want to save an extra request, don't.

Um, I'll make it easy so you can do batch requests, which I would love to see in DRF, by the way.

Well, there's a bunch of things we can do to make lives easier too that aren't always nested.

So you have one request for um ingredients, one for drinks, one for you know whatever.

And but the request that front-end developers want to make is one request fetching you know all of these and all of those and all of those and combining them.

If I'm really hopeful that the async stuff will enable us to build quick proxy endpoints that will really serve um front-end developers really well.

Um so I don't know if that's gonna come in DRF per se, but it'll be part of the Django async move, I think.

That's what I'm hoping.

As uh somebody who does a little bit with with Django Con, I uh think we have a few fun surprises coming up.

So all right.

And maybe we could start with uh so when when we met at PyCon, you mentioned you were off to the what uh Python board meeting.

What what's the titles for that?

And then we'll get to the Django specific stuff.

So you so you're involved with you're sort of like the Django representative on Python right now?

And so a year ago at PyCon, I just a couple people came to me that were directors and they said they were gonna be stepping down and asked me to run.

And so I thought, sure, why not?

Um I really didn't think I would get on the board, and then I think I was on a flight from Chicago coming home, and my phone blew up when I landed, and apparently I'm on the board.

So um, I didn't think they knew what they were getting, and I don't think I knew what I was getting into.

So it's been good.

Um, it's it's basically a lot of meetings, a lot of email.

Um, the the Python Software Foundation is the nonprofit behind the Python language, and so what they try to focus on is the education and the community and growing the community.

So, like if you have events, you can um hit the PSF up for money to try to help and spread the word about uh Python.

I'm still new enough to it that I don't kind of have the spiel down, so I'm still trying to learn it all.

So hopefully none of them listen and then cringe whenever they well,

Well, so what is uh uh so education, community events, are there are there discussions about the language itself and features, or is that handled about handled by a separate part of the organization for Python?

And so um I don't know the timeline, but that recently has changed into a council, which I guess they discussed at PyCon.

Um so the the the board itself has nothing to do with the actual language as far as features and stuff goes.

When they're gonna have meetups or they want to try to like get the all the C Python devs together to work on stuff, I think they do it like once or twice a year.

Yeah, so anything we can do to aid uh CPython for their meetups or their, I guess it's like an in-person meeting they'll do a couple times a year, at least once a year.

Um, if we can help fund that to try to get everybody together, because not everybody works for a big corporation and can afford to go, then really anything we can do to support the community and support that movement um is good for Python.

And that's good for Django and good for all the projects we like to work on.

Yeah.

Do you have a you have a specific title as well within that these days?

I think I'm just a contributing member.

I don't know.

Carlton, do you know what that's called?

I I don't know if there's cassies of that.

There's a DSF.

If you're a Django user part of Django community, go to the um uh Django Project.com website, look for the Django Software Foundation.

There's an a a form you can fill in and you can you know apply to join this.

No, it's not like a there's an entry criteria other than you know just that you're a real person, I guess.

Um but join the join the DSF.

There's a mailing list for that, which you know it it it's private in that only DSF members are on it, but it's not private in the sense that you can't be on it.

Um and that's about the DS the Django community, and you know, there's it's it's not particularly high traffic, so do join.

Um but I don't think there's

Am I right in that?

Um yeah, I don't even know where to start with.

With uh how did you get involved?

So you how how did the ball of organizing Django Con land in your hands?

And um I've I've kind of been to most of them.

I've probably been to half or 75% of them.

Um after after like everything started off as a community model, a couple of things didn't work, I guess, out very well.

And so it kind of became a commercial model, which worked for a while, and then that didn't work out.

So I just happened to go to one where things really weren't working out at all.

And so I just kind of volunteered to try to like make sure that you know there were speakers and there was stuff going on.

So I I guess you could say I was the last minute program chair with about a week or two weeks' notice.

And so I just I don't mind begging and asking people for help.

So I asked a couple of people if they would speak.

I think Russ spoke like three or four times at the conference.

So thank you, Russ.

That was amazing.

And then we um basically made sure that DjangoCon happened.

Russell Keith McGee at the time was the DSF president.

He asked me if I'd be interested in maybe, you know, trying to at least get the next Django Con going, even if I wasn't going to be involved with it.

One of the speakers who stepped up and really helped a lot was Craig Bruce.

And so he said, if you're in, I'm in, we could maybe create a nonprofit and start this.

Um, Stacy Hasler, who was at the time, I think the DSF maybe treasurer, um, she volunteered as well.

And so the three of us started the Django Events Foundation of North America.

And our goal was just to make sure that DjangoCon US happened.

And then after that, things kind of were going a little better.

Every, you know, the community got really behind it and was really, you know, helping us grow and do good stuff.

And so, you know, when we were just basically trying to have a conference that, you know, evened out every year or hopefully didn't lose a bunch of money, we started taking the extra profits, putting some of that back into the DSF, putting those back into other Django events and Python events that we feel you know support the community.

And so that's kind of how that ball got rolling.

And so, and one thing that's sort of really noticeable about the Django community is the um, for one of a better word, outreach, you know, that to make sure that um the speakers are representative and that um you know everybody can attend, or you know, that it's not just not just white men in a room, for want of a better phrase.

Um, so how how did that get going, or you know, what what's the what's the birth of that and that kind of important stuff?

Because for me, it's one of the features of the Django community that makes it worth hanging around for.

And it was really odd for me walking in and knowing four or five of maybe ten women of 200 people.

And so it was just a weird experience.

It was mostly white men.

And so from there, when I looked at, let's say, Django Con, when some of the years were going pretty well, um, representation wasn't very good.

Like we probably the first, and I'll just throw out a number, maybe the first nine or 10 years of Django Con, I don't know that we had a single woman speak as a keynote speaker.

And so looking at that, whenever I was the program chair and started doing like my first actual all-running Django Con, um, I wanted to make sure that we prioritized having a couple of women speak.

And so I think by the time I had my first two keynote speakers of the three, realized these are both women, which was very intentional.

And then I was looking for recommendations for another speaker.

And so I said, you know, got information, you know, got got this list of people that we could maybe pick from.

And and I picked a couple of people that like I was, you know, fans of or uh friends of mine who I really thought a lot of because maybe they helped me in technology kind of get my start.

And so when we had the opportunity, and I realized like this could send a really powerful message to have like three women keynote speaking, and so it was partially by design and partially just kind of happenstance, I guess.

And once that happened, then I think it started sending kind of a message that this is a little different than your average tech conference.

We're gonna prioritize something very different.

And I think it's like the Ruth Bader-Ginsburg, and I'll get the quote wrong, but it was like how many.

I think somebody asked, I should probably like look this up.

It's like how many uh women is enough to have on the Supreme Court.

And I think she basically said all.

Yeah, like it would not be a problem because there have been all men do this thing for so long.

So I'll you know, we didn't have any rules that like XYZ needs to be all men or women or people of color.

Um, what we did do is kind of look at what we've done in the past and notice and then decide that we need to we need to kind of change the way maybe talks are picked.

So let's make it a community model.

Let's go to a blind, you know, type process, then let's go to a double bind blind process.

That way, you know, when you start taking out speaker names and you start removing the bios from um, you know, proposals, uh, it really changes the people at the top.

So you don't always get the same people all the time.

And so we do have some people who are very spectacular, and even though it's double blind, even though they don't put their bios in, they're always gonna be the top 10 as far as reviews go because they're really good at what they do, I guess.

So so I think changing that emphasis was a little better.

And then from there we kind of learn from mistakes, like you know, because we had that first year where we had three women, um, it was a very valid criticism that we had three white women, and so we should, you know, we have a lot of underrepresented people in our community, we can do a better job, and we've just kind of iterated on it over the years.

It doesn't, you know, it's going from here to there, not we're terrible.

Let's give up.

Like, if I get my pick at who I want to speak at a conference, then why would I not ask Jesse Frizzel to be a keynote speaker?

And she's not this year, by the way.

But you know, there are people that are just doing such amazing things that the people who I started following on Twitter definitely changed a lot.

And so every year when we ask for keynote speakers, we just look at who we have.

And like this year, I don't pick them, I haven't picked them in a few years, but I'll give recommendations on, you know, maybe people that I think would be good.

And we do get a lot of white men still, but it just kind of comes down to who's gonna give the right talk at the right time.

And you mentioned async earlier, like how cool would it be to have a Python async kind of keynote for this year?

So maybe that happens.

Yeah.

So you have, I know, a number of side projects, all three of us are, I guess, Django developers of a certain age with kids.

What's what should we discuss that would be interesting to people?

And I think that works for relationships, uh, that works for community projects, I think it works for clients.

Um, and that's the one thing that I think that the more time that you spend making the campsite better or you know putting effort into making the community better, I think people who also identify with that are also gonna put their efforts into trying to do that.

And so if I had any like parting wisdom, it's follow the campsite rule.

And then the kids stuff I think is great too, if you want to talk about that or yeah, whatever you guys

I mean, side note, we can edit it out if we don't like it or we can include it.

People tend to like that stuff.

And when you're young and you can perhaps have a lion on the weekend or whatever, you you can maltreat yourself and somehow get away with it, but actually it has a cost which perhaps you don't notice.

But once you've got youngsters, because on the weekend they get up at exactly the same time as they do every night, there is no lion, there is no break, there is no day off.

So if you don't care for yourself, you can't perform, and you can't perform as a parent, and you can't perform at work, and you can't keep going, not just this week or this month, but all year and all next year, and for the next 20 years when they're they're gonna need you.

Um and so for me it's a that it that's this kind of lesson, professional lesson I learned as a parent was about self-care and the priority of self-care, and it's much more important than some project deadline that's fake and all the rest of it.

That was that would be where I would begin.

So all the things that you know you need to do, you know, like stay up to date with Django, add tests, you just have enough experience where you go, I'm gonna prioritize that over maybe this new feature or this rush deadline, because you just know how it's gonna play out and you've seen the record play.

And you know, again, hopefully this is wisdom.

And you know, I it ultimately it just makes you more it does make you more efficient.

Um I think maybe the challenge is that it's can be hard to communicate that efficiency to someone else who doesn't have that knowledge.

Um but it's certainly I I mean I feel like I'm every year I'm a better Django developer and it has nothing to do with the number of hours I put in, but it has a lot to do with to your point, uh Jeff, initially, of knowing what to say no about and having that framework for making decisions about um you know personal time and then also professional time.

So I'm either gonna be all in or I'm gonna be all out.

Like I I don't I don't like the middle on that.

Maybe my kid has taught me that a little bit because my kid just does not care.

My kid doesn't care if I have a deadline.

You know, he's happy to come to my you know computer.

He loves like Amazon Echoes and Alexa's, so he will point and say bus.

And that's really all he cares about is he wants to hear Will's on the bus.

Um, he just doesn't care about deadlines, and so there's just something about that that I definitely and I I guess I'm the only person here with just a kid.

You all have multiple kids, uh, which is just I don't even know how you do it.

Let's go outside, let's do these things, and so um that's that's kind of nice actually.

And so I've had to kind of learn that I need to be more concise.

And if I do, like if he has taken a nap, maybe that's an hour, maybe that's two hours.

But it definitely changes that I've got two hours whether I'm gonna do something around the house or laundry or whatever.

Um, I definitely approach it very differently.

And to me, it's not an art what we do, it's it's a job.

So I I don't really worry about like writer's block or coding block or plumber's block.

You know, there's it's just I I've got this amount of time, I'm either gonna get this done or I'm not gonna get this done.

And so I kind of pick and choose what I'm gonna work on if I have the luxury of working on something based on what I think I have available in that time.

So I I that's the one lesson about having a kid that was amazing for me is that you know, flow is just non-existent when you're a parent.

I feel like

So when you do have those gaps, you say, Right, I'm you know, I can get a lot done in 20 minutes actually on this coding thing if I have to.

Um no go ahead as well the the the thing if you spend time with your kid, you're qual you know, you you're spending time with a kid, you your right brain, your creative bit of your brain is busy working on the problem that you couldn't solve anyway, and you come back to the computer later on and you've got that 20 minutes say, and it's like, yeah, there's a solution for you.

And that was kind of free work in a way, because you didn't have to sit at the computer laboring for it, you were playing with your kid, and it's like ah you know, the the the life pays you back for being present, and it's like thank you.

Well said,

That's awesome.

Thanks for coming on the show, and uh, thank you all for listening as ever.

If you've got any questions, you can find us on as uh Chat Django on Twitter and or at DjangoChat.com.

All right, bye bye.

Bye.