Transcript: Learning to Love Django Tests - Lacey Williams Henschel

This week we're joined by Lacey Williams Henschel to talk about all things Django.

I'm Will Vincent, joined as always by Carlton Gibson.

Hi, Carlton.

Hello there.

Hi, Will.

And Lacey, welcome to the show, Lacey.

Hi, thanks for having me.

So I think I first met you at DjangoCon because you were running it, or you've run it multiple times, right?

As a conference chair.

How did you get roped into being a conference chair at DjangoCon?

I was kind of reliving this story um recently on Twitter and thinking about how fast it sort of all happened.

So my very first Django Con that I attended was in 2012, and then in 2015 I started organizing it, but it all started because I was organizing a Django Girls workshop in Portland, and then I went to PyCon that year, which was in Montreal.

Um, and while I was there, Jeff Triplett, who was that year's DjangoCon chair, was asking the Django Girls booth if they would organize a workshop to happen at Django Con that year.

And they said that you know they could not do that, but maybe maybe someone else could, and maybe that person could be me.

Um they knew that I worked for the University of Texas, but they didn't know that I actually lived in Oregon.

So they thought they were asking an Austin local to do this.

Um but um because I I don't really have it in me to say no, um, I said, sure, that sounds like fun.

Um and then me organizing the Django Girls workshop as part of DjangoCon wound up me becoming part of the organizing team for the whole conference.

Um so things just kind of grew from there.

I went from being the um what the diversity chair and the financial aid chair in 2015 to being the co-chair in 2016 and then the chair in 2017.

And then the past two years, last year and this year, I've been just sort of an advisor for for the conference, just helping the other people who are running it run it because I've got a few years of experience doing it now.

Okay, super.

Um I I know PyCon does the every the formal every two-year rotation.

Ernest is the yeah.

And I can't remember who the 2020 PyCon chairs will be, or chair will be.

Um, DjangoCon has never had that kind of a formal arrangement.

So it's it's had different chairs in different years or different combinations of chairs in different years.

Jeff Triplett and I kind of switched chairing and co-chairing for two years.

He chaired and I co-chaired, and then I chaired and he co-chaired.

So yeah, but I I think it's it's a lot of responsibility and it's a lot of work to wrangle everything that needs to be done and to keep track of all of the different um things that have to happen to make the conference happen.

So I think that a lot of people don't really want to do it for more than a year, and I think two years is is a really good max to be responsible for all of that.

Otherwise, I think your energy for that kind of thing gets sapped.

Like I think that for DjangoCon Europe, most of the team turns over every year.

And there's yeah, it's like who's gonna be the team for this year?

Right, there you are.

And there's some people that hang around that's like in the role that you and Jeff might play that are experienced and they they know how it works, but yeah.

Yeah, it's fresh blood each year, sort of.

I think that DjangoCon is DjangoCon US is an interesting kind of hybrid of the way that you know DjangoCon Europe works, which is like you you sort of change over everything every year almost.

And then PyCon, where I think it's sort of more formal, like two-year terms, where we just sort of we lose a few organizers every year because they go on and do other things, um, or they get burned out, or or people have different reasons, and but then we also gain a few people every year.

So it just sort of feels like this wonderful revolving door of community members.

You know, we're always um finding new people and and getting them involved in the conference, which is really nice because then you get that fresh energy, those fresh ideas, the people who are really excited, but then you also have this contingent of people who've been doing this for a minute and who understand how things need to work, who have um that historical knowledge.

And so the experience of those people that have over the years learned what the code of conduct rules are and how to enforce them and and how and what um preparation needs to be.

I I've seen that at DjangoCon Europe, it's it's really vital.

I don't think a new fresh team could could pick that up at the quality that it's done without the input.

Um, and a lot of things are really having an effective code of conduct team that's prepared to respond to things that happen is is really important.

And for new organizers, it's a really scary thing to be part of.

Um, so you I think that DjangoCon US is really lucky to have people who respond to code of conduct incidents, who have done it before and who have had some training, um, and then also to have these these new people coming in who sort of get educated about this and can make use of that experience in future years so that we're always expanding the group of people who are familiar with that, even if it's not I think it's a good position to be in to have more people who know how a code of conduct response team should work than are like

actually responding to code of conduct incidents at the conference, you know.

Um if that makes sense.

And and and the as well, it's about um setting the the um what's the word, setting the mood, setting the environment at the conference.

So when you first first arrive, that the code of conduct is very visible, and that's it's through experience, I guess, that it's known that hey, if we make this announcement at the beginning and we make it at bit at lunchtime and we make it in the afternoon and we let people know, then actually the the the in the incident, the number of incidences is will will be lower.

And I'm really happy that over the last several years there's just more and more emphasis on the code of conduct, especially as a serious thing.

I've I've been to conferences um outside of the Python Django community where they mention the code of conduct, but kind of offhand, like, but we don't have to worry about that.

Everything's gonna be fine.

And that's that's not setting an expectation for me as a conference attendee that if something does happen, it will be taken seriously, right?

Um that's setting me up to feel like, well, if I if I do encounter something, I don't know what to do.

I don't know if if this group is is trustworthy, will handle this in the the way that I would need them to.

Um so that's that's an uncomfortable place to be in as an attendee, to feel like you don't really trust that something would be handled well.

So by approaching it seriously, um, which doesn't mean that you can't have a sense of humor about things too.

But I I think more important though, it's it's just ooh, codes of conduct are just kind of hard to talk about.

Um I mean well

Like you don't usually talk about or it's like insurance in a way, but it really is one of these things where you have to uh stay on top of it and make it important because if you don't then things will crop up and it and you know Django in particular is a wonderfully supportive community in part because everyone takes the code of conduct so seriously, and because of that, there's um you know there aren't the same number of incidents that can happen at your standard tech conference.

And it's it's never um I've been on a a code of conduct response team before.

That's part of the responsibility um as the chair of the conference is to be involved in that.

And it's it's never fun, it's always difficult.

Um, it's it's there's a lot of concern and attention that goes into how we're responding to these these issues.

Um, and it it does get very, very complicated to do, which just highlights how important it is, you know, and how important it is to do it well.

So I'm really happy that I'm seeing more people who have other kind of more professional training in code of conduct response who are now giving that training.

Like I know that there are some people who will go around and offer um training to conference organizers about how to respond to codes of conduct, and that was not something whenever I was chair that we that we did, and I'm wishing that we had.

And what's something that I have as a goal for myself is to participate in one of those trainings.

But I know that we have a couple of people on the DjangoCon US team that have done trainings through other organizations, which makes me feel really good about those conference organizers being on our team.

But yeah, I'm I'm happy to see more attention to like I'm I'm happy to see more attention being paid too, to not just having like written materials that tell conference organizers what to do, but actually encouraging organizers to hire people to really walk them through in a detailed way how they should respond to this.

And I I think that that effort is going really well.

Um, and I'm I'm excited to see more conferences be part of that.

And Django really does have a wide, uh more diverse community than your average tech conference.

And you know, for me, do or do you think that the the a code the strong code of conduct enables that?

It's part of enabling that.

I mean, I know that I feel more comfortable at Python and Django conferences than I feel at other conferences because I know that there's a strong code of conduct and I trust the people who are responding to code of conduct incidents.

And as an organizer too, I've I've seen behind the curtain a little bit, so I I know, you know, how incident response can go.

But I also think that kind of making it clear what the expectations are, we we do get like it's not necessarily that we had a a particularly good year if we don't get very many code of conduct reports being made, or we had a bad year if we had several of them made, right?

Like, well, sometimes we might receive several code of conduct reports in a year, um, but most of them were about the language that people were using, you know, and that's that's an excellent opportunity to educate people on how to um participate in you know conversations with people um without making jokes or comments that are exclusionary.

And some sometimes people have it's it's maybe they've it's really never occurred to them before, or you know, this is like this is most of the time whenever we've had to talk to someone who has made a joke that was inappropriate or made a comment that they shouldn't have, they've been receptive to learning about that, and that's a wonderful opportunity.

But you you have you know a few incidents like that, and you didn't have any the year before, that doesn't mean that those incidents didn't happen the year before.

It means that this year people felt comfortable telling you, you know.

So I think it's important to share those incidents whenever they happen, which is why I'm I'm happy to see more conferences too, doing like transparency reports either daily or at the end of the conference that tell people while preserving anonymity, we had this kind of incident get reported, and this is the action that we took, because it lets people know that the response team is in effect, they are taking action, they are taking things seriously.

And it also lets people know that if you make a comment that you shouldn't have made, that doesn't mean that we're going to kick you out of the conference immediately, right?

That's a the first step is a conversation for something like that, you know.

Obviously, you get into more severe code of conduct issues and very different actions get taken, but um, most of what I've experienced has been um incidents where it's it's really been an issue of needing to educate that other person and the and they've been receptive to that, and that's been that's been nice to see.

So what the hope is that then they go forth to you know other conferences and come back to our conference, and this is a thing that they they know about now.

They don't need to be educated about this again, they won't, you know, repeat this particular error um and put someone else in in the situation of having to report something like that.

Um a lot of times we we have these for want of a better biases that we don't we may not even know about.

And you know, we just until someone says, Hey, did you notice that you use that language and you use that don't it's like ah no I didn't notice, but thanks for pointing that out.

One thing I'm excited about this year is there is a um because the conference is coming up in a couple weeks, there is a there's three days and there's an entire day dedicated to advanced talks, which I think is reminiscent of Django under the hood, which used to exist.

Um Carlton and I were just speaking about that before we came on air because he's speaking on that third day, advanced day.

Um I was speaking on one of the earlier days.

Did you uh so I guess a question for you as a former organizer are what are sort of some of the things that you've seen change or you know, if you ran everything, what what kind of works well in terms of the conference in terms of structuring things or what were bad ideas?

I'm just kind of curious behind the curtain, because I've only, you know, most people or like myself just attend and have no idea of maybe the code of conduct, how important that is, how much effort that takes, scheduling.

Um I guess are there any yeah stories you want to share about being in that position?

And what what I've really enjoyed about being part of DjangoCon US over a several year period is seeing how we've been able to expand different things.

So the um opportunity grant program has expanded just in terms of the amount of money that we have available to give to people who need some extra financial help in order to be able to come to the conference.

A few years ago, we were able to add subsidized childcare.

Um, this year we have a nursing room and we'll also have live captioning.

And in years past, we've had the YouTube videos of the conference talks captioned once they were posted, but we haven't had live captioning.

Um, and then this year, we're from a programming perspective, we're adding this um this deep dive day.

Um and I do want to just to make sure that that beginners who are listening to this and attending DjangoCon don't think that the deep dive day isn't for them.

I don't want to refer to it as an advanced day.

It's just a day whenever we're going more in-depth into some Django topic.

So there's there's some um my experience as a beginner at some conferences was that even if a talk was maybe a little bit beyond what I was currently using or what I was currently ready for, even like having a little bit of exposure to that idea made it make more sense later on, you know.

Um but but yeah, so we're we're really looking forward to the everyone who is there is looking forward to the deep dive day this year.

Um, and we'll we'll kind of see how that goes.

We've we've done interesting things too with our keynote schedule, and I think that this year the keynotes start at the same time every day, but for a couple of years we were pushing them like half an hour later every day because we noticed that as people are spending more days at the conference, they're going out to dinner, they're socializing with their friends that they don't see as often.

You know, maybe for various reasons they're they're sleeping a little bit later every day, and so keynote attendance was like dropping a little bit every day.

And so we we experimented for a few years with um pushing the start time back a little bit.

And I think that this year the keynote starts at the same time every day.

It's just a little bit later.

Our conference starts at 10 a.m.

as opposed to nine, just to kind of give people a little bit of extra, extra time in the

by day time.

Yeah, yeah,

Day one, you're a bit like, well, when's it kick off?

But you know, yeah.

Um, but yeah, people are getting a little bit anxious to get the show started.

Um, and by the third day of the conference, you know, people are really doing well to arrive on time at all.

Breakfast attendance drops off a little bit.

Because you told me uh you you keynoted DjangoCon Europe and you almost missed your talk this year.

And because I just went to the conference homepage on my phone and saw an address, typed that into Google and found a pin, went to the PIN.

It's not here.

And so I was quite late.

I I was there on time, but I didn't I didn't have time for the coffee and the cool and you know the the five minutes meditation beforehand, so it was a bit hated.

We made it.

But like the couple of times I've been to Django Con Europe, I've been tired because of jet lag, but also because it's I'm in this exciting city in this part of the world I don't often go to, and I'm staying out late.

And these are I, you know, I'm with people that that maybe I only see once a year, maybe twice a year, maybe I haven't seen this person in two years.

And so, like, I don't wanna, I don't wanna go to bed, I wanna, you know, stay out with these people.

And by the last day of the conference, it's a it's more difficult.

Yeah, it's more difficult.

I almost never really sprint.

Um, sometimes I hang out at the sprints.

I think I've actually sprinted once, but I'm like, how oh gosh, people who really attend the sprints and focus on things and and get things done in the sprints, I'm just incredibly impressed by because how do you have the energy at the end of a conference to be that focused and that productive?

I I I might do better if I had an endless supply of the the stroop waffles.

Yeah.

So you mentioned Django girls a couple of times.

So you you because you you mentioned how you got into Django from that.

So how did you get into doing Django girls?

Because that's a really important thing, I think.

Usually we asked that.

Oh just okay, tie those all together for us.

Um, so I got into programming, I don't want to say accidentally, but not really on purpose either.

Um, I have a bachelor's and a master's degree in English, and I was working at the University of Texas in an unrelated role.

I was um just working in an admin job, and the University of Texas at the time had this centralized software developer training program where they would hire you for six months to train you how to be a software developer for the university, which involved training you in Python and Django, but also in this very old mainframe language called natural, because that's at the time that's what most of the university's code ran on was natural.

Um, and it never occurred to me that this would be something that I could do or would be good at, but one of the other developers that I was, I guess I was her client, you know, her team was was building something new for the department that I worked with, took me aside after one of the meetings and said, Have you ever thought about doing this?

I think that you'd be really good.

I like what you have to say in meetings, and I think you should do this.

And um, so the the process to do this was I I had to take an aptitude test, and then I did a couple of interviews, and yeah, sure enough, I I got hired.

And so um it's a really it was it was an amazing program.

They don't have it centralized anymore, but different departments at the university will do their own like internal training program.

So you still see software developer trainee positions posted at the University of Texas, but it's really unique.

I I haven't heard of too many other organizations that will pay you and give you benefits to teach you how to write software.

Um, so I had been doing that for a few years, and then I wound up relocating from Texas to Oregon.

And whenever I moved up to Oregon, I I wanted a way to kind of meet people and to make some friends.

And just through Twitter, I had learned about Django Girls, and I asked on Twitter if anyone wanted to help me organize a workshop in Portland for Django Girls, and Kenneth Love raised his Twitter hand and volunteered, and so we organized the first Django Girls in Portland in 2015.

Um, and we did a couple more in Portland after that, and then of course I did the one in Austin too um with Barbara Charrette.

And after I had done, I think four total, I decided to sort of stop organizing them.

I've coached at a couple since then.

Like organizing is you know, is is just kind of event planning in a certain sense, you know, like you don't have to know the code very well to organize.

You have to like recruit people and talk to sponsors and make sure that you know everyone has something to eat and somewhere to sit and enough outlets.

You don't have to know any Django to do that.

You know, that's that's not really dependent on your your level of of software knowledge.

Coaching was really scary because gosh, people are gonna ask me questions and I need to be able to answer them.

And I um had a lot of imposter syndrome the very first time that I coached.

I was way more nervous about coaching than I was about organizing.

Yeah.

And now, at least for me, Carlton, maybe in the same place, I feel I just assume I probably won't know off the top of my head, so it's like, well, I don't know, like let's Google it together and we'll figure it out.

And you know, that's actually more valuable going through that.

This is how I would break down this um problem.

That's probably more valuable to the person than just giving a answer I've given a bunch of times.

You you've every time you code, you've got the docs open, right?

You're looking up everyone.

I mean, people ask me questions, I'm like, I have to go look it up.

It's like I I don't know, I wrote that you know two months ago.

Why would I why would I know something I wrote?

I refer to like um code and other projects that I've written.

Like I will open up old projects to kind of look like how how did I solve this before?

Oh yeah, like that's how I use this.

Totally.

But this is why like live coding interviews are such a bad idea, because in reality, if someone wants you to do something, you like, okay, give me half an hour, I'll go and look it up, or go and have a little think.

Here's a solution.

But if they want to watch you do it, it's like, hang on, no, no, no, no,

I'm very fortunate that I've never had to do a live coding interview.

My interview for the University of Texas, because they're training you how to write software, they don't expect you to be able to write any.

That would be silly.

Perfect.

Um, so it was kind of like some logic problems, or like, how would you go about solving this particular, you know, problem?

Um, or just kind of the standard interview questions about, you know, strengths and weaknesses and things.

Um and then for the job that I have now at um Revsis, I um wound up just being offered the job.

They didn't really interview me.

So I'm not sure if they would want me to say that.

Um, so they not everyone at the company, but a few people at the company knew, I think, what it would be like to work with me on a day-to-day basis.

Jeff and I had worked together on DjangoCon US for a few years at that point.

So I think it helped that I was a little bit of a known quantity, but yeah, yeah.

I think every step I've taken in this in this career, you know, like organizing Django Girls workshops, organizing Django Khan, coaching, um writing, you know, tech articles, getting a job at Revsys, I've had just massive imposter syndrome about every single one of those steps, and they've all turned out okay.

And so it feels over the past year or so that I'm finally learning, like, well, if I if I take this leap, if I do this thing, it it will probably be fine.

Well, speaking of uh working with Jeff Triplett, uh he mentioned when he was on the podcast that you are a fiend about tests.

Um so I'm wondering if you could talk about that because testing is something that we're often asked about.

I think it's a very gray area.

Um and Jeff mentioned actually that he hates writing tests, but he said you love tests.

I I do love tests, and I love I think I have such a a deep love for testing because testing is also how I learn things.

Um I when I was at the University of Texas, we we at the time we weren't really writing a lot of tests for our Python code because we were using natural on the back end.

So most of the the business logic was in natural and we're just kind of you know serving up templates and stuff.

Um and then natural, it turns out it's actually very difficult to write unit tests for them.

So I didn't, I came from a strong manual testing culture, but not a strong unit test, you know, um background whenever I started working for Revsys.

And my very first project at Revsys, I was using Django Rest framework, which I had never used before.

And I was writing production unit tests for the first time, which I'd also never done before, and figuring out how to use like the debugger, like how to like set trace and then kind of inspect different things in the response that I would get from Django Rest framework taught me so much about how it worked, about how it behaved, you know.

So I would figure out, oh, okay, like this is where the status code lives, this is where the actual data that I'm getting back in the response lives, this is how that data is structured whenever I'm you know getting a single record versus a list.

This is how I can loop through those.

So it testing is how I learned how to code in DRF, really.

And then I just it just kind of grew from there.

Like I I just wound up wanting to, I wanted to write a test for everything so that I could learn more about how that particular thing worked.

Um and it was also a comfort thing too.

Like, well, I because I this was a new job and I I wanted to do it well and I had some imposter syndrome about whether I would be able to do that, um, having good tests for my code made me feel a lot more comfortable about shipping it too, you know.

So like I I if I have a test for this, then I will know if it breaks.

And like then it it's this like security blanket, it's this extra layer of protection that I have, you know.

So so yeah, that's kind of the source of of my deep and abiding love for unit tests.

Do you want to share your standard out thoughts?

Oh, I'm getting confused.

Excuse me.

And for me, it's a really simple pattern, and it's much more easy than you know configuring log files and blah blah blah.

It's just like log it standard out and then.

Listen that we'll come back, we'll do another episode on that.

But the more interesting was what you said about um the debugger, Lacey.

It's like you could if you write a test harness and you've got you know you've got the unit test and it's kind of exercising your code, and then you can stop it.

You can put a breakpoint in somewhere, and you can you can really like start digging around.

So, what does exactly look like that?

I think that for me is

Yeah, yes, that is that feels like magic, being able to like set a point, you know, somewhere in the view or somewhere in this method that's on the model or somewhere else to see like what are things doing?

Because sometimes you you're getting you've done something wrong, like you're getting results that you don't expect, or you're getting this error that you don't really know what it means, and you're trying to figure out like at what point does this start to happen?

Because you know, I think we've all had that experience in Django where you're getting this error, and the place that Django says it's coming from is maybe that's technically true, but really it's like five lines above it or something, right?

Like the error occurred before, but it didn't matter until you know it was tripped in this later place.

Um, and so sometimes it's really difficult to to debug those situations and being able to set those points and kind of inspect, okay, like these are this is what all my variables look like at this point, this is what's happening, and then to be able to hop into a console and say, like, okay, I want to sometimes I'll like run the next line of code just like manually, or like I'll just like type it in, or or it's a good way to test too.

Like, well, if I um I think the mistake is maybe in the way that I have um written this query set, now that I'm in the my console, like, well, what happens if I just make this change to the query set and then try to do this thing?

Oh, okay, that was it, right?

Like, so it's just it's a really useful tool to have.

And do you use um an IDE for that?

Do you use PyCharm or VS Code or do you use the command line?

I use Sublime Text and I use the command line.

Yeah.

I'm I'm curious about like PyCharm and some of these other IDEs, but I've I'm a very habitual person, you know.

I just I have the way that I do it, and I'm so far I haven't been curious enough to actually take the time to set it up into the city.

How because it's a bit like P P O P P P uh, what are the commands?

How do you get into debugging?

I'm I'm I'm good at writing tests and I'm good at putting like the set trace statement at various points in my code.

But in terms of like actually like running, you know, debugger commands, this is not something that I'm super comfortable with.

Um, Nina, um, her her handle on Twitter is N N J A, I do believe.

Um, but she has a talk from a recent conference.

I'm gonna get all of the details about

I think she's gonna be.

But but Nina has this.

Oh, even better, yes.

Yeah, um, but no, she has a a a talk that I'm really looking forward to seeing.

I haven't made the time to watch it yet, but I've just heard wonderful things about it.

And every talk I've seen of hers before has been really useful and really interesting and really clearly communicated.

Um, so yeah, my advice, even having not seen this talk yet, would be to watch this talk and as you know, and assume that it will teach you things.

Because I'm I'm really excited to be able to take my um my debugging skills in a debugger, you know, to to kind of the next level.

Because I still feel like putting a set trace at different places is just kind of one little half step up from like putting print statements everywhere, which is also a thing that I wanted

Such an important half step because you can you can type type things in and then

Um, but there there are other things that maybe are better.

You can s see it's called Goodbye Print Hello Debugger.

Yeah, that's really

You know, PyCon Australia was up, PyCon, and nobody watches these videos.

I mean, if you look at the count, it is hundreds, if a couple thousand, tops, and these are just gold mines, all the DjangoCon talks.

Um, so you do wait a little bit of extra time for the DjangoCon US videos, but I think that time is worth it because I really love to watch um, especially technical content with captions whenever I can, because sometimes it just I'm a person that absorbs information really well in a written format, but also likes to see examples.

And so seeing someone work through an example live and being able to see what they're saying kind of hits my brain in a few different ways and and helps it really stick.

Speaking of teaching, uh you've taught some courses at Treehouse on I think the Django admin.

I think actually I took your courses.

Oh, fun.

Those are back sever back several years ago.

Uh so I'm just curious what how was that experience and what did um what did you take away in terms of presenting in a video format content?

You know, how because you you write quite often now on the RevSif uh Revsys blog and on your own personal blog.

And actually, and what open source, what's it open source you and Jeff do of a whole bunch of articles?

Um and then yeah, I write um relatively frequently for the Revsys blog.

And my my own personal blog has taken a little bit of a break, which is okay.

That happens sometimes, but you know, okay.

Um but no

What what what did you learn doing that?

I have bad news for you.

For me anyway, video was harder.

And this is, you know, I had like the treehouse team, right?

Like I, you know, I had I had like graphics artists who were making cute little animations for the things that I was doing, and I had sound engineers who were making sure that my levels were right and who were editing things out for me.

And um, for the video portions, I had you know, video engineers who were um doing different takes and like making suggestions for how I would vocalize different things.

Um so, in in a lot of ways, it was really wonderful because I I did a lot of theater in high school, and so it felt like this wonderful convergence of my theater experience and my English background and then my technical knowledge.

It was like this, it doesn't get more interdisciplinary than doing a video programming course.

And I'm sorry to tell you that.

Um and part of what makes it hard so this the screencasting portion of of the treehouse videos was um was really hard.

Because like on the one hand, I think that you might you might think that doing a video course or a video tutorial might be similar to doing like a conference talk, but you're not using slides, you're like you're live coding.

And so, well, if you you know, you can watch your students like you know, watch you recover from a mistake, but it also depends on how long it takes you to recover from that mistake, or like with this, you know.

So there's there's that kind of concern.

Um, and then there's if if your machine just sometimes sometimes things just go really weirdly wrong, and and that takes a while to kind of recover from, but then you are explaining something as you're doing it, which is what makes live coding so difficult.

And so it's it was this this thing of trying to like touch the mouse and the keyboard as little as possible, um, and like maybe keep those movements separate, you know, from from speaking into the microphone so that it would be easier to edit.

And the treehouse sound engineers would have me do this thing where, like, if I if I needed to re-record something, um, I they would have me clap into the microphone so that they could see it on their screen.

Yes.

Now I need to, I know this is a place where she wants me to do some some editing.

Um and I felt like the courses from that perspective always came out really great, but um, because they they just had a really wonderful, wonderful team.

Um, but yeah, it's it's I find I find writing to probably be the the easiest for me personally.

Um, and part of the reason for that is I can kind of do it at my own pace a little bit, and I also have the opportunity to have people look over what I'm writing and give me some feedback on it or make some suggestions, which I find really helpful.

And then after that, I I really enjoy speaking because I there's a an energy that goes into giving a conference talk that is that's really fun.

Like I'm always very, very nervous before I give a conference talk.

The stage fright never really goes away, but that kind of disappears after I've been on stage for a minute or two, and that that that feels really good to like have people in front of you and you you get some energy from them, and then you get to kind of make fun little um pop culture metaphors.

Like I've used Harry Potter a few times, I've used Jane Austen a few times, you know, that's that's really fun to do.

I think that and for me that makes the conference talks kind of more memorable too, right?

Like whenever someone gets a little hook in there, that's a little bit more more fun.

And everyone has like different ways of doing talks, you know.

Like I there are some really great speakers that approach this in in very, very different ways.

And so I've I've been trying to kind of pay attention to the speakers that I that I really like.

Um, and like what do they do?

And like, are there things that they do that I could incorporate into what I do, you know?

Uh, could you talk about what that's been like?

Because that's I haven't used that myself, though we've had Tom Dyson on to talk about it.

I've I've enjoyed using it and and getting to know it.

And it's it's one of those two where it what it it feels like there have been a lot of opportunities for me to um so I I feel like Wagtail has pretty good documentation, which is really helpful, but it also has some features that I feel like are kind of hidden, and a thing that I could do about that would be to write documentation and submit a pull request, which I should do.

Um, but there there it has presented me with opportunities to kind of go into the code base and read the code a little bit to sort of figure out what Wagtail is doing behind the scenes, um, which has been really helpful for me growing as a developer.

Like I've going in and kind of reading the Django source code or reading the Wagtail source code has taught me a whole lot.

Um, but Wagtail is so powerful and it's so it's so specific in the way that it behaves.

So like it it kind of it took me, it feels like it it took me a little while to really understand how Wagtail worked.

I am to the point where I am a solid intermediate at Wagtail, and that feels good.

Yeah, right, good.

I mean, I've taken it on a couple of times and I'm getting there, but it's really like the the whole the way the page you define the page models and how they fit together and how they slot into the site, and I've struggled personally.

Because it's a it's a powerful CMS.

How do you think of it?

I always find that's sort of the question, right?

When when do you switch over to Wagtail?

What makes more sense with it versus raw Django?

Um I don't know that I have a fantastic answer for that yet, but so far my rule has been to look at the fields that are available on the Wagtail page model and think about does this other model need these fields?

You know, like am I gonna wind up using using the things that Wagtail provides on this particular model?

So for example, like the RevSys website is a hybrid of some Wagtail models and some Django models.

And we were having this sort of philosophical discussion a few weeks ago about well, should we make some of the Django models into formal Wagtail page models?

You know, like should we sort of migrate them and convert them?

And I looked at it and I thought about it, and I thought about how that would mean that we would use those models differently.

And I just didn't feel like in our particular case that we gained a lot from that.

And I realized that what we really wanted was to not have to go to two different admins.

So I just put those models into the Wagtail admin and then I wrote an article about it.

I saw that.

Which came out yesterday.

Yes.

Um so so yeah, I I think that that's that's one of the the things that I think about is is what fields that the page model makes available to you.

And then whenever you're looking at the page model in the Wagtail admin, looking at the kinds of things that are available to you in the different panels, like there's the settings panel, there's the promote panel, are these things that you feel like you would wind up wanting to use in this particular model?

And I think a lot of times the answer is not really, you know, like the Wagtail page model is really great for what it's intended for, which is this um

And I realized as I started the sentence, I don't have like a clean answer for that.

Um, which is a uh it feels like something that I should have.

Now I feel like, oh, this is an opportunity for me to deepen my understanding of Wagtails, really think about what is the page model for.

Um, but yeah, like I think that there are corollary models that you would want to use with a page model, for example, um, but don't necessarily need to be page models themselves.

Yeah.

And then next to the ORM it's the admin.

And then the third biggest category is documentation tickets.

Right.

And then there's a whole load of tickets with PRs where it's like needs documentation.

And we have a whole load of PRs that come in where that there's code, but often it's like what holds it up is documentation.

And one thing that I've sort of it's been on my sort of mind is to try and drum up a bunch of people who um you know are good with the written word, who can kind of come in and help with those PRs where it's like, hey, can we work on the docs here and the perhaps the the original author?

I wonder if you think that might be a good idea, and if you think people if there's lots of people in the community who are perhaps reticent to contribute to code, who might come in and join in on a PR that's open that needs some help on the docs or I

Um and I I think that it's something that I probably wouldn't do.

Like, I probably wouldn't go into an open PR that has a flag that says needs documentation and just provide documentation because I would wonder am I stepping on like the original opener of the PR?

Am I stepping on their toes?

You know, um is this is this something that that that person is is supposed to do or is working on?

Is it presumptuous of me to just assume that this isn't forthcoming?

Um and I'm sure after a certain point you do have to assume that it is not forthcoming.

Stay in a while this PR um without the documentation or you're providing it yourself or whatever.

Um But yeah, I do think that that's that's a good a good idea.

Um I think that So do you Oh go ahead.

Do you think people would I mean there's one way of finding out is to try, I guess, but

It's so um I'm such a bad joiner, you know, because like when it comes to like things where there's a deadline, you know, like a conference, well eventually you're gonna have to show up for the conference, so there are deadlines, which is which is helpful.

But I've not been nearly as successful at like code or documentation contributions because it's all self-paced, there's no like external, you know, deadline, um, which keeps me from contributing a lot of of code or documentation because I mean to and I just never get around to it, which is so many of us in so many ways, I think.

Um but no, I can I think that that's a really intriguing idea, and I can I can see that working out.

And I I think that the the key to making something like that successful would be to create like pretty actionable goals for it, you know, like instead of kind of an open-ended.

Could we get that number down?

And I and I think, and this is this puts more overhead on somebody else, but like ticket selection, like out of out of 200 tickets, well, like, how do I know which one is like a higher priority?

You know, like maybe this ticket has like problems that are other than the documentation.

So if there was a list of like, you know, 50 tickets or 15 tickets, that the only thing missing is documentation.

And like, you know, and the expectation for that documentation is is relatively minor.

Like, we need a couple of sentences on what this does.

We don't need a page of instruction.

Like there's documentation where the documentation doesn't exist and needs to be written, and part of the challenge is identifying how much documentation needs to be written for this, where should that documentation go, you know, things of that nature.

And then there are situations where the documentation exists and it just needs to be copy edited.

And I would I would do I would do 10 of those right now.

You know, like just tell me what they are.

So all right.

I've been thinking about this.

And I mean you talk about finding tickets, we've got 1300 open tickets, and if you just approach that, it's really it's really or actually only 1200 now.

We're getting it down.

It's super but um excellent job.

Like if you just approach that, it's too big, so you break it down by component, and then there are ways and means of breaking it down.

Um it's on my list to write that up, but yeah, I'm I'll try and push this forward as well.

Like I'm I'm not a maintainer, I don't know what is successful when it turns to how you tag different tickets in a way that gets people to pick them up.

But for me personally, if I heard, you know, Django needs help with documentation tickets, specifically these tickets that have documentation, but it needs to be copy edited, you know, and rephrased, maybe like punctuation or spelling needs to be corrected.

Um, but it just it just needs to be the documentation is there and it needs to be made ready, you know.

Then I I can do that.

I can take what is there and make sure that it um makes sense and and is grammatically correct, etc.

And part of the reason for that is because it doesn't assume that you know other kinds of programming.

It doesn't assume that you know Python or HTML or CSS.

It doesn't assume that you know what a virtual environment is or how that works.

It walks you through everything.

And my big complaint about a lot of technical writing content is that there's it feels like there's almost always something that they're assuming that you know.

There's background knowledge that they're assuming that you have, but they're not stating that they assume that you have that knowledge.

You know, it's one thing if if if they say, we expect you to know X, Y, and Z.

Um, but it's another thing to just write it as if everybody knows X, Y, and Z.

And then if you don't, you're it's hard to even identify why this is confusing for you.

It's hard to identify what it is that you don't understand and you don't even know what to Google at that point, you know.

So it's it can be really frustrating, especially when you're a real beginner at something.

Um, so that's one of the things that I really love about the Django Girls tutorial is that it doesn't assume really any prior knowledge, um, which makes it really, really great for learning Django, but also learning just kind of some basic like programming concepts or some um basic, you know, how to set up your computer to do any kind of programming.

Right.

I mean, I think that y you often forget what you've learned, maybe because it was painful.

And also Django is really pretty high up the spectrum of of skills.

I mean, it's a little bit like math, it all compounds.

I mean I mean, I'm constantly reminded of this as an educator because to do Django, it's like, well, okay, well, use your computer use your computer, use the command line, understand Python, understand virtual environments, it'd be nice to understand relational databases, it'd be nice to know how HTTP works.

I mean, the list goes on and on and on.

Uh, so it is in some ways, I you know, for me, I sort of both look at going into more advanced Django topics, but then also being like, well, it's really hard just to install Django for

a lot of people.

I'm not sure that in the content that I write, I'm doing an accurate job of that either.

It's hard to do because you you get used to knowing certain things.

It's way more work.

And, you know, I tend to write about things as they confuse me, you know.

Like I I have just figured out how to do a thing, and so now I'm gonna write a blog post about it, partly so that I don't forget and I have a documented resource for myself in the future.

Um, but I'm coming at having been confused by this particular problem with all of the knowledge that I currently have, and I don't know that I'm doing a good enough job in my own writing of identifying the things that I have prior knowledge of that like I that that someone else would need to have prior knowledge of in order to find this particular article useful.

Um so now I now I'm kind of thinking about like, well, gosh, for future things that I write, how can I try to be more mindful of that?

I mean, so for example, like in my my three books, I have a prerequisites section and I provide links, and I'm often asked, oh, okay, you know, you mentioned like Docker.

We use Docker in my new book, and I spend some time on it, but you could go much deeper.

So people say, Well, you know, what's a further study for Docker for you know all these different resources?

And it's a hard thing to do and it takes a lot of time.

And but I think to your point with like quick articles, I mean, I don't I don't do that with all the articles I write, though I do I always start from scratch.

I don't just go download this repo and then go from there, but it's it's just a ton of work.

And a lot of times, you know, you're not getting paid for an article, you're just doing it to solidify your own learning.

So it's sort of you know is how it is.

I mean, it's possible to do, it's just a ton of work.

And then you have to update it, right?

Like I update all my articles whenever Django updates, and that's you know, it's like a week of my life.

Um, and I can do that because I make a living teaching Django, but if you are like yourself, I mean you're not gonna do it.

I really applaud you for doing that.

Um what I've started I saw this tip from someone on on Twitter to put the version that you're working with for everything at the top of your article.

And I have started doing that with my last couple, um, so that I can so that someone can identify, like, okay, well, this is about, you know, Django 1.8, you know, versus 2.2.

And so this is is or is not relevant to me.

Um, because especially we're in a time right now where like Python 2 is gonna stop being supported soon.

Um F strings appeared in a very specific version of Python 3.

So I had a friend who was wondering Yeah, 3.6.

Yeah, so I had a friend who was was wondering like why she was getting a syntax error when she tried to deploy.

Um, and it turned out the it was that where her deployment environment was using 3.5 and locally she was using 3.6 and she was using f strings, and so that's you know, that's why.

No, you're not.

So the the versions really, really matter, and like we've you know, Django 2.0, well I guess it's it's 2.2 now is um still like kind of new, and there's some kind of new features that are like the way that we do URL routes is is a little bit different now.

And so whenever you're kind of looking for information on that, it's way easier to find the information from the Django one, you know, than it is.

Like you have to be really specific.

And so I'm trying to be better about putting all of my versions at the top of my articles, but I'm it is not likely that I'm going to go back and update all of them with each new version of Django.

I'll say, um, you know, just trust me on this one.

I'll explain what's I'll try to explain the thing, but I don't feel obligated to go into all of it.

So for example, with with URL paths, right?

I don't have to explain how it used to be done per se.

I can just say there was a change and was it 2.0 and like link to the documentation.

Um but yeah, it's like where do you draw the line?

And then and you know, and ultimately with all this documentation, most people aren't getting paid to do it.

So the kind of gritty work, like the Django fellows, like um Carlton and Marius do in the same way, you know, updating blog posts.

Um, so that's why I so I sort of made a face when you're saying to pin your um articles.

I think it's great to say up front and certainly definitely uh you know say it pip installed the specific version of Django.

But in terms of like for SEO, it's maybe not great to put that in your URL or your title.

Um but these are you know secondary things.

I know the URL's changed and you know the the the small things do change, but you can take code from a project eight years eight years ago and it'll be more or less the same.

Like the only Django one point average is gonna be totally stumped on these little things.

Yeah, yeah, yeah.

And I I think too that because different different companies, different businesses, and different, you know, people with whatever projects they're working on are going to upgrade at different times.

And so then they're gonna still be encountering problems on older versions.

So, like from that perspective, I think it's fine to have a lot of content out there that is about older versions of whatever library or whatever software that you're concerned with at the time.

Um, I do like the pattern personally of having the the version that you're working with like in the body of your article somewhere.

I don't know that I would necessarily go as far as adding it like to the title or um, you know, I know that the Django documentation, like you have the version in the URL, but like I wouldn't have different versions of this one, you know, technical article that was like maybe a thousand words long or something, you know, and I'm gonna have different versions of it for each version.

Um, I think that that's probably overkill in most for for most kinds of content.

But I do think in general it's good to kind of let people know like, well, this this was working for me with this combination of versions, you know, like I was using this version of Wagtail, this version of Django, and this version of Python.

Thank you so much for having me.

This has been fun.

And for um people listening, you can find new episodes every week at DjangoChat.com or at Chat Django on Twitter.

Um, and we'll see you next week.

Bye, everyone.

Bye bye.