Jacinda is the co-founder of Apero Health and formerly CTO of DoctorOnDemand. We discuss lessons learned building both platforms from scratch and how to scale code and teams.
Will Vincent 0:06
Hello, and welcome to another episode of Django chat the weekly podcast on the Django web framework. I'm Will Vincent joined by Carlton Gibson. Hi, Carlton. Hello, we're pleased to be joined by jacinda Shelley of Afro health. Welcome to the show.
Jacinda Shelly 0:17
Hi. It's great to be here. Well, and Carlton,
Will Vincent 0:19
we're thrilled to have you on I've been a fan from afar of your talks, and some of your writings. So maybe to jump right in. Could you tell us how you got into Django and then we can talk about all the cool stuff you've been doing with it.
Jacinda Shelly 0:30
A Django specifically was
Will Vincent 0:33
our partner Python I art you know, you can give us the origin story is shorter as long as you like,
Jacinda Shelly 0:38
okay, I'll, I'll try and keep it compressed. And then we can expand if we want to i. So I started learning to program in, in Python. When I was at MIT, actually, right after they switched their introductory computer science course I was a transfer student there. When they made the transition from scheme to Python, and so that's where I first got into Python and loved the language and was fortunate enough that the first job I had after university was at a place where all of our back end code was in Python. And our front ends for the the web applications were in JSP and javaserver faces at the time. But a couple years in got the chance to sort of rework that for a different prototype project. And we worked with Django, and then my husband, who's also a programmer, use Django for a side project. And so we started working. We both started working with it, I think around one, two or one three back in in 22,011 2012.
Will Vincent 1:48
Okay, that's back in the day. I'm curious, what is a back end, not written in a framework look like with Python? Was it using something else or is it just sort of raw from scratch the first job
Jacinda Shelly 2:00
It was a sort of from scratch JSON RPC API interface.
Will Vincent 2:07
And what was in connecting with, do you remember what kind of what type of database? Was it like MySQL? Or?
Jacinda Shelly 2:13
It was? It was originally my sequel, and then we transitioned to Postgres. And the we were using mod Python with Apache at the time. Okay,
Will Vincent 2:23
doctor on demand where you were was Django from the beginning. Is that correct?
Jacinda Shelly 2:27
Yes. That was the first project where I was lucky enough to get to choose this stack. And I was honestly quite nervous about building something completely from scratch.
Carlton Gibson 2:41
Yeah, no constraints.
Jacinda Shelly 2:43
No, no constraints, really. And got to choose Django.
Will Vincent 2:49
But it is such a different beast. Like, I've been really struck by the fact that yeah, I mean, your average, you know, Django, engineer expert. You almost never get to start something. from scratch, and so it's not that you don't know where the pieces are. But a number of people I certainly look up to have ping me being like, Oh, I was doing a side project. And I haven't done one for a couple years. And I was trying to do something. And I looked up a post by you and I'm like, Oh, really, you looked up something by me like, you're, you know, you're this genius. But the different spheres and you know, the startup phase is a different one. But I totally agree. Like, it's it also does feel like this burden of like, I don't want to, like I'm almost done with a relatively big project on my end, and I'm totally overthinking it, because I'm like, I should architected perfectly right with what I know. But there is that balance between like, just right, but
Jacinda Shelly 3:38
that's, that's always the balance, right? It's like, I definitely felt this pressure, like everything I did was kind of gonna cascade down but then I also eventually realized that if it did get cascade down, that would mean that people were actually using it and so it's, you know, if you're lucky enough to have right down the road. Something went right on the business sent. Oh, no cares about technical debt on an unsuccessful project.
Will Vincent 4:08
Yeah, right. Right. Well, I think too There's I've started to think more and more about the patterns and the the fact that does some sometimes seem like some things are easily easier to change than others. But yeah, at the end of the day, like it's all code, it can all be changed. It's just some things take a little more effort than others. So maybe I personally, I've gone full circle. Well, I've been like, I really don't want to have to back in these things. I don't, you know, over engineered up front, and that's like, well, it just to your point, though, it's like it's all fixable in tech tech, no one talks about technical debt and something that failed. So
Jacinda Shelly 4:41
that's what I did. Like.
At the time that I started, it was right when Audrey and Danny were republishing The, the first edition of two scoops of Django and so I I had an early copy of that. And basically used it as like a checklist of everything that I needed to keep in mind. Like I read the book essentially covered a cover, and then took notes on all of the things that I needed to make sure to keep in mind as I was building out the initial product. And I'd say that that helped a lot. And their book was, was something that as the team grew, we actually would buy for engineers coming on board because we're like, yeah, there. We don't do absolutely everything in here. But if you use this as a starting point, then
you'll have at least a solid foundation.
Will Vincent 5:40
Yeah, I think that was the first that was the first Django book that I like read more than once and really enjoyed and actually I remember so I before I got into pub to make this about me before I got the book. Like a whole bunch of like typos. And I actually sent them and, and they were really sweet. I is a They had problems with it's and it's, and they sent me like an autographed copy after and so I was such a fanboy. I was like, Oh my god, you know, these crazy people did this thing, but it was such I agree. It's like it's basically the Bible still. I mean, and I think, you know, even though they haven't updated I it's still on 111 I hope that they do because the advice is, you know, 90% of it hasn't changed in terms of being rock solid.
Jacinda Shelly 6:24
I definitely bought the the new additions as they came out. And it's funny funny, you mentioned like a typo. Like I got it like, just a couple months before they published it. But I did find like one typo. So I think my name is right at the the end for the first edition because of that, and I was like, it doesn't seem like enough. Just finding one typo should not be a reason that
Will Vincent 6:47
Oh, yeah, I think I'm in I think I'm in there too. It's a really night. Yeah. Now that I'm thinking about because it's a really nice thing to do. I think I did. On my first book, I had a whole bunch, but now, I mean, so many people catching so many things. I sort of stopped doing that. But anyways, but on architecture, I'm curious. So doctor on demand, so you just started it. And then it grew to this massive thing. I guess the other thing I've been thinking about recently is, I mean, there is no architecture that starts small and scales all the way up like there. It has to change. So I'm curious, what if you can look back and think of like, Yeah, what were those big changes in terms of architecture? Or what were some tipping points reset up? We need to, you know, we need to change how we structure our apps to larger things around I don't know what what were the things right, because that's such an amazing journey to go from, like the initial lines of code to like a large code base with a lot of engineers. Yeah, it was, I think don't get to be it was
Jacinda Shelly 7:38
an incredible journey. I was super fortunate to get to work with like, really incredible people and and stay long enough that I saw the team go from like, myself and the two mobile engineers who started right after I did, all the way to like they have about 50 engineers now, and handle thousands of video visits a day. Interestingly enough, whether by luck, or probably mostly, mostly luck, and like copying people who I admired, large portraits, portions of the architecture are still the same, like it's still a Postgres database. And I think one of the things that helped in, in scaling was trying to like use things in the way that made sense for them. So like, we use Postgres for relational things, but then also make really heavy use of Redis for things where Redis makes more sense. So like, caching, simple key value stores, and then a lot of the priority queues are done in Redis because Redis makes that Really easy. But it can also be persistent which queuing is is a big part of the back end architecture at Dr on demand. Because you imagine like people are waiting to see a doctor and the routing mechanism there is based on the state that the patient is located in. So in the US, you have to be routed to a doctor that's licensed to practice in the state that you're that you're located in. So we have to do a look up. We do a geolocation lookup to find out where you are, and then match you to a doctor that's licensed in your state. One of the things that is an interesting story, I think, is premature over optimization and not doing some simple math ahead of time. I over engineered the original version of how we route patients. So I think you had a reference In some of our notes to the the first talk that I gave on like how we were using celery. And one of the things that I did early on was like, Well, if we need to scale to like every state, it probably makes sense for like every state to have its own celery queue. But that got really unwieldy. Whenever providers had multiple state licenses, in terms of like tracking when doctors were in weren't available in different states if they could see patients across multiple states, and tracking the state there. Turns out that even at like massive scale, the scale at which humans need to see doctors is sufficient to just run through a single process. So later, like after someone was like, so how scalable would this have to be even in like your wildest dreams. And I did some back of the envelope math. And I was like, yeah, that's fast for a human but for, for even for Python to be routing, like you could handle basically, all the patients, like even if 1% of everyone in the US was sick and needed to see a doctor over a single 24 hour period, you can run it through one routing system. And it's, it's totally fine. And when I when I realized that it was like, Oh, well, this is a lot simpler now, it's actually a lot more stable, and kind of automatically fix a lot of bugs. So it's, it's not the typical scaling story, actually, where it was like, I made a realization that I'd overcomplicated something and then simplified it.
Carlton Gibson 11:44
I think that that's really cool. I think that's more typical than you say, though. I like that we, you know, you read, you know, high scalability or whatever. And you think, oh, I've got to build a system like this, but I think 9598 99% of web apps have exactly this. Kind of phenomenon where you actually a simple stack and you might get a slightly bigger server, but one of them's enough and a slightly bigger database, but you don't need, you know, redundancy. And that's that's a common story. I think. I think, you know, we, you see these blog posts will Django scale? Yeah, it will scale more than you need. Yes.
Jacinda Shelly 12:18
If you get to the point where you're worrying about it, it's scaling. That's, that's a good problem to have. And if you're having trouble scaling Django, with a site that has less than, you know, hundreds of thousands of visitors a day, there's probably something in your configuration or your code. That's the issue. It's not it's not Django, that was the other thing was keeping an eye on on queries because the database and like always, learning about how the ORM works, and when it makes queries and and the single biggest thing that helped in in not having to like shard or like do crazy things with the database is just making sure that the queries were
And that the ORM was used correctly.
Will Vincent 13:10
Are there any examples you can give. So I mean prefetch, select related jump out, but what were like what are like next level
Jacinda Shelly 13:16
expressions select related, but then also realizing that like iterating over a query set, as opposed to like pulling all of the values at once can be a big time saver. On certain tables, depending on what you're storing, like, only can be really valuable. Especially if you have certain columns that store like large amounts of data, so you can either like use only or exclude certain columns. That can be an easier way to eke out performance than like trying to redo the whole schema. And, and keeping an eye on like, and using Django debug toolbar was was always super helpful. Anytime I saw that there were like 1000 queries coming from From like a single API endpoint or a single webpage, it's like, there's there's something not right here.
Will Vincent 14:08
Yeah, it's like an N plus one, or I was gonna ask ya beyond Django debug toolbar. But then we made we're probably getting to monitoring tools because I find Django debug toolbar gets, gets me a lot of the way there. And if there's a problem like so, I guess, did you have rules of thumb for beyond seeing hope is 1000 queries like, just looking and saying, Oh, this feels slow, like, how did you when you have so many things you have to deal with a growing platform? Like what jumped out is us like, Oh, this, this deserves to be optimized versus something else. think that'd be like, that's a really interesting question. When you're in charge of the tech stack, how do you decide what what jumps
Jacinda Shelly 14:42
This feels slow thing was, was it a recent employee, good benchmark, to be honest. But also over time. We put in place monitoring. So our architecture was set. That because we actually launched on mobile before web, we kind of got a clean separation between front end and back end. Because the iOS and Android platforms were using in API. So when we added on a web browser, it was just like, Okay, this is going to be a single page web app that is using the exact same API. So at the API endpoint level, we tracked how long on average each endpoint took to respond. And then we could evaluate like, and we had some rule of thumb thresholds based on we we definitely didn't always follow these, especially for certain endpoints that weren't used as often. Like I think the part of me that is like the engineering purist was like, No, we should have a threshold where like, no API endpoint can go above this. And then the other part of me that was was thinking about the business from the startup was like, there are other They're things that are more valuable that we could be working on. And this is this is good enough. And that's always a tough balance. But monitoring that the API response time, average time got us a long portion of the way there.
Will Vincent 16:14
That's pretty forward thinking to be mobile. Your second was at 2013. I think you said or, I mean, because now that sort of, I would say, standard practice, but that I think even then, right. I mean, I found it only bit out, well, I guess, four or five years. But did that was that a big decision to make or like, I mean, because that's very precious. But I don't think that was the case. Really, back then that you would default. This is this is
Jacinda Shelly 16:37
one case where I definitely can't take credit. Our CEO at the time was like, we're launching on mobile. And we're not going to do browser first, I think for a few different reasons. Because we were trying to be next generation was probably part of it. But also, it ended up being that yeah, that's That's one we're actually the requirement came from from outside of me. And I was like, Okay, cool. I'll design around that. And I can't really take any credit for
Carlton Gibson 17:09
my experience. I did mobile app development around that time. And it was that was the real that was like the mobile app Gold Rush days, though, you know, 2013 2014 people. I've got an idea for an app you couldn't you couldn't go anywhere without people telling you their app idea and expecting you to build it for free. It was it was crazy.
Will Vincent 17:30
Equity Carlton equity. Yeah, no.
Carlton Gibson 17:33
And don't get me started on that. That's scars from the past. But
Will Vincent 17:36
yeah, well, that and I assumed you use Django rest framework. Is that correct?
Jacinda Shelly 17:41
You know, this is actually a funny story. We we did not. And, Okay, interesting, and there was a transition to using rest later. It. It certainly stemmed from the previous job that I had had where we were using JSON RPC. And so I was very familiar with RPC. And because partly in my head, it was like, Oh, this is my, there is like some tight coupling in terms of state between the client and the server, where it was important to be tracking what state a call connection, like a video call connection was in over time, and like the progress, I certainly looking back, it's one of the things where it's like, Oh, I wish I had started with Django rest framework. But I didn't have experience with it. And I did have experience with JSON RPC, and it used it previously and it worked sufficiently well. That it lasted for a long time. I think also at the time, and and this was probably my own inexperience with just with the community and the the framework, honestly, where I remember that DRF was, I think there was a Kickstarter project in 2013. And so I was like, oh, they're making this big transition. I don't know if I want to do something right on this transition, or it felt like that without digging deeper into it.
Will Vincent 19:16
Do you have insight, Carlton on what that?
Carlton Gibson 19:18
We do? Yeah, we just had Christy last week and like he was going over the history. And yeah, that time that transition from two to three or one to two, and he was wanted to do one to two in the Kickstarter there and
Jacinda Shelly 19:30
yeah, yeah. I also vaguely remember thinking that I might want to do the entire API. In engineering ideal is terms like, well, if I do it in JSON RPC, then there's a potential that I could do it entirely over WebSockets and like, not be tied to rest based constraints, which, in some part of my mind seemed very appealing.
Carlton Gibson 19:57
But you're thinking like so you've got real time thinking? Between the client, the mobile client and the the API back end, right. So I was gonna ask you what was how are you handling that kind of communication on the back end?
Will Vincent 20:11
Jacinda Shelly 20:12
that was actually one of the first places where we used Redis. So I had a poor man's state machine. James Bennett works at a doctor on demand now, and he can probably like laugh at my my first implementation of this, which was, I mean, it lasted long enough, but it was, I could have done it so much better. Right? That's,
Will Vincent 20:36
that's software, right.
Jacinda Shelly 20:38
So we use Redis to track the state that a doctor was in and that was tied to like, a call ID. We never did the actual real time video we were forward thinking enough to and I had had experience like building out video infrastructure to smaller scale and so I was very pleased when The founders were like, yes, we already have a company that we're using that you just have to interact with their API for the actual video part. So we just had to track the state of a call and it would transition from, you know, like, someone
makes a request that they want to talk to a doctor, and then
the doctors have to be paged.
And then they can either accept or reject a call. If they accept then the call goes into a connecting status and the video connection happens peer to peer. And then once it's confirmed as being connected, then it moves into like, okay, the call is now in progress. And so, that status was, was tracked in, like the state for each doctor was stored in Redis. Since it had to be updated frequently and was was more of a key value entity But also kind of needed to be persistent if the call got disconnected or someone came back later or something like that.
Carlton Gibson 22:06
And so I'm on my mobile phone and I've got a patient and the doctors accepted my call, and I'm in the connecting state. How are you? How are you like polling or using what you're doing to communicate the connection state back to the, to the back end, just from the client? Because
that's kind of the back ends on the tricky question. The
Jacinda Shelly 22:25
back end was the arbiter of all state which which was actually a good decision. So the client, if it did get connected, it would have to ask the server what state the call was in. And then as state transitions happens, that was where we used WebSockets. So and push notifications, so when us so say, you were the patient, and you made a call your call. Once a doctor accepted we'd use the website connection to push a notification to the client that the call had been accepted with information on like, what state it was now in. And then the client if it hadn't received a push notification in a while it could use polling as a backup mechanism, because polling was much more expensive.
Carlton Gibson 23:19
Yeah, you got the whole HTTP over. Yeah, super. That's really interesting. So, you know, I don't know how it comes across on the podcast, but
Jacinda Shelly 23:27
yeah, I don't know. Exactly like, how how getting into that level of detail will come across on the podcast, but um, oh, the other thing that we use that was successful once I got the configuration working was with celery, from the perspective of using scheduled events. So if there needed to be timeouts on something, like if something hadn't happened in two minutes, using celery for that was a very successful choice, although from an infrastructure perspective, like could also be frustrating at times because it's, it has so many little knobs in terms of configuration that the first few times that I started using it. There were some deadlocks that happened like 1130. And I was the only person on call and that interrupted like, a trip to New York, I definitely have to thank my husband for being very patient. That first winter after we launched where I was, like, I need to go find a Starbucks get Wi Fi cuz I would get text message alerts on my phone. If anything, it for any, like errors that happen.
Will Vincent 24:44
So speaking of that, what was it like scaling up the team because you said there's now something like 50 engineers, I guess in terms of I don't necessarily wanna get into the hiring because that's this whole old topic, but for you being the like letting go and then managing people. That's always I mean, that's super deep topic. But what are your, I don't know, what are your sort of rules of thumb that you take away from that, that you're now applying to your new startup? Right? Because especially the first time it's such a, there's so many balls in the air you have to juggle to keep something going, bring on new people find stuff for them to do let go of certain things. All that
Jacinda Shelly 25:22
Yeah. The balance between like, letting go and implementing has has always been challenging for me. And actually, like this is the sort of like third kind of sine wave in my career. I think I'm a little bit unusual in terms of engineers and like I actually also enjoy the management piece of it. But I get a little bit antsy sometimes if I if I haven't done code. So at my first job, I started as an engineer, I was actually hired as an engineer and it was also a very small company. I showed On my first day and they were like, oh, by the way, you're now leading this team, you have one person reporting to you and you need to hire someone else. And I was like, Wait, what? I'm remember this was my first my first job after
Will Vincent 26:18
that's a vote of confidence.
Jacinda Shelly 26:19
It was a it was a terrifying vote of confidence to be honest, like, like, What are you thinking?
but was able to like expand in scope of responsibilities and always enjoyed like organizing projects and like figuring out how different people could fit into pieces together. But after that job I I wanted something more hands on for a while. So that's why one of the reasons why Dr. On Demand was very attractive as like a first year because like, I was excited to be very hands on again. The trickiest thing for me in scaling a team was was was learning to get I think the same sort of dopamine rush that you get from getting a piece of code to work from helping other people build systems that would let them get code to work and thinking of it, right. It's
Will Vincent 27:18
a longer term thing.
Jacinda Shelly 27:20
And it's it's definitely a, I don't know, if it's entirely a personality difference, or, like some people, I think, just naturally seem to be better at it than others. It's it's always been something that's been challenging for me to, to let go more off.
Will Vincent 27:38
I think some people are, get a little tired of coding. So, I mean, I think Part Part of it is maybe this idea that, you know, effective technical managers do oscillate between, you know, rolling up their sleeves and managing others. But, yeah, it's hard to say it's one of those. One of those I just read that with that book. technic technical managers just came out today. Three years ago talking about all these things and all these tensions from the woman who was CTO of English Rent the Runway. Oh, cool. And there is no. Anyways, my quick takeaway is there is no person who has like a perfect equilibrium on this thing. I mean, the very things that make you a good engineer the kind of things that make you go, you know, maybe sometimes not want to deal with other people's issues, but then if you are the type of person who can see that helping others, you know, is a magnifier and also, in some ways feels better than your own individual stuff. So yeah, I haven't seen anyone with an answer, Carlton, I don't know what your thoughts are.
Carlton Gibson 28:33
Cool. I live a hermit lifestyle for a reason. You know,
Will Vincent 28:38
you're an IC for life.
Carlton Gibson 28:39
Yeah, no, I like Yeah, I do like mentoring. I do like helping other people and work in a team environment, you know, to to help on other people reach it. I see that it's great, but do I choose to do that as my main thing? No, I don't choose to do that as my main thing.
Will Vincent 28:57
Yeah. So he was just ended. It's impressive that you've been able to do both because it's either one is a lot of work and to do both three times now. Yeah, not for the faint of heart. So I do want to talk about your, your current thing, and maybe we can transition to that, you know, so round three, like tell us what is appro health what's what's been different, you know, on the technical side versus doctrine demand. Having gone through that turn,
Jacinda Shelly 29:23
appro health is a medical billing startup. So probably tackling a challenge that, you know, it sounds terribly boring. But if
Will Vincent 29:37
we could, I mean, it's very relevant. I'm dealing I think anyone of a certain age is just dealing this all the time if you have family, it's just how Yeah, I understand the problem. But
Jacinda Shelly 29:46
I was exposed to the problem when I was a doctor on demand when we cuz originally we only took cash pay, which was very straightforward when we started accepting insurance things got an order of magnitude more complicated than I expected. And we were working with an outsourced medical billing partner, who, who was supposed to handle a lot of the complexities and so watching the way that they operated. I started thinking about like two or three years ago, I was like, this seems like an area that there's just not overlap between people who really understand software and who also really understand billing. Because they both take, I think a lot of time to to fully understand the complexities. Interestingly, my my husband had been looking at like various ideas because he wanted to found something of his own. He has a connection with a family medical practice and I was like, well, for for a doctor on demand. This is this is a big pain point. Maybe you should talk to your your family practice. And see what it's like for them. And I was I was not. This was several years ago there were there were like so many things that I wanted to do a doctor on demand that I was like, God, it's not something that I can work on right now. But I think there's definitely like problems that could be fixed there. So. So he started looking into that also was looking into other ideas. So it didn't really go anywhere for a while, was working on appro and then and then eventually came back to it. And he had been working on this since the end of last year. And was accepted into yc, which is kind of when when I decided that it was something that I also wanted to pursue. So one of the differences so far has been like, yes, we're still using Django. But one of the differences has been like coming into a project that already has like a significant amount of engineers. work that was done before I got there. And also like I, until really the last month had been much more in operations and sales and wasn't even like touching the code. So that was a whole other exercising a different part of my brain.
Will Vincent 32:17
I just saw I'm just thinking of the dynamic dynamic of like, not just looking at someone else's code, but a spouse's code. What it is,
Jacinda Shelly 32:28
because both ways, right.
Will Vincent 32:31
So it's not it's also with Django. Is it also Postgres, like, what's the quick kind of stat rows using Django,
Jacinda Shelly 32:37
Postgres running on Google App Engine, but using DRF and graph qL, for some things, react on the front end, okay. So it's an interesting mix of things, but mostly, like, mostly boilerplate and pretty much what you'd expect if you've seen the tech stack that I've been working With for the last seven or eight years?
Will Vincent 33:02
Well, it's I mean, it scales we just had women Fang, who wrote a popular post on the boring tech pen to one person tech. tech company was talking about listening notes his company, and I mean, if you can do it, if it works, it works. And yeah. When you say you're boring, or No, you didn't say boring, but when you say you like it's pretty vanilla and how you would expect if you knew the stat but that means you're using it right? You know, you're going with no, but you're going with the grain of the state of the word, you know, you're not fighting it. And then it does scale, then it does work. I mean, that's what David had. Mr. Hanson was was saying with pride, when we talked to him about Ruby on Rails is that both Shopify and GitHub are now on vanilla rails, whereas they had custom this and that over the years, but, you know, it's a point of pride to be even at their scale on vanilla releases. So actually, so maybe that's a relevant question. Django, just, Django just updated? I'm curious either a doctor on demand or, or an app pro? How, how up to date? Were you all with the Django versions? What were those transitions? Like? You know, being hands on?
Jacinda Shelly 34:14
Yes. Um, I can. I can talk about this now at doctor on demand. It was like, something that I felt like I had to hide for a long time. But it's, it's relevant to be on one, five. No, but it's relevant to to the point about vanilla rails where, and it's also relevant to like, choosing dependencies carefully. So there was, yeah,
Will Vincent 34:37
it was it is.
Jacinda Shelly 34:40
Early on, I was actually like, very diligent about keeping up to date with the versions and then, but there was one dependency I was using that needed a patch on on something and so for that reason, we forked Django, and then we do didn't have to after one seven. But the transition from one seven to one eight took a very long time. Actually one six to 177 to one eight took a long time. Yes. So going from and, and it was because this library that that I chose which it was an address library that, you know, had what seemed at the time like a good idea from an architecture standpoint where you have like,
a table for
four countries and four states and then like everything only has one key, but you end up with like, lots of joints. And looking back on it, that's one of the things where I'm just like, yeah, I should have just created an address model with all of the fields and been done with it. Because the pain associated with using this third party library and some of the things that digging under the hood later, they had chosen to do and like undoing that after, like we were using addresses and all sorts of places. Was was more painful than, than it should have been.
Will Vincent 36:22
Yeah, I think I hope I hope I didn't I mentioned this on the podcast, but I've I told Carlton, someone emailed me the other day, cuz I get a lot of emails from people with learning Django saying, Yeah, well, how do I, which Django apps are good ones to use? How do I tell? And I was like, Oh, that's, I mean, I sort of love the name to that question. But it's such a deep question, because it really it often is, you know, you install something, you know, when you're prototyping or you need it. And then that's what caused you to come behind on Django and, at least Personally, I'm sort of, yeah, I'm always extremely reticent to add any third party packages to my stuff. If I can. I'll try to reverse engineer Just for this very reason, but that's not a practical mindset. I mean, you just, you know, you sort of want the technical debt but you always, don't really look under the code until you have to and I don't Carlton, what are your What are your thoughts on this? Interesting question.
Carlton Gibson 37:14
I've been burned so hard so many times for this like, where I wept tears of blood of a third party dependencies. I wish I'd never installed so
Will Vincent 37:25
what can I do? No, no. Something different.
Carlton Gibson 37:29
You know, you have to learn you have to learn why is that this pip install Magic package? like yeah, it's not a good idea, folks. Like there's Okay, so there are there are what a dozen or 20 or 30 right really top notch long term mature Django packages out there that you just wouldn't there's no way would you build your own. You just use them because they've got a history they're reliable, you know? But yet, but be cautious. So go on. There was a post on the forum, Django project.com. The Django for which packages Do you like and that is golden. As you know, people have got I started that one. Well, I used it well, well done. You know 2010 Thank you Well, people with like different overlaps of their best packages. That was amazing. That's great. Use those packages, but don't, you know, be careful. So they, you know, there's something came up on Twitter they hash ID so for slugs you want Yeah, yeah, you want a unique ID I use? I use hash IDs. But I don't use the Django hash IDs project. Not because that might that might be great. I don't know. But I just won't go near it. Because I won't take on the dependency that I can't vouch for. And I learned that the hard way.
Will Vincent 38:43
Yeah. Well, that I think that will link to it. I think I think the question on the on the Jenga forum was top five third party packages because I was curious if there was a standard overlap. And I think you know, it quickly becomes really like 1015 for most people that they're using on every project. But that is one of the things I think about it. terms of Is there a way to shortcut to that without you know tears and pain to
Jacinda Shelly 39:06
you to provide a counterpoint like I'm still very pro dependency and there there are other dependencies where I'm like so glad that I found them yeah, there's there's one called that it's actually not super well known. But it just works. And it's it's called qR but i think it's it's hard to find because
Carlton Gibson 39:31
you can't Google for it.
Jacinda Shelly 39:33
But because there's another package that also has it and like it looks like it all I'll have to find it and put it in the show notes. But it's it's what I used as a wrapper around Redis queues and it worked really well. And the whole thing like was one of the one of the reasons I didn't have qualms using it either was the whole thing was like, probably 500 lines of code and I could like grok it and like, see what it was doing? It was like, Okay, this this is like, fine. And I don't have to write this myself. And thank you to the author for like putting this out there because it was incredibly reliable and easy to use interface. But yeah, there are libraries that I wouldn't start a project without, but it's, I sort of have this. Someone asked me about this once. If I had a philosophy around like what tech I chose to use. And I said something along the lines of like, I like to use things that are new enough that people don't cringe when they hear you're using them, but mature enough that I'm not getting woken up at two in the morning, more often than necessary.
Carlton Gibson 40:56
It's a good rule of thumb. Well, I was just gonna say I like what you said about It's only 500 lines, I can grok it. So the sort of cast iron test for a new dependencies, if push comes to shove, if this never gets another commit in its entire thing, could I take this on and maintain this as part of my, you know, daily job if I for the good of this project in that case yet, okay, maybe take it on. But if it's, you know, loads of models and loads of views and loads of stuff in it, is this is this really what I need? From my point?
Jacinda Shelly 41:25
Yeah. And that was one actually, I think the dependency that I mentioned is actually one that we upgraded to Python three, because we used it to check in I think, I think they open sourced it.
Will Vincent 41:36
Is it Django r q? Is that the one
Jacinda Shelly 41:38
cute? It's just called qR. And if you look it up on GitHub, it's it's TNM slash qR. And I was able to find it because it's one of Dr. demands public repos, this QR three, which is the Python three version of it,
Carlton Gibson 41:52
just just before we move on just just like by going back to the history of Django, like I think that upgrade period. Between, like 1.5 1.6 1.7 1.8 the whole migrations coming in and that was just a, you know, that was a massive difficult period for a lot of people a lot of projects. And I think that it sort of marks different sort of up to one, eight, and then 191 10 111 to, you know, it's there's a whole different world now. Right? It's much smoother, much easier. Yeah. So changing. And, and to that point, my level of the framework,
Jacinda Shelly 42:29
I am actually so grateful that we started with one five and not one, four, because going from one four to one five would have been painful. Yeah.
Carlton Gibson 42:38
So it's a different like, it's just like a different epoch and Django says those early days to
Will Vincent 42:43
now. Yeah, well, and even 3.0 it's just came out sounds like a big leap from 2.2. But I just updated a whole bunch of projects, and it's really not much of a leap. Which is, which is really, really nice. That's how you tell you one, it's a thank you Carlton. Mario's He's
Carlton Gibson 43:00
making that happen is the contributors and Tim Graham has gained for like, put putting the systems in place such that Django has, you know, the stability that he needs as a mature for him.
Will Vincent 43:11
Yeah, I just said I wanted to ask you about. So you've given a tutorial on security, I think at least the last two Django con tonight. I haven't been able to attend in person, but I've gone through all the slides. It's really fantastic. I wonder if you could just sort of tee that up in terms of, you know, because I think you what, what does that tutorial like, and I hope you keep doing it, right, in terms of I think you take a Django app and then ask people to hack it and run through kind of best practices, which are super relevant to your medicine.
Jacinda Shelly 43:42
Yes. Um, it's, it's one of the things that I actually really like about Django is how seriously they take security. Like even when there was a time period where we were using an unsupported version of Django. We we made sure to backport any security fixes? And keep keep on top of that. Much better when you're on vanilla and you don't have to worry about that because you get it for free. Ah,
Will Vincent 44:14
Jacinda Shelly 44:15
but the security tutorial is again another thing that I can't take credit for. It's actually originally a shishas tutorial that he gave that Python. I want to say 25th 2014 2015 I have to double check. But I was giving a tutorial at Python. Yeah, python 2015. I gave a tutorial on the Django admin actually, which I had also given at Django con 2014, which was my first ever Django con. And I was crazy. Simultaneously crazy enough to propose a tutorial and a talk and then the organized accepted both of them from a first time presenter. It was it worked out fine.
Will Vincent 45:08
Yeah, we'll link to that talk. That's a fantastic talk, because you talk about, yeah, building out that early version of doctoring to man.
Jacinda Shelly 45:13
Will Vincent 48:22
But yeah, yeah, it is. Well, I think I don't know if either you know, when the deployment checklist that is part of Django that I think we've talked about in the show, I mean, I find that so helpful, right? Because it really is there is like the dev version and the production version and for someone who hasn't done it before, like I go into some depth in this in my book but it's it's a quite a leap to edge you know, to understand what are the differences and then why would we not just have it be secure all the time and and then it would be what you know, I love the pen test version of like, hack this site, which is I think, yeah, such a fun way to do these look can be some time Dry things. And I didn't realize it was actually you just spin up a dedicated Heroku for each site, I guess, I guess you need two accounts, right? Cuz you only get five free accounts from Heroku. But it's I do
Jacinda Shelly 49:10
Yeah, I got the like,
I have a paid account, but I don't think I've ever even even with the tutorial having don't think I've ever had to really pay very much at all for the way it's being used. And, and all of it is like all of the all of the slide content and web app content is all available on on GitHub. And so anyone can can go through it. And, like set it up. The basic takeaway of the the tutorial is don't override those defaults. Unless you really know what you're doing. And are you really sure that you know what you're doing?
Will Vincent 50:00
Right. I also want to ask you about I saw this year at pi con, you gave a talk on speeding up the Django admin. Oh, yeah, I guess I'm curious. At what point do you leave the Django admin in terms of playing around with your data and stay in it because you showed all these fun optimizations? But with your experience, what's your kind of rule of thumb for when are you abusing the admin? And when are you improving it?
Jacinda Shelly 50:20
Um, you're definitely abusing the admin if it's your primary customer support tool.
That's that's one, one key indicator.
Will Vincent 50:32
I forget did you put I don't think you I've seen people like throw elastic in the search there. I don't recall if you I remember you showed you step through how to speed up. Like some queries.
Jacinda Shelly 50:41
I I did not do that. But I know.
I know the woman who gave the talk about throwing Elasticsearch in there. And it's, it's quite a good talk. I definitely encourage people to go watch that one as well. I think she gave it at Django con this year, or
Will Vincent 50:56
Well, we'll find it and then link to it. But I mean, I love I love your presentation because you took like a really slow query, and then you kind of step through ways to improve it, which I love that teaching approach rather than just giving the answer because without the context, it's just like some code you've memorized. But I assume that came from some real world examples of using the admin to do lots of stuff.
Jacinda Shelly 51:18
Oh, yeah, the admin is a great way to like, get a quick overview of data and like, make quick changes. I think if it's, I think the general rule of thumb that the documentation gives if if you're using it primarily for like internal use, then that's great. If it's, I don't want to give like a blanket rule, because it's like, it's such a useful tool. Yeah, but I think it can get tricky if it's like something that is externally facing like, that's probably a, you know, I don't want to say blanket, bad but a application smell. Maybe like, Are you are you really sure this is a good idea? kind of thing.
Will Vincent 51:58
Yeah, I mean, you can use you can do a lot of permissions. I would, I'm 100% agree you shouldn't show outside or customers, your admin panel, I mean, even and even, you know, basically the clue is the user model, right? It's gone to his staff flag. And if you're not staff, you can't log into the admin by default.
Carlton Gibson 52:16
Right. So go with that.
Jacinda Shelly 52:18
If everyone is staff, you might Yeah.
Will Vincent 52:20
Carlton Gibson 52:22
Well, right, you know, if internal side internal app, you know,
Will Vincent 52:26
well, I mean, cuz you might have, I don't know, customer support versus engineers, some people can do reads, some people can do
Jacinda Shelly 52:32
the, the addition of view permissions, I think was was really nice. From the perspective of I don't know, depending on your perspective, either making the admin more flexible and more useful for for more people but safer, or from the perspective of like, just encouraging people to quote unquote, abuse it more, I don't know, that's, that's potentially one of those like, we could go down a deep rabbit hole here.
Will Vincent 52:55
Yeah, well, I mean, I think on some level, you have to take responsibility if you have enough knowledge to Customize the admin. Go for it. I mean, not go for it, but like, you know, it's a little bit how I feel like when I'm when people ask me about like setting things up computers and they're using Linux, it's like, well, you're in Linux world, like I exempted yourself into a different category
Jacinda Shelly 53:15
sounding trite with with great power comes great responsibility.
Will Vincent 53:19
Yeah, well, yeah, exactly. I was gonna say on the admin, this just came up two days ago. The thing one, if I could solve one thing, it's like, don't have your admin slash admin, like, I was looking at some somewhat prominent Django company. And I was like, I was like, I wonder if admins exposed gets exposed. And I was like, you know, doing past you know, so change that, like, I would rather you give outside access to your admin and have that slash admin. Personally, Crowthorne you just think it's so easy to change
Carlton Gibson 53:52
to magically change instagram.com forward slash add on?
Will Vincent 53:57
Well, I mean, I just I just I just I just really judge harshly. It's a little unfair. But I looked at that as like, nope, they just dropped a whole bunch of notches. Like you got to change that. Anyway, sorry. Your talk, though, I think you focused a lot on, on queries, right on speeding up. I forgot that that schema that you were dealing with,
Jacinda Shelly 54:18
yeah, I think an alternate title for that talk could be like basic usage of a Django debug toolbar for analyzing for analyzing queries, and it just happens to be really easy to like, demonstrate that against the admin because it's very easy to create, oh, in queries, when, when using the ListView.
Will Vincent 54:42
So So one other talk that you've given that isn't technical, I think was on becoming a parent. I'm curious if you will link to that if you could share, you know, the non technical side of being a coder.
Jacinda Shelly 54:53
Yeah. I think being a programmer has been simultaneously like a huge blessing when when it comes apparent because it's fortunate that it's a it's a job that in some cases can can be more flexible. And, and I was really fortunate that it doctor on demand the culture was such that, like, I was able to take I was I was able to have a an extremely flexible working schedule, especially after my, my daughter was born. And so in that talk, I discuss some of the things that like I totally didn't expect becoming a parent. And it was, it's different from most of the other talks that I've given that that you'll find my daughter actually ended up on on stage towards the end of that talk, because she was she was 10 months old and she was being held in in the front row for a good portion of the talk and then she decided that she was just not not happy.
Will Vincent 55:53
Oh, okay. I you know what, I have seen this talk then yeah, programming post progeny because I do remember that talking I love that I think you you generally bring her to the conferences cuz I've seen you in a number of conferences that you're there because it actually makes me feel like I mean, I should have brought my kids she she
Jacinda Shelly 56:08
definitely comes along Yeah, to a lot of conferences and it's been really fun as she's gotten older and like different things. The expos are always really good time. That's one of the things that coming for the language and staying for the community has been a big part of Python and Django for me like when I started it was because I appreciated like the test technical aspects of it. And now going to the conferences is also for me, like just a connection with a really fantastic group of people that I love being around.
Will Vincent 56:41
Yeah, I would agree. And I think too, I mean, just for me like I've now my second year going to conferences, they just get more fun because then you already know people and you you still meet new people but yeah, it's a very welcoming community.
Carlton Gibson 56:55
Right to send a thank you very much for coming on the show. What a Super Chat I you know, Everything technical details all the way through to community and family and life and things like that. So super Yeah, thank you for thank
Jacinda Shelly 57:07
you so much for having me and for like having a podcast for the community and definitely very much appreciate all the people who who spend time putting out content for people.
Will Vincent 57:20
That's well thank you for sharing your your stack too, because I think we're not afraid to dive into the details because for people listening, it is interesting.
Jacinda Shelly 57:29
Thank you so much, and I hope you have a great rest of your day.
Carlton Gibson 57:32
And that was Jango chat. We're on Twitter chat Django and join us next time. Bye bye