Transcript: Django LMS - Sheena O'Connell

Hi, welcome to another episode of Django Chat. I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Hello, Will.

And we're very pleased to have Sheena O'Connell join us for this episode. Welcome.

Thanks. Hi, both of you.

Thank you for coming on, Sheena.

We met you at DjangoCon US. You gave a talk about all the work you're doing. Maybe just

is a quick introduction quickly who are you and um what's your involvement with with django right

who are you and why are you here okay cool um so django was my introduction to python which is

kind of cool i um yeah many years ago randomly had a django project given to me and i was like

i could do this and therefore learned the language um the reason i got to django con was that i was

talking about a thing that I built in Django. Basically, what I do for a living is I work for

a non-profit in South Africa. And our main stick has generally been to find high potential young

people who come from underserved communities, but who really have the aptitude as well as the grit

to succeed in a software engineering career or or another career as well so we do all sorts of

different training we do like web development and data science and we do design and you and like

um copywriting and all sorts of different things but um i'm involved in the in the technical side

of things so we we find these high potential people and we effectively hire them and their

job is to learn for a year and then at the end of that year we get them into um like real jobs

somewhere so we get them um placed into different corporates and whatnot um the django part of that

is that we have a custom-built learner management system that's built um primarily with django um

can i can i jump in with it i've got like a whole load of questions about that but um the most the

one that jumps most to me to me is how so okay you you you're identifying what you call high

potential individuals how on earth does one do that what's what does that look like

it's quite a long process so um the first thing we do is we find people who are keen so we advertise

a lot and we do word of mouth things and that sort of thing um and people apply and they do

some aptitude tests online and if somebody does well on the aptitude test it generally means like

either you or someone you know has maybe the aptitude to take the stuff on so that is a

challenge on its own you have a question i do because aptitude tests are sort of famously biased

um in that you like you know take the classic iq test it it turns out that what that that that

tests more than anything is where you schooled in a particular kind of middle class upbringing

and blah blah it doesn't necessarily test any underlying attribute of the candidate but carl

then the question is what's what's the alternative right i mean failed as it is yeah i believe that's

the issue so i'm just wondering like how do you like it's easy to test aptitude for people who

have had all the advantages because you just give them the standard tests do how do you try and work

around that or do you i mean i don't have any answers or questions it's just a question it's

like so that's just one one step in the process um so we use a bunch of different tests and a lot

of it is also just like comprehension like can you read this text and answer simple questions

about it and then there's some like spatial reasoning and some basic stats and things like

that but it's not like um yeah it's not it's not like super hard um from that we take the people

who perform the best and we we invite them to take part in a selection boot camp so that um so back

in the day when we were in in person we used to actually just bus people into jeffy's town in

johannesburg from all over the country and then they'd hang out with us for two weeks and we would

assess their skills in person um but we don't do it do that anymore um now we have a online boot

camp and basically what we do is we we get these um these applicants loaded up onto our

learner management system, and they behave as though they are already recruited into our

program. So they'll have some cards on a Kanban board, and they need to move the things across

the board. And the things that they do during this boot camp are, like we give them some basic

code tutorials to do, and we give them a bunch of cartas to do, which are like, they're not super

hard. And if somebody comes in with coding experience, and they tend to do quite well in

that um we also get them to do some git things so um we we've got like quite a cool git tutorial

and then they they bump their heads on things like merge conflicts and need to figure that out

um and even people who do have some coding experience who are self-taught often haven't

met that before and so the idea is to give them something that they'll have to learn

like while they're with us um and then if people do really well in all of that

then it might still mean that someone they know has the ability to code

and is helping them out.

This happens, unfortunately, quite a lot.

So then after that, we have a test.

So we use a platform called Coderbyte,

which is really nice because you can run lots of tests for very cheap.

And that's, again, just like a Carta thing,

and we can detect certain kinds of plagiarism.

And even then, we're still nervous about letting the wrong people in.

So we have a staff member interview the people who get through to the end.

And it's very hard to cheat on this kind of thing.

So what we'll do is we'll say, like the staff member will write some code that they made up just then and say, what does this do?

Like, what is this going to print?

and tweak the code as the interaction continues

to make sure that the learner kind of grasped

all of the concepts that they demonstrated

during the course of the bootcamp.

And like that final interview is quite a,

like that's the decision point in the end.

But one of the things we try really hard to do

is just add value at every point in the program.

So like as soon as somebody gets into the bootcamp,

We try and make sure that they're learning and growing, even if they don't get into our program.

So if they come to a point where they don't actually understand something, then the staff member will spend some time with them and try and get them to understand.

Be like, oh, you know, that was naughty, that thing you did when you wrote that code or gave us this code that you didn't write yourself.

But let's see if we can get you to understand it.

So if somebody gets caught plagiarizing, we don't throw them out.

We'll say, um, we can, we can generally tell in this interview, like, look, you actually have the potential to pick this up. You just like, please don't do that dumb thing again. Um, and we'll often take those folks and put them into some kind of bridging course and see how they do, um, for a prolonged period of time before bringing them into a full course. Um, and that is, that's the selection process. So it's quite a heavy thing. Yeah.

it sounds like quite like quite a lot of contact for you know to yeah yeah it is for each individual

candidate it is um but it's worth it as well because once we bring somebody into our program

we don't really like we look after them you know so if somebody's struggling we'll help them and

we'll just like keep on piling on staff hours with this person to to lift them up and like

we have a wellness team that'll coach them and all sorts of stuff like that so if we let in the

wrong person it ends up being like very expensive for us um because yes you can't just say like oh

yeah just ignore that person they can fail there by themselves um and it also ends up being quite

unpleasant for the learner if we if we live in the wrong person they signed a contract with us

for a year and then they're just like bashing their head on this thing that's not suitable for

them for a year it's yeah it's like all around unpleasant so yeah we work very very hard to

to find the right people you said in the beginning of your django con talks um you i can't remember

the first thing you said you built you said you build something and then you said you build people

and i was like yes that's that's amazing yeah that's that's the most important thing so we

build tools in order to build people basically yeah yeah we're going to link to the talk and

try not to um have you repeat it but i one of the other things you mentioned speaking of the

wellness was because it's underserved communities you have courses on financial literacy and all

these non-coding things that somebody who as you said you know once they graduate is going to be

the highest paid person probably in their family and trying to set them up for success you know

beyond the screen yeah yeah yeah that's yeah it's quite a big deal we actually don't run those

courses ourselves we have a partner who does it for us and that's just like another online course

that we offer to all of our learners but it is a very very big leverage point i think so um yeah um

if somebody comes from a very poor community in south africa then chances are um they they don't

have the financial literacy to make good decisions with their very first paycheck um and we are we're

not just about getting people jobs we're about you know um setting their lives up for um all sorts of

good things so we want to make sure that they don't make bad decisions as much as possible like

go have some fun with your money but um save up and look after the important stuff yeah i believe

um to your background i believe you you have a computer science degree is that right no i did um

electrical engineering because because i because i was going to ask you you got you got given this

django project this and then you're like right i'm going to learn python was that your first

programming language or were you already coded before so i learned um so i started coding when

i was in schools i learned turbo pascal as my first language uh which was great fun

um and then after that i learned c++ um i don't know if i learned c first or python first

i don't remember but uh yeah python was something that um yeah like once i started coding in it i

just love the language um yeah when i was in university i picked up a lot of um coding jobs

just to eat and get by um and that was my introduction to python was yeah okay well i i

was mentioning that in the context of um you're mentioning things around git and doing all these

tasks i think still most undergrad computer science majors have no experience with any of that right

They don't know how to build a Django site.

They don't know how to use Git.

So in many ways, you're teeing people up to succeed more readily than someone from that formal background just because they're certainly not getting that training at school.

Yeah, they can hit the ground running.

That's always been the goal is to make sure that people, as soon as they get that first job, they're practical and useful.

I think the other thing to think about or the other thing that I think about is if you put a person into a new job and they last the first, like, three months, then they tend to last for a longer, like, a significant amount of time until, you know, something better comes along.

And so I'm like, all right, so what does a person need to know in order to not annoy their coworkers in the first three months?

Yeah, it is a tough one. But you know, when you start working with a junior person and they just bump their head on Git for the first two weeks, you're like, ah, come on. So we just make sure that none of that stuff happens. We take care of all of the things that their employer would need to teach them in the first three months. Or we try to, at least.

it's hard to tick everybody's boxes and and whatnot but um i think we've got a very firm

foundation built yeah so um we'll have links to all this but the so the code is all open source

so it's tilde right which i thought was a nice play on you mentioned your talk you know muzy's

home home um can we talk about the tech stack i mean oh yeah yeah sure we can technical podcast

Yeah, all good.

So did you start from scratch or there was an existing thing?

We had a syllabus already, and that was basically a Hugo static site.

So we had a bunch of markdown files, and that was what we gave our learners to work through.

And that was generally managed in person.

We had spreadsheets, you know, and some, like, random little scripts that managed those spreadsheets.

But a lot of things were handled just in a very hands-on way.

Later on, so when we went remote, I, like, that's really all we had was the syllabus and some random scripts.

And it was in no way sufficient.

So Tilda came out of that.

It wasn't an obvious thing to build initially.

I think probably the hardest thing about building it

was figuring out what we should actually build.

And then once the solution was clear,

it was like, oh, this is obvious.

Let's build a Kanban board.

So yeah, so the tech stack back in this Django

and Django REST framework,

and we use Dramatic for long running requests.

And then on the front end, React and Redux and some Saga stuff and Material UI.

So it's not like out there in any way.

I think like a lot of people have Django and DRF on the back and React on the front.

There are things that I would do differently if I were to start over again.

A lot of it was built in a hell of a hurry.

I think the the core of the the core of

the application, the Django application is this, is the way we think about content. So our content

is basically consumed as a bunch of configuration files for the Django app. So we've got all these

markdown files, and they've got front matter in YAML. And we look at that YAML and think of it as

a like a knowledge graph so you can say in order to get the syllabus done you need to do this

project and this project has that project has a prerequisite and since you're doing this in python

you should do that in python or since you're doing this in javascript you should do that one in

javascript and so you've got these content items we call them and they can come in different flavors

and so from that kind of graph of knowledge we generate people's we generate some kanban boards

that people need to work through um so yeah yeah go on can i ask because this is a fascinating

question for me it's like the um django and relational database they work very well with

the relational model but a lot of the data structures are graph like and there's always

this sort of imp because you can model a graph in python in memory but then how do you write that to

disk now do you like like how can i ask you to explain a bit about how you're handling because

i think it's a good challenge so i don't know if we did it in the most elegant way possible and i

think it is worth revisiting but yeah basically we've got um a table called content item and then

we've got a another table for marking like what is what which content item is a prerequisite of

which other content item and is it like a hard prerequisite or not like is it a strict requirement

or is it a nice to have um and then from those two tables um we and then we have like a like a

curriculum object as well that says like do these content items in a specific order then from that

we generate a kanban board for a learner so we'll say okay cool you've got these cards and then

that's just like a normal that no longer resembles a graph in the same way um so we yeah yeah you've

sort of flattened it you've made it linear yeah yeah yeah um yeah so we don't have to do like

crazy recursive queries except when we're generating a person's board and then once

the board is set up for that person then they just need to move through it um and do you do

can i just do you serialize so you do that calculation once and then serialize it in the

database so each time you just fetch the curriculum as it was generated yeah okay nice because then

we can add extra status information to the the cards that show up on a person's board so you

can say this is when you started the thing this is when you requested a review this is how it

moved around um here's the repo associated with your card um yeah can can i ask a little bit about

your your previous background with django because like we all talk about you're like oh i needed to

spin up this site and you listed a laundry list of technologies and it worked and you know people

who are new are like wait you can you can you know build a twitter clone in a weekend like

so could you could you fill in kind of your the django or web bit that kind of gets you to the

place where you're like, I could build a Kanban board in a couple of weeks, you know, that is

prototype and then scale it? I'm going to try and understand your question. Let me know if I'm going

off on a tangent. Okay. So the question is your, your, your, the web experience, you sort of

mentioned you picked up programming and doing jobs in college. You know, what gets you to the

point where you can not just, you can say, you can just like spin up prototype anything, right?

Because I think after however many years, you know, any basic kind of crud thing, like, yeah, I can do that in Django.

But you have to have done a bunch of stuff before to get to that point.

Yeah, I think.

Does that help with the question?

Yeah, yeah.

So it's sort of like, what experience do you need in order to get to a point where you can solve these sorts of problems?

I guess so.

Yeah.

Like, how many major sites have you built before?

What got you to that point?

Because it differs by person, right?

It's not a linear thing.

Yeah, it is.

My career journey was not linear or intentional in any way.

It was very, very meandering.

I think I learned a bunch of web dev when I did that first Django app,

but I also did some C Sharp stuff once upon a time,

and I've done PHP and some PHP front-end stuff

and a lot of Pyramid work and some Flask work.

And so I've touched a lot of different frameworks for different reasons with different clients.

And so I think the one thing is knowing, like, having an idea of the lay of the land and, like, what kind of tools are out there and the trade-offs between them is a big deal.

So that's, like, I think that's a huge problem on its own worth solving for people because, like, if you don't know which tool to use, then you could just research that for ages.

Then the other thing is knowing almost like the anatomy of a web app to say, okay, what is a back end?

What is a front end?

Like, how do these things talk?

Where does the code actually run?

And how, like, what are the tradeoffs between, like, using a template, like, something that's generated on the back end versus a React app?

so i think knowing that the like how these different things can talk and how to make

decisions about that is also a big deal um and then once you know how to make those major decisions

it's like um you know which technologies you want um you know their major configuration and then

writing the code it's almost like you've already solved the problem a lot of the time and now you

just need to write down the solution yeah um does that but it's really it's no i i mean i'm not i'm

nodding i i concur i just i when i was first learning i i just had no idea what that roadmap

is for people yeah it's so like my talk my talk at django con was about the roadmap being like

kind of here is the yeah the canvas of what you laid out that you need to have some experience

with. And then it's a matter of picking and choosing and y'all figure out the details,

but I kind of know the overarching structure of what I want to do. And, um, I mean, that's great

that you touch so many technologies, you know, cause I do think some people, um, you know,

learn one thing and just stick with it. And then there's a little bit of like, well, I don't want

to do C, I don't want to do C sharp. Like, um, especially as maybe as you get more competent in

a certain set of tools, it's like, why, why would I change? And that's why knock on wood, it's nice

that Python and Django are still here because I'm not like, you know, I play around with new

frameworks because it's fun, but I don't really want to have to go build a Rails site, you know?

Yeah, yeah. I think one thing that's interesting, I think, is that I actually stayed, so after I

started working with Django and went and tried a whole lot of other technologies, I circled back

to it very intentionally for this project because of the fact that I found Django to be a fantastic

teacher when i was learning python um and when i was learning about web dev as well i think one of

the things that has frustrated me about django is the fact that it is so opinionated it means that

like you have to deal with those opinions and if you have your own opinion then that can sometimes

be like like a little tricky um but if you're a new programmer um and you want to learn about web

dev then jumping in with a very opinionated framework is fantastic because then you get

the opinions of all these like you know like really clever people who built the framework

and thought really hard about it and you get to you know walk that well-trodden path and

do something like you can build something effectively without having to make all those

decisions as your first step so yeah so chose it because it's a good teacher partially because like

a lot of the people who I work with are fairly junior so it's like okay cool guys like learn

Django it's going to serve you um so yeah well the flip side of that exact point though is it's

not just that when you're learning it's when you're um the senior and you need to bring on

juniors to have something where they don't have to be able to intuit what went on in your mind

when you were stuck in your ivory tower writing your thing from scratch that's really kind of

helpful yeah yeah here's the Django app oh yeah yeah I know how that works yeah yeah scalable

teams is a big deal yeah um that's awesome well the the fact that like you know carlton i can

look at the code base and very quickly kind of know how it's structured whereas let me pick on

flask right like that's not the case yeah yeah everybody's got their own flavor yeah it makes

that well back in the back in the day homebrew micro framework i broke myself it's like even

Oh, yeah. Forget that. Forget that. Yeah. Yeah. Well, we just interviewed last week, Craig Kirstens of Crunchy Data. And he was, we were quizzing him on kind of Rails and Django because he's a lot of experience with both. And he was making the point that Rails is more opinionated, but Django has more batteries actually under the hood, which I thought was quite nice to, you know, okay, yeah, it's, you know, because Rails is like, whoa, it just works.

But I hadn't really thought about, like, the built-in auth and the actual batteries part is very strong in Django.

You know, sometimes I wish maybe for beginners it had more opinions, actually.

But, you know, the batteries just take for granted.

Whereas every time I touch another framework, I'm like, what, you don't have an admin?

You don't, like, you know, what are you doing here?

Build that by hand?

Yourself?

Yeah.

Yeah.

Do you have a question?

So you got Kubernetes in here. I have to ask about deployment. That's not a small step to go to Kubernetes. So how did you make that decision?

So I had Kubernetes experience before, which was quite helpful. And yeah, like learning it from scratch under pressure might not have been the best situation, but it was useful to know already.

And I also had experience with making use of auto-scaling things like Google App Engine and how that can go terribly wrong if you use it inappropriately because auto-scaling things can become quite expensive.

And so I was like, okay, cool.

App Engine is really, really nice for front-end things, which is why I'm still using it for the front-end of the application.

So the React app is running there.

but um the kubernetes stuff i i wanted control over um yeah i just wanted control over how many

instances of the django app were running and i didn't want to have to like fiddle with a virtual

machine and like a docker composition or um yeah just kubernetes just fits fits in my head a little

bit so you're running on um google cloud platform yeah yeah yeah and so you so you're using the

managed kubernetes service yeah yeah yeah yeah right so that's that's not there's two things

that's different yeah no but there's two things when you run kubernetes like please can you run

my pod yes i can run your pod no problem i'd like four of those pods that's one thing the other thing

is setting up the cluster yeah yeah so i didn't set up the cluster myself yeah which is just like

The madness was like, why are you doing this?

Yeah, I do prefer managed services very much.

This is a managed service stand show here.

Oh, yeah.

Yeah.

One of the other tech cool things you noted in your talk

was the project cards where when someone,

you create a GitHub repo,

automatically protect the main branch.

Can you talk a little about that?

Because that was really cool to me.

how you automate that and awesome um yeah so basically the way our philosophy for teaching

is we want to make professionals and so we want to simulate a professional environment as much

as possible and if you are a developer working on a team of developers on some realistic project

you're not just going to push to the main branch or willy-nilly you're going to push to

a different branch and you're going to make pull requests or merge requests

And so we wanted to get that feel for the learners.

And we also wanted to make use of GitHub's lovely review functionality.

So basically what we have is we've got this Kanban board and different cards on that board behave in different ways.

And there are these cards called repo project cards.

and if a learner like chooses to start one of those then the card will pop across into the next

column but in the background yeah we create a repo for them and we it's a private repo and they are

added to as a collaborator the main branch is protected there's a little bit of a readme added

in there for them and now they get to start contributing code in their own branch then

other learners get to review this so um one thing that coders need to do in life is review each

other's code read code that you didn't write have an opinion on it um give and receive

constructive feedback so once a learner has finished a specific project let's say um i don't

know um i don't know just some project where they have to build a thing and now somebody else is

doing the same project and they have to build the same thing so a password thing right that's

using your example yeah yeah password checker yeah so there's like a little password checker

project um and so if somebody has finished the password checker project then they are allowed

to review other people's password checker projects um and they can be added as reviewers it's sort of

like a random allocation of like who you're going to review um so long as you've done the work and

And then they can merge the pull requests and help people get their cards across the

board.

So that's, yeah, that's pretty fun.

Yeah.

I love the, you know, automating and just getting a learner set up to focus on what

you want instead of all the other cruft that we have to deal with as programmers that isn't,

yeah, isn't primary.

Yeah.

Yeah.

I think there are a couple of extra benefits.

to getting the learners to review each other.

Like one obvious one is that it saves our staff members time.

So it makes our jobs like way, way easier

because we don't have to always say,

you know, point out the obvious stuff.

But from the learner's perspective,

they get that experience of giving, receiving feedback,

which is great, but they also get the experience,

they get the benefit of like spaced repetition

in their learning.

So they have to revisit things that they wrote,

but now it's written in a slightly different way.

And now they have to understand it.

And that's a pretty good way to make sure that they do absorb as many concepts as possible.

So that's, yeah, pretty cool.

I think as well that reading code and understanding code is by far the biggest part of the actual job.

You know, you'd spend some time writing it.

But realistically, if you just spend your entire training period writing code,

and then you get put into a job where you get to write, I got two hours actually doing some code.

So, no, to have to review it, I think that's lovely.

I think it's a really good thing.

Well, that reminds me of the saying that, sorry, Carlton, one last thing.

And then I know I've been talking.

Jeff Triplett, who works at RevSys, often has said that he gets paid to write tests, not code.

Because when he goes, you know, he gets parachuted into a code base that's on fire.

He's like, you know, where the tests are like, let's write better tests.

So, so much of it is, yeah, writing tests at a professional level.

Like actually writing Greenfield new code is quite rare.

And the more senior you get, the less you do that because your time is better spent

reviewing and orchestrating rather than, you know, actually building the thing itself,

which is sort of, you know, in a way it doesn't make sense.

But with experience, you're like, oh, well, that's kind of where the value add is, is

being in that review capacity as opposed to just, even though it's, you know, fun to,

you need to write your own code too sometimes, right?

You can't just only review people's code.

Yeah, yeah.

Something that I often find, something I often end up doing is just swooping in and writing a chunk of code that has almost gaps in it for somebody else to complete.

And that also works pretty well, especially on front-end stuff.

I'll just, I don't know, build some new functionality, but it's like the padding's all wrong and it's a little bit like squonk.

It's like, okay, guys, here are some guardrails.

and that works pretty well as well for onboarding new people yeah that's a nice word squonk

so i had a couple of questions about the pedagogy one is that um i think you say you're adding start

you know start date spend dates you've got this cameraman board that the curriculum

is kind of like that um how do you find that as um helping people on because sometimes i find people

um you know if there isn't a kind of nice structure they kind of just drift away not

meaning to but there's just not the discipline to do that so that would be my first question is

yeah that's that is a big deal momentum so if we were a purely asynchronous remote course without

any like human interaction then i do think we'd have pretty high drop-off rates because that's

that's a normal thing i think coursera has something like a seven percent completion rate

maybe that's generous even i'm not sure um and i think that that's pretty generous yeah so so

from what i've heard yeah it's pretty bad and um there's lots of reasons for it but um i think

one thing so so we've got a whole lot of different things that we do to keep people on track

um the first thing to know is that we are self-paced so um we don't we don't try to make

everybody do the same project at the same time or sit in the same situation at the same time

um but we do um we do have stand-ups every day so we've got um little baby scrum masters we call

them scrumlings um hopefully they run a lot of the stand-ups um and help the learners like plan

out their week um and spot any kinds of problems that might be happening um and so that's the one

like major interaction we have is just like every day people will say like this is what i'm working

on this is where i'm stuck and that kind of thing um but then we'll also keep an eye on their pace

so if it looks like somebody's falling behind like we know on average how long each project

takes and we know how much time we have with people so we can say oh it looks like if you

continue like this you're probably not going to finish in time um so how can we like what can we

do um and sometimes just telling the person like look you've got to pick up the pace is enough

um sometimes they need extra support in different ways um so that's yeah so those are the main

accountability things um we've also got all sorts of different um interventions for different kinds

of different kinds of things so um one so there's all sorts of different pitfalls that junior coders

tend to fall into when they're self-taught um so one thing for example is that um if somebody is

self-taught, they'll often think that print and return are the same thing. And the reason for

that is because of REPLs. Because they learn to code in a REPL and they have a function that

returns a thing and then they run the function and it's like, look, it printed. And so there's

all sorts of little weird things like that that we've noticed. So we'll have mini workshops just

on those concepts. So it's like, all right, cool. We're just going to sit with one staff member and

three learners for 45 minutes and we're just gonna make sure everybody freaking nails the

difference between return and print and then once that's done it actually solves a lot of problems

so so you know it'll be return and print and some other like how functions interact and um just

because you're printing the returned value twice doesn't mean you're calling the function twice and

and like yeah there's all sorts of like weird little pitfalls that people fall into um yeah so

we we aim to like nail those very very early um yeah you have a question that's an important

knowledge as well i think that there's there's just like really understanding how a function

works in terms of what happens when you pass the the the arguments in and are they by reference

or value and you know is it a reference of value type and then what happens if you don't return

anything is it like what what's the return value of a function without you know they're kind of

low-level stuff but actually learning those is really important yeah and while we're teaching

that we're also trying to teach people how to experiment with code and how to assess their own

understanding of things so we always like follow the same sort of process when exploring the stuff

like the staff member will write a little simple piece of code and say hey learners what do you

think this is going to do and they'll each like tell say what they think and you'll write that

down and then you'll run the code and then you'll write some code and then ask them what they think

and then run the code and that's the way we explore the topics and it's like look you can

actually do this yourself we don't actually have to do this for you you can explore like this look

we just made a random change and you took another guest like cool and um the people who click onto

that way of self-assessment um they tend to do really really well and that really fits the python

model of like iterative exploratory yeah yeah yeah yeah so that's um nice yeah um

I had another question, which was just about what you think about this new wave of AI tools that are coming along.

So CodePilot and the chat one that's been out this week that people have been talking about.

I mean, is that a worry for plagiarism and people sort of hacking the course content?

But also, is it a tool that you think is useful for people in their careers?

So I haven't personally used them. It's something that I want to explore. I think for junior coders, it's probably a bit of a danger to get too reliant on them. So one problem that exists that I've noticed, I think it's probably everywhere, but it happens a lot in our education system.

The South African education system is a bit of a mess, really. It's nonsense. And people come out of that system thinking that memorizing and understanding are the same thing. And it's really not.

I think that's pretty universal, unfortunately.

So annoying. And so snapping people out of that is really, really hard. Yeah. And the other thing

that's challenging is things like illusions of competence, where you read the code, you run the

code and you're like, yeah, I could have guessed that. And then you think that you can write the

code, but you can't because you've just stroked your own ego instead of actually assessing your

own ability to do the work. And then there's people who are so focused on moving their cards

to the complete column that they don't necessarily

put in the time to understand everything.

They just want to get things done quickly

so they can look cool.

And so I do worry about people making use

of those kinds of tools while learning

if it just ends up giving them perceptions

of being able to do things that they can't do.

Yeah, that's a big deal.

So, yeah, it's a concern.

And I generally actually tell the learners to not rely on that stuff for their projects.

Like they can play with it and it's cool.

And maybe some kind of co-generating thing will come up with something that they can learn from.

But they shouldn't be reliant on it.

Yeah.

Have you guys used those sorts of tools?

I've played with Copilot or Copilot or whatever it's called.

And I like it for writing boilerplate-y stuff like bootstrapping, unit tests, that kind of thing.

It's awesome.

But when I really want to think, I have to turn it off because I'm like, no, no, no.

Because it's like pair programming with someone who's drunk.

It looks right and it's fine.

And then you realize that it's massively wrong.

And it's like, no, no, no.

If I just tab through there, it would look as if it was right.

And it just isn't.

There's logic errors.

So when you're trying to think, you don't want that distraction. But yeah, if I'm trying to write a unit test and it's the same as the other 40 unit tests in the file and I don't want to have to write out 30 lines of boilerplate, it's super for that. I'm sure they'll improve with time, but I'm just interested in, I think, the points you made about the comprehension and the understanding and that false sense of competence. That's an interesting viewpoint I hadn't considered, so I like that.

Yeah, I would agree with you. I spent quite a while. I don't think I mentioned this before, talking with Simon Wilson at DjangoCon about these AI tools. I mean, specifically that was a Dolly, the image generation, but because he's like, you know, really interested in all that. And then he was with Copilot. He was mentioning that he uses it all the time. And the thing is, you know, he said, you know, half the time it's rubbish and half the time it's correct.

But, you know, it'll return, like, code he wrote because it's, like, pulling from Django, right?

So I think I agree that, like, if you're Simon Willison, like, sure, like, it's just, like, sort of interesting and you, like, immediately pick up on, like, oh, that's wrong.

But for an average person, yeah, it's the—I think it's dangerous, actually.

It's, you know, the drunk programming.

And certainly for a beginner, I think you don't want the crutch.

It's really not helpful.

But it's interesting. I was like, of all the people who don't need this, and he's like, no, no, it's cool. I just always type it in. So I would also advise people to play with it. But yeah, I think there's going to be some tricky things there other than the more mundane tasks.

But yeah, in a couple of years, like maybe the new frameworks will be, you know, there'll be like an AI framework and we'll all be focusing on some other part of the web stack, right?

I mean, probably.

Yeah, yeah.

I can imagine it getting way, way better than it is now.

Yeah, but it is still, I think it'll always be a thing where you should learn your basics, probably.

Yeah, I mean, actually the testing might actually be an area where it's easier to, you know, have it generate stuff.

you can kind of look and see like i don't know anyways i speaking of testing i wanted to ask you

so you use on your stack um drone drone io right for your continuous integration like could you

talk through just the testing or just change but just your testing strategy and how it's changed

over time um so yeah it's it's slightly more chaotic than i'd like it to be um but it is what

of this so um our test coverage on the back end is quite high um like it's like very high um so

that's that's pretty solid um if somebody makes a pull request the tests have to pass

and before we deploy the tests have to pass um we yeah so nothing nothing fancy it's just um

standard unit tests that need to pass at different points um yeah so testing strategy you might be

also referring to like tdd versus not um we're not too fussy about like if you write your tests

first or later or anything like that um so long as the code is properly tested um yeah yeah fair

Fair enough. Yeah, it's a very broad question. With your current stack you're using, Hugo,

I think you've mentioned maybe you would revisit that decision. What do you make of static site

generators like Eleventy and others? What would you use today if you were starting from scratch

with static site generators? So for a long time, I was thinking I should move towards Eleventy

because it's sort of like low level in a way in that it just relies on web components. And

Yeah, it's just like a very elegant little thing.

It's like small and it's very easy to understand and the code is all in JavaScript and I'm

pretty good at JavaScript, so that helps.

So we were using Hugo initially and it seemed like a good idea at the time, but I think

the version that there was at the moment is pretty unstable.

So as soon as we wanted to upgrade it at all, like even by zero

0.01 then it'd be like oh now things are broken and we have to fix them um and that was a little

bit frustrating it's javascript i mean what do you expect oh hugo's in golang which is no oh yeah no

hugo's oh i thought you'd my 11t yeah javascript i'm just gonna get a dig in on javascript it's

totally acceptable like every time i have to write significant javascript i have to go take a shower

afterwards it's a messy language but but it's also um yeah it's also solid in a lot of ways

um so i've done some playing with eleventy and it seems very very capable and very um

yeah like easy to extend in different ways which is really cool like hugo

like i hardly ever write go code like practically never and so if i want to do anything interesting

then it's a bit of a mission, and so interesting things don't happen.

Whereas with 11T, it would be much, much easier.

I'm actually also thinking about Next,

because you can also do static site generation with Next,

and it's got the full power of React.

So it's heavier again, but it's also,

you can do all sorts of cool things with it, so that's an option.

Because it would be nice for the contents itself

to be a bit more interactive.

So right now we've just got markdown files.

It comes out as text with some pictures and some videos and things like that.

But maybe it would be cool to have a little quizzy thing or some interactive content.

So I think maybe Next would be better for that sort of thing.

So it is going to change at some point, but it's not like the highest priority thing on the list right now.

It's difficult as well because these framework decisions, they come with a lot of overhead in terms of each time you switch.

So you've got to choose carefully, you know.

When you do go, you've got to say, okay, we can commit to this for a period of time.

Yeah, yeah.

Yeah, we chose Hugo like years and years and years ago.

And at the time, from what I knew at the time, it seemed like a good idea.

It seemed like the best bet.

But yeah, there's different things now and things that seem more appropriate now.

that point about not not using go very often it's like whenever you've got like multiple

texts in the stack it's like the one on the edge where you don't use it very often every time you

go back to it i've got to remember all that and you say the the velocity is just so slow yeah

yeah and it's got like that mental hurdle that you're like okay getting into it you've got to

block out a week yeah yeah um but that's one of the benefits of next because it's just react

well it's react with other bells and whistles and our front ends react so it's not like super

different it's not like a whole other thing um so that's that's cool gatsby is also available

but i think react i think next is maybe nicer yeah right if we want to get yeah i haven't used

next seems like a mindshare next seems to have the mindshare at the moment it seems to be you know

it's always a it's always an up and down thing with javascript worlds but like you know that

your Hugo story is bringing back memories because six years ago when I was at a startup, we had

someone had started and I had to gin up the blog using Hugo. And it was exactly like that. It was

like, oh, this is fast and it's cool. But anytime I had to do anything, I was just like, oh God,

I don't really want to be an expert in another language. Which maybe it's not the worst thing

because you just sort of leave it alone and just post content. But it's nice to stick to Python,

javascript if you can just because one less thing to worry about but anyways yeah i agree it's yeah

i don't think it's quite the hotness that it was um pandas you're are you using pandas in the

project in some way like so it is being used not by me personally um but basically we've got another

repo off to the side um that our data folk um deal with and it's got a tilde client api thingy in

there um that they can fetch data from tilde and put it into a data frame and do what they need to

from that um so from that we do things like figure out how long different cards are meant to take

and spot different kinds of outliers and spot different kinds of problems um yeah so so there's

a bunch of random things happening there or like syncing data from Tilda into things like Airtable

because a lot of our non-technical staff live on Airtable. And so we get data dumps and put it into

Airtable and then they can wrangle it how they want to and make reports and send emails to

partners and things like that. So yeah, Pandas is handy for all of that kind of thing.

Do you, is it one cohort goes through over a year and then you have another one each time?

Is it like that as opposed to continuous?

So everything's pretty overlapping.

We generally take in a cohort every couple of months.

And it's nice because of the fact that they review each other.

So there's overlap and one cohort will be a little bit more senior to the next cohort

and they'll be able to help out.

We even have things called JTLs, which are junior tech leads.

So we'll generally take like a more advanced learner and then get them to sit in the standups

of a more junior cohort so that they can like have an opinion on things. And that also works

quite nicely. So yeah, that overlap is really handy. If or when is there time for the team to

go, okay, a cohort's graduated, let's revisit and potentially change things. It sounds like

that has to be more continuous too, because you're just constantly having people go through. So

So maybe, I guess it'd always be nice to have a month to think about things, but it's not a real-world situation.

Yes, that's what holidays are for.

So a funny thing is that I actually work with my brother.

So he started off volunteering at Amuzi, and then I was like, I want to hire my brother.

Will it be dodgy?

And they're like, yeah, it'll be dodgy, but we like him.

You should hire your brother.

And then my boss hired my brother, which is better.

But he's great.

He works freaking hard, and he's not a techie.

He's more like a management type of person,

so we're actually quite a good team in that way.

Now he doesn't work in – it's complicated,

but a lot of major decisions were made in random caves

in the Drakensberg because we're away from work,

having a nice hike, sitting in a cave somewhere.

We're like, oh, I just thought of something.

So, yeah, sometimes getting away from the daily grind

is yeah critical it helps a lot um but yeah other than that reflection happens yeah reflection is

just a constant thing yeah right it's like a active equilibrium as opposed to a you know

going off to a monastery or something yeah um so speaking of external things i i did see from

your cv that um you've i guess not not as much now but you had done brazilian jiu-jitsu at quite

a high level for a while. My daughter has recently gotten really into it. And that seems like the

kind of thing people, once they get to it, they don't usually step away, especially if they're

as accomplished as you were. So I'm just curious, what was that like? Because it seems like a

natural fit for a programming mind, right? You're solving problems. And that's for my daughter,

who's 10, she likes the intellectual aspect of it, as opposed to just run harder or, you know,

The fact that it's solvable fits her mind quite well.

Yeah, it's super cool.

Yeah, it's a puzzle.

And I love how many subtleties the different moves have and the little tweaks that you can make to things to make them more effective.

Yeah, you can really geek out about BJJ for ages.

It's super cool.

Yeah, so I started it randomly.

So I've always been a climber, and I wanted to do something else besides climbing.

And this mixed martial arts gym opened up near my place.

And I was like, let me go see what that's about.

And BJJ was part of what they taught and it just stuck.

So I ended up getting like seriously into it.

I've competed internationally.

I am, so I'm the world runner up at Blue Belt, which was.

Yeah.

I mean, like not, not a small thing.

Yeah, it was a mission.

Yeah, it was hard work.

Yeah, so that was, so at the time when I was training for that,

I was working for a fintech and it was just a very, very intense time.

So I was like, wake up, like go for a run or something, go to work,

work like freaking hard, then go train, you know.

So it was just like, that was all that was happening.

And go choke a couple people out and go to sleep, right?

Yeah, but it was very, very nonstop.

And then afterwards, I needed a break.

I was just like, okay, I just need to step away from this for a moment

because I've been too completely obsessed.

And then my gym closed and my very favorite coach moved to Germany.

And I haven't found another home gym that quite fits my personality, I suppose.

I'm actually thinking very seriously about getting back into it next year because my original first room ever is nearby and I just haven't been able to get back into it.

I haven't been able to build up the habit again.

I don't know my own head sometimes.

I really loved it for a really long time, but I haven't managed to refine the love for it in the same way.

I think when you're so committed, you need a full reset to kind of enjoy it for itself as opposed to, I mean, I'm thinking of something in my life, like to get the competitive part out of it and rediscover the primal part because it's hard not to just switch the mode into like, I need to be good and do all these things.

And then it kind of leads to the things that led you to go away in the first place as opposed to the initial interest.

Yeah, yeah. That is a big deal. Just to bring it back to that playful way it used to be. It would be nice. I think it was also, I don't know, my coach was fantastic. I find that I can push myself incredibly, incredibly hard if I'm like involved. Like if there's, I don't know, if there's somebody on my team that's also doing that.

when i got my medal i tried to give it to my coach but he didn't want it

which was a bit of a um yeah it was a bit weird but

yeah he's such a great guy um gosh yeah it's super cool that your daughter's

into it yeah no i mean i think the habit the

habit the point about habit is that if once

you drop the habit it's really hard to pick it back up it's

like it's you know you miss one and then oh dear it's really easy then to miss

the next one and then but to be in that routine of like no this is what i do this is what i am i

i am a jujitsu i am a tai chi or i am a you know this i know you're looking at me carlton i'm just

a parent yeah i was gonna say what i yeah no i had well i bring i have to bring my um my two-year-old

son and he's watching the you know the the sessions and he's he asked me the other day he's

like he's like daddy you exercise and i was like you know no i pay money and watch other people

exercise with at this stage of life so but he was like he's like you do that i was like no no

but now he now he wants to you know he wants to do everything they do so he's

you know yeah anyways yeah it's a it's a good it seems like a good activity so i'm pleased my

my daughter's into it and then i just okay world runner-up like oh like yeah no that's super yeah

that's pretty impressive um are there any any things you want to as we wrap up any things you

want to promote or things people can do to help moosey or publicize um nothing offhand actually

that i can think of um yeah yeah i think uh i think that's fair enough i mean yeah go on if

you've got something else to say i was just gonna say thank you to sheena for coming on because

i've really enjoyed the chat and but if you've got something else i say thank you and i i was

i was gonna say i was um thank you for coming to django con like you know the fact this is why

these communities exist that and then you were around for some of the sprints as well i mean

i think for all of us i think i don't know if i had you been to a django con before or a us one

no that was my very very first um yeah it was a very good experience the django community it was

just lovely yeah um oh actually it's a big you know time and money thing to go so yeah yeah it is

yeah it was it was a bit of a pricey place america um but it was totally worthwhile i'm

i'm happy that i went um made some new friends went on some adventures so yeah very very worthwhile

um django con africa is happening next year and that's going to be cool so um we've just started

organizing it and there hasn't been one yet um so i think it's probably going to be in around

november next year not sure which country yet um but stay tuned it should be cool yes it was going

to be before the pandemic and then and then yeah and then and then the pandemic yeah yeah that's

really exciting all right well again thank you for thank you for coming for coming on we're

going to have links to everything in the show notes so everyone should check think check it

all out um uh we are at jango chat.com chat jango on twitter i guess if that's still around are we

on are we on the are we on the freddy version yeah yeah we are we well i guess i don't know

we'll find out we may or may not be on the very verse as well folks we will be we will be i'm

i'm personally done with twitter so uh we're gonna move over there so uh okay anyways jango

chat.com. Thanks everyone. See you next time.