Transcript: Kenneth Love

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

Hi, Carlton.

Hi, Kenneth.

I'm uh glad to be here.

You're on the short list of people I wanted to have on the podcast when we were thinking about it way back when.

So uh perhaps you you could tell the folks out there uh who are you and w why are you such a big name in the Django world.

Um so yeah, I'm I'm Kenneth Love.

Uh I've been involved in the Python and Django worlds for about um about a decade now, I guess.

Quite a while.

Um I'm uh an open source contributor.

Uh I speak at conferences a lot, uh or did.

Um I was chair of DjangoCon US for 2018, which was really fun.

Um and uh I uh what else?

Oh I used to t I used to teach Python online.

A lot of people watched that.

Uh and I've done some technical editing, um, namely uh Python Crash Course by Eric Mathis, which is an amazing book if you haven't read it.

I got to read it a bunch of times.

A lot of people have read that one.

Let's start off with something.

So I think I first came across you um partly from Treehouse, but before that, you had done, I believe, Django Braces, right?

And that has since been I wonder if we could talk about that because that has since been rolled into Django.

So kind of what was that process of coming up with your own uh Django things and then rolling that in?

I think that might be interesting for folks to s understand how uh new features are rolled into Django itself.

Yeah, um so quite a while ago, uh when class-based views first came into Django, so that was I don't know what like 1.4, something like that?

I don't know.

It was a long time ago.

Um they they honestly kind of sucked when they first came in.

They were very difficult to use.

Um It was a great idea.

They were a wonderful game-changing idea, but they were just kind of hard to use.

Um mainly because you had to go and recreate a lot of stuff yourself every time you used them.

Even though they were class-based views, there wasn't a lot of uh really nice features for like using them like there were with the function-based views that have been around for you know five, six years by that time.

Um so a lot of people really kind of hated class-based views.

Uh, I gave a talk at DjangoCon about them because I thought they were awesome and nifty, uh, and tried to get people excited about them.

People seemed to like them.

Uh, and around that same time, uh my friend Chris Jones and I were working uh as contractors.

We were using a lot of class-based views and we were finding a lot of the pain points.

Um and so we just started writing uh mix-ins for the class-based views to make them easier for us to use in our job, like in our our day-to-day work.

Uh, and that's what became Django Braces.

Uh, the name's a joke on a couple of different levels.

It's it got really weird in meta, so like I don't even try to explain it anymore.

But it's just called braces.

Um and so it's a whole bunch of mix-ins that make class-based views easier to use.

So you can make it to where your view requires that the user is authenticated, that they're part of a certain group, that they're a super user, um, that they pass some arbitrary test.

Uh, and then we got a bit further into making it to where like you could use class attributes to specify the fields used for a select related or a prefetch related.

So just stuff like that.

I, you know, whenever I started the Django project, it was install Django, install Django braces, install there was another one I used called model utils, and these are like, you know, these were phenomenal.

Thank you retrospectively, though.

I used it very many times.

Did did you work on that, Kenneth, or did others bring the code in?

Because I know login required mix in.

I mean, most of these are now part of Django itself.

And those are all built on top of a common uh class that's like uh what is it?

I think it's access mix-in is the name of it.

Uh we name things as obviously as we can.

Um so around see, what was it?

I was this was Django Birthday, so that would have been 2015.

Yeah, Django Birthday was like right when it happened.

Uh so around Django Birthday, um braces had gotten enough steam, or class based views themselves had gotten enough steam that people were really invested in using them.

Uh and some I cannot remember the name.

I I I can I will put the commit into the show notes if I can find it.

Okay.

Um and there was a lot of back and forth, like DevChatter, um, and uh oh man, you're gonna see how bad my memory is for people's names.

Mark something, he was uh core committer, probably still is.

Mark Tamlin?

He did the post

Okay.

I think it was him.

I'm sorry.

Whoever it was, I'm terribly sorry I forgot your name.

Anyway, they reached out to me uh and Chris because we had written Django Braces and they went, hey, is this a good approach?

Um and the code they had was was fine, it was good, but there was a couple of race conditions in it to where um, or not race conditions, but a couple of conditions in it to where you couldn't necessarily override things cleanly in like multiple steps uh or multiple places, mainly around like the uh access, or not access, the um Django has a thing that's user passes test.

Yeah.

Um basically the idea is you can pass a lambda to this thing, and if your user object passes that lambda, then the user's considered good.

Uh the way they'd built it, and you'll have to forgive me, this is five, four, five years ago, I don't remember what they wrote.

But the way they wrote it made it to where uh it would prevent having like multiple checks on users passing tests, because the user can only pass one test at a time.

The way they'd written it, you couldn't have multiple tests.

So we were like, why don't you just use what we wrote in Django braces?

Like it's BSD or MIT, it's it's open source, like you can just merge it in.

Just take what you want, and that's basically what they did.

So that's how those three or four mix-ins got into Django.

It was I don't know.

It was basically us just going, here, we did the work, take it, and then they took it.

And um, this happens on Django, it also happens on REST framework a lot.

Um, but it's like say you've got an idea for a feature, it's like, well, great, can you put that in a third-party package?

And then, you know, if that third-party package gets take up, well, then we can look at bringing it into core.

And the great thing about this is it gives you a playground in which to test it, and if there's bugs and issues and they they can get worked out and ironed up, and then we can really see, you know, is this useful?

And that it and then it can be brought in.

So this happened with South, I guess, most sort of famously, the migrations framework that that became Django's migrations.

I mean, you know, with a rewrite.

But the idea is exactly the same.

Like it doesn't do much that's special compared to South.

Um, and I saw I think you tweeted about this a while back that you had one of the projects you'd done is uh new onboarding.

Um I was curious that's that's a that's a uh an important thing that isn't well served in tech in general.

So I was curious kind of what you learned and where that was at, because I know of almost no cases where people say, Oh yeah, my onboarding was a great experience.

You know, you you show up at you show up at the office for we're a remote company uh to a very large degree.

So you show up at the office for uh like a week, and you know, you're gonna meet with your manager, and we have a thing called an onboarding buddy, or had.

Uh, and the idea is like, you know, say I'm getting hired, and Will, you're already established, maybe you're on the team that I'm gonna be joining.

You'd be my onboarding buddy, I'd spend a week basically, you know, connected at the hip to you.

Right.

And uh we'd go to stand-up and you'd show me around all the code, and you know, we'd work on a ticket or two together, and so then I'm like, I'm good to go, right?

And I can join my own team or your team if that's the team I'm joining, whatever my thing is, and I'm ready.

Uh, and that's okay.

It works.

Like we we've all been through something similar to that, and it works okay, but it's not great.

Um, usually, you know, you end up spending two or three days with like HR and IT getting things set up.

In my case, my buddy, and dude's great, like no no uh no shade towards him at all, but I arrived right when like a major fire broke out on the platform, and he spent four out of the five days fighting that, um, because it was in a section that he was working on.

And so while I figured out what was where at O'Reilly and got everything sorted, it wasn't the illuminating educational week that I think everyone had hoped for.

Um so a month or two later, six months later, I don't know, a while later, uh speaking to my manager, and I was like, you know, our onboarding is kind of messy.

Uh I mean, like, so the onboarding buddy thing, that's a really great idea, but that buddy ends up spending half or more of their time working with the new hire instead of doing sprint work, which they were calculated to do a certain amount of sprint work.

Um, and often you as a new hire are on a team that you're not actually going to be part of.

So you spend a lot of time kinda sorta trying to fit in, but you know you're only going to be talking to that team for a week or two.

Um, so you're not able to make like a good like friendships or really get to know a particular person or whatever.

You'll still work with them even if you're not on the team, but it's not, you know, that closeness.

So my idea was like, well, why don't we have a team where all the new hires go to, and they all exist they all live on this team.

We're not taking time away from existing sprint work, and while they're on that team, they're doing tickets from the backlogs of all the other teams.

The stuff that the team wants to do, but never is like never finds time to do, right?

The the little cleanup stuff, the improving test coverage stuff, uh, make the deploy process better, just whatever.

Right, yeah.

I can improve code test coverage all day long without worrying that I'm gonna break something.

But it still shows me the code base and it teaches me how does project A touch project B and both of them feed into project C somehow, right?

Now I get a bigger idea of that picture.

We're doing microservices, you've got permissions projects that run, you've got to get permissions, you've got to get, you know, everything talking to each other in Docker, like all of that.

You're gonna be faster at it the more times you do it, and you're gonna get to do it a whole lot while you're on the onboarding team because that's all you're doing is working on other random projects.

And you have to go talk to those teams and deal with PRs and all that stuff because you gotta make PRs to all of their projects.

Um, and it's worked out as like a really great way for a new engineer to come into O'Reilly.

They're not pressured on time, they're not pressured on points, um, there's no like velocity tracking, there's nothing like that.

It's just here's a bunch of tickets, find one that you find interesting, and I or someone else will help you get in touch with the right people, we'll review the PRs, we'll try to help you get it merged and deployed, whatever we have to do.

Um, we'll work on all of that with you as someone who's dedicated just for onboarding.

You're not taking me away from other work.

I've got nothing to do but help you.

Um and it's worked out really well.

We've had uh 20-ish people go through it.

Uh we we really only use it when we have like a lot of hires.

If it's like we hired one person in the last three months, we don't really bother with it.

But if we've got five new hires coming in, then we spin the team back up and and do onboarding for a month or so.

That sounds you know yeah.

I mean, I'm remembering when I was at Quizlet, we our goal was to have the first day someone was there, they committed code.

So that was sort of like a good witness test.

So like I would I had a routine because we were hiring at the time, and I would swing by before work the Apple store, get my corporate, you know, uh corporate card, corporate account, get the laptop, run all these commands, get them set up, poke someone on the shoulder to get permissions.

Um and even yeah, even that was sort of the the goal and and it just really helps with um we always thought it was you you can only have someone feel comfortable they're gonna be there for the first three week three months, excuse me.

So you're still kind of selling them.

I mean this is San Francisco, this is a number of years back, but so the idea was you know you can't just take them for granted just because they're there and plop them down, like you know, just as small as it sounds, like coming in and being like, what did I do today?

Like, oh I I committed a little bit of code, and this is all pre-docker too, so um a lot harder to do that.

Um But yeah, that sounds great.

Yeah, it's an important thing, and that's also the cultural stuff, right?

It's just like your first reference point, you're so wide-eyed and yeah, um impressionable about the organization you're gonna uh work on.

Um, but HR interviewed everyone that went through the program, the onboarding afterwards, and asked them, like, you know, how how was it?

Was it was it positive?

Was it negative?

And like everyone so far has been really positive about it.

They've they've enjoyed their time that they spent on the onboarding team.

Uh they've often said they haven't had an onboarding like that anywhere else, which I believe, because I haven't heard of many people doing that.

Um, but they also also said that they they ended up being much more comfortable when they got on their final team.

They they felt like they were already good with like how our whole system works together.

And they kind of knew like, okay, if I have a question about this aspect, I go to this Slack channel and ask, or I ping this one person.

And they they weren't, you know, they they you lose that shyness you have at the beginning of a new job, you lose that awkwardness that's there.

Right.

Um, simply because you're you've already talked to all these people, you've already met a bunch of these people.

And you've been there a month without having to do anything that's like super stressful.

And if you, you know, it it's not a one-size-fits-all.

We don't say like everybody stays there for a month or two weeks or whatever.

It's when you feel like you're ready to go, cool.

You can go join your team and and we're good.

Um, so yeah, everybody kind of has their own time on that too.

We we let people be comfortable.

Can I ask, is so is the O'Reilly platform is uh is that largely built on Django, a bit built on Django, not built on Django at all?

Or you're allowed to say.

Yeah.

Uh so by the by the O'Reilly platform, just for anybody who's not familiar with it, because it's a little pricey.

Um it's basically a way for you to come and you can read uh books from O'Reilly and a bunch of other publishers like Pearson and Manning and stuff like that.

Um and then you can also watch conference videos from the O'Reilly conferences, and we do like some live online training, stuff like that.

Uh so that is built.

I don't have an exact number for you, like exactly, but it's 75% or better Python and Django.

Cool.

Um obviously there's a lot of like SQL.

We have some stuff that's in Ruby, some stuff that's in Go, but yeah, like

Python and JavaScript.

Can I ask what version of Python you're on?

Yay.

Well, just because uh we just did an interview with actually the folks at um edX, uh just speaking of the education platforms and uh and more generally here at Django Boston, there's some talks on you know migrating from two to three because 2020 is approaching and uh there's gonna be I think January and February, there's gonna be a lot of renewed interest in this.

Um we have uh a really handy tool that we built internally, we call it the chassis, that is um kind of like cookie cutter on steroids.

Um basically you can you can run a start command and uh tell it what kind of project you have.

It's a Django project, a JavaScript project, or you know, whatever.

Um, and it will set up all of your Docker stuff for you, it will set up all your Kubernetes stuff for you, it will install dependent, like it'll do basically everything.

Um and so because of that, we can push out like, hey everybody, the chassis now has the newest version of Django and Python 3.7 point, whatever, right?

And all that the um engineers have to do, any like you know, one of them per project, they go in, they basically run a uh Docker Compose build pull to pull down the newest version of the chassis image.

They run like a regen, which regenerates their Docker Compose files and Kubernetes files if it needs to be, and they deploy, and that's it.

And now they're on the newest version.

So like it's 10 minutes from us putting out a new version of the chassis to literally every team being.

There's that one little there

by there.

But most of our apps are stock Django and Django REST framework kind of stuff.

They're not super complex or fragile, so most of the time it gets by just fine.

We we've actually had more we've had more things fail with Py test upgrades than we have Django upgrades.

Yeah, I mean Carlton.

So we all for the progress, but no all the you know,

But like you will get a point release of PyTest that has like eight new features and suddenly a fixture doesn't work anymore.

And good luck finding that one in you know less than a couple of minutes.

Django Crispy Form's as mature as you want and stable, and it could you know there'll be a new re release before through before 3.0 and you know it it's just ticking away, and there's like one release per major version of Django, and and like all of a sudden the PR will come in and it's broken.

Why PyTest upgraded?

Okay, all right, let's fix that.

I was gonna say on the Django thing, if you've not if you haven't gone right down into custom modern fields and using internal APIs that aren't really documented, that that that upgrade process now is just you know, you there's no reason not to keep up, as I say, every week on this.

Carl Carlton and I internally channel um David Hennemeyer Hansen came on recently and we talked about this at length, you know, in the Rails world and the Django world.

And he uh what was it what was his saying, Carlton?

upgrade your yeah FS.

Um uh so yeah,

You should always upgrade.

So I'm wondering uh what was it like?

What's it like for you going from you know teaching full-time to engineering?

Is that something because obviously I think about this, um, is that something that you see as a back and forth?

Or um what are your thoughts on that?

Because that's the challenge with teaching this stuff is it changes all the time.

It's not math.

So, you know, every time you spend teaching, in a way you're kind of getting stale and rusty on not working on bleeding edge stuff.

I spent about three and a half years at Treehouse, uh, and I spent about a half a year doing uh corporate training before that.

Okay.

So I had about four years of not really writing code other than as I mean, well, you you've written several books.

You know, you know how it is when you you write code, but it's it's illustrative code, right?

It's it's some small project.

Right.

Yeah, it doesn't feel real.

Yeah.

No matter how complete the thing you build is, it always feels not real because you conceived of the entire thing from beginning to end and you built the entire thing from beginning to end in a process that's replicable and it's like gonna work.

So going back to dev where it's messy and and real, I felt very new to engineering.

Uh I could obviously read and write the code, no problem, but like dealing with the scope of things was often a little strange.

I mean that's you know, I feel like I miss go having to go deep on stuff because I have to maintain all these other things and you know, so it's all trade-offs, but these are some of these trade-offs I hadn't anticipated.

Um, but you've you're further along on this journey than I am.

Um but having done this for so long, I'm starting to find like the things that I like to do, the things I don't like to do, you know.

I if I have my choice between teaching and programming, I'm gonna choose teaching every single time.

Um but as an engineer, that's not a question I really get.

So that's led to like the onboarding group, to um, you know, considering going into management, um trying to do other things to scratch that teaching itch.

Uh but yeah, it's made it to where like going back into the engineering is great.

I've enjoyed writing code again, but I've come to realize it's not the thing I want to do all the time.

Surely you have 18 side projects going on, and you know, what do you mean you're dating someone?

How do you have time for dating?

You should be writing code, like

Well, c um we'll link in the show notes um Carlton actually we've Carlton and I first connected because he gave a talk, I think, just last year at JingoCon Europe

Um it was in Heidelberg.

2017.

Okay.

Um and well, and I I think of that in the context, I'm curious what what you both think, in that there's this idea that in any area of of expertise, somewhere around five years, plus or minus, you've you know, you haven't gotten your 10,000 hours, but you've the newness is worn off.

You you you kind of understand how hard things are to do, and you sort of re need to redefine um why you're doing it, find new reasons to do it.

I I see that a lot with programmers too.

I mean, and I'm I'm probably in that boat a little bit too.

You know, if I was gonna write just code eight hours a day, uh I don't know.

You know, it's not quite a you know, when I was starting out, that was fantastic, do more and more, but now I don't know if it's I'm interested in deeper questions or I see the limits of my own ability, but you know, I think it I think it's extremely common and just people don't really talk about it.

But you know, if five, ten, fifteen years in, I think the things you're interested in have to and do change.

Um and it's not for everyone just to have pure code.

In part because if you work in organizations, you see that code is often not where the problem is.

It's management, it's onboarding, it's all these soft things, but you have to be fair.

And like a junior, yeah, brilliant, stick them at the keyboard, get them banging it out.

But more experienced engineers are there in meeting designing the software and coming up with coming up with how it's gonna work, and that's part that's just as part as just as much of the software crafting process as actually, you know, opening up the editor and writing some code.

Where you know, that's why I I love you know I'm sure you've had this, you know, with beginners, all they'll email me or talk to me and say, Oh, I want to build this thing, and they'll just list all these things, and in my head, I'm just calculating all how painful it's gonna be, all these third-party APIs, and they're so excited.

But like, that's great.

So I I have to balance my knowledge with like, well, maybe it's doable, maybe it's exciting, instead of thinking about, oh god, like how hard it's gonna be.

And that's a little bit, I think, at least I'm kind of at that point where I'm like, yeah, I could do basically anything, but I kind of know how hard a lot of that is, and so it makes it maybe a little bit less exciting than it would be if I didn't know more of how the sausage is made.

Um, I have a couple of fairly junior programmers that I mentor just completely like outside of work, just divorced from anything.

And with one of them especially, um, the idea of like you need to sit down and plan your software before you start building it is like this horrible thorn in their side and this thing that they just cannot deal with doing.

And like they'll do it, obviously, because you know, like it's a good idea, you're supposed to do it, and I, you know, I'm helping them and walking them through it and stuff, but like that idea didn't really enter their mind, right?

Like they gave themselves like a bullet list and then that was kind of it.

And it's like, well, that's cool, that's great for like your script, like your your your first rough pass-through version.

But when you want to build something that's like uh, you know, a SAS product or uh uh some other kind of like thing actually being used by humans for money, you generally have to go a little further than a bullet list.

And so like sitting down with them and thinking through like, okay, how are you how is this part going to work?

How can I get from A to B and still get the thing I want done?

Um was I feel like it was fairly eye-opening for them.

And I mean and for me as well, with the like you're saying, like the junior programmers don't they don't know how the sausage is made.

They don't they're just excited to build something.

They just want to make something.

What could possibly go wrong?

I'm just writing software I'm good at logic puzzles.

Yeah what could possibly go wrong oh my as you fall off the cliff.

Right.

Well and then yeah and then

But they didn't know that before.

They were like yeah we're gonna build this thing and it's gonna be amazing.

Right.

Like in the beginning everything's foggy there's no cliffs there's never been a cliff what's a cliff and then you do it for five ten years and you're like oh my god we are going to die on any step we take

Yeah I'm why aren't you programming?

Yeah you're

and then I was in management and I'm sliding backwards into you know developer on Teams and now solo developer.

So I find this it's interesting to me that you think management might sound interesting.

Let me just say that.

But I think that's because I have all the scar tissue from it where I I see the need then I just go you know sometimes I'm fighting with code and I'm like well at least it's not uh at least it's not beat all my yeah yeah well you know I mean we all have all of us have kids you know I have kids it's like I don't need more work kids to deal with sure uh you know you need parents but um and I guess so it's like anything right like when you have experience doing it you realize how important it is but also how much work it is to do.

Um and it's um and I would say you know and probably this is the teacher in me which you can relate to I mean managing someone and a group to get somewhere is more rewarding than doing it myself but it is harder.

Yeah right like I you can't control people as well as you can control code.

Like that's as I get older I'm like oh code kinda works like there is an answer out there but these real questions are just like who knows like yeah so I guess I'm just I'm just speaking out loud but I um I'm encouraged that you you're going the opposite track as I've gone because I'm like what are you doing?

Congrats I've had like four different names for what this title is so I don't even know how to describe it.

Um basically I'm in

And I know a lot of those like there's tons of those people.

I don't know I don't I don't know why it's like oh I want to do the management.

I think it's just that it's it's much closer to my ideal of being this teachery kind of thing but still working in like corporate America because I can't get a position as just like you're gonna teach stuff to people we've hired.

I know it exists

Yeah well I think I mean just as we were you know we were saying about losing your skills when you're teaching that's the that's the problem with management is you go uh manage for you know sure and then you have to manage and code and then you know in two years you have to go to another job and you're like what are you gonna hire me for?

Engineering manager?

Great okay pass all these coding tests and you're like well I haven't actually coded much in the last two years.

Like yeah yeah yeah but you still need to pass the test.

So there is this like fear that like once you switch over you can't go back.

Um and I don't think that's true because I think you forget how much you actually know but that's definitely the the problem is people become a manager but then also have to do coding and then they're doing two jobs and then they get burned out and I've had friends who were I mean I mean God, they're I worked with them at Quizlet when they were in college and now they're like 27 and managers at Stripe and stuff and they've already gone through this process of being promoted up to managers and then burning out and then going into a new company as an independent uh

solo contributor for a year and now they're in management again.

But I almost think that maybe maybe that's the natural way to do it is to have that flow because when they're managing they're just working crazy hours and when they're developer, you know they can work a lot less and get paid more and it feels better.

So yeah I don't know it's it's not a static thing I guess.

Even for people who I consider to be really good managers.

And that's partly what makes them good managers is that they they haven't spent ten years you know running sprints.

They're they're still doing the sausage themselves.

Um and I I think there's I I've been reading um a book called The Manager's Path can't remember if it's Manager Path or Manager's Path uh by I think it's uh Camille Fournier something like that.

Uh it's a really really good book uh awesome book I've been reading it stupidly slowly um because every once in a while I have time to read.

Um but a really good book so far and she talks about how I think it was her.

It may have been Charity Majors on Twitter.

It's one of those two

And after two years you should go back to being an independent contributor so that you keep your coding chops right you you keep up to date with stuff.

Right.

I don't think that's a bad approach.

I think that makes a lot of sense of having this like management's a thing you do for a few years and then you go back and then maybe you go back to management.

That's cool because you're ideally still a good manager but you're able to dip back in and get that relevant real experience in your company.

I think it also would help if we didn't do tech management like we do tech employment which is badly because we have an industry that burns people out really, really fast and really really hard and those need to be fixed.

We we we shouldn't be burning people out like that.

We have engineering managers and and engineers that have been there for a decade or better.

That's insane in modern tech companies right like what's the longest tenure at you know like Twitter five six years other than you know CEO

So he's worked at this same big place here in Boston for 10 years.

He works two years he leaves and does something else for a year and then comes back and that way he gets bumped up 15% every time.

Otherwise he'd be stuck at two percent a year.

Um and same thing with startups, you know it's and I've 'cause I've managed people and been like, hey we need to pay this person more.

It's like nope don't have money for them so we lose them and then someone else comes in and we can jack that person up.

It's like only when you're hired can you actually get paid what you're worth.

And so aside from the culture just the pay is a problem where most companies don't pay people what they're worth and undervalue how much it costs to lose someone and train someone and you know and for me personally being a manager I mean managing sounds good, but hiring, I did that for two years at Quizlet.

I don't want to do that again.

That's so much work and so soul sucking and um not soul sucking, it's just so much work to do.

And then you um that I think I when I think of manager, I think of hiring.

Um and that's hard.

I I obviously we've done interviewing things like that, but I haven't done uh hiring or firing, so I can imagine that that's pretty stressful and and a lot to deal with.

Um I can't say though at the moment.

I'll I'll come back once I've done some hiring and firing and we'll talk about it then and find out what's up.

But it's like a dedicated shed.

There's things everywhere.

But you have a dedicated place though, right?

Um and we never really used it.

We we park our one vehicle outside, and and the garage was kind of just a junk collection area.

Um and then I've got two kids and we only have three bedrooms, and I was using one bedroom as an office.

That's not enough rooms for people.

Uh so um we converted about three-quarters of our garage into new living space.

So we've got like a laundry area, my wife has an area for crafting, and then I have a dedicated, fairly soundproofed office.

Um, my plan is to use it for filming video courses uh myself, but uh that has not happened at all yet.

Uh so it's just my office.

And yeah, it's it's kind of a mess right now.

Um there's like uh we I got a poster on the wall, which I don't think you can see in the current video.

No, we can see.

There's a poster.

Uh there is a cutout of me on the wall for placement of a camera later.

Uh there's climbing gear, there's board games, there's keyboards, there's just stuff.

It's a mess.

It's a giant mess.

Yeah.

That's a good thing.

And I think also, again, when you've been doing it as long as all three of us have, you sort of find out what works for you.

And um, you know, like I mean, for myself, like I think I've I haven't taken advantage of the flexibility that I have.

So I'm partly like working from home sounds good if I could like take breaks all the time, but um having little kids, they don't respect my boundaries.

Your k your children go to school.

So my kids leave eight o'clock in the morning, so five past eight, I'm at the computer, I'm there till you know, gone twelve.

That's solid, that's my time, that's my like core, you know.

Uh and it's silent, there's nobody here.

And but you know, every hour my computer tells me to stand up, so I go and you know, hang up the washing, put make some bread, you know, have a coffee, whatever.

I've got all that time and all that flexibility, but I've got that solid block of you know really concentrated work, much more so than I ever had the few times I've worked in an office where everyone's like, oh, you know, let's want a coffee, want to chat?

Like, no, I don't want to chat, I want to work.

Why?

Because I want to stop.

Why do I want to work?

Because I want to stop working when the you know time comes and I want to go and live my life.

I don't want to be stuck here till 10 o'clock at night because I messed around the water called.

All right, Carol, we're just gonna start with the code.

You talked about the industry and the way we employ people and the way it kills people, but like we have this culture where they have you know, your remote work's not allowed, and you have to come into this office, and this office is like a um, I want to say a boiler room of stress and you know, and your commitment.

And they're like, you know, why don't you socialize with your work people after work?

No, why don't you go home and socialize with your friends and family, and then when you come to work, you can be at work.

Like, why don't we have that set healthy separation?

I mean, my observation is that from a distance, code is as close as you'll get to being able to tell what work is, because you can just read the commits.

But it's still the case that attitude and butt in seat is the easiest proxy for hard worker, um, even with code, because if you're managing a bunch of people, you can't you you're probably not doing code reviews of all their code, so it's like a s it's just it's just hard to manage people.

I think it's hard to know what someone's actually doing, even with code, from my experience.

I mean I don't know what your thoughts are.

Code is the artifact of programming.

The work of programming is thinking.

That doesn't require my butt to be in any particular place.

It just requires me to think.

Because I mean, like that's that's programming is problem solving, right?

Like that's all it is.

It's it's literally I have these inputs and I need to make that output, how do I do that?

And I connect dots in the middle somewhere, right?

So programming is thinking.

Programming isn't writing code, programming isn't drawing UML diagrams or anything like that.

Programming is thinking, right?

It maybe it's notes on paper, maybe you write down your notes in a text editor, maybe you lather to a friend as a rubber duck, whatever.

You you think.

And eventually you create some sort of artifact which is probably code, but may or may not be.

Maybe it's a Google Doc, maybe it's a README, maybe it's an API blueprint, I don't know, whatever.

Um so like I don't feel like butts need to be in seats for that.

I've I feel like if there's any job that can be 100% remote, it is definitely programming because it requires nothing.

It requires an internet connection on a laptop.

That's basically it, right?

I mean, just from my experience, even managing a small team of a half dozen people, even then it is hard to separate the work from you know these more intrinsic indicators, I would say.

Treehouse was really good about this of um if you're gonna be a remote company, it's remote first.

Everything is done remote.

There are no in-offices, in-office meetings that don't include a video call of some kind.

No notes get taken anywhere but like Google Docs, right?

Um conversations happen on Slack and you pay for Slack so that history persists.

Those kinds of things, you you do everything remote, you do everything async.

Uh, and that way you've built up this trust in your employees and in and them in like their managers or just management in general, that everything is in the open.

They can see what's going on.

They may not have, you know, the latest budget numbers, but they understand that this decision got made, and here's what was made, and here were the arguments and the questions before, and this is what we're gonna do.

Because there's a link to this library, or there's a Google Doc about it, or the code's been written, and they just have to look at a PR.

Um, so I think that I I think that adds a whole lot to the business working well with remote.

Yeah.

Yeah, it never works.

So as a teacher, how do you rec what would you recommend to someone who's new to web development or Django?

What kind of approach would you recommend given that you've taught and you you mentor people now?

Um where to start?

Yeah.

So how much Python do you need before you dive into Django?

You should you should be able to understand how imports work, where the thing is coming from.

Uh I think you should be comfortable with classes, at least that they exist and like the difference between different kinds of attributes and methods.

Um not as much now.

I used to say you need to be able to read regex even if you can't write them.

But with the path stuff that we have now for URLs, it's much less of a problem.

Um And other than that, as long as you know what like the different basic data types are and functions are, like, you kinda don't really need anything else for Django.

Django's Django is large, but Django is fairly simple once you get under the hood.

Um and it's just Python.

There's nothing.

Now that admin has been made fairly sane Python, there's nothing magical inside Django anymore.

Um admin for a long time was the one last magical spot, but I think most of that's gone now, right, Carl?

But you know, if you just if you're just using the admin, I mean, you know, there's a difference between the the surface area where you have to go and look up the options versus digging inside it.

Um, but yeah, I don't I don't think you have to know a huge amount of Python for Django.

I think you can start off pretty simple.

Um I think the one learning thing I have that's weird to a lot of people is I don't think Python or whatever should be the first language you learn.

I think the first programming language you learn should be SQL, because we are used to SQL, right?

You you go to a restaurant and you order something off a menu and you tell the waiter what to bring you, which is exactly how SQL works, as opposed to programming languages where you tell the waiter how to make your meal.

Right.

But then there's more expression, more um newer features that have come on, like uh window functions and the expressions API, and the the kind if if you know how they map down to the underlying SQL, which if you learn SQL from a from a newish book, you will learn all that stuff, then it makes much more sense, and then you can really get the power out of the ORM.

You know, the ORM is super sophisticated, and lots of people aren't getting the full out of it because they don't know the underlying SQL, I guess.

A day or two, yeah.

Because there's a million book books and things, but I don't know if there's that many great ones from my experience.

Um there is sorry, go on.

Um there's other JavaScript emulators, um, but I'll link to that in the show notes.

But if you just want to, you can import a file and you know you can do it just in the browser.

It's good.

Oh good.

You should learn SQL first.

Uh often aimed more at getting data analysis out of SQL than just like querying for records.

But you'll still learn how to query for records because you have to be able to query to get data out.

So I've got to check this out.

But um there was a um a detective story based on a um uh SQLite database.

So you um uh you you have to solve the the crime by querying the database.

And then Simon Willison's uh wrapped it up in date in data sets, so you can browse data set or find browse it, in use dataset, enter the thing, and you s you solve the crime.

I saw that camp through today.

We'll put that in the show notes.

That looks amazing.

Yeah, that looks amazing.

Oh yeah, I saw that.

Um, what a fantastic idea.

Anyway.

I think it'll be I've learned some stuff.

I think it will help others to just hear about what it's like to be an experienced dev, to be a teacher, and and working at a place like O'Reilly that um seems to get a lot of this stuff right.

Well, thanks for coming.

Thanks for having me.

We'll see everyone next time.

Bye bye.

Bye everybody.