Transcript: Understand Django - Matt Layman

Hi. Welcome to another episode of Django Chat, podcast on the Django Web Framework. I'm Will

Vincent, joined by Carlton Gibson. Hi, Carlton.

Hello, Will.

And we're very pleased to have Matt Lehman back on to talk about his new book, Understanding

Django. Welcome, Matt.

Well, thank you.

Thanks for coming on.

So a number of things to talk about, but maybe you're one of the more prolific people out

there. I'm always impressed by the fact you have a day job. You do the books, you do these video

casts every Wednesday night. You had a podcast for a while. Um, I guess, how have things been

the last two years? Are you still doing all those things? Are you still managing to keep all those,

uh, all those plates in the air? No. Uh, some of those plates have definitely crashed on the

ground and broken and yeah. Um, it is, it's tricky keeping up with it and, um, you know,

burnout's a real thing. Uh, life is a real thing that happens to you. So, um, I've done,

I've managed to do some of them, but, uh, definitely we'll chat about some others that

probably have not continued to the level that I would desire to. Um, but it's been good overall.

Okay. Well, I, I do, we will talk about the book, but maybe we could start your day job is quite

interesting. Like, can you give a quick pitch on what that is and the challenges you face? Cause

you're still, you're still, I believe in the healthcare space, right? That's right. Yeah.

so i i work for a company called included health and last time we were on that company was called

doctor on demand uh we we merged with another company um named grand rounds health and uh

now we're kind of like the i don't know if you're the power rangers reference of megazord or voltron

for those of you might be of a different generation uh we've got all the health care

pieces bolted together now uh and and do some really super things for people in the u.s health

care system ranging from telemedicine to helping you with billing claims and finding you the right

doctors if you're dealing with some kind of acute need for medical care so that's what the company

does and and Django is definitely still a big big piece of all that. Can I just talk about the

sector for a moment because it seems to be the big thing like my phone company are trying to sell me

you know a similar not you know your service come in europe but like you know um access to a doctor

online and these kind of things it seems like a real growth industry yeah i think space certainly

since um when we when we hit the covid period that was a big jump uh in in access as you might

imagine because people did did not want to leave their homes or were recommended not to um and so

we had some, some serious scaling discovery issues there where we're like, Oh geez, the world's on

fire and, um, we need to be there to help. So, uh, we did a lot of work to, to make sure that our,

our Django site, um, was able to handle all that traffic. Uh, there's a whole other side of making

sure we have enough doctors to, to meet demand, but that's a different kind of, um, problem to

deal with. But, uh, yeah, when, uh, it, it did over time, it has like come down a little bit

from, from that peak, of course, as you might expect, but, um, it's, it's definitely, there's

a lot of interest in, and there's a lot of places in the world that are released in the

U S that, um, have poor access to healthcare, um, where there are no doctors in, in a town

and in the middle of nowhere, uh, because folks can't make that work with the cost of

getting that kind of education and then going to a town that doesn't have enough people

to support it.

So folks are in a little tough spot and having access to telemedicine is, is a really great,

great thing for them that uh they wouldn't otherwise have access to okay i mean i meant

also imagine though that in a city environment where you know people are busy but also that the

clinics are busy and you can't necessarily get an appointment easily and oh yeah sure sure yeah

it's not although i did kind of characterize it as being something for folks that don't have access

it's also super useful just it's a convenience thing for for life is like um just general access

to anybody who needs it whether you're your kid's sick at home and you just didn't want to go into

an urgent care clinic or you need to uh you know we do stuff like behavioral health visits and you

can meet with a psychologist or a psychiatrist if you need to or just a therapist um to to get

okay talk talk through your your uh your your mental health as well okay that sounds super

i recall that um because i because we had uh just just send a shelly on um back in 2020 who was the

original CTO of Doctor on Demand. And I think she had mentioned that there were at the time

restrictions around cross-state provider and client. And I know those were loosened during

COVID, but I don't know, are those still loosened or is that still a big technical challenge to

link up all that? It is one that we have to work through. So I think some of the biggest

restrictions around actual telemedicine have been removed. Unfortunately, I can't name what those

words off the top of my head. I don't know. Um, but one of the challenges that we do have to face

is, uh, um, you need to be a licensed provider in your state. So we have to, we have this big

routing operation where we need to make sure that a California doctor can see a California patient.

And, you know, you can't have just somebody from Massachusetts talking to somebody from California

because of how the legal system works. So, uh, we do a lot of work to make sure that our providers

are licensed in as many states as possible that's our solution for dealing with a lot of that

so that they can you know have access to to more patients um and that we're more accessible to

others but uh yeah that's that's the kind of the more of a clinical team logistical challenge that

they face and at the tech pure technical level um there's there's not really the restrictions that

we might have had in the past but for that problem though there's you with a big switchboard and you

put a kind of cable in one hole and a cable in the other and yeah connect up because we have a

whole dedicated subsystem within our django app called the router and uh it's kind of gnarly

because it's i've cared i've described it as just clinicians and their licensure but there's also

other factors about who can see who because of their insurance plans and it gets really gnarly

i'll just i'll leave it at that so just one big many to many uh it's a big if l statement

yeah right good i love it you mentioned the big s word you said scaling now i i think last time

you talked about some really interesting stuff can you give a kind of overview of the architecture

and how you scale it and you know interesting challenges that you might have come because i

think you know a lot of a lot of us don't run at that scale very often yeah so as a context um

doctor in demand had a a big um a big django monolith and that monolith i checked the lines

of count lines of code count in the last month or so and about 500 000 so nothing to sneeze at

um and as as what comes with that is hundreds of rest endpoints hundreds or thousands of json rpc

endpoints, a different protocol style, and the need to serve a high volume of traffic to satisfy

not only our member side. So we have built out in our system, both the electronic health record

system and EHR, that's what the actual doctor uses. So when you go into an office and they're

filling in all of your information, they're using an EHR. So we built one in-house and then we built

out the actual member applications on the other side to handle that. So that's kind of, you can

Think of it like a two sided marketplace. And so that's the scenario we're working with. And so the Django monolith is deployed using Kubernetes as to get some the scaling that we need. And we deploy with Docker to put everything into a single package or container and put that on a myriad of pods that are deployed on our infrastructure, which is on US East two and AWS, like classically.

as, you know, so many San Francisco based startups are. And there's, there is a thick

clients that talk iOS, Android web native stuff that so everything is over, over these API

protocols. Mostly we don't do many server render pages, we have some back office functionality

that is still using some server rendered stuff. But that's generally how we achieve the scale

that we need is is using kubernetes to spin up a bunch of extra pods to to get us our our throughput

okay and then i guess the question that sort of comes to mind when you talk about running a big

monolith like that is do you have you thought have you considered ruled out have you thought

about spinning off like a smaller thing that might load quicker to be able to spin up more

lighter weight like microservices essentially have you thought about spinning beats out or

you happy with the monolith style or yeah so um that there's actually like layers of complexity

that come in here because of the merger the merger took like all so our our teammates from

gram non's health came in with their their tech stack was a ruby on real shop so they have their

own monolith and i say they it's it's now us but it's been a couple of years but so we have our

our secondary monolith that is the the primary functionality of that legacy business which is

in of itself um it's not quite as big as the the python monolith it's probably in the order of

still hundreds of thousands of lines of code but it's maybe two-thirds the size or something like

that but it's a lot of code still um plus uh they they were farther along on the the microservice

architecture path so they had stuff written in scala and java and some python stuff and there

was data science stacks in there so when when we joined together we suddenly like whoa okay there's

this whole new polyglot world here and and what are we going to do about that and the business

decision was not to create some sort of subsidiary strategy it was an equal merger and we didn't want

to say okay you've got your tech stack and we've got our tech stack and we're just gonna not join

them together like the whole value proposition of the merger was actually to also merge the

technology so we had this extra problem and on top just to layer one more thing on there just

if it wasn't interesting enough they they were using primarily graphql as their interface player

and you would rest and obviously so we now have three protocols at least there's probably some

i think there were some some grpc in there somewhere as well um like five or six languages

and the doctor in demand team was starting to branch out and explore some microservice

architecture ourselves so where we land today is uh a big hodgepodge of stuff still um we probably

have uh half a dozen to a dozen python services um most of them are written in django there's a

couple that are not there were some older legacy stuff we have um lots of uh go services uh that

we have and then all this whole uh roster that that they had as well um and we're doing and

And because it was two healthcare companies and we had two monoliths, it would be one thing if they were just fully independent services.

But we have also overlapping concepts.

We both have modeled a doctor in some way, and we need to now unify the modeling.

And actually, the modeling merger is probably the harder part of this than the actual data tech merging of individual services on Kubernetes.

Kubernetes can handle a lot of run stuff on a network.

Like that problem is a fair, I mean, it's hard,

but it's a fairly solved problem.

But then actually bringing together design

is like a whole other challenge that we're working with.

That's fantastic, man.

I love that story, everything about it.

You began before we went down the alley

talking about life and burnout and scars and things going on.

Yeah, I can imagine that.

Life hits you hard.

It's a good challenge.

I mean, I really enjoy the challenge,

but it's like, wow, that's just not what I stepped into when I first started with Doctor on Demand.

And now you're, I believe you're a senior staff software engineer. So what is your mix of,

do you get to just do code all day or are you managing or architecture? What does that look

like right now for you? My mix these days is mostly architecture. So we're working on some

really large projects. So I mentioned we have an in-house EHR, that's electronic health record

system. And we are trying to switch to a vendor to finally sunset ours because it's not, it got

us to where we are now. We're really grateful for what it did, but the longer term we are planning

to say, okay, we'll use one that's a bit more off the shelf and provides the functionality that

clinicians still need, but we can focus on other pieces that actually add more value to our

our ecosystem. So that's a big rewrite, because the the the health record system is deeply

entwined in our Django monolith and very integral to our member apps. And so it's a it's a really

big project to rewrite a lot of stuff and take on a lot of work there. So that's that's the biggest

thing that I focus on. And then you know, a lot that your classic like, I love developers, but

they are like herding cats they're they have their own mind about things and want to do things in

certain ways and getting everybody to actually kind of come to some reasonable consensus like

there's always going to be disagreement but something that is is good enough is is the

the real challenge and what i deal with mostly on day-to-day stuff you're not one of those mean

bosses that asks for like estimates on how long things might take or anything like that are you

no no no i've read uh there's a great book it's um i guess it's is it steve mcconnell it's a called

book called um software estimation or demystifying the black art of of software something along those

lines um fantastic book on showing how how to actually do estimates which our industry is

horrible at and i'm not the guy that comes back to you and says i want a single point estimate

it needs to be as short as possible now it's a it's very much a dialogue of a we've got a certain

amount of uncertainty here what are the ranges that we expect on how long we are going to build

these things and and uh yeah it's been a useful tool so if anybody's looking for some light reading

software estimation realm go check out mcconnell's book that's a good one yeah it is um one thing i

want to ask from what you say you're taking on a vended product so you know just sort of generally

what's your can i get your take on kind of using a an off-the-shelf solution versus building your

Brian, what are the decisions that, what are the factors that go into that kind of call?

Because obviously you always want to rewrite everything yourself, right?

Yeah, this particular decision was a really hard one because of how much this EHR tool was at the beating heart.

I mean, it's how we serve and do telemedicine visits.

So it was not taken lightly.

We did months of research on this particular one with a fairly sizable team because we didn't want to make a really bad choice and then mess up our whole system to the point where we can't really go back.

So there's a lot of analysis that needed to happen by many teams.

It's not just purely the technical problem, but also is this going to work for our clinical teams?

Is this going to work for our operations teams?

There's logistics problems and challenges.

There's the financial cost, like when do we break even on what do we, you know, this is

an investment of this sort of amount of time, we need to get out this kind of margin gain

from not working on some of these features that are required by regulations.

regulatory problems. And so it's, it is complicated. I think from an engineering perspective,

we looked at what we met with their, their team extensively. In other words, when you go into a

vendor that's this large, you really get into an enterprise sales pipeline. And part of that is

working with customer implementation teams that they have, they have their, their design to help

you onboard and walk through here, all the things that you're going to need to consider. So those

teams are, are vital with tools of this size. Uh, and we've done a lot of, uh, work and negotiation

with those teams of, Hey, here are your public APIs. Here's how we think we're going to need to

do this. And let's, let's navigate this together. So it's a very big process to, to go through

that um and it just requires a lot of a lot of patience uh because people don't always see eye

to eye there's a lot of um i mean there's some amount of anxiety too it is still a massive change

and and we know that like the project we're undertaking is going to be at least a year

before we're done and ready to roll out so um in in your smaller shop settings that that you folks

might be familiar with and i i am familiar with myself it's like a year man that's like an

eternity in a product. So those are the challenges we're facing. And I have to ask because it's

timely, but so I haven't heard you say AI, which I'm sure would, you know, increase the company

value a little bit. How does that discussion go internally? Because I know it's, you know,

it's just like magic dust you sprinkle on things, but yeah, yeah, yeah. We are, our CEO is not

immune to the AI bug either. We've actually made good use of it already, which is, um, so one of

the aspects that i mentioned that the business does is we we have a large care team so that's

the team that like i don't understand my medical bill and i need to get some uh like something

looks funny on this insurance claim that's happening i need some help and we can either

help you understand that bill or find out actually you know what that you're right that was

missed miscoded and we need to go fix that and like save you potentially thousands of dollars

we have cases where you know this the kind of things that are in our all hands meetings we're

hear of a story of a family that was dealing with like millions of dollars in medical bills for

their young child. And it's all because the stuff was miscoded and we were able to get the, the

amount down to almost nothing, which is like shocking to me. Um, and it's really a statement

on the U S healthcare system. Uh, but also, um, just something encouraging that we're actually

able to provide that service. Um, so that, that team though, that care team, um, interacts with

a lot of members, and they need to be as efficient as possible, because that's the way that we have

some of our margin gains is by being a lean and mean kind of team. And AI was was something that

we applied pretty early here of we have a lot of messages that, you know, for all of the unique

cases that happen out there, there's plenty of just standard stock cases. And we don't want to

give something so canned of like, you're clearly dealing with a bot. But we want to make those

folks those real flesh and blood people faster at their jobs so we integrated tools that did

learning on our data for the very specific domains that they have and provides back prompts of almost

like a built internal health care chat gpt kind of thing and it will provide back a prompt of here's

here's something that you could probably send to the member member we don't send it automatically

we make them the the care team member like look at it and they report back like you know some

something on the terms of 50 60 percent of the times it's good as is and they can just hit the

send button and uh send it out otherwise they other times they have to tweak it and make the

modification that will make it a more meaningful message to our member but it has saved just oodles

and oodles of their time they're they're thrilled to pieces that they have access to some some of

these ai tools that that we've built yeah that that seems to me to be the hopefully the unlock

is AI plus a human

makes the human better

at whatever they're doing.

Exactly.

Rather than just,

I don't want to be dealing

with bots all day.

I don't know about you,

but there's always

that uncanny valley aspect

of so many of these things.

And I'd rather have a human,

like, okay,

I still believe you,

you've passed the Turing test

because you are a person

and you're not just a machine.

Well, and then there's that,

we've had this discussion

with some recent guests,

like metaphysical,

when it's like bots talking to bots,

just like if AI writes the web

and then AI is built on the web,

like where does that lead us?

Yeah. It's like the other one that I've seen is the email one where it's like, I can make my email sound really fancy so that I look really good. And then the person on the other side is like, summarize this email for me so I don't have to read it. And it's like, we just bloat on the web of expand on one side and shrink it on the other.

Love it. Well, is it alright if we switch gears to some of the other projects? Or is there anything else around? I mean, obviously, it is how you spend the most of your time is on the day job. And that's a that's a I mean, to me, that's the most interesting space, honestly, in all of tech is the merger with healthcare. And then you throw the AI piece in there.

Yeah, I'm happy to answer any more questions you might have on it, but nothing's jumping to mind about the healthcare space. I could go on and on forever about it.

Well, maybe one quick one. I don't know if we've already covered this, but because you're in the healthcare space, on the database end, I believe there's specific databases that meet all the regulatory requirements that you have to use, right? Is that correct? Because I know there's a higher level of, I don't know, it's the higher standard when you're dealing with healthcare data as opposed to just consumer stuff.

Yeah. So in the US healthcare system, there is a legal set called HIPAA.

Okay. That's what I was going to reach for. Is that, that's just like the umbrella. You just

say, oh, HIPAA. And then it's like, yeah, it's all HIPAA stuff. And within HIPAA, they define

some of these, these rules that you're talking about. We basically, thankfully we're using a

lot of services that come from AWS and AWS, love them or hate them. They have done a lot of work

to make HIPAA compliant services

where we have to layer on

additional requirements for health care

is usually stuff around

like data retention

with the data retention policies.

It's I think it's seven years

or something like that

that we have to hold on to data.

We it's no joke.

We have to be very careful

about storing all this stuff

into either S3 or what snowplow.

Is that the other?

What's the long long?

Oh, glacier.

That's the other.

Yeah, it's an Arctic metaphor.

Yeah. Yeah. Yeah. Um, so we have to be careful about that stuff. Um, our, our cloud, we have

a cloud platform team. We have a bunch of platform teams that help us build on, on these layers and

they think long and hard about making sure that we're compliant with this, these different

regulatory stuff. All of our developers have to be trained on this. Um, but those teams have those

extra responsibilities of when it comes to the data and what does it mean to be HIPAA compliant

and how do you, um, encrypt in transit, encrypt at rest and all of these things to protect the

data as well. That's where those teams are coming into play. Got it. Well, let's speak about fun

stuff where you can just use Heroku and go. So you have this weekly series, um, building SAS,

where I've actually watched, I watched a bunch of them. Um, and I really enjoyed, I watched,

I think the first six of your, your new ones. So you had the homeschooling app you've been

building for, I think what, over two years or so publicly. And then you just started this journey

inbox, recreating, um, a service that went down that, uh, that you like to use. And that's been,

even for me, like that's been really fascinating just to see someone, how someone else does it,

because I think we, I certainly feel like I can get locked into my little roots. And

aside from some monolithic, huge thing, not many people with, uh, experience are publicly showing

how they do things from scratch. And I picked up a number of things from you, just, just seeing how

you set things up. I mean, I didn't do it, you know, I probably do 80% of what you do, but I was

still like, okay, Matt likes that too. Like that's, that's good to go. So all of that is a preamble

to like, how's that going? Right. I can imagine when you're day-to-day dealing with a one-year

project and all these things, and then you can just fly. Um, yeah, that must feel good, but it's

also, but what, what are you getting out of that? Cause I know, like, I don't know how you manage

that. There's like a live stream street or whatever they call it, like a chat of people

asking questions as you're doing it, as you're thinking out loud. I certainly couldn't do that.

I would need all sorts of notes to do that, but you're able to kind of just make it seem like

you're just out of thin air prototyping these things well i could say that like like so many

things in life is a skill that is developed over time i mean you can i i've so i've now done um

almost 200 of these like live streams you go back and look at the first one it is rough man it's

super rough um nobody's watching me like you can hear my the the fan of my my mac like just going

super loud it looks awful so so many bad things about it so everything is a journey and including

uh the streaming stuff i think on this particular project i also gave myself some some additional

constraints which is i i said for this one i'm i'm not going to do any any code that is not

streamed live so this is a like i'm i'm coupled myself to a couple of hours a week um to doing

the code so that you see the the intent of that is that the the whole picture is available and

that means anytime i get stuck anytime i don't know like like what i'm doing anything i need

to refactor anytime i need to do dependency upgrades and all of like the nitty-gritty

like i want to put you know there's a like full open kimono thing because it's the the point of

it from my perspective is is not only to to build a product that i'm planning to use i'm kind of

scratching my own itch with this this journaling thing but also to show folks what it's like to

build a real app that is it is not uh necessarily a glamorous thing it's not an easy thing sometimes

it's easy sometimes it's not um and sometimes you don't know what you want to achieve uh and

and seeing that i think is i'm i'm hopeful that that tells a tale of like that that being a

developers is this like journey and experience thing that that uh yeah i think it too much gets

packaged up with the the very nice i appreciate the very nice tutorials that are out there for

learning but i think that they lose some of the the real grittiness of life and building apps

there must be a kind of courage step though because i've got like 20 years of experience

i'm a good developer but no way would i stream just stream what i do you know you don't want

to watch 40 minutes of me browsing the docs or banging stuff out in the terminal to see what

happens no one's surely ah well sometimes no one does want to watch it watch that kind of stuff

like there are moments where i mean i'm not doing rocket science kind of work here this is our

a pretty standard stock bread and butter Django apps. And, um, I'm going to stop you there. You're

downplaying it a little bit. I mean, I think, honestly, I think it's, I mean, I don't watch

them live cause at that time he doesn't work for me, but, um, I think, honestly, I think this is

invaluable just even for people studying computer science to see like, this is a real life. And

again, it's not a perfect tutorial or, or book, which we can talk about. It's like, how is it

done? I mean, I think the two things I found most interesting that obviously resonate with me is

when you get stuck, how you debug it, because everyone is a little different, you know,

it's like, oh, where do I look? How do I do that? What do I look up? But also the fact that with

this project, you're, you know, certainly in the beginning, you're just pulling things from the

homeschooling app, which is what we all do. Like we all have this like toolbox of projects that we

can pull from. And I think that's a big thing that people miss that I'm really aware of now

that I mentor someone on a weekly basis.

And it's not that I, you know, in the moment know more.

It's just that, you know, you have this toolbox,

you've done it once or twice.

I'm like, oh yeah, that kind of fits with this.

And I know where to look.

And I probably have a version of what I did.

So that to me was, you know,

I think that's really important for people to see.

Like, how is someone so fast?

It's not just that you can whiteboard

what I'm going to do and then you do it.

It's like, how do you do it?

It's like, well, you're quicker at the docs.

You have this past projects.

And a rare occasion you get stuck,

You say like, I'm stuck.

And then, you know, it comes to you 20 minutes later when you're working on something else.

Like that's, that's as close to God, like, as it gets for anyone.

So I think it really humanizes the profession to see that.

I think maybe one thing that I'll even add.

So Carlton, you're chatting about like, how could somebody watch there?

There are some really dedicated folks who I'm so grateful for.

And actually it turns out that they are another superpower that gets added to this layering

is like, I'll have moments where I'm stuck and, and the chat will pop in and be like,

hey what about you miss this thing why don't you go just check out like because one one thing that

happens when when i'm streaming anyway is reading documentation becomes super hard when you're like

trying to focus on a camera and you're you're paying attention to a chat over here and like

there's just a lot going on in your brain and and so i will i will literally have to read out

documentation or i will miss it and even when i do that i still miss stuff they're like you

Matt, you missed that option. You're looking for this thing and it's right here, dummy. It's right

in front of your face. So having kind of mob programming with a chat that is paying attention

to what you're doing and giving you suggestions, not always the best suggestions, but suggestions

that you can think through is a really valuable tool as well. Well, I'll just say one more thing.

I mean, I'm always impressed at your stamina. I mean, because you go two, three hours for a lot

of these things. And I feel like maybe I'll blame my kids for this, but I don't think I can go three

hours anymore on anything. I need to walk around, just go daydream. That's so impressive that you're

able to do that. And then as part of that, one of the things, just one specific thing, I'll let you

go, Carlton. When you were going through Django all off with your setup, I hadn't seen this before,

but it makes sense. You went through the docs, there's 30, 40 settings. You went through every

single one and um you know i think you included it in the code and commented it in or out but

that's even for me like i've been doing all off for 10 years like i've never actually

done that and i was like that's like i was just like grab the ones i need and then if something

doesn't quite work i pull in another one but that that was such a good exercise like i should do it

that way actually that that makes sense because there were a couple things in there i was like oh

yeah i i know they're probably new in the last five six years and i just haven't reached for

them before. So that methodical nature of like, yeah, it's reading the docs and deciding in real

time. Um, it was great for me to see, you know, and I'm sure for a beginner, it's even more

eyeopening. That's an aspect of my brain that I guess I love and hate is like, uh, I'm a systematic

kind of person. Like, you know, if, if we're as a tortoise and hare race, I'm absolutely a tortoise.

Like I, I go slow and methodical, but the tortoise wins, the tortoise wins though, right?

tortoise does win which is something i like to keep in the back of my mind um but i i do sometimes

feel like i'm i'm going way slower than i i could or should be uh and but it gives me a deep

understanding of some of these things or or at least like oh yeah i do remember seeing that

option before because i wasn't you know i i did literally see it at some point carlton you you

look like you have something to say no i was just thinking thinking about that i think

I mean, this line about being the tortoise,

I think that's dead right.

I've kind of, we, as an industry,

we kind of sort of glamorize this idea

of the fast program, of the fast development.

It's like, no, go slowly, go really slowly

and just make sure you get it right.

And you know, take whatever time it needs

because you build this one little block

and then you build another little block

you build another and it might have taken an age to get something but good software doesn't just

appear right it's it's kind of crafted slowly i think and so that methodical approach is good

this is especially important if you're operating your own stuff that's so the the extra layer on

on top of my projects here is that the ops guy is me yeah right so not that i want to dump on some

some poor soul and with some bad code but like when you know that that poor soul is absolutely

going to be you and you don't want to deal with fires at two in the morning you take a little bit

you slow down a little bit you're willing to go a little slower and write the thing that's going

to be as bulletproof as you can make it because i need sleep and you know i don't have time for

it goes down on a holiday weekend you can't oh excuse me i'm gonna leave the family dinner now

to go and work on myself but no that's not gonna happen very true well if we could switch to

another, I guess, two big topics, the book and the podcast. So I know, so Jenga Riff's podcast,

you did, you had quite a run there. I know it's been, I guess, a year. I'm curious what a year

on, how do you look back on that experience? I mean, I listened to all your episodes. I would

imagine doing the podcast informed the writing on your site and then the book. But yeah, how are

you feeling now about having put all that work into those podcasts and maybe picking it up again

in the future yeah so i did mention early on this plate spinning this is one of the plates that

dropped and and kind of shattered on the floor but i think i can piece it back together um it is a

it's it's a project where it's fun but it takes a lot of work and like that i know what you guys

must do or at least one of you or both of you uh it uh it's a lot to get the um the editing going

and uh to take that takes time uh so i i built what i could with that and and recorded some

episodes but then ran out of gas frankly and uh i i left it up so thankfully um i do have like a

patreon and a small group of people who who send some money my way and i pour pretty much all of

that money back into either the paying for the podcasting or paying for like equipment that i'm

setting out for my streaming setup. And, um, you know, I, I, I'm not quitting my day job.

Let me put it that way. Um, so I'm happy to like leave that content up, but I do plan to return

to that and kind of a question of what do I want it to be in the future? I have a few more content

episodes that, that I think wrap up a lot of what, what does map to the book that I've written

and the series that I've written. Uh, and then beyond that, um, I'll be switching to, I think

the the thing that will follow will likely be an exploration of the third party package space like

there's a um i think something that can use some love is like what are the the core packages that

are out there that are people really gravitate to and how do you use them why are they interesting

and is there any kind of spotlight that could be shown upon upon those things so that's that's the

plan for django riffs when i when i do get back to it may not be well at this rate certainly won't

be this year. But sometime next year, I'll pick up the rest of that and keep it going.

Yeah. No, I think that's a great, the third party package is definitely an area that needs some love.

And I think more, I mean, there are resources like Awesome Django and some other ones. Like one of,

I think one of the more popular posts in the Django forum is one I put up a couple of years

ago about like, what are your top five or 10, you know, if you have to pick, and it's not the same

for everyone. But, but going that extra step, as you were saying of like, how do you actually use

it and maybe showing some of that i think that's the big unlock right it's easy to say use use

django all off but like okay how do you use it you know like right you could write a book on

some of these third-party packages and yet yeah i would say there's five or ten there's probably

ten we could name that i'd say almost everyone uses and then there's another 20 30 that um

yeah people choose you know you pick and choose but like you can't write a django app without

third-party applications and i think and especially looking at what happened with flask recently with

the flask login, it makes me feel how stable and mature the Django third-party ecosystem actually

is in comparison, right? I think it's easy to appreciate that. It's easy to be a little Debbie

Downer about it, but it's like, I can't think of a, I can't think of one that's been left for a

year. Like, I mean, Carlton, you know, has picked up a bunch of people who do that, but that's a

real, another real strength of Django is, yeah, there's, I don't think any of the core, core ones

are neglected at this point. Yeah, it's a really great thing about that community. I'm sure there's

a lot of thankless work that goes in there. So for those folks that are out there that might

be listening, thank you. I really appreciate what you've built. But yeah, one of the things I do in

my podcast is I don't shy away from actually talking through some code. And I know, I don't

know how often how good that comes across in audio, but I make an attempt of we're gonna actually talk

about some some code snippets here and there. And I think that does lend itself to giving a

demonstration of what some of these packages can do so that's probably in the plans of of just

showing how how do you integrate these things how what is it useful for what's the main main use

case can we get a early example of what that might look like to give people a sketch that then they

could go and take it and turn it into something they could use themselves yeah i i think it's

helpful i mean and that is always it is helpful to have podcasts like this where we sort of talk in

overarching terms about things but you know at some point you do need to see see and talk about

real code. There's interesting, you know, what you're saying about the time it takes to do the

podcast. I mean, when we started this, we did a bunch that were topic specific. So we talk about

sort of like how you did, you know, about settings files or deployment or signals and stuff. And

those are all kind of, those are a lot more work than having a guest on. I mean, you know, that

the feedback I got at DjangoCon was like, you should do more of those episodes like that are

deep dives and it's like, yeah, but there's so much more work, um, to do. Uh, so there's a lot

of show notes prep and all of that that goes with it to have the content ready. Yeah. Yeah. So it's,

you know, I think it's okay to not have lighter ones, but sometimes, you know, conversations like

this, right. Where there's still value, but it doesn't, the prep isn't quite as high as it is for

just solo talking for 40 minutes on a topic. Um, fair enough. Well, um, maybe the book,

we could talk about the book. So you recently published your book, Understanding Django.

What was that process? I know some listeners, I know that I'm guilty of sometimes talking about

the book writing process, so I'm not going to say anything on my end about it. But for you,

translating from writing the series online to the book, what was that? How long was that in total,

right? Because you were working on that for quite a while, the online series and then now the book.

Yeah. So I built this series. If you actually go back and look at the first one,

And it's, I think it started maybe in 2021.

So it's been a long time to write the content.

And it was as the book is a repackaging of my online understand Django series.

And it's, it's 20 articles that are, you know, around 3000 words a piece.

So it's a, it's a good sizable book at this point when you have it printed out.

I should have brought my proof copy, but to show it, it's a, it's sitting up upstairs

in my house.

um and the process was uh fine for a while and then i i got to the editing process and i've

discovered about myself that i really don't enjoy the editing process what i did was uh i i like

like any programmer might i built a tool chain to help support myself and i wanted to make sure that

that the online version of the book stayed true to that and use language about like make it clear

and evident that this is on the internet and that when you have a print copy that all of those you

know switches to from article to chapter and like the the length there are language shifts in there

that make it seem like oh yeah this is in fact a book so that was a challenge in and of itself

but that was actually the fun challenge the the harder challenge was i have a have a mailing list

and i said hey i'd like to to gather a group of beta readers if if you would be willing and i

actually got probably 50 or 60 people to respond and say yeah i'll do that and so i sent them week

after week a chapter of the book to edit and goodness that was the grueling process of like

and i got some really great feedback but oh man it is it is hard work if you've have and i'm sure

dealing with a professional editor or something is a very similar experience where they they will

they will light you up on what you can make better about your book question your soul a little bit

yeah totally um so i think i got through that ending process and then again frankly the book

was one of those things where i dropped that plate for a while like i was basically had a done

manuscript uh and didn't finish it off like i could have been finished with the book probably

six months ago and actually had it out for effort and available. Um, but just, just was

exhausted and wasn't ready to publish it yet. So I finally got my act together the last couple

of months and, and got it out there to the world to, so you can buy eBooks and paperbacks and

I'll also be doing hardbacks and audio recordings of it as well. So, uh, it'll be in all the forms

to make it as, as accessible as possible, but that it was quite a journey to get all that,

that done. Wow. That's interesting. So the audio version, are you going to, cause I've never done

that. Uh, is that you're going to record that yourself and then just release on audible and

all the places, I guess. That, that is my plan currently. Um, I know that audible has some

weird rules, uh, Amazon being pretty controlling about their ecosystem. So I'll have to see what

I can do in terms of making it beyond the, the audible store. Although I think that accounts for

something like 90% of the audio book market. Uh, so it's definitely, it, it would be a shooting

myself in the foot to, to not put it there. Um, but I'll do my best to try and to make it available

in other stores that where people might want to, uh, also consume audio books. Yeah. Well,

we don't go, we could talk offline about that. It's harder than people think to get outside of

the Amazon, um, system. Uh, uh, do you have any thoughts on how you're going to handle the code

snippets? Cause that's the one thing for audio for me. I'm, I'm never quite sure how to,

or at least my books have quite a lot of code and I, you know, you do as well. You know,

how do you, how do you handle that? Right. If it's like 15 lines of code, do you read it and

then talk about it? Do you, what are your thoughts on how you, how to tackle that?

Yeah, I got to confess, I haven't fully thought through everything that it will mean. Um, there,

might be a i have an advantage here that i'm committed to always leaving the content of my

book online for free on my website so if this i do an okay job i think at reading code content

from from my actual podcast episodes that's something i've tried to to do and people have

commented that they oh yeah they actually understood that so i'm taking it from at face

value that somebody else has asserted that I'm okay at this. Um, so I'm going to try and read

as much of it as I can, but there probably are chunks in there that will be too, too gnarly.

And maybe I will, uh, editor's note kind of insert, Hey, go check out this link and

view the view, the code snippets here, because this is just too much to really describe well

with audio. Uh, so that that's, that's my plan with the, the code snippets for audio book format

of stuff yeah no i think that's the right way i don't think you need i mean it's also the question

of a lot of times you're you're you know you'll change two three lines even if it's a 15 line

snippet and so i think you can in audio format talk to or um just speak to what's changed yeah

it's i i haven't i think that's the answer if i were if i were to do it too but right i haven't

um carlton the internet has come back online in spain apparently so i don't know what happened

there but um my kid i know my kids were busy screaming about something so maybe they broke

it but it looked more serious than them breaking it like the router was off and whatnot anyway i'm

back oh that was the check that's good we we just we just were talking about the the pod

jinger's podcast and um matt's matt's book that he published and he's going to do an audio version

and so we're talking through the logistics of that a little bit i'm gonna have to listen to

the f-side well it's um we're coming a little bit up on time um as one question we ask a lot

these days is deployment uh matt and i know that you're i believe for personal stuff on the heroku

bandwagon is that still the case or where do you how do you see the landscape and i'll i'll preface

this by saying like i've played around a lot with the various platforms of service providers and i

i think i've pretty much come full circle that for my own stuff heroku though i heard some rumor

they might change something with their databases, um, which I hope they don't do their managed

Postgres, uh, works fine for me for solo stuff. Um, but, but where do you, where do you come out

these days on, on the deployment topic? Yeah. For personal, I bias towards as simple as humanly

possible. And that does mean eating some cost. So there's always that cost versus effort trade

off that can happen like you could no doubt spin up a five dollar uh droplet on you know or any

any pick any of your uh preferred vendor for using cloud hosting uh but uh get get your machine

running get do all the work to host your your web app and put it in front of some kind of load

balancer and or nginx or you know choose your tech stack to get that going uh and i i along

with that comes the risk of well maybe you got it wrong maybe it's not secure or or maybe you

didn't optimize it quite right and it breaks in weird ways that you don't expect um i don't mean

to throw throw shade on those things like it is possible i have done it in the past of having

good stable configurations uh but as i'm as i'm getting older and i know that my time constraints

on my personal projects are x number of hours in the week i look for simple so that's that's

my personal preference um on the the work spectrum deployment is a whole different beast uh if you've

got especially at a certain scale um you reach for different technologies so um i i'm not honestly

i'm not wild about docker um i in many senses of the the deployments sorry not the deployment

story the development and debugging story is is i find i find challenging i find it that adds an

extra layer and either i don't have my editors configured in the right way to set up debugging

in all the ways that are necessary or um it's just it's just some friction that that i think

slows me down but overall having docker in a stable deployment container is valuable for

deployment into the the platforms that our teams build so there's that there's a a cost but it's

a worthwhile cost uh so if i'm gonna have a personal project i'm gonna reach for a platform

as a service because i i want easy mode and then for business that has higher scale i'll reach more

for docker that's my my take yeah i i have to say i i took from you seeing i think i even messaged

you when you started the journaling app saying you know why aren't you using docker and you said

some version of that and i've actually i've a new project i've been working on for a couple months

i'm just doing it um without docker because i i take your point i think

it's it's tricky that in a professional setting once you once you start collaborating or scaling

i think you know docker is an invaluable tool but uh it is faster without it like there's a lot

a lot that goes into just dockerizing things and you know yeah when you're in god mode just

solo developing i mean carlton's been preaching this for forever but you know i i gradually am

coming around to carlton's point of view on everything you know custom user models docker

it's just like where am i going to be in five years carlton the phrase is for me is that always

comes almost horses for courses right matt said it at a certain level of complexity or a certain

level of scale these tools become yeah absolutely valuable but like when you're single developer

two-person teams even 10 people like you don't necessarily need all these extra bolts and when

wizards that you need when you're a 50 team a team of 50 or you know where you've got if it's

homogenous environment you don't need necessarily to worry about the dependencies because they're

all the same everywhere but if you've got like multiple services in multiple languages with

multiple dependencies in multiple versions ah right then have everything in your container

that's a lovely thing to have but i don't know i do appreciate the platforms that give you an

on-ramp to those tools so like you you can start with heroku and you can start with just a proc

file and the the standard heroku way but they also give you a path to be like okay you want a

container yeah we can do that too so that that's useful and i say heroku but like i'm pretty sure

that works for fly and like other other systems have different kind of schemes that allow more

for that on-ramp path um and that's that's great i think that as you go up to those other levels

that's that's very useful as well yeah there needs to be an evolution right there needs to be

a growth path a journey from something simpler to something more complex as you need it you know

yeah well maybe i'll have one final question for you matt um it's something i've been thinking of

which is the need for basically checklists so like again when you were doing your journaling

project you were looking back to your old projects and i mean i honestly i do that all

the time i do that even in my books i feel like i wonder i i increasingly wonder you know as people

progress from learning how to do things to like needing to get the reps i'm like i'm almost

thinking with the new updates to my books should i almost have checklist like versions of like okay

i showed you how to do cred with auth now here's here's like two or three different examples of

you know of a flashcard app or recipes app where i'm going to kind of give you like what i have

for myself which is just like the code snippets basically right where i can just go boom boom boom

boom, boom, boom. I wonder if that resonates for you, like both we as developers, can we

formalize our own toolbox rather than just like digging around through old code? And then is there

a benefit to people progressing beyond that beginner's space to at least seeing how other

people do it? Yeah, I certainly think I would be a lot more efficient with a checklist. I think

about same same and it's it's just there's so many layers right like building web apps

it's as much as it's just bits on the internet and some html pages like there's there's a lot

that actually goes on to make it safe secure scalable all of these these qualities that we

look for um and that that's a real challenge uh i i take some it's not a checklist but the

the thing that springs to mind right now is the actually the django rest framework documentation

and one of the things that i love about that documentation is when you hit the the guides

this portion of the docs there's this big drop down that shows all of the different

kinds of things and i don't know why but my brain thinks of that like a checklist oh oh yeah i have

to do authentication i have to do authorization i have to think about rate limiting like and it

is like a perfect list of and that's that's in the context of building rest apis of course but

that that kind of list and just seeing that list in that format is is a reminder that that oh yeah

if there was a checklist that i could reach for that would hit these big categories of topics to

make sure i've thought about what kind of url setup am i going to do how am i going to configure

my user accounts and and the things that i've now done a couple of times in some of these projects

that i've started on my stream i'm starting to see the same patterns there's a question i have of

like maybe i'm maybe i'm being inefficient and that i should be reaching for some kind of uh

built template like i started if you go back and if you if you're looking at the the journal stream

i i start from stock django with a manage start project command um and i think that's informative

for those that are wanting to learn and they see okay there's there's no mystery here all the

layers get built up on over time but is that the the right choice that i should be making as a

developer or should i jump straight to like i've i've made these decisions multiple times i should

have my own personal template when i'm starting a new project the trade-off is i'm not a consultant

i don't i'm not in that industry so i'm not the number of times that i am starting up a new project

from scratch total in in my life for django so far has been three so it is like it's like kind

of a once twice refactor thing is like it maybe because i did it a third time as i'm starting to

feel that pressure of of perhaps i shouldn't do this anymore and the next time i should do it i

should also build the thing on the side that will help me for project four and five and six uh yeah

that's that's that's my thought on a checklist would be useful but could we just skip the

checklist altogether is where i'm going yeah i mean the question is how how much is could be

universal and how much is everyone does it differently right because there's a cookie

Cutter. There's Django X. There's Corey Zhu has his Saspegasus. But yeah, I was thinking that,

I mean, I was watching the first couple episodes of your journaling. I mean,

on the one hand, I really liked seeing that. On the other hand, it was like, even me, even Matt

Lehman, it's hours just to like set things up before you've done anything, you know, anything

new, anything interesting, it's still hours. And so there's a tension there. How often do you do

it? Like, do you keep it up to date? But I mean, I guess, and I, I mean, no, there are, there isn't

really, there aren't a lot of startup projects out there. Like, I mean, pedagogically on the one,

like I think experienced people maybe would benefit from like, okay, Carlton's way of doing

it. Like, yeah, I trust him. He has a quick little docs. Fine. Save me the time. But you need to do

it a bunch of times to understand that, right? Like that's what I found with cookie cutter is

that I couldn't use it before I understood how to do it all from scratch a couple of times.

so there's i guess there's a place for both but yeah that that is the really hard problem

with templates that i would i would fear like if i picked up somebody else's template

yeah what don't i know that's in here what don't i know especially if again if i'm going to be the

operator what what the what don't i know is a really big risk of this might blow up my face

and i don't know how to fix it because i didn't write it in the first place um that that's that

analogy sort of breaks down a little bit for for me if you think deep enough like i don't know how

to fix the kernel either but i guess there's also the probability that it breaks as much lower so

there's there's the how much of the stack are you willing to bite off is is how i how i've

sometimes thought about it i've challenged people to we need to live in our level of abstraction

that you know we're kind of up here in the stack and we're not dealing with electrons and like at

the hardware level we're not at the kernel driver level so you know it's always about drawing your

lines about what you're willing to accept as the complexity you're going to take on but i do like

knowing stuff and i think that biases me towards taking a little slower making sure i understand

all the pieces and and know that what i'm operating carlton concluding thoughts no i'm just uh i would

agree with everything matt said that i think the key bit is the uh the consultant if you're in a

consultancy and you're turning out project after project after project and it's you're probably

doing it with juniors and mid-level and with senior developers you need a standard template

that everyone uses but if you're turning out the odd project every now and again just crank it out

by hand because there's there's value in doing those exercises doing the reps as you as you said

um you know maybe i don't know maybe the django ecosystem is missing something like

templates for the login system so that you you know you're not constantly recreating nodes where's

the the one repo that we all go to to get the login templates well okay that would be a something

that would speed it up but you know yeah i i agree kind of what i said i don't know a concluding

question though for me i don't know if will asked you if you had a magic wand perhaps you asked you

when it worked but if you had a magic wand and you could change one thing in django what would

change man uh can i give you two answers yeah yeah absolutely so you can be put a feet up and go

so the first is is more at an intro audience so i i view sometimes i look at

jango's sibling projects in other language ecosystems so this is your ruby on rails

in the ruby ecosystem your laravel your um phoenix if you're thinking about elixir there's

a bunch of them that are and the general ethos being we're building a full stack framework we're

going with the kitchen sink approach and we're including everything that we think is valuable

to actually build a full application and i try and take some some inspiration from those of what

do i think is valuable so my the first thing i would i would if i could snap my fingers would be

to take some inspiration from laravel and if you look at the laravel page and you scroll down

enough you get to the section that talks about all of the extras that that they have built in

and i think one thing that we could do better as a django community is highlight our community

packages and and actually i'm gonna be a little make a statement that's a maybe a little aggressive

hopefully not too much is in our spirit of being egalitarian i think that's great about us

sometimes i think we're afraid to declare winners and i think that there are some winners for

certain categories of packages like if i said what email package are you most likely going to reach

for i'm gonna immediately without blinking say django and email it's a pretty clear winner to

me and the folks that have built it have worked their tails off to make it awesome so i would

love to be able to showcase those folks and honor them and say like hey you need some extra email

stuff pick this one don't don't bother thinking like just pick it because that's that's a great

tool and there's probably you know a dozen of those packages that we could reach for different

categories that we could highlight and say django has an awesome community and we could really

showcase that by saying this tool will almost certainly meet your needs for auth you know all

auth static white noise like there's a list you could put together that i think are the clear

um most used packages um now how you do that and how you'd vote on that like i'm not gonna i'm

again i'm this is my magic wand right uh so that that that's one thing that i i would suggest um

or wish was it was true the the second thing if i could have a magic wand it relates to um

i guess it's more of a enterprise so it's the other end of the scale you're you're not starting

up but you've now got a huge scale so this is like i'm now wearing my company hat and like what can i

do to make my life better um one of our challenges is we would like to have a more microservice

architecture and we'd like to be able to split off pieces to scale them independently for a variety

of reasons that i don't have time to go into uh but we have found with our monolith the way it's

designed is that those those django apps that we built are very coupled and they're they're not

easy to extract and remove from each other. So if I could snap my fingers, I would love like to have

a Django app, strict mode or firewall mode, where there's some kind of extra enforcement of

boundaries between the apps, such that let's let's pick on the related manager. I love that feature

of a foreign key where you have a related manager and you can kind of, you know, my model dot some

other thing and access some other models through that that's great except when you have found that

you've coupled a bunch of things to one model and you actually have a like six or seven apps

interacting with each other all through the related manager it's really hard to see that

so if there were a functionality to actually maybe forbid some of those use cases so that you could

create from the get-go an app that is meant to be more independent from each other then that would

give you a fighting chance in the future of actually removing those pieces and maybe having

that become its own microservice in the future. So that's my other, like, snap my fingers. It'd

be awesome if we had these extra controls to enforce harder separations between apps to make

it so that you could actually decompose a Django app into something more manageable if it's grown

too large. Yes. Well, there's a redesign happening for djangoproject.com. And I know some of the

people working on that listen to this podcast so maybe they'll uh find inspiration curating the

third-party packages is is hard but is there's a value in it but like you know one of the things

we always say is django secret sauce is the third-party set packages the third-party ecosystems

but then there's like a veil of silence in the django docs as to you know what packages there

are and how do you find them and do they even exist and ah it's like one of our best features

we don't tell anyone about.

Well, there has been some progress, right?

It's now in the polls tutorial.

It mentions, I think, was it debug toolbar?

And then it mentions Django packages

and Jazzband as well,

which is sort of an opening into some of the ecosystem.

I mean, it could be even something

for Django packages to have a greatest hits.

I mean, curation is hard

because I mean, I can say this,

you know, running with Jeff Triplett

who does Django packages,

the awesome Django repo,

you know, it's a little bit of a thankless task

and, you know, you don't want to bloat out too much

it's hard to remove things. But at the same time, like there are, there are these ones,

any male all off white noise, like we could probably list 10 or 15 that we kind of have one

out. Um, so anyways, yeah, that's a very good, two good insights. Thank you, Matt. Yeah. Well,

we are up on time. Um, we'll have links to everything in the show notes. Everyone should

check out, um, understanding Django, uh, book, which is available for, for a paperback or ebook.

it's also on your website and you also mattlayman.com you have all the all the links to

all your activities that you do that people should check out there are plenty of ways to connect to

me up there discords all sorts of stuff i'm accessible on the internet carlton and i are

too old for discord i'm afraid i try but basically i have to treat it like it's a static page i have

to quickly log in quickly look and then run away again i can't i can't i don't promise to be fast

on responding to those things,

but they are accessible.

Great.

Well, thank you again, Matt,

for making the time.

Yeah, thanks for coming.

Sorry I dropped out mid-call.

I just want to say well done

on getting the book out.

That's phenomenal.

Thank you very much.

I can tell you it's no small thing.

So congratulations.

Thanks.

All right, everyone,

we are at DjangoChat.com

and we'll see you all next time.

Bye-bye.

Bye-bye.