Transcript: Telemedicine - Matt Layman

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Hi, Matt.

Hi.

Thank you for coming on.

Glad to be here.

You came up, and maybe I was even talking to Carlton at the time.

Um, but I've been following your work.

So you're 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 gonna ask you all about those things.

But maybe we could start with how did you find yourself into programming and then specifically Django?

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

So I I was one of those typical suburban kids in the 80s or 90s.

I grew up in uh suburban town in Massachusetts and was really into video games as a lot of kids or at least at least boys were at that time.

Um and it 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 I pursued that path to a a degree.

I went to the University of Virginia and got a computer engineering degree, and somewhere during the course of those years realized that being a game developer was a really hard gig, um, or at least the reputation was, and I said, uh no thanks.

Um so by the time I finished school, I I didn't go into game development.

I actually went to uh Lockheed Martin and worked uh there and did a lot of um communication software actually.

So nothing to do with the web at all.

Um but I I got into uh satellite development.

The first thing I did was working on the GPS um ground control station and the the modernization from moving it off of a mainframe and onto actual Lin uh Unix operating system is actually it was Solaris at the time, but um 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 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.

I mean C?

So the when when it came to the satellite stuff, it was usually C seemed to be the language de jour.

Sure.

Um but you know what what I found was that there were a lot of actual languages that go into supporting these contracts.

So I did a lot of Perl development and Java and all these other languages that kind of build around it that are used for the glue, uh to do the build systems.

Because you know, just like any other gig, you you have to build um a binary or you have to build an artifact for your for your product.

And uh there was a lot of that.

So I got into Perl um of all things, and that's actually where I 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, and it the 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 uh in in the scheme of things and was much more into the electrical engineering side of my uh degree.

Um so

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

It was just like, I don't even know what you're doing here.

Yeah, you'd

I learned data structures.

I I now don't get me wrong.

I I I did like my time at university and I learned a lot of valuable computer sciencey things.

So, you know, big O notation and data structures and all the typical stuff that you might expect from a comp sci degree.

Um so I I but

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, 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 the you know, early 2000s computer science curriculum was very uh it wasn't web

And so I and I still didn't get into to 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 I found this dive into Python book from Mark Pilgrim.

Oh yeah.

And 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 and I really fell in love with language.

I actually I I read the book by uh printing out the web pages and then putting them in a three-ring binder at work.

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 a three-ring.

I I I don't really have a good answer anymore because the the way I learned Python was uh pretty different from uh 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 of DC, an hour du stri due west of Baltimore, and I was driving to Baltimore every day.

Uh to a classified lab, uh which means no cell phone, no no way to communicate with the outside world while you were there.

So I'd I'd basically for my wife I'd go dark for like thirteen hours a day.

And she was just like, This is this is not working, dude.

You need to you need to buy something else.

Um so I did.

Um and I I I got my I got a job uh with a s education startup uh called Storybird and there were Django shop.

And uh that that's how I got into to Django was um you know, I'd I'd 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 d um but I had dabbled with like turbo turbo gears and pylons and pyramid and and those sort of um frameworks, but I I just I never had gotten into Django for whatever reason.

Um in fact I 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 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 I got into Django and spent four years at Storybird doing all sorts of stuff, learning um getting really into the web stack and 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, uh which is where I am today, and so 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.

I mean, you actually you st you studied in undergrad and you had broad exposure.

I mean, Carlton and I were both, you know, educational mutts.

We didn't study it.

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

And even the Python world, you look at it today, and if if you've been in the Python space long enough, you know that there's uh schism's not the right word, but there's a 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.

Uh it's such a broadly utilized language and so versatile that uh you can do so many things with it that it makes it really difficult to provide this clear guidance.

Uh 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 uh on what I suggest to you about how you get into it.

Well, so doctor on 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?

Because I know a lot has changed around regulations, and I assume you've seen a big spike in traffic

this year.

So, Dr.

Anamand, as you said, it's it's telemedicine, so it means you can get on a video call like we're doing here with uh Google Meet, 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 um 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.

Um so it's not for everything, but it can uh serve a lot of the needs for uh the common ailments that are out there and and uh it has that that convenience factor, I guess, of being a simple video call.

Um, and then can you also sort 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.

It's um it it provides that service, but it's also it's it's focused on patient care and uh getting you your lab work done.

There's uh uh 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 I definitely feel good about the product and and what it stands for.

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

Um, but it's uh it's a Django app with 80 plus Django apps, so a Django project, I guess, with 80 plus Django apps, and uh somewhere in the range of 300,000 to 400,000 lines of Python code.

So it's it's no small app.

Right.

Do you keep them in each app or do you keep them in a project level templates folder?

We're we're uh we have a lot of um uh JavaScript clients that uh do our member web application and our our provider application.

They're both Angular apps, and uh there are native native clients as well, which are you know the primary way that our our patients actually interact with us is either through iOS or Android.

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.

So it's you know the the legal stuff is complicated, I guess, but uh there they're it has gotten a bit easier with the with the quarantine mode.

Um yeah, it's I I can't speak to Jacinda's awesome, and and she obviously knows a lot of the history because she, as you said, was the technical co-founder.

Um so at some point uh within the last, I guess it was sometime in 2019, she she stepped away, she went on to a new gig and uh was as the CTO left that that hole in our our um our company.

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

Um and so my my role actually is actually uh I'm 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 I'm doing a good job, I think.

Um and so this broad have to I have to get this broad view of how Doctor 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 you gotta 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 the reality is that some of those choices were made uh in Doctor on Demand's history, and and we are working to steer the ship away from a glacier, I suppose, um, and and make sure that we have a a good solid forward trajectory.

So we're doing a lot of modernization to switching from kind of legacy uh EC2 deployed instances uh to a more uh Docker and container flow and and getting towards uh containerization and orchestration and all the bits that come along with that.

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

So uh 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 of becoming because of the pandemic, because of just the need for the growth of telemedicine general, uh, we're 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 in our build pipelines and and get our deliver of the actual software.

Um so it's a big transition that we're

But you're running like lots of instances, right?

Because you've you're you're 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 big you know, container orchestration platform becomes well, that sounds like a good idea.

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, uh, that's a really hard engineering challenge in order to make sure you do your database migrations properly so that you never lock the the database tables.

And uh there's a lot of stuff that that if you can if you can skip that stuff, if you can be like 99.

you know, three 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.

Well, speaking of scale, last or the episode that came out last week was Karl 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 wanted 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

And I I didn't know what the role would necessarily mean.

And and it had to mean something different, and 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 I did move from kind of a an individual contributor or lead lead-ish type of role uh to to being at this architect.

And and I did I don't have any, you know, I'm not a a manager.

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

Um, which is is really cool in some ways, but really intimidating to me in the other.

So I I said I didn't actually know what I was gonna do when I started.

Uh my my initial process was to essentially interview the entire engineering team and say, hey, what do you think uh is is important to you as an architect?

Because everybody's gonna have this different vision of what an architect is actually gonna be helpful for, or what they think an architect even is.

And uh that's that was how I started, just trying to shape like what does it mean for me?

And oh, 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.

So the and you know, the boots on the ground, uh engineers who are w writing tons of code.

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

That's that's the real goal.

How does that divide?

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 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 we 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 the business logic because business logic has, as you mentioned, um insurance and dealing with the actual communication of of uh uh medical data and um you know the clinical operations aspects of it that deal with um all of your interactions between the physicians and the patients.

And um so there's kind of different camps in the in our business logic as well that have wildly different functions and what they do within our our gigantic monolith.

I've got a whole list, but I feel like I've been monopolizing.

I mean a team of a hundred engineers has a big team, and yeah, 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

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.

I 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 our staff is really like we have a lot of QA engineers as well.

Um there's there's a wide variety of uh of staff beyond just Python.

So there there is the complexity of of managing a lot of people, that's true.

Um but I think that we have enough kind of specialized roles that we're still there's still enough autonomy in there, I guess, is is what I'm getting at.

Uh that it's not like a management nightmare.

We don't have tiers and tiers.

Like I I I came and I say all this because I came from this gigantic defense contractor where when I was the one who's called one engineer there, 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 we're now nowhere near that level of complexity, uh, Dr.

Underman.

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.

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 I don't know, maybe start.

I'm I assume you're using PyTests, but how do you think about testing and what are your kind of your goals as an organization to be well tested?

Because obviously you probably don't have 100% test coverage.

It's um not a realistic goal in a lot of cases.

But we have shifted the culture it wasn't always this way, shifted the culture so that new code today is comes with tests.

If you're changing code, there's an expectation that you're gonna write test code along with it.

And we did that uh for a lot of reasons.

We we were we started on Python 2 or uh you know moved to Python 3 was important and and we wanted to make sure that uh 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 a language that you can't compile?

Well, you just gotta 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.

There's a lot of advantages to using PyTest um that come along with that, of using um fixtures, although I've I have mixed feelings on fixtures that maybe we we don't need to get into.

Um and u using other aspects of that.

But those those are that's kind of the ground floor of our our testing and uh strategy is to have good unit test coverage to get the confidence that we need.

Uh but we have a pretty rigorous release process uh as because as you said, this is a medical company and if we make mistakes we could really mess with people's health.

Um 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, uh, 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 it goes every week.

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

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

Yeah, the the client apps do have their whole other chain of stuff, and and yeah, I was I was primarily referring to just the the back end delivery uh on that weekly train.

But you're you're right, Carlton.

The the client apps they they're they're on their own cadence just because we are subject to the whims of uh Apple and Google when it comes to delivery of apps.

Or you know, and what what scale of time we're gonna roll it out to 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.

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 long much longer than you'd necessarily like it to, because there are you find better ways of designing better APIs that that fit the pattern of of the business better.

And well, you know, you gotta support the people that are there.

That's tough.

Do you use GraphQL GraphQL at all?

That that kind of

So we didn't actually start with REST Framework.

We started with uh Django JSON RPC.

Uh JSON RPC is a uh a protocol that exists.

You can go read the spec.

It's actually not very long.

Uh and it it's fine.

I'll say that

about it.

And and you know, had the industry adopted it more broadly, um it 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 JSON RPC endpoints, you're just 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 uh to uh rest framework.

We we have a lot so I I say that we actually do have a lot of REST API endpoints.

We've drawn a hard line in the sand that 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 and the partners that I'm talking about are like healthcare 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 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 go use that.

Um because that's that's just not gonna fly from them.

Um it's been it's been a good tool.

It's not a perfect tool.

It's it's and I think we're gonna run into some of its limitations perhaps uh because e 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 you know, 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 to do your future flags?

It's like, oh, 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 as a way to do flags.

Because I'm always amazed.

I'll be honest, I didn't even know you wouldn't.

So I'm like, oh my god.

So let's we're gonna start.

So maybe let's start with um Django Rifts.

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?

So the the idea behind it was uh I I love the the format that you have for the show already.

And so I I didn't want to replicate that and have all of the same guests on and just do rehashes of 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 and one thing I like to do, and we haven't really talked about this, is I I organize Python Frederick um in my local community.

And so I get a I encounter a lot of people, well, pre pre-pandemic I did, I'll 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 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 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 I s 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.

Uh but so I 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 uh to get an opinion I take, to to plow the uh pave the cow path and and give people a real uh clear idea of this is a if this

is a flow you can do, this is how you get into it.

I start the first episode talking about the browser and like you know basics of how do browsers and servers talk to talk to each other.

And I I go layer by layer and start getting deeper and deeper into the stack of of Django and and you know getting into I'm not gonna shy away from any topic.

I 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 gonna shy away from the maybe scarier corners um uh of the framework.

And uh

What are the what are the scary corners, do you think?

Hmm.

I don't know, but uh

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 there what jumps out at you because I'm always thinking about this too about how do I explain Django to people.

Yeah, it just gets deeper and deeper.

And then you get to aggregates and you get to you got like subqueries and you get to the nitty-gritty of the ORM, and that that is a potentially scary place for people because it it it also the ORM is very powerful, but at some level there's a a level of SQL knowledge, I think, that comes along to take advantage of the really advanced features of it.

Um and ultimately I want to get to those areas too.

Um 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'll we're gonna get it bring our sword with us and go slay them.

And you're yeah, it saves you from writing the SQL by hand, but I you you got at some point you've got to learn that.

You've got to know it.

Yeah.

And I do think the Django RM is a well-written abstraction.

Like it's a it's a great tool.

The times that I have to get to raw SQL are basically zero.

Um, so you know, as you pointed out, Carlton, it's it's we you do need to know some of the details of of SQL, but uh most of the time I can be blissfully ignorant of that stuff.

James, James also.

He delivered it at Doctor and Amand for our own staff, and he did a he does a good job.

He knows his stuff but when it comes to the ORM.

Yeah, and I 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 it's I don't know where you get the energy because you have you've got a job, you've got kids, and I'm just like dead like that.

And you don't have enough children or something, like streaming.

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

The I think I got into it so I I listened to a podcast called The Changelog, uh, which is an excellent open source podcast.

I 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, uh code development specifically on Twitch.

And she got into it, I don't know, sh she has a certain uh quirky charisma to her, I guess.

Um, but she just made it very sound like a a fun thing to do.

That hey, uh 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.

She like she's a hobbyist who does hardware um 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 it I 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 I think that vi advice is okay.

And and that's where I land personally.

So um but 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 an audience that commu 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 that can communicate and say, like, why'd 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, it turns out streaming also takes a lot of your demand on your card.

So like half the stream is just from the the my fans revved up super loud.

Yeah, yeah.

But um over time I I learned how to do some of it, and and yeah, I I stream um every Wednesday night uh at 9 p.m.

Eastern time in the US and and work on Django projects, work on side projects that I have going just to it I 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 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 gonna make work uh get work done on 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 uh today.

The college finder one, or initially that's how you you had a that was like how you started?

Yeah, so 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 figured I have have a customer in my house that I can talk to.

So let me build something that she's gonna 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 or we we decided actually that we're going to homeschool our children.

And so she's like and just the the level of work for um homeschooling our children meant that she didn't really have the time to do the the college guidance stuff as well.

So she set that aside and it's like, well, I'm not gonna pursue this if if she's not even doing it anymore.

And um, but to that end, I I created a homeschool app to help with uh scheduling for our kids and making sure that her schedule is manageable and and got to start that from scratch.

So you know you can go back to I don't know, it's episode 38 or something.

I I have show notes for you 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 Environment and all these tools that are are needed to get an app going from the ground floor.

Um so that's that's

the process there.

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 to 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 um ed tech.

Because as you know, people think it's B2C and it is really, really B2B.

Although I I would recommend people do if you're starting a new project, do market research maybe beforehand.

I I did look, I did some market research recently and realized there's actually like 15 competitors out there.

So it's good basically.

You don't want to be the 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.

So it's I 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 uh 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.

I know Doctor and Demand is hiring, and you also have on your website a whole uh fantastic series on Django.

So what would you like to leave with our audience?

Pandemic is unfortunately good for medical companies, I guess if you can look at it that way.

So we're growing rapidly and uh need more people.

So if you're interested in in working at a at a company that is doing a lot of good for patients out there and serving um communities, um that's that's definitely a good place to go.

So there's there's a careers page or you could reach out to me directly um and I'd be happy to connect folks there to to get them into our engineering organization.

Um as for um my Django stuff, uh I have a series on my website.

So I I my website is mattleyman.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 Risk 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, how do what's an opinion and take on learning Django docs or or learning Django more generally, then I think understand Django is a good good way to go about it.

Um I and I write on about other stuff periodically too that that come up as as uh as the as the need arises.

Uh that from things that I discover.

I shared that with Carlton before this because uh 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.

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 um served by by Django and White Noise, uh without you know, without putting a reverse proxy in front of it and all the baggage that comes with that.

Fantastic.

Well, Matt, I I love your content and I just you have so much enthusiasm for coding.

It it really rubs off when I read your articles, when I hear your podcasts.

It's 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.

I'm just in awe of your of how prolific you manage to be.

Like it's uh

That's all I do.

Right, okay.

Yeah.

Yeah, okay, super.

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

Thanks again, Matt.

Thank you.

All right, bye bye.

Uh