Transcript: Telemedicine - Matt Layman

Hello, welcome to another episode of Django Chat, a fortnightly podcast on the Django

Web Framework. I'm Will Vincent, joined by Carlton Gibson. Hi, Carlton.

Hello, Will.

And this week, we're very pleased to have Matt Lehman join us from Doctor in Demand.

Hi, Matt.

Hi.

Hello, Matt. Thank you for coming on.

Glad to be here.

So I think I first met you at DjangoCon out in San Diego. You came up, and maybe I was

even talking to Carlton at the time. But I've been following your work. So obviously you're

at Doctor in Demand. We'll ask you about that. You have a personal site. You do Twitch. You have

a podcast. You do articles. So we're going to ask you all about those things. But maybe we could

start with how did you find yourself into programming and then specifically Django?

The Django part of it starts probably around 2014, but I'll rewind before that. So I was one

of those typical suburban kids in the 80s or 90s I grew up in a suburban town in Massachusetts

and was really into video games as a lot of kids or at least boys were at that time

and it drove me it drove me to be one of the ones that wants to go on to college and become a game

developer and so i pursued that path to a degree i went to the university of virginia and i got a

computer engineering degree and somewhere during the course of those years realized that being a

game developer was a really hard gig or at least the reputation was and i said no thanks so by the

time i finished school i i didn't go into game development i actually went to lockheed martin

and worked there and did a lot of communication software actually so nothing to do with the web

at all but i got into satellite development the first thing i did was working on the gps

ground control station and the modernization from moving it off of a mainframe and onto actual

unix operating system is actually it was solaris at the time but so that was my my first exposure

to real life programming was working on this thing that people use all the time which is kind of fun

um and so i just worked on a bunch of uh contracts going through there um and along the way

uh you know didn't do python because you don't you don't put python on satellites typically

yeah i was gonna ask what languages are using i mean see yeah like a wide variety so that when

when it came to the satellite stuff it was usually c++ seemed to be the the language du jour sure

but you know what i found was that there were a lot of actual languages that go into supporting

these contracts so i did a lot of pearl development and java and all these other languages that kind

of build around it that are used for the glue uh to to do the build systems because you know

just like any other gig you you have to build a binary or you have to build an artifact for

your product and there was a lot of that so i got into pearl um of all things and that's actually

where i i really fell in love with programming actually because my experience at college i

actually kind of hated programming to be able to be blunt um i came out of the school you got through

it but and it was a the school was heavy into the the microsoft stack and this is old microsoft

remember this was not this is like the balmer days and it's not the microsoft of today um so it

wasn't a pleasant uh experience and i just didn't do that well at it in in the scheme of things and

was much more into the electrical engineering side of my degree um so well this is pre-internet

right because i think you and i are about the same age i went to william and mary and i didn't

take a single computer science class because i looked at the curriculum and i talked to people

who were doing it and it just sounded yeah as microsoft stack it just sounded super technical

and boring yeah to me um no one was doing a startup no one was showing their work it was just

like i don't even know what you're doing here yeah you'd build you'd build some kind of windows app

and it yeah i learned data structures i i no don't get me wrong i i did like my time at university

and i learned a lot of valuable computer sciency things so you know big o notation and data

structures and all the typical stuff that you might expect from a comp sci degree how to find

stuff in the windows registry yeah yeah a little bit of that too um so i but you know but a couple

years later like when you hire people right they're all like have their own they're all like

yeah i was doing php in high school and then i have my own site i have a startup or at least for

me when i was out at quizlet hiring people so this is 2010 so you know kids in college then they were

all like entrepreneurs right because so it was just a big shift from i think again like their

you know early 2000s computer science curriculum was very it wasn't web yeah for sure and so and

i still didn't get into web for a long time so i i kind of my first exposure to python was uh it was

probably i think 2007 and i found this dive into python book from mark pilgrim oh yeah yeah it's a

great book especially i mean i think you have to know a bit of programming first because it's kind

of throws you headlong in and assumes you have some knowledge about loops and all that kind of

stuff uh but but it was it was a good intro and i really fell in love with language actually i read

the book by uh printing out the web pages and then it was free online putting them in a three ring

binder at work and like that was that was my experience to to learning python so when when

folks actually asked me today like how do you learn python i'm like well first you learn pearl

and then you go print out a book and put it in three right i i don't really have a good answer

anymore because the the way i learned python was uh pretty different from all of the the tools and

and sites that are available to learn it today um so fast forward a few years and and uh getting

getting up to 2014 um my my youngest daughter had just been born that summer i had a two-year-old

son as well and i was driving i live in uh frederick maryland which is an hour northwest

west of DC and our Duke strip due west of Baltimore.

And I was driving to Baltimore every day to a classified lab,

which means no cell phone,

no,

no way to communicate with the outside world while you're there.

So I'd,

I'd basically for my wife,

I'd go dark for like 13 hours a day.

And she was just like,

this is,

this is not working,

dude.

You need to,

you need to find something else.

So I did.

And I got my,

I got a job with a education startup called story bird.

And there were Django shop and, uh, that, that's how I got into Django was, um, you know, I, I, at the end of my time at Lockheed, I'd done a bunch of web development with, uh, uh, Microsoft stack, ironically, and Java and, and for graduate school.

And I, um, but I had dabbled with like turbo turbo gears and pylons and pyramid and, and those sort of, um, frameworks, but I just, I never had gotten into Django for whatever reason.

um in fact i think back in that uh 2007 2008 time window i had seen django but i just wasn't ready

for it totally bounced off it when i hit the page i'm like what is this i don't get it and i was out

um so yeah 2014 i got into django and spent four years at storybird doing all sorts of stuff

learning um getting really into the web stack and learning it deeply and uh by 2018 i was ready to

move on to a new thing and i moved on to doctor on demand which is where i am today and so i have

been doing django there ever since so i guess that's that's my backstory that's great that's

just that's phenomenal that's that's that's about as traditional uh you know uh lineages i as we've

had for a guest to be honest i mean you actually you studied an undergrad and you had broad

exposure i mean carlton and i were both you know educational mutts we didn't study it and and you'd

already had web experience because i always you know for me like python is my first programming

language and django is my first web stack so i came with all this you know baggage that i you

know initially applied to python and django um so to that question of like how do you learn python

right like the first question usually i ask is do you know how to program because most people you

know if you do if you do okay you can take the mark pilgrim or these sort of you know your third

or fourth language books and if you don't you probably want like python crash course like eric

mathis's book but like that's a big distinction and same thing with web stuff right like the whole

approach is different depending on where you're yeah they're very different there's a lot of

different worlds out there and even the python world you look at it today and if you've been in

the python space long enough you know that there's a schism is not the right word but there's there's

a definite divide between if you're doing data science or if you're doing web like there's there's

two camps and it's two two different choose your own adventures for uh how you get into the language

it's such a broadly utilized language and so versatile that you can do so many things with it

that it makes it really difficult to provide this clear guidance. It depends on like,

you really have to ask the question, what do you want to do with this language by the time you're

done? Because it's going to matter on what I suggest to you about how you get into it.

Right. Well, so doctor in demand, maybe that's very timely now that we're all in quarantine.

So this is broadly speaking, telehealth. Could you just talk about, you know, what services it's

done and then how that's changed? Cause I know a lot has changed around regulations and I assume

you've seen a big spike in traffic yeah we have we have this year significant significantly so

doctor on demand as you said it's telemedicine so it means you can get on a video call like we're

doing here with google me and except a physician's on the other side and the physician has your bio

information and all the tools that he or she needs to do everything to help get you a prescription

if you're sick or tell you your arm is broken go to the hospital i can't do this virtually

so it's not for everything but it can serve a lot of the needs for the common ailments that

are out there and and it has that that convenience factor i guess of being a simple video call

and then can you also serve at the same time serve underutilized areas like in rural communities that

are having hard times, um, actually having the doctors out there. So that's, that's largely what

we do is, um, it, it provides that service, but it's also, it's, it's focused on patient care

and, um, getting you your lab work done. There's a behavioral health stuff. So psychologists and

psychiatrists and that kind of thing too, uh, which is also something we've seen a large uptick

with the pandemic. There's a lot of, um, as you might imagine, there's a lot of depression out

there and, and a lot of people really struggling. So, um, yeah, I think, I think we're, we're doing

some good in the world. So I definitely feel good about the product and, and what it stands for and

knowing that it's, it's built on Django. So we're a gigantic Django shop. I was looking at it last

night, just kind of have some rough estimate for the crowd of like, how big is this thing? And so

our Django system is primarily a monolith. We're, we're moving to services and we can talk a bit

more about that but it's a it's a Django app with 80 plus Django apps so Django

project I guess with 80 plus Django apps and somewhere in the range of 300,000 to

400,000 lines of Python code so it's it's no small app right so here's the

big question then templates do you keep them in each app or do you keep them in

a project level templates folder API Carlton API it's more of

the ladder. As Will noted, we have a lot of JavaScript clients that do our member web

application and our provider application. They're both Angular apps. And there are native clients

as well, which are the primary way that our patients actually interact with us is either

through iOS or Android. So we had Jacinda Shelley on in February, who was the technical co-founder

of doctrine demand and she talked kind of about the early days so i'm really curious about uh

yeah the challenges now with you guys are huge what are the i mean because she had mentioned

yeah you know building it from scratch and video and there's a lot of around things around billing

um around if the insurance provider was in a different state which i believe that's something

that was relaxed during um quarantine it's gotten some of the laws are still there so it's you know

The legal stuff is complicated, I guess, but it has gotten a bit easier with the quarantine mode.

I can't speak to, Jacinda's awesome.

And she obviously knows a lot of the history because she, as you said, was the technical co-founder.

So at some point within the last, I guess it was sometime in 2019, she stepped away.

She went on to a new gig and was, as the CTO, left that hole in our company.

And we needed someone to fill those shoes, which is a very hard task because she's a very talented individual.

And so my role is actually, I'm the software architect.

So I kind of stepped in halfway to, you know, if I do half the job that she did, I'm doing a good job, I think.

And so this broad have to, I have to get this broad view of how Dr. On Demand works. And it has changed quite a bit since, um, since she's left. We're, we're doing lots of, lots of things to modernize the stack. Like, you know, when you start the company, when you start any startup, I guess you got to get default alive. You have to make sure that your business gets off the ground. And sometimes that means making choices that, you know, in a perfect world you wouldn't make.

um yeah so the reality is that some of those choices were made uh in doctor on demand's

history and we are working to steer the ship away from a glacier i suppose um and make sure that we

have a good solid forward trajectory so we're doing a lot of modernization to switching from

kind of legacy EC2 deployed instances to a more Docker and container flow and getting towards

containerization and orchestration and all the bits that come along with that.

And it's not because, you know, I'm actually a big fan of not doing that in my personal projects.

So there's definitely a spectrum of what it means to when you should apply these techniques versus

others and i think it's important for a company of the size we're becoming because of the pandemic

because of just the need for the growth of telemedicine general uh we're growing rapidly

and in order to make the product work for the team uh we have to move to these different

technologies that kind of make it more manageable to move artifacts in our build pipelines and

and get our deliver the actual software so it's a big transition that we're going but you're running

like lots of instances right because you're a big service you've got lots of client calls you've got

lots of you know individual clients making api requests all the time so you need you know it's

not just that you can run one container you're running many containers and at that point

orchestration you know container orchestration platform becomes that sounds like a good idea

yeah because you know part of it is like we we need to be available for doctors like you

we have active running calls basically all the time and so to the best of our ability we have

to be a zero downtime service and going from you know really high uptime service to as close to

zero as you can possibly get that's a really hard engineering challenge in order to make sure you do

your database migrations properly so that you never lock the database tables and there's a lot

of stuff that that if you can if you can skip that stuff if you can be like 99.3 nines or four

nines whatever you know is the term that we like to use in industry right if you can be at that

level of uptime your life just gets a lot easier i think yeah well speaking of scale last or the

episode that came out last week was carl meyer at instagram which is you know the ultimate like

however many nines you want um but yeah it is interesting how yeah you add the nines and it

just sort of becomes exponential with the difficulty but i want to ask so this software

architect role so did you so are you managed so you're managing engineer like how does that differ

from cto and had you done that at storybird right that's that's a big shift from being a

you know individual contributor if that's what you were before which yeah it is a really big shift

and i i didn't know what the role would necessarily mean and it had to mean something

different and the company wanted something different from jacinda's role as as the

technical co-founder that she was she also was pretty forward with the the customers so

she had a lot more direct interaction um just because of the nature of she was the first

engineer and she had had to talk to them more directly but in the intervening time we've grown

large sales organizations we've grown different kinds of capabilities so the the the role that

was asked of me was uh was really purely a technical one um where i didn't have to to

stand in two worlds um so i've been i did move from kind of a an individual contributor or lead

weedish type of role uh to to being in this architect and and i don't have any you know

i'm not a manager my job is i've basically been asked to step back from the whole system and and

stare at it from the 30 000 foot view and say hey what what can we do to make this whole thing go

better which is it's really cool in some ways but really intimidating to me the other so i said i

didn't actually know what i was going to do when i started my my initial process was to essentially

interview the entire engineering team and say hey what do you think is is important to you as an

architect because everybody's going to have this different vision of what an architect is actually

going to be helpful for or what they think an architect even is and that's that was how I

started just trying to shape like what does it mean for me and here's this idea in my head of

about how I can best help the team and so ultimately I settled on you know my job is to help

unblock engineers as much as possible to try and help set standards for the teams to make sure that

we have the right tools in place to do all the things that are essentially boosters and for and

multipliers for the actual team itself the the end you know the boots on the ground uh engineers who

are writing tons of code i do still write code just to be clear um just less of it these days

um but the the ones that are fully devoted to those feature lanes that are doing tons of work

um they get all the the junk out of the way um that's that's my objective i think that's a wise

approach yeah i try and be a try and be a force multiplier that's that's the real goal how many

engineers can you say do you do you all have now oh the rough number roughly is 100 plus and growing

rapidly i think and then what's what's the split of django versus front end or you know servers

how does that divide up we do have a large because django is so big there's so much of that code it

is the majority of our engineers i think fall into that that camp um but we have solid front-end

teams and as i mentioned we have native clients too so it's a lot of specialized knowledge because

when you get to a system this size you can't ask the the android developer well i mean there is

there there is the rare breed mobile developer who can just jump around between all the different

mobile languages but you know what we found is that you get specialists that specialize in android

and specialize in ios and specialize in the javascript stacks and so we have a lot of

littler teams for our different clients and then a large pool of python developers to actually work

on all the business logic because business logic has as you mentioned insurance and dealing with

the actual communication of medical data and the clinical operations aspects of it that deal with

all of your interactions between the physicians and the patients. And so there's kind of different

camps in our business logic as well that have wildly different functions and what they do

within our gigantic monolith. Carlton, do you have some questions? I've got a whole list,

but i feel like i've been monopolizing no i'm just listening and i mean it's massively

interesting and a team of 100 engineers that's a big team and you know the coordination problems

on a team that size and so you talked about um starting to think about breaking off into services

and one reason why companies do that is because the coordination problem in the monolith becomes

too big right so it's much easier to hey let's break off a bit and then we can give that to

that team and they can work independently and i mean and not take down the whole stack yeah well

i mean i've heard that argument that serverless is just you know to protect the the technical

thing from junior developers and not let them take it all down now we're you know 100 is a pretty

that's to some level it's a target i i don't know the exact number i wish i did um although i don't

know that i'd be allowed to share it technically but um so our staff is really like we have a lot

of qa engineers as well there's there's a wide variety of of staff beyond just python so there

there is the complexity of of managing a lot of people that's true but i think that we have enough

kind of specialized roles that are still there's still enough autonomy in there i guess is what

i'm getting at uh that it's not like a management nightmare we don't have tears and tears like i i

came and i say all this because i came from this gigantic defense contractor where when i was the

the top guy the c ceo of the whole company was if you had counted the numbers was like level 12 so

if you imagine a pure like it was literally a command and control structure that was a gigantic

pyramid of managers and i was at the bottom and this guy was at the top and there were 12 layers

in between. We're now nowhere near that level of complexity, Dr. Nerman. So it is a, it's a bit

more amorphous and, um, we've got a lot more flexibility, which is, is, uh, there's, I guess

the point is that there's a lot of opportunity for us to, to be rapidly evolving to the way

things are going with our technology. So you mentioned QA, can you talk about

testing and how you, again, you're, you're in the medical space. It's very important for it to work.

how do you maybe start i assume you're using pi tests but how do you think about testing and what

are kind of your goals as an organization to be well tested because obviously you probably don't

have 100 test coverage we don't but we are we we strive we're never striving for outright 100

it's um not a realistic goal in a lot of cases but we have shifted the culture

wasn't always this way shift of the culture so that new code today it comes with tests if you're

changing code there's an expectation that you're going to write test code along with it and we did

that for a lot of reasons we were started on python 2 or moved to python 3 was important and

and we wanted to make sure that the system worked as we switched the runtime from a major breaking

change with the language and and how do you discover that in the language that you can't

compile well you just got to run the code and so we did a lot of work to to really increase our

test coverage and i think we're probably the back-end code is probably in the range of 90

ish percent coverage which is um pretty well covered that's that's fantastic yeah it's um

it's a lot of it uses pytest and and pytest django um as our test runner um which is a is a pretty

great system. There's a lot of advantages to using PyTest that come along with that, of using

fixtures, although I have mixed feelings on fixtures that we don't need to get into,

and using other aspects of that. But that's kind of the ground floor of our testing

and strategy is to have good unit test coverage to get the confidence that we need. But we have

pretty rigorous release process as because as you said this is a medical company and if we make

mistakes we could really mess with people's health so that that weighs a lot on people and we want to

make sure that what we deliver is is safe and so our our release process takes a little longer

but we we do try and have basically a release train that is is cutting a release every week

And we have a dedicated QA team that is really focused on making sure that the fit and finish is there for the product.

And it goes every week.

I do have objectives and goals to move us towards continuous delivery in a safe manner with making heavy use of feature flags and that kind of technology.

But that's adjusting from a culture that is very cautious, and you want to keep that caution to keep that safety, but at the same time move quickly and deliver the value of the new features is something, it's a balance that we have to walk, try and walk that line.

It's difficult with native apps as well, because you have to get them through app store approvals and all kinds of things, which is not an instant process, right?

that's true yeah the the client apps do have their whole their chain of stuff and and yeah i was i

was primarily referring to just the the back-end delivery on that weekly train but you're right

carlton the the client apps they they're on their own cadence just because we are subject to the

whims of uh apple and google when it comes to the delivery of apps what's the one thing that sort of

comes to mind is that um you know you're constantly looking at is this change compatible with the

client that's available now or you know and what what scale of time we're going to roll this out

so you talked about database migrations well that's one thing you've got to keep you know your

your python app your django app compatible with your database as you migrate your database forward

but also you've got to keep your python app compatible with the clients that are consuming

it as they're able to deploy it yes yeah that's a nice problem when to deprecate things or when to

because there are we have some big hammers that we could bring out and say you know what we really

need to stop working on this api so we're gonna force upgrades on if you're on this version of

android we're gonna just flat out say sorry you need to upgrade so but we want to do that rarely

because you lose patience when you when you do that kind of thing and that means that keeping

around apis is is uh tricky that that stuff lives around much longer than you necessarily like it to

because you find better ways of designing better APIs

that fit the pattern of the business better.

And, well, you know,

you've got to support the people that are there.

That's tough.

And can I ask about,

do you use like REST Framework or REST Startup Approach?

Do you use GraphQL at all, that kind of thing?

We've decided to use REST Framework.

So we didn't actually start with REST Framework.

We started with Django JSON RPC.

jsonrpc is a a protocol that exists you can go read the spec it's actually not very long

and it's fine i'll say that about it cindy mentioned this as one of her mistakes

in hindsight yeah it it was a good a decent choice at the time and just maybe a little bit of

a gamble and and you know had the industry adopted it more broadly um it would have worked out okay

but the reality is it kind of just is a bag of of data that goes into a dictionary like object and

and when you make jsonrpc endpoints you're sort of throwing out whatever you want in there it

serializes a dictionary and go um which okay is is convenient but it does lack some of the

the structure that comes along with rest framework so um we are moving slowly in some some ways so

to rest framework we we have a lot so i say that we actually do have a lot of rest api endpoints

we've drawn a hard line in the sand and says no more json rpc everything must be rest going going

forward um and we're doing that because we have a lot of partners who would love to have apis that

they can consume that gives them information um you know and the partners that i'm talking about

are like health care companies that that embed doctor on demand in their applications and

services um and they want to be able to to not just put a fancy uh frame around our actual app

embedded in their stuff they really want to call our rest endpoints and and integrate deeply with

our product so we're pretty rapidly moving towards heavy rest adoption because you know the last

thing we want to do is say well hey here's our json rpc endpoint go use that um because that's

that's just not going to fly for them for feature flags do you use something like django waffle or

did you write your own in-house solution we do use django waffle currently um it's been it's been a

good tool it's not a perfect tool it's and i think we're going to run into some of its limitations

perhaps because even though we have a monolith today we're moving to a more distributed

architecture so we have services that are starting to grow out and do their own thing and things are

starting to talk to each other over http which means more databases for these different services

and and since uh waffle is database backed what does it mean when you have more than one database

like where do you go yeah to do your future flags it's like well there's a flag over here and there's

a flag over here and you know the management of that is is harder but but today it's serving us

pretty well as a way to do flags yeah that's a long way fine so maybe let's talk about your

personal educational efforts yeah i'm always amazed i see you pumping out stuff i just know

you from all your you know django content stuff yeah i know you're putting out more stuff than me

and you have a day job so i'm like oh my god so let's we're just so maybe let's start with um

django riffs so this is a podcast you've done a number of episodes and this i think so far this

is just you talking about different areas of django is that right that's right so the idea

behind it was i i love the the format that you have for this show already and so i didn't want

to replicate that and have all of the same guests on and just do rehashes of the same content um

because this this podcast already exists um but i thought like well well what do i like to do

and one thing i like to do and we haven't really talked about this is i organize python frederick

in my local community and so i get i encounter a lot of people well pre pre-pandemic i did i'll

caveat with that um but when we were able to meet in person i would encounter a lot of people who

want to get into python and ask kind of beginner questions and and all that sort of stuff and

and i really enjoy teaching those folks i enjoy just seeing that light bulb go off on folks i'm

like oh i get it um so i wanted to bring some of that to django if i could because i i've in the

last year especially i'm just kind of niched down to django and said like this is the community that

i care about and what can i do to add add value to that community and so i thought well if i like

teaching and there's already a podcast maybe i can teach through a podcast for those that might be

more oral uh learners because not everybody likes to read uh not everybody likes to learn through

video um so if there's what if there's a different format for consuming this and and learning a

little bit about django and hearing the terms and and can this all all this information come together

in somebody's head so that was the path that i i walked down i this year i started this podcast and

and uh turns out it's a lot of work to make a podcast as you guys know

so i'm making about an episode a month that is essentially digesting as much of the django

documentation that i can putting my take on it because i i wanted to be a little personalized

and and just have an opinion because sometimes there are multiple ways to do things in django

and to get an opinionated take to to plow the uh pave the cow path and and give people a real

clear idea of this is a this is a flow you can do this is how you get into it um so the podcast

approach is to be and take that high level view of things i start the first episodes talking about

the browser and like you know basics of how do browsers and servers talk to talk to each other

and i go layer by layer and start getting deeper and deeper into the stack of django and and you

know getting into i'm not going to shy away from any topic i do believe that once people learn

things i i really um trust people's ability to understand concepts even if they're more difficult

and so i'm not going to shy away from the maybe scarier corners um of the framework

and can i just stop you what are what are the scary corners do you think

well maybe i maybe i will shy away from some scary corners i don't know but

no i'm curious i mean there's two answers right there's as a you know at scale as an expert and

then there's for beginners i'm just curious if what jumps out at you because i'm always thinking

about this too about how do i explain django to people there's a depth of knowledge that

like the the orm for example is this well that you can go down yeah it just gets deeper and deeper

and you get to aggregates and you get to like sub queries and you get to the nitty-gritty of the orm

and that that is a potentially scary place for people because it it also the orm is very powerful

but at some level there's a level of sequel knowledge i think that comes along to to take

advantage of the really advanced features of it um and ultimately i want to get to those areas too

but but there's there's so many layers to get through before you even get to that point so

that's that's probably one of the areas that you know here be dragons but it's okay we're going to

get to bring our sword with us and go slay them i think that's a really good point is that you know

to really leverage the orm you've got to know how it maps down to sequel and you've you've got to

understand how the group by clause is working and you know why these particular columns need

to be referenced and you know yeah it saves you from writing these SQL by hand but I you you got

at some point you've got to learn that you've got to know it yeah all abstractions are leaky

to a degree even even really well-written ones and i do think the django orm is a well-written

abstraction like it's a it's a great tool the times that i have to get to raw sequel are basically

zero um so you know as you pointed out carlton it's it's you do need to know some of the details

of sequel but uh most of the time i can be blissfully ignorant of that stuff well and i

believe james bennett is a colleague of yours right yeah that's right james james because he

has a he has a you know in addition to working on it he has a three-hour talk that he's given

at uh jango con and pycon which maybe i'll link to which is is quite the deep dive on the orm

yeah it's a it's a great talk he delivered it at doctor and a man for our own staff and

he did a he does a good job he knows his stuff but when it comes to the orm well fantastic yeah

And I'm really glad you're doing the podcast.

I really like your, your format.

I know how much work it is, especially just to speak, you know, it's like a university

lecture, imagining the audience response.

And, um, it's a lot easier to have a co-host.

So, um, I want to ask too about Twitch.

So you stream almost every week, right?

Like I, I see you tweeting out and I've, I've watched a couple of your streams.

It's like nine o'clock on Thursdays.

Is that right?

or you i don't know where you get the energy because you have you got a job you've got kids

and i'm just like yeah do you not have enough and you don't have enough children or something

and you're streaming hey so i'm curious like how is that what's twitch like because i'm pretty

ignorant about it other than knowing that i get it for video games but i haven't consumed much

around you know programming other than i know i would love to see how other programmers do their

job yeah and and that was that was what it was for me too the i think i got into it so i listened

to a podcast called the change log uh which is an excellent open source podcast if people haven't

heard of it they should go check it out and one of the episodes they had on there was with uh an

individual um her name is suze hinton hinton i think uh but she goes by the handle of no op cat

um and is a twitch streamer and she was just describing her experience of of streaming code

code development specifically on twitch and she got into it i don't know she has a certain

quirky charisma to her i guess but she just made it very sound like a fun thing to do that hey i

can build up a community or this is her kind of her words i can build up a community i can

work on things that are fun for me like she's a hobbyist who does hardware programming and

programs little microcontrollers and those sort of things and and just enjoys programming for fun

and that's kind of where i'm coming from like you know the people have all sorts of hobbies

and you know some folks say find other hobbies that are outside of programming and that's fine

i think that advice is okay um but if your hobby also happens to be coding i shouldn't think that

should be fine too and and that's where i land personally so um my my goal with it was to

experiment with the format and and see is this something that i would enjoy doing and it kind

of gets back to this theme of i like to teach um so i thought well what better way to teach than

have an audience that can communicate back with me because as you said with the django riffs thing

like i'm speaking into the ether and talking for 45 minutes straight about a particular topic and

i don't there's no feedback loop um so having twitch and having an audience and they can

communicate and say like why did you do that or what do you think about this i think is really

cool so my first twitch stream was was absolutely horrid it was like purely an experiment i i knew

nothing about recording um i didn't even bother to have uh you know an external mic so i had my

my mic from my macbook like as the picking up my audio but you know turns out streaming also

takes a lot of your demand on your card so like half the stream is just from the my fans revved

up super loud yeah yeah um it's pretty terrible but um over time i learned how to do some of it

And yeah, I stream every Wednesday night

at 9 p.m. Eastern time in the U.S.

and work on Django projects,

work on side projects that I have going just to...

I did it for two reasons.

I guess one was to teach

and the other reason was to actually make progress

on my side projects.

So I have too many side projects

and everybody maybe struggles with this to some degree

and I wanted to get something done.

And it was a time where I could lock myself in

and say like matt for the next hour and a half you're going to stream because you're going to

make work get work done on this project and so that's that's largely why i did it and how i got

into it and i'm still doing it today and i believe you you rebuilt your startup that you closed down

right the college finder one or initially that's how you you had a that was like how you started

yeah because i saw i saw some of those because i was i was fascinated by that because i that's

incredibly educational to see to go through it again from scratch and talk about what you would

change and just that process from prototype to you know something you can deploy i i was

i'm perhaps guilty of following my wife's pursuits with my side project so you did mention that my

wife is a was a college guidance counselor and and so the product that i was building was wasn't

primarily for her so i figured i have have a customer in my house that i can talk to

so let me build something that she's going to find useful and uh around that time period around

six months into um developing this this app and doing it live on twitch because i'd done it for

years prior to that uh she decided or we we decided actually that we're going to homeschool

our children and so she's like and just the level of work for um homeschooling our children meant

that she didn't really have the time to do the college guidance stuff as well so she set that

aside and it's like well i'm not going to pursue this if if she's not even doing it anymore and

but to that end i i created a homeschool app to help with scheduling for our kids and making sure

that her schedule is manageable and and got to start that from scratch so you can go back to

i don't know episode 38 or something i have show notes for every episode that i produce on twitch

and i start a project from scratch and you can see me fumbling through things and getting it

up on heroku and integrating django environ and all these tools that are needed to get an app going

from the ground floor um so that's that's the process there i've been guilty of building

something close to my heart and it's it's always a little dangerous when you have one or two good

customers because you get blinders on um but i think you know the homeschooling space is a

it's a fascinating space the whole time i was at quizlet we were looking at that because that's

always been the early adopters for any sort of educational technology because you kind of cut

out the admin you go straight to teachers as customers teachers of the parents so you know

even more so now i think that's a great way to look for innovation and to just be able to do

stuff direct without the b2b cruft of ed tech because as you know people think it's b2c and

it is really really b2b yep it is although i would recommend people do if you're starting a

new project do market research maybe beforehand i did look i did some market research recently

and realized there's actually like 15 competitors out there so it's a crowded space i mean that's

good you don't want to be that like i mean that's true but also you don't want to be the only one

who's doing something because that's probably telling you you're missing something right right

so it's i enjoy the project and and i i want the real goal for me is i want to make something

that's useful for my spouse to make her life easier and if the side effect is it also happens

to make other homeschooling families lives easier that's that's a bonus so we're coming up a little

bit on time but i want to give you a chance matt to talk about i know dr and demand is hiring and

you also have on your website a whole fantastic series on django so what would you like to leave

with our audience. Yes. Doctor in a Man has a lot of stuff going on. Pandemic is unfortunately good

for medical companies, I guess you can look at it that way. So we're growing rapidly and need

more people. So if you're interested in working at a company that is doing a lot of good for

patients out there and serving communities, that's definitely a good place to go. So there's

there's a careers page or you could reach out to me directly and I'd be happy to connect folks there

to to get them into our engineering organization as for my Django stuff I have a series on my

website so I my website is mattlayman.com and the series is called understand Django which you can

find right in the the banner at the top and I'm doing essentially understand Django is essentially

the feeder material for the Django Rift podcast so I do all this research on the Django documentation

and distill all this stuff and I write it write down all these notes and kind of put together

these topics and put it out there and then speak to them later on the podcast but uh if you don't

have time for the audio version and you just want the quick hey what's an opinion you need to take

on learning Django docs or learning Django like more generally then I think understand Django is

good good way to go about it um and i read about other stuff periodically too that that come up as

as uh as the as the need arises uh from things that i discover like hugo inside of django i

shared that with carlton before this because we've had separate discussions about you know

not needing to do that but you know i've used hugo hugo's great and you had a whole you have

a whole post on putting it inside of django yeah it was a fun little experiment just to see if i

could do it and not use a subdomain and and do a different approach to it and it worked out it

worked out didn't work perfectly that i and i i document the some of the trade-offs of things that

i learned in the process but it was a fun way to go to try and see if i could get a static blog

served by by django and white noise without you know without putting a reverse proxy in front of

it and all the baggage that comes with that right well fantastic well matt i i love your content and

And I just, you have so much enthusiasm for coding.

It really rubs off when I read your articles,

when I hear your podcasts, it's very impressive.

It makes me think, come on, Will, like get it together.

Like he's got a family too.

Like, I love your enthusiasm

and you're just pumping so much great content out.

So I hope people get a chance to see more of it

if they haven't already.

Well, thank you very much.

I appreciate that.

Carlton, any closing thoughts?

No, exactly.

In awe of your, of how prolific you managed to be.

The secret is Pomodoros.

Right, okay.

Get out a Pomodoro, commit yourself to 25 minutes.

You can do it.

Yeah.

Do it daily.

Just chip away at it.

That's all I do.

And what about going to bed early, this kind of thing?

No, I'm actually a night owl.

Right, okay.

Yeah.

So stay up late with your Pomodoro.

That's right.

Okay, super.

Well, we'll have links to everything in the show notes.

We are at DjangoChat.com, ChatDjango on Twitter, and we'll see everyone next time.

Thanks again, Matt.

Thank you.

Thank you.

All right.

Bye-bye.