Transcript: Practices of the Python Pro - Dane Hillard

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

We'll get to the book, but before that, I've seen you in person give two talks, and maybe you could mention how you got into the Python Django world.

So what's your what's your origin story?

And um sometime into that uh a friend of mine asked me to join him at a hackathon.

Uh, and it was it was a Ruby thing that he was working on.

I think we were trying to develop some arbitrary precision number library.

Um and

Like so did you so you didn't do Python with your undergrad uh programming at all?

Um geez.

Um Wow.

Uh computer engineering, I guess.

So um kind of a mix of of hardware in there too, but um all all kind of focused on embedded applications and things.

Um But you got through it, so now everything is just downhill from there.

Uh I've I've sort of foregone the uh the hardware aspect of things in my career, which I'm okay with.

Um so I I guess after this, after this kind of like realization that maybe there are some fun languages to work with, um I started using Python uh at one of my jobs, maybe my it must have been my last job early on in my last job.

Um and we were doing bioinformatics um work.

So uh data science applications obviously are one thing Python is good at.

Um and around the same time, I guess I was looking for something to rewrite a personal website in for my photography.

Um and I wanted to do something that would help me learn something new rather than just using you know WordPress or something like that.

Uh and so I decided I I heard about this thing called Django.

Uh and so I

what year was this?

Yeah.

Um, either that or time.

Yeah, I didn't

rate that was.

Uh yeah, and so uh you know, since then I've I've picked it up for more things uh and then uh kind of got into my current job by way of Django.

Um at the time they were uh migrating off of kind of a legacy uh CMS, if you will, um and working toward more continuous integration and custom infrastructure on AWS and a lot of that kind of stuff, and uh major part of the the sort of front end of of the website that we build, uh they had started doing in Django.

Is the name of the company?

Like what's that what's the business aspect of that?

Right.

Uh, and that's uh an academic journal archive.

And uh there's also art store that we emerged with a couple of years ago.

Uh kind of the same concept uh for art history studies.

Um, and then they they have a couple of other business areas, all kind of in higher education.

Um but got it.

What does the full stack look like where you can say that Django is the front-end part?

Uh I think that Django for me uh sits very much at the area of concerns uh on most of my projects, I should say, uh, where uh you're you're interested in responding to requests directly from users often.

Uh and and to me that makes it sort of part of the front end.

Uh and at Ithaca, that's especially emphasized because really once a request makes it to Django, we then talk to a variety of further back-end services, typically written in Java, uh, in order to get authentication and metadata about content and all this stuff.

And Django acts kind of as a as a glue to all of that with a specific application toward the JSTOR web front end, right?

Yeah.

How does that glue together?

Um those are those are all dealt with in the back-end services.

So um we use the ORM for some sort of internal back office type things.

Um, but we're really just using the mainly the request handling portion of Django and um the middleware aspects of Django, I suppose.

We have integrated kind of the um the the authentication backend with Django's authentication system as well.

Okay.

Like how how much are you getting into it?

It's been a while since I've got a lot of money.

But you know, for for listeners, so you the sort of quick way is to use abstract user, which brings in abstract base user, but if you want to go way down under um you can use abstract base user, which the further I use Django, the more I'm like, I'll just use abstract base user.

But when I teach it, I just do abstract user because it's it's a lot simpler and you don't have to worry about screwing up as much.

But the eventual code is arguably cleaner, assuming you understand.

But then you're I don't know.

What do you think, Carlton?

Like I don't know.

You know you know my view.

Okay, yeah.

We're not using that.

And you can use that to have email only.

Um but behind the scenes it's still using username uh for admin, and it's sort of like adding two digit numbers onto username.

So you know that's a problem you want to have when you kind of blow through all the you know will-999, all those iterations.

But part of the purist in me goes, well, I don't like that.

I wanna do it all myself.

So, anyways, as an aside, this is the problem, Carlton.

The more I program, the more I become one of those people.

I'm like, I'll just do it

No, but this is where you end up, right?

You you're like, oh, I'm just gonna knock up a website, and then you start building a website builder, and then you start, you know, it just goes on and on.

It's like why even use Django and you know, just yeah.

Sorry.

Authentication though.

I'm trying to think if there's anything else that we also take advantage of.

Are you using a JavaScript library or using the server templates?

Uh we definitely use the templating engine from Django.

Uh so I I guess that's another major aspect that we definitely leverage, right?

Uh and then we also are starting to use some more uh front-end frameworks.

Uh View and React have made their way onto the site in some areas.

Um both of them.

Yeah, both of them.

Yeah.

Um, and I'm actually on the team that is that is working on that.

So we're trying to figure out how we can build uh web components that will be supported in a variety of these frameworks.

Um web components proper, like the the standard that's being worked toward.

Yeah.

You gave a a talk at I think PyOhio on PyTest.

I wanted to ask about testing, and I assume you know it's a large site, you're probably using PyTests, unit tests.

Like what does the testing situation look like?

We kind of moved to PyTest maybe within the last year for sure.

I'm trying to remember how long ago it was exactly, but uh I would highly recommend it to

Yeah, that's hard to explain to a business person, but something like that is like deeply meaningful.

say that PyTest has really boosted our testing productivity for sure.

Um we're also maintaining kind of a variety of packages that are installed in our various applications.

And um, so between PyTest and Tox, uh I think we've really seen a lot of productivity.

We're trying to I guess Tox uh helps us test across uh sort of current and next version of both Django and Python.

Um it's helped us make sure that we're forward-facing.

Well, you can build a Tox environment, run your test suite, when that's passing, you can upgrade.

It's you know, and then you can get 3.8 in.

And it's just it's it's a really nice way of.

We're uh we just migrated to 2.2.

Um, that's fantastic.

So I was happy about that.

That's not common.

Like um updating Django now is incredibly easy, incredibly stable, versus uh you know, before it there was more breaking changes.

And you know it's it's it's a it's a much more mature framework now than it was.

Yeah.

Um I remember maybe putting in two conditions, I think, uh sort of, you know, if if Django 2.2 or higher do this.

Um only only in two or three places that I can think of.

And the rest just sort of like worked in both versions, yeah.

Um so that was that was really enjoyable actually.

Tim again, it's like Tim Tim Graham did so much work to get Django on his stable footing that it's on.

I mean, so you know, again, to go Tim.

Fortunately now we're on 3-1.

Uh yeah, 3-1.

Fortunately, we're on uh 2-2, which will be uh long-term support for some 2022, is it?

It's another two years from now.

So like you could, but like if you've got that TOX environment in place, there's no reason why you couldn't do the little hop sp hop step all the way, you know, 3.3.1 when that comes, and then nine months time you're on three three point two, that you know, as soon as it's out the door.

So what's what does this um CI CD look like for running all these tests?

Yeah.

I think that's by far the most common still at large sites.

Um and it's free, uh, which has its ups and downs.

Yeah.

Just developer time.

Yeah.

Um they do have this Jenkins file approach now.

You can write sort of declarative and procedural stuff in Groovy.

Um and that has been helpful because it's it's much easier to kind of define what you want rather than um fiddling around with their UI menus.

Um we're doing we we have sort of a Kubernetes cluster uh that can spin up Jenkins uh instances and run jobs uh as as we see fit, which is pretty fantastic.

But um sort of managing all of the resourcing and um pooling of workers and nodes and things has been somewhat troublesome.

We're kind of at a at a steady state now.

Yeah, it's difficult.

I think we want to get there.

Um but we uh our apps are containerizable.

Uh right, clearly.

Yeah.

Um yeah, I think we there's mostly kind of uh efficiency things to work out before it would be too helpful in local development.

Um we still haven't made our images small enough to iterate quickly on.

Um because of course Slim has the Psycho PG too, but um yeah, it optimizing your containers is incredibly important.

Yeah.

I I mean I'm I'm not very good at it.

I mean, but I know it's it becomes a big issue fast when it's you know 700 megabytes for Python and on you go.

Yeah gigabytes locally.

Um so we had a couple of libraries specifically that um have no wheel available for Alpine.

I don't I don't think Alpine even does wheels, if I remember correctly, I'm not sure.

Uh but in any event, it you know, we had to incur the cost of building uh like libxml uh or lxml um from scratch.

I mean, yeah, so personally I I just default to Slim these days because it's like yeah, maybe I could use Alpine, but it's yeah.

Yeah, there's gonna have to poke under the covers too much.

So Yeah.

Let's let's talk about so your book.

So you have this fantastic book.

Um I've read it.

How did that come about?

Like, are you crazy?

Uh in my particular case, um sort of the publisher that I that I wrote this book with has someone on staff who reaches out to people doing online blogging and things like that to see if they're interested in.

Have you ever considered writing a book?

And I was like, Well, no, I never never have thought of that.

Uh and I I guess I thought about it for a bit and um it spoke to I think a lot of the goals I had with writing online in the first place.

Um I I like sharing knowledge, I like um, you know having starting conversations.

Um so by putting things out there, you give others a chance to say, well, I handle this problem this way.

You know, you said you approach it this way, but I have this other solution as well.

So opening up those kinds of conversations is really interesting to me.

Um and so in general, I like just putting things out there and seeing um you know if I can help someone or if I can um pull information out of other people uh by way of those conversations, right?

So um, you know, I figured writing a book could be you know another sort of natural way to go about that.

Um and then from there they they have you kind of propose a whole like not just the table of contents or or what the book might contain, but sort of a timeline of how you think you can get that done.

Which is generally

How on earth are you going to come up with the you know?

Right.

Six to eight months.

I think my original proposal was probably something like a year, uh, and I was over that, but not by not by a heck of a lot as far as things go in the in the long term.

Uh maybe a year and three months or something, right?

Um so a lot of that time is really spent uh with your development editor uh going through making sure that you are teaching to the audience that you identified up front, um, as well as uh then each each chapter sort of goes through a technical editing phase.

Uh they check your code, make sure that it runs, make sure that it does what you said it does.

Um and then at the end they also do all of the typical kind of copy editing, language editing.

Um, and then throughout your sort of writing um writing these examples, uh, they have someone do a final check on all those.

Um you're creating figures for the book, so they have people uh kind of re redo those and make them look nice and polished.

Um you just ended a nap.

Yeah.

Um, you know, the the time is one thing, um, you know, your estimate versus how long it takes, but seeing seeing all those things that really go into it uh on the publisher's end was pretty fascinating to me.

Um you said you target that they they do a review to make sure you're targeting the audience, and the the audience for the book is what I think of as advanced beginner, right?

So they know how to program, they've done their first you know few projects, they're you know capable, but then it's how do you move up beyond that to a more sort of high level?

Um and go on, carry on.

Um I think it the book is intended to help folks who are starting to move into those larger projects that may last you know a year, many years, uh, so that they can sort of build in maintainability and um long-term kind of understanding and and uh the ability to collaborate on that code base with others.

So I think even just the first part, just to sort of know the the playing field of choices that you're gonna face in a large project is incredibly helpful to people.

Thank you.

Um a lot of times as a developer, you anyone at any stage in their career, right?

You there's often just things you don't know that you don't know.

Um so it all comes down to exposure.

Um so you know, as someone a few years earlier in your career, if you start thinking about those now, you'll be in really good shape.

Yes.

Because there's I would say there's a lot of options and I don't see any what do you tell people when they say, should I use pip?

Should I use poetry?

Should I use pipem?

Should I use uh you know py env?

How do you answer that question?

Or Docker.

That's what I did in my most recent book.

I was like, we're just gonna Docker everything, so don't worry about it.

Yeah.

It's like what's Docker?

Uh just download this, copy this file, and pray that it works.

Yeah.

Um I'm not sure that it's as comprehensive as maybe I'd like.

If I if I were talking to someone face to face, I think I would go into more detail in some areas or or um suggest maybe a slightly different approach.

And I I think the best approach to me is one where you build off of the basics and really understand what's going on behind the scenes a bit.

Um things like poetry and pipend especially are, you know, they're fantastic in their own right, but they also do abstract a ton of things away from you.

And if and when they break, which some some of them often do, um, it's kind of hard to know how to correct course if you didn't do those underlying things yourself before, right?

Um, so a really good understanding of pip and dependency resolution in general um would be a good thing to do before sort of just letting poetry or pip env do all the work for you, right?

And as you know, we always have this.

Because like JavaScript, you don't have that, for example, great.

Because a lot of people, JavaScript's the first one, and then they hit Python, they're like, uh yeah, that it doesn't make sense to them why they need virtual virus.

I appreciate there is a learning curve to VMv, but you've got to have that.

But I what I find is that the problem is is that beginners have already mucked up their local computer by the time they get to the right answer.

Right.

Right.

They've gone to python.org, they've downloaded a couple tar, you know, this uh what tars or whatever it is, um they've messed up their path, you know, so they've half half downloaded three things, and then when they go in their command line to type Python, what does that even mean?

And so even if like on a Mac, for example, I recommend homebrew because I think I like using homebrew, but they're already their path is already messed up.

And to explain to a beginner what a path is, like I can't um so anyway, so I see I almost I do tell people sometimes like if you can just wipe every like to get an external hard drive, wipe everything truly, and then start from there, but that's a bad place to be in the community.

But that is the reality, like if you ask a normal person face to face to do Python, um, they're gonna struggle.

Yeah.

So it kind of walks through what is a shell, what is a terminal, what are Python virtual environments, uh, what are tools that manage Python virtual environments.

Well, sorry.

I just real you mentioned real Python.

It's like, you know, that's been on my radar for a little while, but recently it's just been blowing it out of the water.

It's just super, it's just so much good content on real Python at the moment.

I really recommend it to whoever.

it's like a super friendly group of people too.

I'm in the like the Slack channel, uh, and they're just constantly like adding new people to, and everyone's you know, welcoming each other.

And it's I if you're thinking about writing and want sort of a a channel other than your own to write on, I would definitely uh look into joining that group because they're great.

I mean, because he he took it over from my um from my friend Michael Herman and I think only two years ago, and um Yeah, it's it's I mean it's amazing that he's able to um the crew um is able to maintain the standard quality because it's quite a lot of work to have contributors and to have a consistent level of quality.

Um but they've been pulling in some of the people I I've seen individually writing fantastic stuff, and I yeah, they've been doing great.

Anyway, real Python.

Um, I we're talking about the the book editorial process.

I think one reason that they're so strong is that they also have a very robust editorial process.

Um so every article it's not like you just write it and then it goes up.

Um, it there's a lot that goes into quality content people can actually learn from.

That's always my question.

I mean, there's no easy answer with I mean, Python stuff is a little bit easier, but web framework stuff, because in two years, you know, Python 3, whatever, is gonna be out.

I wonder how they handle that because that's the like for me, if I think of like, well, maybe I want to run a Django magazine, I don't know the answer to that.

Yeah.

Like that's the one that really trips me up.

Um, they also, you know, anyone on the team who notices an article could use updating, is welcome to to voice it and maybe make the update if you know whoever wrote it isn't around or needs help with it.

Um so yeah, uh stale content is one of the most frustrating uh things as a developer uh today, I would say.

Yeah.

And so it you know it's a limiting factor, but at the same time, you know, yeah, I don't want to read something that's old.

And then and then I think the challenging thing is that if you're a professional, you can kind of you know, 90-95% of it is helpful and you can fill in the gaps, but if you're not at that level, you will get stuck on maybe a minor implementation thing, but you've lost the entire thread.

Yeah.

And so that's kind of the yeah, that's the reality of it.

Um, and I think stale content on the web contributes to that too, because um, you know, for instance, a lot of people don't even know that VNv exists in Python 3 standard library now, right?

Um and it's you know, they're finding content that's like first easy install virtual and wrapper.

Yeah, easy install setup setup was it, setup tools, isn't that the other one?

There's a couple out there.

Yeah.

Yeah, but it's it's gotten better.

Um, but it's still I like I would you know if I put my hat on, I would say the two things that hold Python back are the packaging and then in terms of like how do you share Python and then just installing it.

Because I don't like so I recommend using like mini conda for the Chromebook.

I have a section on that, because in that case, uh Chromebook, the more recent versions, you can go and use the Linux.

Um and I've found that using conda there is by far the easiest.

But I I do see, I mean, for example, um the Django Crash Course, the new a new book by the um uh Daniel and Audrey uh Greenfeld who did two scoops of Django.

They recommend Anaconda from the beginning.

I'm so we're gonna have him on so he can talk about it.

Um it's I guess it makes sense in a data science realm to me, but if it seems I yeah, I don't know enough about it.

Um, because I I had never really tried Anaconda, uh conda, miniconda, any of that stuff.

Um, and I guess the uh another value add that it has, right, is that you can install non-Python things with the same package management system.

Um so you know, it is

well and then interesting.

Basically, you do it within there.

So I've seen students who didn't even really know what a virtual environment was because it was all handled within PyCharm.

Um so they were going through my book and they're like, Well, yeah, we just skipped the virtual environment part.

And I was like, How'd that work out?

They're like, Oh, we're in PyCharm.

And I, you know, asked a couple follow-up questions and was just like, ugh, it's PyCharm.

Um, and you know, maybe that's you know, plenty of professionals use PyCharm as well.

Um, but that was interesting to me because it's that trade-off.

It's like I don't want people to get stuck on installing it and these details, but I also don't want it to just be broken and not work.

Yeah.

Um and yeah, so

Like uh like I was saying earlier, it's often helpful to build from the ground up so you understand the the foundations.

But at the same time, the reason we encapsulate and abstract things is so that you can start at a high level and then eventually work your way down to the details.

If you need to.

It's hard to know which way to go.

It's Babbel, you know, where the where they, you know, you can use any basically any version of JavaScript.

And I know there's been versions sort of like that with Python, though I don't think they're widely used where you just like you know could use everything from 3.8 down.

Um that would be nice.

Certainly in JavaScript, that was a huge I think I'm saying this correctly.

I think Babel is the name of the package because there was that big switch in JavaScript where they like waited 10 years and then nothing happened, and you know, and now it's all kind of like handled in the browser for you, which is also nice.

But again, Python, like you call it just out of interest, you call it the Tower of Babel.

I say Babel.

I say Babel as well.

Because it'd be the Tower of Babel.

But anyway, no, it's just one way

That's fine, it's cool.

Um well, I mean it's specifically with Python, I don't know, I I find it's the the F strings, so 3.6.

Um but you know, beginner, right?

Like nine times out of ten, that the tell that they're on an old version is that the the F strings.

And again, you know, strings, I mean, if we're gonna pick on Python, what there's four different ways to do strings in Python, I think, these days.

I mean, I I well you're the Python pro.

Which one do you like?

Uh I was a big proponent of using dot format.

Um, I think it it seems more readable to me.

Uh, you know, it it lets you specify what data type thing should be, um, which can be helpful.

Um whereas format will work as long as you can turn whatever object it is into a string.

Um and then uh I I mean nowadays I definitely use F strings as much as I as much as I can, but

And it's really it's just so good if what they type just works, right?

And if as soon as we start accelerating the support matrix, so we start saying, well, you know, 3.5 is still, you know, it's still got another year or so to run before it's end of life, but we're gonna drop support early, then we're cutting out those.

And obviously, we can't support 3.4, 3.3, 3.2 forever and ever and ever.

We've got to cut off somewhere.

But I just I don't want to see us leave those people who are picking up a computer that's a few years old and it's just got Python, they just need it to work because if they hit an error, the chances of them getting over it are like really low.

Yeah.

Um, I think that's where that that bootstrapping, if you will, uh that Will's talking about could really start to be helpful if we found a good solution for that.

Yeah.

It is a book-length treatment.

What what are some of the discuss feedback you've gotten from readers about about the book?

Because you cover a lot.

Oh, I didn't realize that, or maybe what's yeah, what's the feedback like?

Um I have Oh yeah, yeah, I have like a chance to make a free um, you know, I like I select a couple of chapters from my book, a couple of chapters from other books um that kind of have a common theme.

Um so I asked people what the most helpful chapters for them were.

Um and a couple of different people said um the chapters about separation of concerns and um flexibility and extensibility were kind of what resonated with them.

Um so earlier in the book there's a chapter about separation of concerns, and then later on there's this chapter about putting that stuff into practice.

Um so I think the reason I see that maybe it maybe why people are saying that one was helpful, the the one about putting it into practice, um, was because a lot of these concepts, especially if you haven't been exposed to them before, can feel very abstract and it's easy to just kind of pontificate about them and say that they're good things to do.

Um but uh it takes a different kind of uh learning to actually apply those things and and to see examples that actually do that in a useful way that you might do that in a real code base.

And then, you know, six months later, 12 months later, eighteen months later, you're doing a bit of code, you think, oh, I could apply that, you know, that idea from Dane's book.

And so uh, you know, each each axis of the spiral is a different concept that you're learning, and you start in the center of the spiral, uh, or maybe on the outside of the spiral and you work your way in.

And so each time you reach that axis, you're like relearning something about that concept, but at sort of a different fidelity, right?

Yeah.

So that the idea is to first introduce the concept and then start to show some examples and then give someone like a project that actually uh they they sort of need to do that thing.

Um, and I I think that's what leads people to use the thing when they need it rather than look for a nail for their hammer, right?

You know.

I mean that's that's I tried to kind of shy away from design patterns too strongly in the book because I think uh when you when you learn just this library of of things at your disposal without necessarily seeing how they can be used in practice, you you tend to try and apply them to every single thing you work on, right?

Um and that's you end up you end up with kind of a mess.

So I can say to you, oh, we're gonna use the decorator pattern here, and you know exactly what I mean, and you know, we're able to fluently communicate about the domain in a way we weren't.

I think um I think I think shared vocabulary is one of the most important parts in a lot of this.

Um and I was talking about a design system earlier that we're building at Ithaca, and that part of part of its value is exactly that same thing, uh uh just applied to sort of visual interfaces, right?

Um you're talking about um a button, and then you're talking about a buy button, and you're talking about specific buttons, and everyone knows in their head the same button that you're referring to, right?

That um that kind of thing is really important, um, especially with software engineers who are sort of you know stereotypically poor communicators or or grumpy people.

Um it's really nice to externalize a lot of that thought and make sure that everyone's on the same page.

Which when I I started off as a book editor before I got into programming, so I sort of assumed that programming, you know, the code has to be perfect, so they're just gonna be flawless typeers, right?

And then I didn't know about lit you know, linters and you know all these things.

And then in practice I see it's like they're even worse than authors, because some authors have terrible grammar, but programmers have just atrocious grammar, broadly speaking.

But it's just self-corrected for them, so it comes out looking pixel perfect.

If you're if well, but you know, it's yeah, it's it's like I'd I I say it's it's basically like Microsoft Word plus Grammarly on steroids, and everyone uses it as a default.

So, anyways.

Aside for for beginners.

Um It's not true.

Including, you know, video conferencing Carlton.

I mess it up every yeah.

So everyone's on Zoom right now, and it's like how many you know Django professionals does it take to do video conferencing?

What's Pylint?

Um it checks a number of PEP 8 things for you, I think.

I've I I can't recall for sure, but um it also finds uh some things that Flake 8 won't catch.

Um I can't think of any examples off the top of my head, but um it finds common things that might be you know dangerous down the road, whether it's you know mutable default arguments or something like that.

Um maybe Flake 8 catches those two, I don't remember.

But uh yeah, so it's it's uh kind of code safety and um code quality tool.

It tries to be objective.

Certainly some measures are always gonna be subjective, but

Or how would you answer that?

I mean, obviously you it'd be nice to say, you know, look at the book I wrote on it, right?

It's like people ask me questions.

I'm like, I already answered this somewhere, I don't know where, like, you go look it up.

But it's nice to have a bullet list response.

Yeah.

Like what are the sort of I mean we mentioned sort of separation of concerns.

Like, how do you prioritize that stack of beyond beginner Python knowledge?

It's a great question.

But um a lot of what I a lot of what I've been learning lately is is because of sort of shared package uh management that I've been doing, and a lot of it comes down to the very as various aspects of the package management lifecycle, um, which are testing and formatting, consistent formatting for um people to have an expectation of what the code's gonna look like wherever they jump in.

I I guess I wouldn't necessarily tell just anyone off the street, right, uh, to to know all the things from my book, because a lot of those really are meant for someone who's advanced on to these larger projects.

Um but separation of concerns I think is something anyone can benefit from, and then testing I think is is pretty important to get into early on.

Um yeah, I don't have I don't have that like I I feel like I need maybe like five or six points on that on that list, uh not coming to my head readily, but

So before this package name Prettier came out a couple years ago, it was just a nightmare, everything looked different.

Um, you know, Python at least, white space does matter.

You it's easier to eye check, look at something, and say, that seems oh that seems okay.

I mean like one one tell I have is like if your function or your functions are super long, I sort of knock some points in my head.

I don't know about you, Carlton, what

do you think?

And if there's a four, I'm like, yeah, I'm sure that's a subroutine, and uh, you know, like but like the thing is though, you don't want to

Yeah, exactly, that kind of thing.

You don't want to break things up too much, right?

Because um then it you've got to go looking for the implementations.

Um whereas if you've if it's all if it's you know only a hundred lines, it's easier to read it in one single function than it is to break it up into sub-routines and Do you see what I'm coming from, right?

Because if it gets if it gets really long and you're you're having to go, well, well, what's this bit doing?

And then you're reasoning about that, well then pull it into a different function and give it a good name, and then it's really understandable.

But there's no hard and fast rules, but don't don't over don't overfactorize, right?

Don't don't have functions that are two lines long.

It's what font you use.

Are you using uh shout out triplicate font?

If you know triplicate font, I give you props.

That's what I use.

I haven't heard of this one.

I use fire code.

I mean triple how condescending can I be?

Sorry.

When I get tired, I get utility goes out.

It's it's dope.

Sorry, what were you gonna say though, Dane?

I think um it's another case of like if you use separation of concerns for every single thing you can think of, uh you do end up at this like litter box of one-line functions or something, right?

Right.

Um so you kind of have to define what a concern really is.

Um and often the granularity of concerns changes depending on you know where you are in the stack, right?

Like um granularity of a Django view, concerns in a Django view are gonna be probably a slightly different size than if you were um you know building a real-time millisecond response time API endpoint or something.

Um I guess those have some overlap, right?

But right.

You can yeah, overfactorize these things.

Whereas I would say like test coverage basically can't do enough

of that.

Is if I'm having if I've got like four or five files open in the editor and I'm having to jump between them and go back and forth to kind of like, oh, what's this?

Oh, I've got to go and look in that file.

And then I go back to where I was, okay, okay, okay, oh, what was this?

And I mean not from another file.

At that point, I'm like, no, this is this is bad code.

Like, because I should, I should, okay, nice encapsulation, it's in one file and I use it from another, but I don't have to go and jump and look at the implementation the whole time.

That's where it it becomes too much like hard work.

It's like you're sweating a brow just to understand the code.

You want things that are working together often to be in the same space.

Yeah.

I knew that was a word for it.

So if anyone wondered about my like inner snob, it's it's totally an outer snob.

But my two favorites, one is by Linus Torvelds.

If you need more than three levels of indentation, you're screwed anyway, and you should fix your program.

It's a very Linus hard love approach.

Um but the one I really like is by Ryan Dahl, who created Node.js, who said the only thing that matters in software is the experience of the user.

And he has a whole blog post on this because you know it's easy to get caught up in the tooling, but at the end of the day, whether the the user is the developer or the you know website, it's the yeah, sometimes you lose track of that.

But I do take that to be true.

Um especially I have a whole post on this, Carlton, I'll share it with you.

There's like eight quotes in there.

Like, let's see.

No, I haven't got ideas.

I've got a blog with nothing on.

Like, that's what I've got.

Like, I try

It goes, I want

Go on, you talk, you talk.

Bad programmers worry about their code, good programmers worry about data structures and their relationships.

You know, show me your methods and I'll be wandering forever.

I can't remember it's a good thing.

But what were you

Yeah.

Yeah.

And you know, you see the personality of the of the you know the person in them too.

Yeah.

There's different ways to come at the same idea.

Um well, so we're we're wrapping up on time here.

I know that we have links, um, we'll put in the show notes, pod Django20, that uh listeners get 40% off the books, which is a pretty nice discount.

So they should use that.

We'll link to your book.

What else would you like to mention?

Is there a way people should get in contact with you?

What what do you have?

I've taken a little bit of a a break, but maybe, maybe someday soon.

Um I'm easy as python on Twitter.

Um, that's probably the sort of best entry point to to get in touch with me.

Um, I made a website for the book recently called thepythonpro.com, which will also be in the in the show notes, I imagine.

And that's probably that's probably it.

I would say we'd do one of those two things.

Well, thank you so much for taking the time to come on.

Um, as I mentioned, I really enjoyed your book.

I think it's one of the best out there on Python.

So glad

No, no, no.

Really good, interesting chat.

Yeah, it was

a pleasure.

See you next time.

Bye.