Transcript: Kenneth Love

Hello, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.

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

Hi, Will.

This week, we have a very special guest, Kenneth Love. Hi, Kenneth.

Hi, I'm glad to be here.

Yeah, we're thrilled to have you on. You're on the short list of people I wanted to

have on the podcast when we were thinking about it way back when.

uh perhaps you you could tell the folks out there uh who are you and why are you such a big name in

the django world um i will i can definitely or i can do it for you if you want uh i'll give it a

try and then you can fill in anything you think i missed 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 uh i'm an open source contributor uh i speak at conferences a lot uh or did um i was chair of

jango con us for 2018 which was really fun um and uh i uh what else oh i used to 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 Mathes, 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. A lot of people have read that one.

Let's start off with something. So I think I first came across you 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 Django things and then rolling that in I think that might

be interesting for folks to understand how new features are rolled into Django itself sure 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.

So a lot of people really kind of hated class-based views. I gave a talk at DjangoCon about them

because I thought they were awesome and nifty and tried to get people excited about them. People

seemed to like them. And around that same time, my friend Chris Jones and I were working as

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

And so we just started writing mixins for the class-based views to make them easier for us to use in our job, like in our day-to-day work.

And that's what became Django Braces.

The name's a joke on a couple of different levels.

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

But it's just called Braces.

And so it's a whole bunch of mixins 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, that they pass some arbitrary test.

And then we got a bit further in making it to where you could use class attributes to specify the fields used for a select-related or a prefect-related.

So just stuff like that to make class-based views just nicer to use, to where you don't have to write all that stuff yourself constantly.

Back in the day, this was one of my main packages.

Whenever I started a Django project, it was install Django, install Django braces, install – there was another one I used called model utils.

And these were like – it was phenomenal.

So I have to say thank you retrospectively.

You're very welcome.

I used it many times.

Well, so – and actually, I don't know this.

I could look it up.

But how were they brought into Django itself?

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

Because I know login-required mixin, I mean, most of these are now part of Django itself.

Yeah, the ones that deal with authentication.

So, like, the authentication-required or login-required superuser and group, I think, are all added in.

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

I think it's access mixin.

Yeah, that rings a bell.

Basically, it's the one that just controls access.

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 classmates views themselves

had gotten enough steam that people were really invested in using them uh and some i cannot

i remember the name i i can i will put the commit into the show notes if i can find it okay um

somebody was working on effectively django braces for django as an actual patch to django

um and there was a lot of back and forth like dev chatter um and uh oh man you're gonna see

how bad my memory is for people's names mark something he was a core committer probably

still is mark tamlin anyway tamlin yeah i think so he did the postgres postgres country postgres

stuff later on i think it was him okay i think it was him i don't remember certain 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 jingle 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 racing this but a couple of conditions in it to where you couldn't necessarily override things

cleanly in like multiple steps or multiple places mainly around like the uh access or

it's not access the um django has a thing that's user passes test yeah which is built into the old

login required and it's a class-based view or mix in now 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 built it and you'll have to forgive me this is five four or 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 you 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 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 but that's a great story because like very often a user will

come to django developers and i say i've got an idea for a feature and um this happens on django

it also happens on rest framework a lot um but it's like people 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 that

third-party package gets take up well then we can look at bringing it into call 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

can get worked out and ironed up and then we can really see you know is this useful and that and

then it can be brought in so this happened with south i guess most sort of famously the migrations

framework that that became jangles migrations i mean you know with a rewrite yeah yeah there's not

the underlying code there's a huge difference between south and jangles right but lessons

were drastically improved but the idea is exactly the same like it doesn't do much that's special

compared to south uh so i know these days you're working for o'reilly right on their platform um

and i saw i think you tweeted about this a while back that you had one of the projects you've done

is new onboarding. I was curious, that's 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.

Yeah. So I joined O'Reilly just about two years ago. And I feel like my onboarding was pretty

typical for a lot of tech companies 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 going to 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 going to 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'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 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 kind of sort of 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 yeah but those little tasks they're really

important because you've got to you want to be actually touch the code base but without really

touching it right yeah i can go fix docs all day long i can improve code test coverage all day long

without worrying that i'm going to 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 yeah you still have to get your development environment running and

all of those things which right and not only do you have to get your development environment

running and at this time we were still somewhat messy on that you have to get multiple development

environments running because you have to have each project set up right we're doing microservices

You've got right permissions to run

You get it permissions. You've got to get you know, everything talking to each other in docker like all of that and often

That's a big mess

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

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've got to 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 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 really good that sounds you know yeah that stuff's really important 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's like a good witness test so like i would i had a routine because we

hiring at the time. And I would swing by before work, the Apple store, get my corporate card,

corporate account, get the laptop, run all these commands, get them set up, poke someone on the

shoulder to get permissions. And even, yeah, even that was sort of the goal. And it just really

helps with, we always thought it was, you only have someone feel comfortable they're going to

be there for the first three months. So you're still kind of selling them. I mean, this is San

Francisco this 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 sure 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 going to work on

yeah and i mean it we i didn't do this part at all 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 did it make you feel more comfortable whatever 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

it's probably true i believe because i haven't heard of many people doing that

um but they also all 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 you lose that

shyness you have at the beginning of a new job you lose that awkwardness that's there right um

so because you're you've already talked to all these people you've already met a bunch of these

people yeah you've been there a month yeah and you've been there a month without having to do

anything that's like super stressful and if you you know 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 that sounds good can i ask you so

is the o'reilly platform is that largely built on django a bit built on django not built on django

at all um so what are you allowed to say it used to be called safari yeah uh so by by the o'reilly

platform just for anybody who's not familiar with it because it's a little pricey um it's basically

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

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 sequel we have some stuff that's in ruby

some stuff that's in go but yeah like anything big almost everything you touch

yeah almost everything you touch is is python python and javascript yeah can i ask what

version of python you're on um almost everything is on 3.7 yay oh wow good for you all we do still

have a couple of things that are on 2.7 right well just because uh we just did an interview

with actually the folks at um edX uh just speaking of the education platforms and and more generally

here at Django Boston there are some talks on you know migrating from two to three because

2020 is approaching and there's you got about three months there's gonna be I think January

and February there's gonna be a lot of renewed interest in this yeah there's gonna be a lot of

panic um we have 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 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 wow 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 engineers have to do, any like, you know,

one of them per project, they go in, they basically run a Docker compose build pull to pull down the

newest version of the chassis image. They run like a region, 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 right but assuming their application code is compatible right there's that

one little there well yeah they have to run tests and all that stuff 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've actually had more we've had more things fail with pi test

upgrades than we have django upgrades yeah i mean there you go there you go well no but pi test have

been quite aggressive in breaking stuff so all for the progress but yeah you know no all of us you

know yeah no shade toward them at all but like you will get a point release of pi test 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 but like we've had um builds on say django crispy form

django crispy forms is mature as you want and stable and it could you know there'll be a new

release before before 3.0 and you know it's just ticking away and there's like one release per

major version of django and and like all of a sudden the pl come in and it's broken why pi

test upgraded okay all right let's fix that so yeah yeah yeah i love pi test but sometimes those

updates but that's stupid i was going to say on the django thing if you not if you haven't gone

right down into custom modern fields and using internal apis that aren't really documented that

that upgrade process now is just you know you there's no reason not to keep up as i say every

wake on this yeah yes 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 in the django world and

he uh what was it what was his saying carlton upgrade your yeah fngs so in our head we're

always thinking about that um uh so yeah you should you should upgrade uh so i i also wanted

to ask, so O'Reilly is a teaching platform and you had spent, I think, a couple of years at

Treehouse and maybe some other areas. So I'm wondering, 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, is that something that you see as a back and forth or 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 yeah i it was definitely not necessarily weird but it was

it was very i felt very new going back to being an engineer i spent about three and a half years

at treehouse 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'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 it feels like toy apps for forever and everything is

clean because you control everything and there's nothing uh it feels like it's not real to worry

about yeah it doesn't feel real yeah 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

right a teaching teaching first yeah idea with the code yeah yeah so going back to dev where

it's messy and real yeah i felt very new to 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 um

but it's also nice in a way that you can also just focus on one area and go deep because you

have to because it's blocking something I mean that's you know I feel like I miss 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 but you've you're further along on

this journey than I am so yeah I mean it's also been strange because like being back at O'Reilly

being back as an engineer I'm obviously doing more engineering but being you know older and

uh ideally wiser 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 if i have my choice between teaching and

programming i'm going to 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 it 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 right which is a weird thing for a

lot of younger programmers because you kind of get taught that like well you should be eating and

sleeping and breathing code like all day long 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 you can date a programmer right yeah well um we'll link in the show notes um

carlton actually we've carlton i first connected because he gave a talk i think just last year at

jingles on europe year before um it was in heidelberg 2017 okay anyways on being you know

programmer of a certain age 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 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 has worn off you you you kind of understand how hard things are to do and

you sort of 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 probably in that boat a little bit too.

You know, if I was gonna write just code eight hours a day,

I don't know, you know, it's not quite, 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,

think it's extremely common and just people don't really talk about it but you know if 5 10 15 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 even from an engineering point of view it's not it's not just code it's about the design

of the software that you're building and it's about it making sure that it meets the actual

needs that really are rather than something you came up with in your head and like a junior yeah

brilliant stick them at the keyboard get them banging it out but more experienced engineers

are there in meetings designing the software and coming up with coming up with how it's going to

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 well i think it's the burden of knowledge

in a way because when you're starting out or you're newer you just fix what's in front of you

and you don't even know about these larger concerns where you know that's why i love you know i'm sure

you've had this you know with beginners 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 how painful

it's going to be all these third-party apis they're so excited but like that's great like i'm just i've

got scar tissue around it. Right. So 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 going to 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.

Yeah, it's been an interesting thing. 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 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 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 first rough pass-through version but when you want

to build something that's like uh you know a sass product or 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 yeah they're like driving

a car at night with head beams and you know yeah it's exciting stay on the road but um so i yeah

and i i wonder how much of that is is it an attitude shift or is it just a knowledge thing

where it just doesn't even it doesn't even occur to them to ask these questions what it's what

could possibly go wrong what could possibly go wrong i'm just writing software this is logic

yeah good at logic puzzles yeah what could possibly go wrong oh my as you fall off the

cliff right well yeah and then like everybody who's been doing it a while has been on these

projects which have just yeah exploded but they didn't know that before they were like yeah we're

gonna build this thing and it's gonna be amazing right yeah oh my word yeah you get better at

seeing the everybody the longer you've been doing it 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 right how do we not right why do why

yes then you just sit in silence like a sort of you know enlightened lotus position yeah

why aren't you programming yeah because i'm thinking what are you thinking about all the

horrible things well i mean so you uh you have a newsletter which um we'll link to i have one

episode of the news or one issue of a newsletter you know what it's a oh everyone's gonna right

i watch carlton's talk right he blogs once a year kind of thing it's the same thing for me yeah yeah

yeah yeah yeah exactly exactly way to sell it way to sell well way to sell that newsletter

under promise over delivered right it's a good it's a good issue when it comes you know yeah

well i was i was gonna say though i feel like in many ways i'm the inverse of most developers and

yourself included where i started off not in tech and then i was in business and then i was in

management and i'm sliding backwards into you know developer on teams and now solo developer

um 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 all my yeah yeah well you know i mean we all 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

well code kind of 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're going the opposite track as i've gone because i'm like what are you doing yeah i mean

it's i've been reading as i'm getting more interested in management and actually yesterday

i got it was official i've been promoted to a dev lead team lead nice 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 promotions and promotion i'm in charge of the care and feeding of a group of developers

but i'm not their manager which is important um well well played anyway as i move into this uh

and i read more about it investigate more into it um yeah there really is this kind of dichotomy

kind of thing where it's like you have the the engineers that that want to go into management

like myself and then you have the engineers that are like i would never be caught dead in management

and i know a lot of those like there's tons of those people um right i don't know i don't i

don't know why it's like oh i want to do 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

um i know it exists assuming that's assuming that's the case 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

going to 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. 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 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 solo contributor for a year.

And now they're in management again.

But I almost think that 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 a 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 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 haven't spent 10 years, you know, running sprints.

They're still doing the sausage themselves.

Yeah, I don't know.

I mean, I think there's a lot to be said for the managers that have that, um, recent relevant

experience.

Um, and I, I think there's, I've been reading, um, a book called the manager's path camera.

If it's manager path, manager's path, uh, by, I think it's a Camille Fournier, something

like that.

Uh, it's 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 we can look at let's talk about how like you shouldn't really

be a manager for more than two years 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 the 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 shouldn't

be burning people out like that

it's honestly one of the things I love the best about

O'Reilly we have people that retire

every year at like 30 years of being

at O'Reilly we have engineering

managers 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 what's the vesting schedule

oh well yeah it's probably whatever the vesting schedule is right so because you hit that vet you

hit that cliff and then you're gonna you're gonna go well in startup land i think i heard is something

like it's under two years the average um i think for startups it's like 18 months yeah yeah but

But part of this is even, I have a friend who works at a hospital on the business side.

And part of it is companies don't promote internally.

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 comes back.

And that way he gets bumped up 15% every time.

Otherwise, he'd be stuck at 2% a year.

And same thing with startups. Because 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 for me personally, being a manager, 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. Not soul-sucking, it's just so much work to do. And then when I think of manager, I think of hiring, and that's hard.

I have not had to do hiring yet. Obviously, we've done interviewing things like that, but I haven't done hiring or firing. So I can imagine that that's pretty stressful and a lot to deal with.

uh i can't say though at the moment 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 i also wanted to mention um for listeners so both

you and carlton work out of a home office though i think carlton you're in your home and you're in

a brand new place which last time i spoke with you last fall was clean and now you have

accumulated stuff it's like a dedicated shed there's things everywhere you have a dedicated

place though right yeah um we when we bought our house we it had like a garage attached to it um

and we never really used it we we park our one vehicle outside 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 kind of a mess right now um there's like uh i got a poster on the wall which i don't

think you can see in the current video no we can see there you go there's a poster uh there is a

cut out 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 well i

guess i find it interesting how people get their best work done and it varies for everyone and i

think also again when you've been doing it as long as all three of us have you find out what works

for you and um you know like i mean for myself 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 no but they go to school

right your children go to school um yeah but so and so when they're at school you work 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 12 that's solid that's my time that's my like core you know 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 you don't play starcraft after work no no i don't want to we're just gonna start i want to

spend time with my family angry engineers podcast it's not it's not angry it's just wisdom no but

this is this is you know but this is the thing right 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 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 healthy separation well yeah i'm curious as a manager what you think 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 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 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 i don't really feel like code is the work of

programming code is the artifact of programming the work of programming is thinking that doesn't

require my butt to be in any particular place 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 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 um well maybe

maybe we'll talk about this in a year or two 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 i i think a lot of it comes down to to culture of the companies

because like O'Reilly's been pretty good about this.

Treehouse was really good about this of

if you're gonna be a remote company, it's remote first.

Everything is done remote.

There are no in-office meetings

that don't include a video call of some kind.

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

Conversations happen on Slack

and you pay for Slack so that history persists.

Those kinds of things, 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 going to 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 think

that adds a whole lot to the business working well with remote yeah i think it's hard to not be remote

first i i've known several places that tacked on remote and they all just it was horrible at every

one of them no it never works 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 i'll tee one up so how much python do you need before you dive into django um

you should have uh you should be comfortable with like importing you should you should be

able to 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 so long as you know what like the different basic data types are

and functions are like you kind of 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 carlton it's still you know it's it's amazingly powerful and so because it's powerful

it takes a lot quite a lot of effort to work through 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 yeah 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 yeah 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 sql you just

say i want this thing give it to me and the waiter but also as well with jack that's a great suggestion

actually because with the django orm like the basic filters you can get those without sql but

then there's more expression more um newer features that have come on like uh window functions and

expressions api and the the kind 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 yeah

Well, and you can learn the basics of SQL in a day, certainly a week.

Yeah, a day or two.

Yeah.

There's a PG exercises thing, which is great.

Yeah.

Well, I guess as we go out, what resources do you recommend for learning SQL?

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

It has been quite a while since I've read SQL, since I've learned SQL.

There is...

Sorry, go on.

I was just going to say there's a site I run is a JavaScript implementation, SQLJS.org.

So you can play around without having to worry about loading up a database in SQL, which a lot of times that's the biggest hurdle for folks.

There's other JavaScript emulators, 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.

there's a super site called pg exercises postgresql exercises.com pg exercises.com

which um talks you through you know getting started with postgres and sequel with postgres

and so i recommend that it's good oh good i didn't know about that one no yeah i don't know

that i have any sequel specific ones unfortunately after i go you should learn sequel first but i

there are a lot of like um if you go look a lot of the the like data science oriented um

like boot camps or training sites like um like data camp or data quest things like that a lot

of them often have really good sequel guides as well uh often aimed more at getting data analysis

out of sequel 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.

Oh, and there was an amazing thing as well,

which came up today.

So I've got to check this out,

but there was a detective story

based on a SQLite database.

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

And then Simon Willison's wrapped it up in Dataset

so you can browse Dataset.

I'll find, browse it in, use Dataset,

enter the thing and you solve the crime.

I saw that came through today.

We'll put that in the show notes.

That came out yesterday.

Yeah, that looks amazing.

Sequel, murder mystery, and data set.

Oh, yeah, I saw that.

Oh, what a fantastic idea.

Yeah, let's put that in the show notes

because that looks just awesome.

That is an excellent idea.

Occasionally, Simon has a good idea.

Occasionally, like about four times a day.

Anyway.

Well, Kenneth, thank you so much

for taking the time to come on.

I think it'll be...

I've learned some stuff.

I think it'll 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 yeah i am very glad to be here and to share what i can well thanks for

coming thanks for having me all right we'll see everyone next time bye bye bye