Transcript: Learning to Love Django Tests - Lacey Williams Henschel

Hello and welcome to an episode of Django Chat. 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.

Yeah, we're thrilled to have you on.

Thanks for coming on.

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

of times as a conference chair. Maybe we could jump in and talk about that. How did you get

roped into being a conference chair at DjangoCon? Yeah, it's funny. I was kind of reliving this

story recently on Twitter and thinking about how fast it sort of all happened. So my very first

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

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 DjangoCon that year.

And they said that, you know, they could not do that, but maybe someone else could,

and maybe that person could be me.

They knew that I worked for the University of Texas,

this, but they didn't know that I actually lived in Oregon. So they thought they were asking an

Austin local to do this. But because I don't really have it in me to say no, I said, sure,

that sounds like fun. 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.

So things just kind of grew from there. I went from being the, 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 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.

And it is something that I don't think people usually do multiple years of being conference chair because it is a ton of work.

Yeah, I know PyCon does the formal every two year rotation.

Right, Ernest is the, yeah.

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

DjangoCon has never had that kind of a formal arrangement.

So 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 think 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 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 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.

Yeah, definitely.

And there's, yeah, it's like, who's going to 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 know how it works.

But yeah, it's fresh blood each year.

Yeah, I think that DjangoCon US is an interesting kind of hybrid of the way that, you know, DjangoCon Europe works, which is like 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 or they get burned out 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 finding new people 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 that historical knowledge.

Yeah, I mean, one area that I've seen that that's really important is with like the code of conduct enforcement, because it's actually really difficult to know how to do that properly. 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 what preparation needs to be, I've seen that at DjangoCon Europe, it's really vital. I don't think a new fresh team could pick that up at the quality that it's done without the input.

Absolutely. And it's something that's really vital to having a successful conference is having an effective code of conduct. And effective means effective enforcement of that code of conduct. And a lot of things are really having an effective code of conduct team that's prepared to respond to things that happen is really important.

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

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 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, if that makes sense.

Yeah, no, entirely, entirely. And as well, it's about setting the, what's the word, setting the mood, setting the environment at the conference. So when you first arrive, 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 lunchtime, and we make it in the afternoon, and we let people know, then actually the incident, the number of incidences will be lower.

Yeah. And yeah, I think I think definitely I think that making your code of conduct front and center is really important to having a successful conference because what you talk about, how important it is to set the tone, to set the expectations for for everyone's behavior.

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 been to conferences outside of the Python Django community, where they mentioned the code of conduct, but kind of offhand, like, but we don't have to worry about that everything's going to 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?

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 way that I would need them to. 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 codes of conduct are just kind

of hard to talk about um yeah yeah no fun i mean well well it's sort of a thing where if you you

only need it when something goes wrong so if it doesn't come up i don't know it's like a defensive

thing right 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 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

right and it's it's never um i've been on a code of conduct response team before that's part of

the responsibility as the chair of the conference is to be involved in that. And it's, it's never

fun. It's always difficult. It's, it's, there's a lot of concern and attention that goes into how

we're responding to these, these issues. And 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 training to conference

organizers about how to respond to codes of conduct, and that was not something whenever

I was chair 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 happy to see more attention to like, I'm happy to see more attention being paid 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 that's super and one thing that that one sort of the

one for me i guess you it ties into the work that you've done as well is um one of the benefits

of having a strong code of conducts is it leads into a um a more diverse community and jango

really does have a wide a more diverse community than your average tech conference and you know

And for me, do you think that the strong code of conduct enables that, is part of enabling that?

I think so.

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 seen behind the curtain a little bit.

So I know, you know, how incident response can go.

But I also think that kind of making it clear what the expectations are, we do get, like, it's not necessarily that we had 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, 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 participate in, you know, conversations with people without making jokes or comments that are exclusionary.

And sometimes people have, maybe 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 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

to share those incidents whenever they happen which is why 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 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 most of what I've experienced has been incidents where it's really been an issue of needing to educate that other person and that and they've been receptive to that. And that's been that's been nice to see.

So 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 know about now.

They don't need to be educated about this again.

They won't, you know, repeat this particular error and put someone else in the situation of having to report something like that.

Yeah, I think that's super.

A lot of times 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 use that

don't it's like ah no i didn't notice but thanks for pointing that out

well staying on the topic of uh django con conferences one and how they evolve 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. Carlton and I were just

speaking about that before we came on air, because he's speaking on that third day, advanced day.

I was speaking on one of the earlier days. Did you, 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 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 are like myself, just attend and have no idea of maybe the code of conduct,

how important that is, how much effort that takes scheduling. I guess, are there any stories you

want to share about being in that position? You know, it's, it's interesting because I feel like

we've, we've tried like slightly different things every year. 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 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 child care. 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. And then this year, we're from a

programming perspective, we're adding this, this deep dive day. And I do want to just to make sure

that that beginners who are listening to this and attending Django con 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 whenever we're

going more in depth into some Django topics. So there's there's some 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 really looking forward to the

everyone who is there who is looking forward to the deep dive day this year um and 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 keynote 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 their friends that they don't see as often, you know, maybe, for various reasons,

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 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 10am as opposed to nine, just to kind of give

people a little bit of extra, extra time. I think by Wednesday, I think by day three,

I think they appreciate that extra time. Yeah, day one, you're a bit like, well,

when's it kick off? But you need it. I think that I think day one, people are showing up early,

they're getting in line to get their badge, they're heading over to breakfast. And having

that extra time is extra time that you can you know run into people that you haven't seen and

you know maybe since last year's conference um but yeah people are getting a little bit anxious

to 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 that applies

to keynote speakers too right carlton because you told me uh you you keynote a django con europe and

you almost missed your talk this year yeah no i i went to the sprints so i was the opening talk of

the in copenhagen and i went to the sprints venue which was like a 40 minute walk away and i just

i've rocked up i'm like i'm looking for the conference it's not here and because i just

went to the conference home page on my phone and saw an address typed that into google found a pin

went to the pin it's not here and so i was quite late i was there on time but i didn't i didn't

have time for the coffee and the cool and you know the five minutes meditation beforehand so

it was a bit hectic we made it yeah i know especially whenever i've like traveled to a

conference any conference that i'm helping organize i'm kind of tired the whole conference

because i'm running around and helping helping do things but like the couple of times i've been to

jango con europe i've been tired because of jet lag but also because like 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

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 want to i don't want to go to bed i want to 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 it's a marathon not a sprint right and then you get to the sprints you

know like how does anyone have the energy to sprint 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 sasha roman gives out these little um dutch biscuit waffle things

or whatever they're called that are just like sugar bombs that keep you going

yeah i might do better if i had an endless supply of the the stroopwafels yeah yeah those 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 well and also django because i totally skipped that over usually we asked that

we didn't give you a chance to mention how you um got into programming oh okay tie those all

together for us? Yeah. So I got into programming, I don't want to say accidentally, but not really

on purpose either. 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 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. 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 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 so the process to do this was I had to take an aptitude test. And then I did a couple of

interviews. And yeah, sure enough, I got hired. And so it's a really 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 haven't heard of too many other

organizations that will pay you and give you benefits to teach you how to write software.

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 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 charette 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 right yeah because like i've coached one

to organize it's a whole nother level of uh commitment it's funny i was more scared to

coach than i was to organize 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 going to 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 i was glad you said imposter syndrome though because i was going to

say like surely that's imposter syndrome though like you've been trained you've been working in

this for years you know the software well and yet you've got this nagging doubt yeah well i think of

that as if it is sort of a hill where you start off and you don't know anything and then you

get to a point where you sort of know stuff but you feel like you should know everything so you

feel bad if you don't know something 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 yeah but no but nobody knows it

off by heart right you every time you code you've got the docs open right you're looking up every

i don't even remember my own books i mean people ask me questions i'm like i have to go look it up

it's like 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 the docs all the time i refer to like um code and other projects that i've

written like i will open up old projects to kind of look how did i solve this before oh yeah that's

how i use this totally um but i think that's the difference is you you know that you're like i kind

of sort of know you have the abstract idea of how it all fits together and then you know that you've

done it once before in some capacity so there isn't quite the like blind fear that you get with

like i have no idea how this works yeah but this is why like live coding interviews are such a bad

idea because in reality if someone wants you to do something you're like okay give me half an hour

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

well i think you were they knew who you were yeah like they you know they had worked with

me on jingo con for a couple of years 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 DjangoCon, coaching,

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 take this leap, if I do this thing, it will

probably be fine. Yeah. Well, speaking of working with Jeff Triplett, he mentioned when he was on

the podcast that you are a fiend about tests. 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. And Jeff mentioned

actually he hates writing tests but he said you love tests oh gosh 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, 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. And it was also a

comfort thing too. Like, well, I, because I, this was a new job and I wanted to do it well,

And I had some imposter syndrome about whether I would be able to do that.

Having good tests for my code made me feel a lot more comfortable about shipping it too.

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

And like, then 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 my deep and abiding love for unit tests.

so what were there well carlton you you have some opinions on tests that we were talking

about before we went on air do you want to share your standard out thoughts oh that was logging

no logging oh i'm getting confused yeah yeah excuse me well okay so the thought that we were

talking about is like um i always log to standard out and then i use a process manager to run

django say and then i capture the logs by the process manager and they pipe them wherever i

want. And for me, it's a really simple pattern. It's much more easy than, you know, configuring

log files and blah, blah, blah, blah. It's just like, log it, stand it out, and then

catch it.

Well, but that's how I...

Sorry, go ahead.

Hang on. No, no, no, no. We'll come back. We'll do another episode on that. But the

more interesting was what you said about the debugger, Lacey. If you write a test harness

and you've got the unit test and it's kind of exercising your code, and then you can

stop it.

put a break point in somewhere and you can you can really like start digging around so what does

exactly look like that i think that for me that is magical really valuable 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,

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.

And so sometimes it's really difficult to to debug those situations and being able to set those points and kind of inspect, OK, 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, OK, 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 it's a good way to test to like, well, if I I think the mistake is maybe in the way that I have written this query set.

now that I'm in 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. Yeah. And do you use an IDE for that? Do you use PyCharm or VS Code or do you

use the command line? I just 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 yeah massive inertia to try the new tool right

so the so okay but the one thing that comes up then is so what advice would you give to somebody

who perhaps doesn't use a debug or anything how because it's a bit like p p o p p p what are the

commands how do you get into debugging yeah what resources did you find that were any good

so i am i am not like a fantastic debugger 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 nnja i do believe um but she has a talk

from a recent conference i'm gonna get all the details about the super clear

are there are there show notes for the podcast yes yes okay i will find this talk and i will

so that it can be in the show notes but but nina has this i think also she's giving an updated

version at django con oh i think you're right oh even better yes um but no she has 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 want to do such an important half step because you can you can type type things in

but the print the print statement is still like you know a beautiful thing to me um but there

there are other things that maybe are better well that's the name of her talk i was going to say you

can see it's called goodbye print hello debugger yeah that's right okay so we'll link to that and

then um i'm always telling people the conference videos are up very quickly soon thereafter 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 jango con

talks and jango con us we don't get our sometimes we don't get our talks up as quickly as some other

conferences um because we generally don't post them until we've we've gotten them captioned

um so you do wait a little bit of extra time for the jango con us videos but i think that time is

worth it. Because I really love to watch, 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

helps it really stick. I agree. Speaking of teaching, 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 several years ago.

So I'm just curious, how was that experience?

And what did you take away in terms of presenting in a video format content?

Because you write quite often now on the RevSys blog and on your own personal blog.

And actually, in what, open source?

What's it, open source?

You and Jeff do a whole bunch of articles.

Yeah, last year, Jeff and I did a monthly Python column on opensource.com.

um and then yeah i write um relatively frequently for the revs 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 so

yeah so i guess so video versus print how do you because i'm you know selfishly curious about this

because i'm going to start doing some videos what what did you learn doing that video is so much

harder that's what i was afraid you're gonna say i'm really sorry 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 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 for the video portions, I had, you know, video engineers

who were 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 right right right but even

with all of this external support oh gosh it's really hard 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 you know yeah 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 and they would know like okay there was a huge spike here 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. 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 really enjoy speaking because I there's 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 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 to write 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 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

I'm like what did they do and like are there things that they do that I could incorporate

into what I do you know um so in terms of what you're doing with Django these days I notice

you've been writing a lot about Wagtail. 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.

Yeah, I find Wagtail to be really interesting. I've enjoyed using it and getting to know it.

And it's it's one of those two where it what it feels like there have been a lot of opportunities

for me to. So 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'm 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 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 because it is there is a learning i mean i've taken it on a couple of times

and yeah 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

so what's your rule of thumb now for wagtail versus straight jango on a project for folks

who are listening right because it's a it's a powerful cms how do you think i always find that's

sort of the question right when when do you switch over to wagtail what what makes more sense with it

versus raw Django? Yeah. 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 going to wind up using?

Am I going to wind up 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.

Yeah, which came out this week.

Which came out yesterday.

I just saw that.

Yeah, we'll link to that in the show notes.

Yeah, thank you.

So yeah, I think that that's one of the things that I think about 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 well it's a full-scale page builder right yeah and

now i'm kind of thinking like well gosh how to describe what the page model is intended for and

i i realized as i started the sentence i don't have like a a clean answer for that um which is a

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 one thing i was going

to ask you yeah was um about um so as an english major and one thing we have in django one of the

like so if you look at django's bug backlog the biggest issue is the biggest area is the orm

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

of tickets with prs where it's like needs documentation and we have a whole load of prs

that come in where 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 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 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 think that's a really good idea um and 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 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 yeah i mean there's some if you're accepting this pr

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 well do you think that if we

like if we structured it and we worked out how to phrase it and we put a docs team together and we

said hey there is there is an opportunity to contribute here in these ways do you think that

would get pickup do you think people would i mean there's one way of finding out it's to try i guess

Yeah, I think it's certainly possible that a docs team aimed at that could could get pickup. It's so 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 going to have to show up for the conference. So there are deadlines, 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 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 well i mean but there are these tickets yeah exactly there's a dashboard and we could say look

there's there's 200 documentation tickets could we get that number down yeah 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 yeah no often it's just a little

rephrasing but sometimes it's a contributor their native language is in english and so it's really

difficult to get the phrasing exactly so and but there are lots of people who have that english

language ability who could perhaps come in and and that's i almost feel like that needs to be a

an additional tag 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 just tell me what they are so all right well yeah well

that's been on my sort of back burner for a while 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 oh actually only 1200 now we're getting it down which is super but um like if you just

approach that it's too big so you break it down by component then there are ways and means of

breaking it down and it's on my list to write that but yeah i'll try and push this forward as well

and i i don't know if other people would would agree like i'm i'm not a maintainer i don't know

what is successful when it comes 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 can do that i can take what

is there and make sure that it um makes sense and and is grammatically correct etc yeah and the

phrase you use there which is really handy is copy editing because it's kind of a lot of times

it just needs a rephrase um so lacy given that you've learned django through texas austin and

you're involved with django girls if someone comes to you these days and says they want to learn

django but maybe they don't know python at all or very well how do you direct that person in 2019

I still think the Django tutorial is one of the best beginner Django tutorials, like true beginner Django tutorials that's out there. 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

which makes it really really great for learning django but also learning just kind of some basic

like programming concepts or some basic you know how to set up your computer to do any kind of

programming right yeah i agree with that i mean i think that 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 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

jango topics but then also being like well it's really hard just to install jango yeah a lot of

people and i say that like the complaint that i have about other tutorials is that they they

don't identify the prior knowledge that they expect you to have 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 way more work yeah like you well and you you just get used to knowing

certain things 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 going to 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 someone else would need to have prior knowledge of in

order to find this particular article useful um so now 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 well I can tell you

from experience it's just a lot of work 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, 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 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. And I can do that because I make a living teaching Django. But if you are like

yourself, I mean, you're not going to do it. Yeah, that's amazing dedication. I really applaud

you for doing that what i've started what i saw 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 going to stop being

supported soon um f strings appeared in a very specific version of python 3 so i had a friend

who was wondering 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 um i've had readers out you know complain to me about things in the book

and that's why i know that because i'm like oh well are you on three six no you're not yeah so

the the versions really really matter and like we've you know django 2.0 well i guess 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 so 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 well i i think the challenge too is sometimes it's okay

to like i like sometimes i can't you know i can't go into everything 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 a 2.0 yeah 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 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 your title um but these are you know secondary things also for the readers also

for readers like um django is so stable it has been for years i know the urls changed and you

know 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 well we don't carlton right like you me and lacey

is going to be totally stumped on these little things yeah yeah yeah no because if it yeah

in the beginner environment it is the case that if it doesn't work if it's not exactly the same

it doesn't work they haven't got the resources to work out why it's not working 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 going to 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 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 1000 words long or something, you know, and I'm going to have different versions of it for each version. I think that that's probably overkill in most 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.

I think we've probably gone over our allotted time, but thank you so much for taking the time, Lacey, to come and talk to us about Django and all the work you've done volunteering to help the community over the last couple of years.

Oh, you're welcome.

Thank you so much for having me.

This has been fun.

Great.

And for people listening, you can find new episodes every week at DjangoChat.com.

We're at ChatDjango on Twitter.

And we'll see you next week.

Bye, everyone.

Join us next time.

Bye-bye.