Transcript: Understand Django - Matt Layman

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome, Matt.

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 podcasts for a while.

Um I guess how are 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?

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 I probably have not continued to the level that I will desire to.

Um, but it's been been good overall.

Your day job is quite interesting.

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

Because you're still you're still, I believe, in the healthcare space, right?

That's right, yeah.

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 you, those of you who might be of a different generation.

Uh we've got all the healthcare pieces bolted together now uh and and do some really super things for uh people in the US healthcare system, um, ranging from telemedicine to helping you with billing claims and finding you the right doctors if you're dealing with some kind of um acute need for medical care.

So that's what the company does, and and Django is definitely still a big, big piece of all of that.

Because it seems to be the big thing.

Like my my my phone company are trying to sell me, you know, a similar, not you know, your service coming in Europe, but like, you know, um access to a doctor online and these kind of things.

It seems like a real growth industry.

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 uh over time it it has like uh 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 in the world that or at least in in the US that um have poor access to healthcare where there are no doctors in in a 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.

yeah, sure, sure.

Just it's 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 talk talk through your your uh your your mental health as well.

all that?

So the the I think some of the biggest restrictions around actual telemedicine have been removed.

I can't name unfortunately I can't name what those words are.

I'm not 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 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 our solution for dealing with a lot of that, uh, so that they can, you know, have access to more patients um and that we're more accessible to others.

But uh yeah, that's that's the kind of the uh more of a clinical team logistical challenge that they face.

And and at the tech pure technical level, um there's there's not really the restrictions that we might have had in the past.

Uh I'll just I'll leave it at that.

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.

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, uh, and the need to serve a high volume of traffic to satisfy um not only our our member side.

So we 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, um 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 uh that's the scenario we're we're working with.

And um, so the the Django monolith is deployed uh using Kubernetes uh to get some the scaling that we need, and we deploy um with Docker to put everything into a single single um package or container and uh put that on a on a myriad of pods that are deployed on our infrastructure, um, which uh is on US East2 and AWS, like classically, as you know, so many San Francisco-based startups are.

Um and um there's there is uh uh thick clients that talk iOS, Android, web native stuff that uh so everything is over over these um API protocols mostly.

We don't do um many server render pages.

We have some back office functionality uh that is 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 get us our our throughput.

And then I guess the qu 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're happy with the monolith style or

The merger took like all so our our teammates from Graham's Health came in with their their tech stack was a Ruby on Rails shop.

Uh 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 a secondary monolith that is the the primary functionality of that legacy business, which is in and of itself, um, it's not quite as big as the the Python monolith.

It's probably in the order of it's 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 uh some Python stuff, and there was data science stacks in there.

So uh when when we joined together, we suddenly like, whoa, okay, there's this this whole new polyglot world here, and and what are we going to do about that?

And and the business decision was not to create some sort of subsidiary strategy, like it was an equal merger.

Uh, 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 of it, just to layer one more thing on there, just to if it wasn't interesting enough, they they were using primarily GraphQL as their interface layer.

Uh, there's probably some R, I think there was some J some GRPC in there somewhere as well.

Um, like five or six languages.

Um, and the Doctor and 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.

We have um lots of uh Go services uh that we have, and then all all this whole uh roster that that they had as well.

Um and we're doing and because it was two healthcare companies and we had two modelers, we had uh like it was what would be one thing if they were just fully independent services, but we're we have also like overlapping concepts.

Like we both have modeled a doctor, you know, uh in some way, and we need to now unify the modeling.

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

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

Like that that problem is is a fair, I mean it's hard, but it's a fairly solved problem.

Uh, but then actually bringing together design is like a whole whole other challenge that we're we're working with.

I love that story.

Everything about it.

Yeah, I can imagine that.

It's it's it's a good challenge.

I mean, I really enjoy uh enjoy the challenge, but it's like wow, this is not what I stepped into when I first started with Doctor on Demand.

So what what is your mix of do you get to just do code all day or are you managing or architecture?

What is what does that look like right now for you?

So we're working on some really large projects.

Uh so I mentioned we have an in-house EHR, um, that's an electronic health record system.

And we are trying to switch to a vendor to finally sunset ours uh because it it's not it it got us to where we we are now.

We're really grateful for what it did.

But uh the longer term, we 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.

Uh so that that's a big rewrite because the the the health record system is deeply entwined uh in our Django monolith and very integral to our member apps.

And so it's a it's a really big uh project to to rewrite a lot of stuff um and 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 your classic, like I love developers, but they are like herding cats.

So they're they 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 I 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.

I've I've read uh 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 Software Estimation, something along those lines.

Um fantastic book on showing how how to actually do estimates, which our industry is horrible at.

And I 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.

No, it's uh it's it's very much a dialogue of a we we've got a certain amount of uncertainty here.

What are the ranges that we expect on how long we are gonna build these things?

And and uh yeah, it's uh been a useful tool.

So if anybody's looking for some light reading in the software estimation realm, go check out McConnell's book.

That's a good one.

Um, one thing I I wanted to ask from what you said, you're taking on a vendored product.

So, you know, just sort of generally, what would you can I get your take on kind of using a an off-the-shelf solution versus building your own when what what are the decisions that what are the factors that go into that kind of core?

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

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

Um 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 a bad a really bad choice and then like you know mess up our whole system uh to the point where w we can't really go back.

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

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

There's there's uh logistics problems and challenges, there's the financial cost.

Like when when do we break even on what do we, you know, this is an investment of this sort amount of time we need to get out this kind of margin gain from uh uh you know not working on some of these features that are required by regulatory problems, and so it's it is complicated.

Um I think from an engineering perspective, we looked at what uh we we met with their their team extensively, though there's when you go into a a vendor this th this large, you really get into an enterprise sales pipeline, and part of that is working with um customer implementation teams that they have they have they're they're designed to help you onboard and walk through here are 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 gonna need to do this, and 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 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 we're done and ready to roll out.

So um in in your smaller shop settings that that you folks might have be familiar with, and I I am familiar with myself, is like a year, man, that's like an eternity.

In those big projects kind of product.

So those are the challenges we're facing.

How does that discussion go internally?

Because I know it's you know it's just like magic dust you sprinkle on things, but

We our our C A our CEO is not uh immune to the AI bug either.

But we've actually made good use of it already, which is um so one of the aspects that I 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 clan 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 all hands meetings.

We're here 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 to that team though, that care team, um, interacts with a lot of members, and they uh 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 healthcare 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.

Uh 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 fifty sixty percent of the times, it's good as is, and they can just hit the send button and uh uh send it out.

Otherwise, they other times they have to tweak it and uh make the modification that will make it a more meaningful mem message to our member.

Uh, but it has saved just oodles and oodles of of their time.

There's there's thrilled to pieces that they have access to some some of these AI tools that that we've built.

Yeah.

Yeah, exactly.

Rather than what we want.

I don't know about you, but uh there's always that uncanny valley aspect of of so many of these things.

And I'd rather have a human like, okay, I I still believe you you've passed the Turing test because you are a person um and you're not just a machine.

And it's like we could just bloat on the web of stand on one side and shrink it on the other.

Um well, is it uh is all right 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 re 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.

I I could go on and on forever about it.

Uh because

well maybe one quick one.

Like, is that correct?

Like because I know there's there's a higher level of um I don't know what's not you know, it's the higher standard when you're dealing with healthcare data as opposed to just consumer stuff.

Is that that's just like the umbrella you just say, oh hippa, and then it's like

Um and within HIPAA, they define some of these these rules that you're talking about.

Uh we have we basically uh thankfully we're we're using a lot of services that are come from AWS.

And AWS, love them or hate them, they they have done a lot of work to make um HIPAA compliant services.

Um where we have to layer on additional requirements for healthcare, is usually stuff around like data retention.

With the 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.

Uh we have to be very careful about uh storing all this stuff into either S3 or you know what snowplow.

That is that the other what's the the long long oh glacier.

That's the other effect.

Yeah, it's an

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 these layers and they they think long and hard about making sure that we're compliant with this these different regulatory stuff.

Uh, all of our developers have to be trained on this.

Um, but that those teams have those extra responsibilities of when it comes to the 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.

Uh, that's where those teams are coming into play.

Got it.

So you have this weekly series um Building SaaS, where I've actually watched, I've 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.

Yep.

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, uh not many people with uh 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 how 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, that must feel good, but it's also, but what what are you getting out of that?

Because I know like I I don't know how you manage that.

There's like a live stream stream 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.

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 is 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 it looks awful.

So so many bad things about it.

So everything is a journey, and including uh the streaming stuff.

I think uh on this particular project, I 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 uh I'm I've 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, it's a like full open kimono thing because it's I the the point of it from my perspective is is not only to to build a product that I'm I'm planning to use, I'm kind of scratching my own itch with this this journaling thing, um, 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 the that the being a developer is 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 I appreciate the very nice tutorials that are out there of uh for learning, but I think that they lose some of the the real grittiness of life and and building apps.

I'm a good developer, but no way would I stream just stream what I do, you know.

You you don't want to watch 40 minutes of me browsing the docs and banging stuff out in the terminal to see what happens.

No one wants surely, ah

Like there there are uh moments where I mean I'm not doing rocket science kind of work here.

This is our uh pretty standard stock bread and butter Django apps and um thankfully.

You're downplaying a little bit.

I mean, I think honestly, I think it's I mean, I don't watch them live because at that time it 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 look is a little different, you know, it's like, oh, where do where do I look?

Where do 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 um 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 I I 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, and 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.

Um, 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 gonna do and then you do it.

It's like, how do you do it?

It's like, well, you're you're quicker at the docs, you have this past projects, um, and a rare occasion you get stuck, you 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 godlike as it gets for anyone.

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

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

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

And 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 you miss this thing?

Why don't you go just check out?

Like, because uh 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.

Like that you you're like looking for this thing, and it's right here, dummy, it's right in front of your face.

Like so uh um having kind of mob programming to with a chat uh that is paying attention to what you're doing and uh giving you suggestions, not always the best suggestions, but suggestions that you can think through is is a really valuable tool as well.

I mean, I'm always impressed at your stamina.

I mean, even like could you go two, three hours for a lot of these things, and I feel like maybe I'll maybe I'll blame my kids for this, but like I don't think I can go three hours anymore on anything.

I like need to like walk around, like, you know, just goes daydream.

I I that's so impressive that you're able to do that.

And 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 Alloth with your setup, you I hadn't seen this before, but it makes sense.

You went through the docs, every you know, 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 even for me, like I've been doing all authors for 10 years.

Like, I've never actually done that.

And I was like, that's that's like a I always 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 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, just 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 eye-opening.

Like, you know, if if there's a tortoise and hair race, I'm absolutely a tortoise.

Like I will I go slow, I'm methodical.

But the tortoise wins.

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 I do remember seeing that option before because I I wasn't, you know, I I I I did literally see it at some point.

something to say.

I think this line about being the tortoise, I think that's dead right.

I've kind of we we as an industry we kind of sort of glamorize this idea of the fast program, of the fast development.

It's like no, code 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 and 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.

That's so the the extra layer on on top of my projects here is that the ops guy is me.

Yeah, right.

You're willing to go a little slower and uh write the thing that's going to be as bulletproof as you can make it, because I need sleep.

And you know, if I don't have time for uh

No, that's not gonna happen.

Very true.

So I know so Jenga Rif'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 I I would imagine doing the podcasts informed the writing on your site and then the book.

Um, but yeah, how are you feeling now about having put all that work into those podcasts and you know maybe picking it up again in the future?

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 uh it's a project where it it's fun, but it takes a lot of work.

And like the I I know what you guys must do, or at least one of you or both of you, uh it's uh it's a lot to get the um the editing going and uh it take that takes time.

Um so I I built what I could uh with that and and recorded some episodes, but then ran out of gas, frankly.

And uh uh I I left it up.

So thankfully um I do have like a 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 up for my streaming setup.

And um, you know, I 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 I do plan to return to that and kind of a 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 I've written and the series that I've written.

Uh and then beyond that, um, I'll be switching to I I think uh the 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 and it's can is there any kind of spotlight that can 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.

Uh, but sometime next year I'll I'll pick up the rest of that and and keep it going.

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.

Um, like one of I think one of the more popular posts in the Django forum is one I put up a couple years ago about like what are your top five or ten, you know, if you have to pick.

Um and it's not the same for everyone.

Um, 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?

Because it's easy to say use use Django all auth, but like, okay, how do you use it?

You know, like you could write a book on uh 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 be fun to appreciate that.

Like I mean, Carlton um, you know, has picked up a bunch.

They're 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.

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.

Um I really appreciate what you've built.

Um, but yeah, one of one of the things I do in my podcast is I I don't shy away from actually talking through some code.

And I know that I don't know how oft how good that comes across in audio, but I 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 use case?

Can we get an 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 that they could use themselves?

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.

Um there's interesting, you know, what you were saying about uh 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 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 it there's still value, but it doesn't yet 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.

Uh what was that process like?

You know, I I know some listeners, I know that I'm guilty of sometimes talking about the book writing process, so I'm not gonna say anything on my end about it, but for you, translating from writing the series online to the book, what was that?

How how many, 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.

If you actually go back and look at the first one, it's I think I started maybe in 2021.

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

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

Um and it's it's uh 20 articles that are you know around 3,000 words apiece.

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

I I should have brought my proof copy, but to show it, it's uh it's sitting upstairs 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.

I what I did was uh I 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 used 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 lank 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 I 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 I and I got some really great feedback, but oh man, it is it is hard work if you 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 on what you can make better

Question your your soul a little bit.

Um so I think I got through that editing process, and then again, frankly, the book was one of those things where I 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 done finished with the book probably six months ago and and actually had it out for and 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 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.

Well that's interesting.

Uh is that you're gonna record that yourself and then just release on Audible in all the places, I guess.

Um I 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 audiobook market.

Uh so it's definitely it it would be a shooting myself in the foot 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 audiobooks.

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 gonna handle the code snippets?

Because 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 there, 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 uh what are your thoughts on how you how to tackle that?

Um there there might be a I I have an advantage here that I I'm committed to always leaving the content of my book online for free uh on my website.

So if this I I do an okay job, I think, at reading code content uh from my actual podcast episodes.

That's something I've tried 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 gonna 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 uh view the view the uh 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 uh code snippets for audio book format stuff.

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 I think that's the answer if I were if I were to do it too.

But I haven't.

Um Carlton, the internet has come back online in Spain?

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.

That was the chat guy.

We we we just we just were talking about the the pod Jengerus podcast and um Matt's Matt's book that he published, and he's gonna do an audio version, and so we're talking through the logistics of that a little bit.

Um as uh 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 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?

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 uh you know or any any pick any of your uh um 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 choose your tech stack to get that going.

Uh and I I the 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 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 you reach for different technologies.

So um I I'm not w honestly, I'm I'm not wild about Docker.

Um I in many senses of the the deployment uh sorry, not the deployment story, the development and debugging story is is I find I find challenging.

I find it it 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 and 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.

And you said some version of that.

And I've actually I've a new project I've been working on for a couple of 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 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?

Matt said it 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 it it you don't necessarily need all these extra bolts and win were wizards that you need when you're a 50 team team of 50 or you know where you've got if it's homogenous environment you don't need necessarily to worry about the dipl 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.

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 we can do that too.

So that that's useful and and I say Heroku but like I I'm pretty sure that works for fly and like other other systems have different kinds of schemes that that allow more for that on-ramp path um and and that's that's great.

I think that that as you go up to those other levels that's that's very useful as well.

You know

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 with my books I feel like I 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 almost I'm almost thinking with the new updates to my books should I almost have checklists like versions of like okay I showed you how to do crud with auth.

Now here's here's like two or three different examples of you know of a flashcard app or a 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 form like formalize our own like 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.

I like I think about uh same and it's it's just there's so many layers right like building web apps is 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.

And one of the things that I I love about that documentation is when you hit the the guides 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 as 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 a perfect list of and that's that's in the context of building REST APIs of course but uh uh that that kind of list and just seeing that list in that format is is a 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 thoug

ht 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 um 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've if you're looking at the the journal stream I I I start start from stock Django with a manage start project command.

And I think that's informative for those that are are wanting to to learn and they see okay there's there's no mystery here all of 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 is I'm I'm not a consultant I don't I'm not in that industry so I'm not the 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 is 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.

Yeah that's that's that's my thought on it a checklist would be useful but could we just skip the checklist altogether is where I'm going.

anything interesting it's still ours 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 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 um 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 I couldn't use it before I understood how to do it all from scratch a couple times.

So there's I guess there's a place for both but

Like if I picked up somebody else's template.

Um and that that's kind 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 is much lower.

So there there's there's the how much of the stack are you willing to bite off is is uh how I how I've sometimes thought about it.

And 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 we're we're not at the kernel driver level.

So it 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 um but I do like knowing stuff and and I think that biases me towards taking a little slower making sure I understand all the pieces and and know that what what I'm operating.

I don't know maybe the Django ecosystem is missing something like uh templates for the login system so that you you know you're not constantly recreating notes where's the the the one repo that we all go to to get the login templates well okay that would be a uh something that would speed it up but you know yeah I I I agree kind of what Mike said I don't know a concluding question though for me I don't know if we'll ask you if you had a magic wand you asked you anywhere but if you had a magic wand and you could change one thing in Django what would you change man?

Yeah yeah yeah

So I I I view sometimes I look at uh Django's sibling projects in other language ecosystems.

So this is your Ruby on Rails in the Ruby ecosystem, your Laravel, your um uh Phoenix if you're thinking about Elixir.

There 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 uh 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 I'm gonna be a little make a statement that's uh 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 any mail.

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 think 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 are the clear um most use packages.

Now how you do that and how you'd vote on that like I'm not gonna I'm I'm again I'm I'm this is my magic wand, right?

So that that that's one thing that I I would suggest um or or wish it was it was true.

The the second thing if I could uh have a magic wand it relates to um I guess it's like 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 I'm now wearing my company hat and like what can I do to make my life better?

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 I don't have time to go into.

But we have found with our model that 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 a firewall mode where uh there's some kind of extra enforcement of boundaries between the apps such that um 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 dotsome 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 if it'd be awesome if we had these extra controls to to um enforce harder separations between apps to to make it uh so that you could actually decompose a Django app into something more more manageable if it's grown too large.

Well there's a a redesign happening for Django project.com and I I'm 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 it is is hard but is ness there's a value in it.

the ecosystem.

that's a very good instant 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 uh paperback or ebook it's also on your website and you also mattleyman.com you have all the all the links to all your activities that you do that people should check out

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 be in the

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