Transcript: Django Testing and Debugging - Karen Tracey

Hello. Welcome to another episode of Django Chat. I'm Will Vincent, joined as ever by

Carlton Gibson. Hi, Carlton.

Hello, Will.

And this episode, we're very pleased to have Karen Tracy from Cactus Group join us. Hello,

Karen.

Hello.

Hello, Karen. Thank you for coming on.

Yes, thank you. You've been one of the original people I wanted to have come on the show because

you've been involved with Django for a long time. And we've emailed about various things,

So I'm very excited to have you on the show to share all your knowledge and wisdom with us.

You're scaring me.

Well, I mean, specifically, I'm thinking about the fact that you were on the DSF board back in the day and helped with some matters.

And Django is not that old, but it's been around for a while.

And there's been sort of these generational things of knowledge and changes around the framework.

So anyways, we'd love to talk about how you got into Django, obviously, what are you doing today?

But maybe we could start with, you know, your background.

I know you have a formal background in how you got, how you slid down the slope of computer

science into Jenga.

Yeah, I started, I mean, I chose computing as a, as a focus in college.

So I'm more of a traditional, came into programming and computing via school.

that was a long time ago now. I think I was fortunate in the timing that I was getting

into choosing a career back when personal computers were just coming out. The internet

wasn't a thing yet. And there wasn't a lot of, it was at a time when it seemed like women were

getting into all sorts of new things. You know, women could be doctors and lawyers and all this

other thing. And I didn't have any back pressure of, well, this is something women don't get

involved in. I think nowadays it's much more seen as a guy's thing. I think I was fortunate

in the timing that I didn't, uh, didn't run into that. And I also came from a family that worked

for IBM, both my mother before she started having kids and my dad worked for IBM. So it was sort of

Like, this is something my family does.

Right.

So I think I was very fortunate there in how I got into it.

And I went into, I went to Notre Dame and that was where my dad had gone.

And I went into the college of engineering.

They didn't have computer engineering, but they had electrical engineering with a focus in computers.

And yeah, that's how I got into computing.

i come to the question that the thought you know but you said i read an article a little while ago

that said something like you know in the early days of um computer and computer science computer

engineering there was um women were very much involved in that and then there was there came

a sort of time where it it switched i was wondering if you've if you've got a take on that you know

because it seems you know now with django girls and these initiatives we're trying to

bring it back but it's still very male dominated and i kind of wonder why if you look at the

history of it early on you know before he older than me there were women involved in you know

rewiring you know back when in the days when you had to unplug and plug wires into computers

women were involved i think

yeah i don't know i i wasn't i don't i'm not a historian i don't know the how it all happened

but if you look at my mother's experience you know she stopped working when she started having

kids so it was more a societal thing of women didn't continue working yeah okay so there was

that aspect to it and then when personal computers came out i've read various articles that talk

about how the games and the the marketing was all targeted at boys right and it became much more of

a this is a a boy thing and then women didn't girls didn't didn't get attracted to it didn't

get into it but i do think there's no reason i don't think there's any reason that the programming

aspects i think women are an asset well i i thought it was yeah i've seen that chart where

I think it was something in the 70s, it was majority female, and then it just sort of drops off a cliff.

But I know that, I mean, there's like that book and movie Hidden Figures.

I mean, there's female mathematicians.

I mean, they called them computers, like, because they were computing before they had.

So there's a long, obviously, history of that.

I always thought maybe it was like once computers started paying well, all the men were just like, well, we'll take those jobs.

Whereas before it was seen as a little more menial, which I think is inaccurate, but it was very, you know, more detail focused.

who's, I guess who's to say, but it's a shame. It doesn't make any sense to me from an objective

point of view, why that would be the case. No, me neither.

Anyways, but so you had the background, you went into computing. So what was, I don't know,

what were the languages that you were studying in school? And, you know, how did you find your

way to the web since you predated the web a little bit? Oh, back in school, let's see,

The first thing we learned was Fortran, then we did Pascal, then we did C.

C is probably the language that I feel most like that's my core language still, even though I haven't used it in decades.

I got involved in a research lab at Notre Dame, and that's what led me to stay there and get a master's and a PhD.

And we were doing research into how mainframes and personal computers were going to talk and interact with each other.

And we ended up, that research lab focused on building an operating system.

It was microkernel-like, you know, a base set of services onto which you could build an operating system.

And all that was written in assembly in C.

So I had four good years of that was all I did with C pretty much.

So, um, so kids these days, right.

They just don't know what they're, they're missing.

But so over time, like when I would go back to, I'm going to jump around here, I guess

in the early two thousands, I wasn't working and I was thinking about, uh, I should probably

go back to getting a real job and having a decent income.

Uh, and I should try and see, you know, interview for interviews, make sure you could solve

problems or whatever.

So there's various sites you can go and see, you know, solve this problem, do that, whatever.

And I had programmed in Java and Python by that point.

But when I went to do these little problem solving problems that like my natural language,

The language I gravitated to do things in, even though I hadn't used it in decades, was C, which I found interesting.

I was going to say, was that like, so you have all this experience and a PhD, but can you reverse a linked list on a whiteboard?

Did you have to do all that?

I did not.

Well, I did interview a couple of times with Google, and those were days of pretty much whiteboard coding.

And I'm very grateful now that I did not get a job with Google because I don't think I would have enjoyed it particularly.

Cactus didn't have that kind of interview.

So it's Cactus what you ended up, you went directly to Cactus after?

Yes.

Okay.

So I was right when it started, right?

Because we've had them on.

When I joined, they were four or five guys in a co-working space in one little office that's probably as big as this room.

and i didn't fit so i was in the co-working space um that was i joined in 2010 i think they were a

couple years old at that point yeah okay so go on and that but that would be about the time when

you wrote your book so and the reason i jumped to your book is because it's massively influential

when i for me when i was picking up django because i needed i had the sort of introductory material

and then i had you know your testing and debugging book which was like my book yeah yeah no i mean it

was as influential to you you know really like me too i read it i haven't all the other all the

other books have gone you know i don't need that anymore i don't know i've still got your book and

it's like you know it's you know the unit testing framework doc tests um the debugger you know

you know print logging log logging you know it's such a hard thing to pick up and such a hard thing

to get right in python and then your book was just like you know walked through in such a good

way so you know that's one of the reasons why i'm super excited to have you because it's like wow

karen she wrote that book honestly i hate python logging it's so hard to configure properly

yeah uh so that was i it was after i had finished the book that i started working for cactus um

so i got out of school i went to work for ibm for about a decade and i took some time off

and then I got involved in crosswords and I wrote my own set of utilities for building

crossword puzzles and what got me to Django was I wanted a a I wanted to be able to see my database

of published puzzles from various outlets New York Times Los Angeles Times I forget what all I had

and I wanted web pages where I could see the puzzle the the aspect the way I could see it

in my crossword builder programs was little bits of it.

And I wanted to be able to see like,

this was the whole puzzle.

This was the context in which this entry appeared

so that I could more easily evaluate

is this work in this puzzle in this context

that I was working on sort of thing.

And I had a friend who suggested Python

as a language to learn as was a cool language.

And I knew very little about web protocols

um, back in my IBM days, I knew, like, I, we knew that I knew the details, the bits and bytes of

the TCP protocol, IP protocol. That was the level at which I worked, I worked at the operating

system, the middleware, um, the web. I didn't want to learn how to, I, I needed a framework.

So, and I looked around, what was there, pylons? There was a set of them and there was several

to choose from and i gravitated to django because of

the documentation okay interesting pretty much and the the completeness like i didn't have to choose

i didn't have to make a lot of decisions like do i want i forget the other ones seemed like

they were piece parts like you had to make decisions and i didn't want to have to make

a lot of decisions about do i want to use this or that i just want to like do it for me and let me

focus on what yeah batteries i need to do yeah so that's really cool that was what because that's

the that's the philosophy right great docs and batteries included and you know 15 15 years into

its lifetime that's still what people say about you know we had um some folks on recently saying

you know what it was the docs it's the you know it's the fact it's got everything with you can i

just, I just say, I, I feel like writing like the definitive testing book on a framework and then

getting a job is like the biggest subtle flex I've ever seen for a job interview. So kudos. I love

that. It's like, why should we hire you for Django? It wasn't the definitive book then. Cause it

barely come out, I think. But still, I mean, and just to take a moment, I went out at your chapter

titles, like as a book author, like I love your chapter titles. Like you have, you know, when you

don't even know what to log using debuggers like when problems hide getting more information and

then what was my favorite one is yeah when the wheels fall off like the Django debug page I love

those things because you know it's hard to liven up a technical book but anyways no Carlton you

were gonna ask a question I mean I didn't study computer science so I studied philosophy so

you know I was self-taught and it was all print statements you know and I you know I could reason

my way through a program and i do print debugging the whole time and when i found your book it was

very much like ah bam this is the tooling that goes that's that step beyond and so and to learn

the debugger and you know that it's just like a whole new power tool that you've you've gotten it

so it really did um you know it really did change i wish you would update it i wish there was a

modern defense

testing book. I mean, Adam Johnson has his, you know, he's gone a step beyond with, you know,

speed up your Django tests, but I think there's still a spot for fully testing a Django project.

If I did more Django books, I would do one on that. But it's a big, yours is the only book on

that. It's a big topic. Yeah. It's like, it's a big commitment. Yeah. I wrote that when I didn't

have a job. So it was, I mean, I was full-time working on that when I did it. Well, what was I

doing then i was doing that i was i was writing crossword puzzles i was helping out on django

users i had to answer a lot of questions you know helping out with django um and i i use i

volunteered at cat rescue and i have uh we track the cats in a django database um so i was

i wasn't full-time on the book but i was spending a lot of time writing the book

um and i just can't conceive of doing a writing a book or even revising a book

with a full-time job in the rescue it's just just every eight months it's not a big deal

priorities um yeah there's just so much i would like to do that i don't have time for

ah yes

carlton you're asking about that you're asking a question well i would so then okay so you're

using Django you you said you get involved in um you know helping on Django users and then you got

involved in helping with running the project itself and the board and the DSF and things

like that can you talk about that um that part of it because yeah I want to hear war stories

of the early board you know what was what was it like back in the day uh it was I'm trying to

remember it was a long time ago it was probably not very I like I don't know what it's like now

because i'm not on the board but we dealt with um requests for aid i'm sure you still do a lot

of that of people asking for grants for this that and the other thing um i think we did the

around then was when we were working on getting the trademark and agreement finalized um and we

had a lot of issues and back and forth with getting how do we affordably get legal advice

that's still an issue yep still an issue uh and accounting accounting help um

and funding i think i i i think django is in a better position now than it was then with getting

funding well this is all pre-fellows too because um this was pre-fellows pre-technical board pre

i mean this was still back when there was the core team well so what was the funding for um

i mean i the servers i mean how i guess how was how is it being used i mean i guess sponsoring

conferences and stuff or i think it was primarily for sponsoring django girls events those kinds of

things that was needed for um we didn't have the fellows then but there would there was a sense

that something was needed to make Django sustainable you know a self-sustaining organization

um like the fellows because as an all-volunteer organization not funded by a big company it's like

people's situations change their interests change they you can't Django couldn't continue

if it was going to be the focus of, you know,

just the core group of people working on it forever.

That just wasn't going to work.

I mean, so as, you know, working in a fellow role,

one thing that comes up is it's the sheer amount of new tickets that come in

that's the main issue.

So if you're a volunteer open source contributor, you know,

working on your patch, working on the whole thing,

doing a little bit of, you know, new ticket comes in,

But it's like this fire hose of ticket reports.

And Marissa and I are just spending the whole time paddling upstream against it.

And that's fine because we're contracted to do that.

But that's not sustainable for a volunteer contributor at all.

Yeah, that was the kind of thing that I like to do when I was involved in it.

Answer questions on the mailing list.

Look at every ticket that comes in.

Is this valid, not valid?

point them in the right direction that kind of thing and yeah i can imagine it's even worse now

than it was then but i see i see lots of um you know lots of comments from you in tracks we still

use the old track and you know there's every so often it comes up why aren't we using github

github issues you know why don't we move that it'd be more accessible perhaps because the track's

a bit kunky but i think the ultimate reason is that the history there you know there'll be

discussions featuring you and others that really explain why it is that the framework's the way it

is and if we just move to a different issue tracker that knowledge is lost and um yeah

unless you can import it yeah which probably i think the thing that kept us off of github issues

way back when we moved from svn yeah svn before good i think uh

was the ability i may i don't know that this has changed like anyone could create an issue or do

something in track and move something along or or change the state or whatever and we didn't have

that capability in get with github issues it didn't seem like to be honest it still doesn't

really have the the level of um project management knobs and buttons that the track's got and so okay

it's difficult to learn the track but it is very powerful you know yeah the triage part there's a

lot of history there now yes why things are the way they are can i ask with your specific to the

testing book so you came to django and python with you know testing programming experience in other

areas what how did that seem to you the the python django approach or the tools you know

then and now since you still use django like what do you what are your takeaways like if you

sat at 30,000 feet looking at like the pros and cons of the sort of Python Django approach to

testing? I don't know that I actually had a whole lot of experience with automated testing before I

came to Django. Back in the day of working for IBM, the testing we did was manual.

Like there was a whole test organization. You'd throw your code over the wall to

test and test would come back with with issues we didn't do a whole lot of automated testing

in my experience so my experience really is with Django and actually before I wrote the book I was

not big into testing for my own project oh yeah yeah like it was such a hassle Django itself had

the test suite and I was involved in maintaining Django and I, I understood how to, I understood

the value of Django's tests. And, and that sort of taught me that the reason you want a test suite

is to be able to make changes and have confidence that you haven't broken anything. Whereas a lot

of people, I think, come to testing thinking, particularly when you're writing a feature and

part of it is supposed to be tests, like to prove that your code works. And that's not really the

goal. It's more to make your code maintainable, meaning someone else can change it later and

your tests will indicate to them whether or not what they've done is having some unexpected side

effect of breaking previously held assumptions. So my learning of Django and writing that book

was a lot of learning about how to test

or the value of testing.

I think that's the best mode in which to write a book

is while you're learning and mastering it

because you have empathy for a reader

in a way that later on you have to work harder to get.

Like, just do it. It's obvious, right?

Why doesn't...

There's one thing that you cover quite deeply in the book

which is kind of dropped away, which is doc tests,

which is this brilliant thing that Python has

where you can write a doc string

and if you put a little terminal snippet in,

it will run the terminals.

You can run it as a doc test

and it will run the terminal snippet

and tell you if that didn't work

or if the output wasn't correct.

I was wondering what, you know,

I come sometimes shed a tear

for the loss of doc tests.

So you think any way of rescuing those

from the graveyard?

I do kind of, I did,

I wrote that whole chapter.

I did include them.

I mean, back when I was writing the book, doc tests and unit tests were sort of on equal footing.

There wasn't then a sense that doc tests were going to be eliminated as they were eventually.

But I did find the unit test framework much more powerful, I think.

and just from a i think from a maintaining the tests point of view i think they're easier

unit tests than doc tests um i didn't ever get into writing a lot of doc tests in my own code

i think i did get some feedback that i downplayed them a bit too much and i i sometimes wonder if

they um it might because one complaint about comments is oh they always get out of date i

I wonder if there's some sort of literate program in DocTest style mashup where you can use the DocTests to ensure that your comments stayed up to date.

Yeah, that's true.

That is a big problem with comments is that they get out of date.

Yeah, DocTests, I do kind of regret that they're entirely gone.

I mean, I think they could have a place.

They don't have a place anymore, but there was a crusade to get rid of them at some point.

And they're all gone now.

They obviously upset someone.

Yeah.

And I don't know that I really understood why they were so rigorously removed.

I think they could have continued.

I think there was a place for them.

Okay, fair enough.

So, Cactus Creep, you've been there, I think, going on about 12 years now.

I'd love to hear about projects you've worked on.

You know, this is about, as much as anything, real-world stories of Django and, you know, interesting things that you've thrown Django at and how that worked or didn't work.

I'm sure you have many to choose from, so that's a big question to ask.

Yeah, there's lots.

What's the life of a jobbing developer, as Carlton would say?

Life of a jobbing developer.

Right? That's the phrase, Carlton?

Yeah, yeah, yeah. No, exactly. You're a jobbing developer.

Not just like, you know, for fun or like a book writing developer, like a jobbing developer, like getting paid by an employer.

Yeah.

So I started with Cactus, like it was really small and then it got bigger and then it got smaller and bigger.

Um, but we've worked for, we've worked with various projects over the years and I really

enjoy the direct contact with people who are gonna use the software or that was, that's

the primary thing that I really enjoy over like working for IBM where it's small cog

in this huge, huge wheel and you don't really understand why you're building what you're

building or you hear from marketing they need these features and you're like that doesn't make

any sense I don't understand that like um I really like the direct interaction with clients who are

going to be using um the projects over the years and we've I've worked on smaller bigger um there's

one that's we still got that uh it's probably I think it's out on the website as a case study the

survey for schools school surveys we've um it's a tool that's used to administer surveys

to in chicago state of illinois yeah yeah there's a there's a case study so i'll put that in the

notes yeah yeah so that that is still running and actually the uh i believe the illinois school

survey starts today. So that's a funny project in that the website associated with that goes from

needing 24 web servers a day to not being used at all, depending on...

the time of year so over the summer like it's completely dead you could turn it off and no one

would know whereas this time of year when schools are in session there may be surveys running for

the state of illinois chicago public schools other places um so it's that's an interesting project in

the the periodicity of it and the having a set time where like you could make massive major

changes and and get it all done and not have to worry about migrating the data because you know

the data for the last year gets purged and the new year you start completely fresh so it's kind of

an interesting different sort of thing from a website where you're it's always up and you need

to you need to maintain the data all the time and it's always got traffic and you need to

be aware of that so there's all sorts of different projects some are small can i just ask about the

scaling there i mean do you deploy that in a kind of traditional way you know servers and you know

one db server and various servers in front that has that has an environment has at least two web

At least two web servers running all the time.

There are at least two database servers, a master or a primary,

and one read replica cache worker server for Celery Rabbit kind of stuff.

So there's at least, I think, five minimum servers.

It's set up with – it's on AWS.

It's got an auto-scaling group, and it's set up to auto-scale based on CPU of the web servers.

Okay, so then that handles that flux between that smaller setup and then the peak demand for you.

Yeah.

When we know it's going to be in active use and the traffic for this particular case of the entire state of Illinois starts surveys,

you know school starts at 8 a.m and the class is going to come in you're going to get

yeah okay a massive millions of students right like a couple million you're going to get a

massive influx at a particular time we did find that the auto scaling could lag so we usually

set it up so that instead of so there's a scheduled action at the beginning of the day

to bring up at least six servers which allows for enough time to get everything up if it needs 24

like it doesn't yeah it doesn't fall off a cliff before it adjusts to the fact that you've got that

much server so we do have some timed actions that bring up a minimum that increase the minimum

capacity at the beginning of the day yeah okay and then let it then let the auto scaling based on

cpu handle it during the day okay and then i wondered that's super i wondered about whether

your your original work on micro kernels and client you know the relations between mainframes

and personal computers where that ties back into this sort of containerization and cuba

kubernetes things micro kernels is a is a hot phrase right and i wonder if you could have

thoughts in that i'm sort of half being silly but i have so there are so many aspects of web

from deployment to you know configuration management of the servers deployment the

the web framework itself the front end the javascript my folk my my my desire to learn

more is more on the front end okay fun that then on the there is a huge amount of kubernetes

interest at at cactus and um most of our current projects are deployed using kubernetes this older

project is not using kubernetes um and i don't know that we will ever move it to kubernetes but

for the most part with kubernetes i'm like okay all that complexity y'all figure that out and

Give me the commands to run or set up a CI to do it.

Throw it over the wall to the DevOps and, yeah.

Okay, super.

So can I ask then, which are the bits of front-end

that you find most interesting, most exciting, you know, in the game?

The user.

I would like to learn more about how to effectively design user interfaces

that are a joy for people to use versus not.

Okay.

It's what a lot of websites are not a joy to use.

I'm excited about, we're starting to experiment with HTMX.

I was going to ask you about that.

We have to ask it in every episode now,

but we just, yeah, the last couple episodes,

we spoke to some folks from Berkeley using HTMX and yeah.

So what are your experiences with it?

We're just starting to use it.

I, it's interesting to me, like it's, it's just replaced this part of a page sort of focus.

If you go back to that, that survey thing we wrote, the survey taking part of it is all a single page.

And when you press next, it just replaces that part, you know, the question part of the page.

submits the answers and replaces that. It was a requirement of the original specifications that

it not say that you're on page, the URL not change as you progress through the survey.

You're not supposed to see the page number you're on reflected in the URL. So that was sort of

dictated by the specifications, but it was, it required writing, you know, a little JavaScript

to do that and it's cool that htmx would make that a whole lot easier to do i like it i there

were several django con talks about htmx it seemed like or the javascript yeah this year there was

i think three or several yeah i think there were three and i found all of them interesting i

I do like approaches where you can take advantage of all the stuff that Django has.

Forms, authentication, so that you don't have to redo everything in the front end.

Do it twice.

So I'm excited about HTMX.

Don't have a whole lot of experience with it yet.

have done like have added what is it um the endless scroll pagination where if you reveal

the bottom of a list it just pulls in more infinite scroll i think that was very easy to do

infinite scroll um it was very easy to do with htmx uh i think that's one cool thing about it

is none of us have got a whole lot of experience with it but there's lots of people excited about

it and using it and being like ah yeah one thing for me that it really laid out when i first gave

bit ago was i was able to be i was able to do things that i haven't sort of been a quote-unquote

allowed to do for you know say five six years i haven't been allowed to do it this way you know

you can't do it that way and i was like but i can do it that way and it's really speedy and it's

just using the basics and oh wow i kind of had to know wow um yeah i think one of the things

i've not been involved in a heavy front-end project that use react or whatever i would

like to you to learn more about uh using react for sophisticated user interfaces what i'm what i

don't know what i'd really like to figure out is if i can if we can figure out how to use django

forms and not like recreate all of the validation that you can put in a django form and have to do

it in both the front end and the back end i don't know if that's going to be possible but well

There's a front-end framework called Alpine,

which is a bit like Vue, but much simpler.

It's sort of uptake.

The reason I got into it, the tailwind people said,

if you would be using jQuery, then we recommend Alpine.

And it's sort of like for that level up from HTML,

where you really want to keep the state on the client.

And one trick I was able to use was to send the data as form data

rather than as JSON, because you just create a form object

and add that, you know, in JavaScript and then send it

and reuse then my form layer in Django.

And that turned out to work really well.

Cool.

That sounds like a talk, Carlton.

Oh, if there's ever a conference again, yeah.

Are we ever going to get back to in-person conferences?

But, yeah, so, I mean, anyway, I think there's a really fertile territory

around here, around this area.

I'll have to look into that.

Can I ask again about crosswords?

Because you mentioned it, but I mean, you've had, what, over 100 published in the New York Times.

I mean, it's not just a hobby for you, right?

I think I saw that you have a lot in the New York Times.

I had 100 maybe total published.

Yeah, yeah.

So that was in the time when I didn't have a job.

I was doing crosswords, and I have not—that did continue after I had a job.

I had one editor I worked with who had a curated list of constructors that he was working with for the, I forget now where that was, but he, so instead of doing freelance, it was, it was scheduled.

You have a puzzle due and it will get published kind of thing.

I have not been constructing crosswords now for a few years.

So that's sort of also fallen by the wayside of one of those things I'd like to get back to you sometime.

Can I ask just what was your approach? Because I've seen like some documentaries on crossword puzzles and people make them differently. Like, how do you how do you get all the fit together? I mean, it is a puzzle, right? Like, what was your approach?

I wrote my own crossword builder helper kind of crossword builder program that helped me in writing a grid.

I focused on, so there's two, there's main, in American crossword puzzles, there's basically two different kinds.

One has a themed crossword where the long entries all share some theme.

And then there's themeless crosswords where the long entries are basically, there is no overriding theme to the puzzle, but the long entries are going to be interesting.

There's usually fewer words in them.

And I focus more on the themeless crossword puzzles.

So there you would start with what are just some interesting words to have in a crossword puzzle.

And interesting usually means unusual letters like J's and Q's and X's and Z's.

You know, how many of those weird oddball letters could you pack into a puzzle?

So you start by place, you start by with a theme list, you start with one or two long entries, maybe that you want to pack into a puzzle and then figure out how to place black squares.

Right.

following the rules of no few, you know, no, no word, less than three letters and symmetry. And

how do you place black squares so that you likely going to be able to fill it? Like you,

you're not going to put a Q at the end of a word. Like if you'd want to think about where you,

where you're particularly where your special letters are, there may be some constraints on

where you want, want the words to end and start and end. And then I would focus on the most

constrained area of the grid and see what is possible to put in there and pick the best set

and then move out to the left. And by doing that, you constrain, you make another area of the grid

more constrained and then focus on that. Are you going to be able to fill that part of it?

the the program and other programs my program and other programs would do auto fill like here's a

here's a set this fills it like a thesaurus kind of options or it is like you can say it you know

just fill the grid and you see you got word lists and you could fill the grid and but you might look

at that and say there's a lot of junk entries in there you know things that are three-letter

acronyms or abbreviations or yeah stuff that is just not interesting you've got an aesthetic

you know standard to uphold here yeah yeah and it's not like you can

in some cases you might say well

Just remove those entries from your word list and just never include them, but then it's probably okay to have one or two of them in a grid, and just having them available makes it more possible to have something that is a great grid.

So it's very hard to, like, you need to, ideally, I guess, maybe you could automate the whole thing if you could rank your word list or give assignments of value to the entries.

But there's just, I mean, that's a huge task.

And that becomes like a search problem.

Yeah, it is a search problem.

Like, what are the solutions to fill the grid?

And what is the highest score?

highest ranking

that's going to be your best

are your crosswords sort of the property then of

the newspaper which published them or could you

put together a compilation

they are the

property of like

the New York Times and the syndicates that I worked

for that you sell the whole thing

so they appear in

compilations of the New York Times

crossword puzzles yeah we have my wife

loves them so we have all those books

yeah one of the editors I worked with

the New York Sun

And he did create a compilation of my puzzles and another constructor's and turned that into a book that he did give us part of the royalties for.

So depending on the outlet, you may have some ability to continue getting paid for it, but mostly you just sell it.

Very cool. Very cool.

Okay, I had one more kind of question about software development.

So we talked about, you know, your preference for front-end

and working with and creating nice user UIs,

and that's something that you're interested in, designing good UIs.

And then we cut into HTMX and React and talking about those things.

I wonder if, do you think UI design is more of a people, you know,

is it software, you know, is it, it's more of a design thing, right?

It's not, oh, if I do it in this framework.

You need to be aware of people.

I think there's definitely a technical aspect to it as well.

I think all of software is more people-oriented than is generally understood.

Even just writing readable and maintainable software.

The person writing it today is not necessarily, if it's going to be successful, it's not going to be the person maintaining it tomorrow.

So just being aware that the code is not just for the computer ever is an important aspect of programming.

Even if it is you maintaining it.

Yeah, because you're not the same you, right?

You're not the same you.

i mean you i come back to code that was written years ago or even just months ago and i'm like

who wrote this i did but like i mean things change if you're holding you know it takes time

to load it into your your mind right you get into that that where you're really holding the whole

logical structure in your brain and to to reload that can take you know yeah even if it was just

yesterday yeah well that that's my my favorite programming quote of all time is ryan doll who

created node.js and he said the only thing that matters is the experience of the user

yeah having just built node

so it's sort of a full circle like you know because to your point about you know why is

the ui bad i'm most of my friends are non-technical so they'll be like oh this website's terrible why

is it terrible and i usually say because they don't care about you you know it's a it's a

government website or it's a corporation. That's not the focus. Yeah. It's bad because you're

going to struggle through it. But it is on the learning journey, right? I got into software

because I wanted to build websites. And I was like, oh, some are good, some are bad. I didn't

know why. And then I became enamored with the tools. But then at some point you come back to,

well, tools are tools. They're not the end goal. And the end goal is making it better. And yeah,

But to Carlton's question, that's a mix of psychology.

And then I think there is some hard truths around how do you actually make something navigable for a user?

I don't know where that line is, though.

It's hard.

I mean, watching someone, right?

Like that's always my test for even startups or tech companies.

Like, let me get the CEO and see if you can go through the process for your main product.

Because I bet half the time you can't, right?

Yeah.

Another thing you learn from building websites and having people use them is people don't read.

Not like my parents are like, no one reads and they mean like novels.

It's like, no, they don't even like read, read.

They don't even read the error message or they don't read.

So to make it so that it's intuitive to use is very difficult.

Right.

They turned like the Hulk like ASAP and shut off all reasoning.

Well, I even notice it myself.

when I'm using a website, and it doesn't do what I want.

I don't even bother to read the error message.

Make it go away.

If there's a pop-up, my initial reaction, just make it go away.

I don't even want to read it.

It's like, why is there a pop-up?

Get rid of it.

And that's not wrong.

That's why you must never break the back button, right?

Because if you break the back button, that's it.

Your site's out the window.

Well, that was in the history of kind of UI stuff,

Intuit, which makes TurboTax,

I feel confident saying generally is an evil company.

But when they were starting out, their only measure was how fast can people file their taxes.

And so they would go around to retirement communities, all these places, and they just rigorously were like, anything we can do to bring down the time.

And they brought it down from, I think, like 30 minutes to five minutes for these different sections.

And it was just put it in front of people and just see where they get stuck and sit back and shut up.

And that's kind of what it takes, right?

Even a startup like startups I've worked at, you need to spend that time to go and watch real world users using it because generally they'll get stuck on things you didn't think of.

Right.

Like we would always want to show a new feature at this education startup is that we'd want to like go to a classroom every week when the classroom we'd want to show off this new feature.

And nine times out of 10, something else broke or was confusing.

And we're like, oh, we need to focus on that, which we never thought of.

But it's, you know, putting in the time and it can feel like wasted time when you have a long queue of features and bugs.

But ultimately, of course, you know, sitting with users and making like senior people sit with users, not just people who are told what to do.

Make like the product manager, make like the CEO sit there and watch a user struggle through generally kind of clicks whatever you've been, someone's been saying about the UI.

Yeah. Yeah, really understanding what the perspective of the people who are using it is.

Which goes back to my point, like the UI is bad because they don't care about you.

Which I jokingly, but also seriously say to people, it's like, you know, right? A consumer or an enterprise product, you will hunt for that button because there's money involved.

A consumer product, if it's not right there, you won't. So something that's free, the UI is always going to be better than, I don't know, pick a company to rag on into it.

yeah i don't know if it's they don't care about here they they don't have them

they're the programmers don't have the knowledge of your perspective like

whenever there's a long chain of of things in between the end user and the person writing

the code i fear there's a there's a loss of context and understanding around what

what is required what is needed what would make it good

separate from ui sorry i just say i was gonna give your quote to you carlton which is that

separate from ui all production code is just like just barely good enough to work yeah no more

so you've you've interrupted to say what i was exactly going to say is that you know

the budget often isn't there for the developer to spend time building the ui at all you know

we got the database working and we got it so we got to form up the form just about takes the data

the unit test passed oh can i actually make the form nice no no no move on another product

and that kind of really bare bones development environment is quite frequent i think yeah the

focus is often on we need this to do this and if it can do that task then right it's the spec

yeah it's the spec sign it off you know next project we have clients you have budgets i mean

and then deadlines and we do the best we can i think people are doing the best they can in

this situation they're at right well um we're almost out of time is there anything else we

haven't asked you about or that you want to bring up while while you're on any other interests or

projects or i think so so carlton and i doing this podcast regularly we know each other's saying so

that's why it's now it's sort of a game to like interrupt each other with those like i kind of

know with each other i know what he's gonna say you can probably guess what i'm gonna mutter

so it's like like bingo between us to keep it interesting carlton right

you're just like teasing me because i repeat myself well so do i so do i well you know what

it is it's because i have to edit these so i have to listen to them all two three x than you so i

think that's why okay i'm like oh yeah anyways well karen thank you so much for taking the time

to come on i'm really wanted to have you have you on for a while massively interesting and i'd just

love to chat to you and hear your story and you know again thanks for everything you've done for

Django and thank you for you writing that book all that time ago because as I say it really did

make a massive difference to me and you know I've still got it on the shelf yeah I think there are

I think it still has I think one of your questions was uh you know what's still true and what's

different I mean the specifics and the details the error message may be different but uh I think it

tried to focus on doing things in small steps and validating what you got and understanding when

like i think one of them is breaking things on purpose like understand what it's going to do

when things don't work you know so you can understand what it's saying when things don't

work and you don't know why it doesn't work like none of the happy path uh coding well you can do

the happy path coding but then also like make it fail on purpose and make sure that that it's

showing you the right you understand what it says when it's breaking you know what it means um

so i think there's still stuff in there that's valid no i don't know how it still stands out it

is to the the only two chapters which don't like that sort of dated with the doc test chapter and

then the um the interface testing one because i think you used a different flamework than selenium

and selenium became much bigger afterwards so that but the underlying principles there still

account but the rest of it is still kind of basically up to date you know it's one of the

amazing things about django is you know you've got a whole project you fire up and you know you

had an on cascade delete to your models and it just sort of runs and the same with your book is

you know like you you explain the um the debugging page like the you know the chat and that's still

exactly the same that's you know it's hardly changed in and people people come in to django

and don't know don't understand all of what you can get out of that page like there's there's a

tendency to see the top and say like okay it's broken and hardly even read the error message

and just go back to the code and i was like you can actually dig in here and see why it's broken

and that can that can make things a lot better in fixing whatever the underlying problem is like you

don't have to go back to the code and just like no it's broken somewhere you can see it's broken

specific place because of these values and variables and stuff yeah but inside that

discussion you also taught about reading a stack trace and you know and things like that and it's

like this it's just gold dust to be honest it's such a good book um and it's really stood the

test of time so i can keep flushing about it forever i love it hopefully are we gonna ever

get back into, like, in-person

conferences? Oh, I hope

so. I hope so. I mean, I was thinking

the other day, like, I really miss DjangoCon.

You know, I just

had this moment. I'm not a social person,

but I miss having

get-togethers of people

to talk about random things

of interest.

It will come. It will come.

We just have to hold on until it does.

Well, Karen, thank you again.

We are at DjangoChat.com,

ChatDjango on Twitter.

and we'll see everyone next time bye-bye thanks join us next time bye