Transcript: Django LMS - Sheena O'Connell

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome.

Thanks.

You gave a talk about all the work you're doing.

Maybe just as a quick introduction, quickly, who are you and what's your involvement with Django, right?

Who are you and why are you here?

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 I learned the language.

Um the reason I got to DjangoCon was that I was talking about a thing that I built in in Django.

Um basically, what I do for a living is I I work for a nonprofit in South Africa.

Um, and our main trick has generally been to find high potential young people who um who come from underserved communities but who really have the like the 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 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.

But um the most the the one that jumps most to me to me is how so okay, you you you identifying what you call high potential individuals.

How on earth does one do that?

What's what does that look like?

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 in 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?

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 were you schooled in a particular kind of middle class upbringing and blah blah blah.

It doesn't necessarily test any underlying attribute of the candidate.

I mean, failed as it is, yeah.

Yeah, I believe that's the issue.

Do how do you try and work around that?

Or do you?

I mean, is I don't have any answers or questions.

It's just a question, it's just like

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 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 Jeff'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 an online boot camp, and basically what we do is we we get these um these applicants loaded up onto our um learner management system, and they um they they behave as though they are already recruited into our program.

So they'll have some cards on a can band board and they need to move the things across the board, and the things that they do during this boot camp are um like we give them some basic code tutorials to do, um, and we give them a bunch of cartas to do, which are like they're not super hard.

And if somebody's 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 um is helping them out.

This happens unfortunately quite a lot.

Um, so then after that, we have a test.

Um, so we use a platform called Codabyte, which is really nice because you can run lots of tests for very cheap.

Um, and that's again just like a KATA thing, and we can detect certain kinds of plagiarism.

Um and even then, we 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?

Um, like, what is this gonna print?

And um tweak the code as 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 of the boot camp.

Um, and like that final interview is quite a like like that's the decision point in the end.

Um, 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 boot camp, we we try and make sure that they're learning and growing, even if they don't get into our program.

So if it 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 and 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, let's see if we can get you to understand it.

Um so if somebody gets caught plagiarizing, we don't like 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 for each individual candidate.

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 you can't just say, like, oh yeah, just ignore that person, they they can fail there by themselves.

Um, and it also ends up being quite unpleasant for the learner.

If we if we let in the long the wrong person, they sign 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 you build something, and then you said you build people.

And I was like, yes, that's that's amazing.

So we build tools in order to build people, basically.

Yeah.

Yeah.

Yeah, yeah.

We actually um 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 as much as possible.

Like go have some fun with your money, but um save up and look after the important stuff.

Yeah.

Was that your first programming language or were you already?

So I learned um so I started coding when I was in schools.

I learned Turbo Pascal as my first language, uh, which was uh great fun.

Um and then after that I learned C.

Um I don't know if I learned C first or Python first.

I I don't remember, but uh yeah, Python was something that um yeah, like once I started coding in it, I I just loved the language.

Um yeah, uh 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.

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 I think still most undergrad computer science majors have no experience with any of that, right?

They've they don't know how to build a a Django site, they don't know how to use Git.

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

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

Um I think the other thing to think about, or the other thing that I think about is um 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.

Um and so I'm like, all right, so what does a person need to know in order to not annoy their co-workers in the first three months?

Like yeah, yeah, it is a tough one.

But you know, when you like start working with a junior person and they just bump their head on Git for the first two weeks, and you're like, oh, come on.

Uh so we just make sure that none of that stuff happens.

We we take care of all of the things that their employer would need to teach them in the first three months, um, or we try to at least.

Um it's hard to tick everybody's boxes and and whatnot, but um I think we've got a very firm foundation built.

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, Muzi's home, home.

Um can we talk about the tech stack?

I mean, technical podcasts.

I think you

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

And that was generally managed like in person.

Um we had spreadsheets, you know, um, and some like random little scripts that managed those spreadsheets, but a lot of things were handled just in a very hands-on way.

Um later on, um, so so when we went remote, um I like that's really all we had was was a syllabus and some random scripts, and it was in no way sufficient.

Um so Tilda came out of that.

Um, 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.

Um, and then once it's like once the solution was clear, it was like, oh, this is obvious.

Let's let's build a Kanban board.

Um so yeah, so the tech stack um back end is Django um and Django REST framework, and um we use dramatic for long-running requests, and then on the front end React and Redux and some saga stuff and uh material UI.

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

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

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

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

Um so um I think the the core of the the core of the application, the Django application is this um is the way we think about content.

So our content is um basically consumed as a bunch of um configuration files for the Django app.

So we've got all these markdown files and they've got front matter in YAML, and um we look at that YAML and think of it as a um 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 um items, we call them, and they can come in different flavors.

And um, so from that um kind of graph of knowledge, we generate people's um, we generate some Kanban boards that people need to work through.

Um so yeah, yeah.

Because this is a fascinating question for me, is 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 is always in this sort of impedance, because you can model a graph in Python in memory, but then how do you write that to disk?

And how do you like like how can I ask you to explain a bit about how you handle it?

Because I think it's a good challenge.

But it yeah, basically we've got um a table called content item, and then we've got uh another table for um 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 um we generate a 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, so 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.

Yeah, okay, nice.

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.

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 uh so 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, yeah, I could build a Kanban board in a couple weeks, you know, that is prototype and then scale it?

Let me know if I'm going off unintended.

You know, you know, what gets you to the point where you can do that.

Yeah, I can do that in Django, but you have to have done a bunch of stuff before to get to that point.

I think

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

Um I guess I guess so, yeah.

What what got you to that point?

Because it differs by person, right?

That's not a linear thing.

Um it my career journey was not uh linear or intentional in any way.

Um it was uh very, very meandering.

Um, I think um I learned a bunch of web deb when I did that first Django app, but I also did like um some like C sharp stuff once upon a time, and I've done PHP and um some PHP front-end stuff, and uh like a lot of pyramid work and some flask work, and so I've I've touched a lot of different um frameworks for different reasons with different clients.

And um, so I think 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.

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

Um then the other thing is knowing almost like the anatomy of a web app to say, okay, what is a backend, what is a front end, um, like how do these things talk?

Where does the code actually run?

Um and how um, like what are the trade-offs between like using a template, um, 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.

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 DjangoCon was about the roadmap being like kind of here is the 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 yeah, I'll figure out the details, but I kind of know the overarching structure of what I want to do.

And um I think that's cool.

I I mean that's great that you touch so many technologies, you know, because 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, oh, 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 like I'm not like you know, I I play around with new frameworks because it it's fun, but I don't really want to have to go build a Rails site, you know.

Yeah, yeah.

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 you're 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, um, 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 gonna serve you.

Um, so yeah.

From scratch.

That's really kind of helpful.

Yeah, yeah, here's the Django app.

Oh yeah, yeah, I know how that works.

Scalable Teams is a big deal.

Yeah.

Like, that's not the case.

Everybody's got their own flavor.

It's like uh even worse.

Forget that, yeah.

Yeah.

Well, uh uh we just interviewed um last week um Craig Kirsten's of uh Crunchy Data, and 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.

Um, which I thought was quite nice to you know, okay, yeah, it's a 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 um is very strong in Django.

You know, it sometimes I wish maybe for beginners it had more opinions actually, but um you know the batteries just take for granted.

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

You don't like Yeah, yeah.

You know, what are you doing here?

Um do you have do you have a question, Carl?

I'd want I saw so you got Kubernetes in here.

I have to ask about deployment, and like that seems like um that it's not a simple that's not a small step to go to Kubernetes.

So how did you make that decision?

And so

And um yeah, like learning it from scratch under pressure might not have been the best uh situation, um, but it was it was useful to know already.

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

Um and so I was like, okay, cool.

Um 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.

Um 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 uh fits in my head a little bit.

Yeah, yeah, yeah.

Yeah.

So that's that's not call there's two things when you run Kubernetes.

No, but there's two things when you run Kubernetes.

Like please can you run my can 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.

So I didn't set up the cluster myself.

Yeah, I I pushed it.

Why are you doing this?

That's um I do prefer managed services very much.

Yeah.

This is a managed service um stan show here.

Easier, yeah.

Uh one of the other um tech cool things you noted in your talk was um the 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.

Um how you automate that and awesome.

And if you are a developer working on a team of developers on some realistic project, you're not just gonna push to the main branch or willy-nilly, you're gonna push to a different branch and you're gonna make pull requests or merge requests.

Um, and so we wanted to get that feel for the learners.

Um, and we also wanted to make use of GitHub's um lovely um like review functionality.

Um, so basically, what we have is um 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 um, 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.

Um, and we it's a private repo, and they are added to as a collaborator, the main branch is protected, um, there's a little bit of a README added in there for them, um, and now they get to start contributing code um in their own branch.

Then um 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.

That's you using your example, right?

Password checker.

So there's like a little password checker project.

Um, and uh 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 as reviewers.

It's it's sort of like a random allocation of like who you're gonna review, um, so long as you've done the work.

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, yeah.

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.

Um, 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 um space repetition in their learning.

So they have to revisit things that they wrote, um, but but now it's written in a slightly different way, and now they have to understand it, and that's um a pretty good way to make sure that they do absorb as many concepts as possible.

Um, so that's yeah, pretty cool.

You know, you'd spend some time writing it, but real realistically, if you just spend your entire training period writing code and then you get put into a job where you get to write um uh I got two hours actually doing some code.

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

I think it's a really good thing.

Um Jeff Triplett, um, 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, Where you know, where 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 training rather than you know actually building the the thing itself, which is sort of you don't in a way doesn't make sense, but with experience you're like, oh well that's 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?

Like Greenfield such as only review people's code.

Yeah, yeah.

Um and that also works pretty well, especially on front end stuff.

I'll just um I don't know, build um 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 uh onboarding new people.

Yeah.

I'm gonna use that.

One is that um I think you say you're adding start, you know, start dates, spend dates, you've got this Kanban board, that the curriculum is kind of like that.

Um, how do you find that as um helping people along?

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.

I think Coursera has something like a 7% completion rate.

Maybe that's generous, even, I'm not sure.

Um, and

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 I hope they don't and they 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 and this is where I'm stuck, and and that kind of thing.

Um, but then we'll also keep an eye on their pace.

So if it looks like somebody is 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 gonna 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 that 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 thing 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.

Um, because they they learn to code in a REPL and they have a function that returns a thing, and then they they run the function and it's like, look, it printed.

And and so um there's all sorts of um little weird things like that that we've noticed.

Um so we'll have um like mini workshops just on those concepts.

So it's like, all right, cool, we're just gonna like 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 and then once that's done, it actually solves a lot of problems.

So I mean 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 uh 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?

I would think that there's there's just like really understanding how a function works in terms of what happens when you pass the val the the the fun the arguments in and are they by reference or value, and you know, is it a reference or 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.

So we always like follow the same sort of process when exploring this stuff.

Well, like the staff member will write a little simple piece of code and say, Hey learners, what do you think this is gonna 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.

And um, the people who click onto that way of self-assessment, um, they tend to do really, really well.

Yeah.

So that's um go on.

Go for it.

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

I mean, is that is that a a worry for plagiarism and people sort of um hacking the the the course content, but also is it a tool that you think is useful for people in their careers?

Uh it's something that I want to explore.

Um, I think for junior coders, it's probably a bit of a danger to get too reliant on them.

So something so one problem that exists that I've noticed, I think it's I think it's probably everywhere, but um that happens a lot in our education system.

Like the South Af the South African education system is a bit of a mess, really.

Like it's it's nonsense.

Um, and people come out of that system thinking that memorizing and understanding are the same thing.

Um, and it's really not.

And so

Yeah.

And then you think that you can write the code, but you can't, because um, you've just stroked your own ego instead of actually assessing your own ability to do the work.

Um, and then there's people who are so focused on moving their cards to the the complete column that they don't necessarily um put in the time to understand everything.

They just want to get things done quickly so they can look cool.

Um and so I do worry um about people making use of those kinds of tools while learning if they if it just ends up giving them perceptions of being able to do things that they can't do.

Um yeah, that's that's a big deal.

Um so so yeah, it's a concern, and I generally actually tell the learners to not rely on that stuff for their projects.

Um, like they can play with it and it's cool, and maybe 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.

Um yeah.

Have you guys used that's th those uh sorts of tools?

It's awesome, but like when I'm when I really want to think, I have to turn it off because I'm like no no no because it's like it's like um pair programming with someone who's drunk, is it looks right and it's fine, and then you realize that it's it's massively wrong.

Um it's like no no no, I if I just if I you know if I just tab through there, it would look as if I it was right, and it just isn't.

There's logic errors, and it's like so so you know when you're trying to think, you just 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 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 that's an interesting viewpoint that I hadn't considered, so I like that.

I I spent quite a while, I don't think I mentioned this before, uh, talking with Simon Willison at DjangoCon about these AI tools.

I mean, specifically the Dolly, the image generation, but because he's like you know, really interested in all that.

Um 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.

Um it's yeah, the drunk programming, and certainly for a beginner, I think you don't you don't you don't want the crutch.

It's it it's really not helpful.

Um but it was it's interesting to you know 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 and you know by one yeah, so I would also advise people to you know to play with it, but uh yeah, I think there's gonna be some tricky things there other than the more mundane tasks.

But yeah, in a couple years, like maybe 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.

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

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, but it is what it is.

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 the 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 enough.

With your current stack you're using, Hugo, I think you've mentioned maybe you would revisit that that decision.

Like what do you make of static site generators, like 11T and others?

What like what would you use today if you were starting from scratch with static site generators?

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.

Um so we were using um Hugo initially, um, and it seemed like a good idea at the time, but I think the version that we uh the version that there was at the moment is pretty unstable.

So as soon as we wanted to upgrade it at all, like even uh by a 0.01, then it would be like, oh, now things are broken and we have to fix them.

Um and that was a little bit frustrating.

I mean, what do you expect?

Which was

Oh yeah, no, Hugo is oh, I'm talking about 11D.

Yeah, JavaScript is a lot of things.

Like every time I have to write significant JavaScript, I have to go take a shower afterwards.

It's it's a messy language.

Um but but it's also um yeah, it's it's also solid in a lot of ways.

Um so I've done some playing with 11T and it seems very very capable and very um yeah, like easy to extend in different ways, which is really cool.

Like Hugo, uh 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.

Um, and so interesting things don't happen.

Um, whereas with 11T, it would be much, much easier.

I'm actually also thinking about Next, um, because you can also do static site generation with Next, and um 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 it's um maybe it would be cool to have a little quizzy thing or um some interactive content.

Um, so I think maybe next would be better for that sort of thing.

Um, so it is gonna change at some point, but it's not like the highest priority um thing on the list right now.

You know, and you so you've got to choose carefully, you know.

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

Yeah, yeah.

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

It seemed like the best bet.

Um but yeah, there's 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 the one on the edge where you don't use it very often.

Every time you go back to it, you're like, Oh, I've got to remember about that.

And you say the the velocity is just so slow.

And it's got like that mental hurdle that you'd like okay, getting into it.

Gotta block out a week.

Yeah.

Yeah.

Well, it's React with um 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, uh I think Next is maybe nicer.

Yeah.

If we want to get yeah, I haven't used Remix.

Next seems to have the mind share at the moment.

It seems to be, you know, it's always a uh it's always an up and down thing with JavaScript worlds, but like you know.

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.

Like which maybe it's not the worst thing because you just sort of leave it alone and just post content.

And um, but it's it's nice to stick to Python JavaScript if you can, just cause one one less thing to worry about.

Anyways, yeah, I agree.

It's yeah, it 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?

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 tilde 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 um wrangle it how they want to and make reports and send emails to partners and things like that.

So um yeah, uh pandas is is handy for all of that kind of thing.

Is it it's like that as opposed to continuous?

Um we generally take in a cohort um every couple of months.

Um and it's nice because of the 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.

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

Um so we'll generally take like a more advanced learner and then um get them to sit in the stand-ups of a more junior cohort so that they can um like have an opinion on things, and that also works quite nicely.

Um so yeah, that overlap is is really handy.

It sounds like it that has to be more continuous too, because you're just constantly having people go through.

So that maybe I guess it would be it'd always be nice to have a month to think about things, but yeah, I hear it.

It's not not a real world situation.

Um, so a funny thing is that I actually work with my brother.

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

Will it be dodgy?

You should hire your brother.

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

Um, and but he's great, like he works freaking hard, and he's 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.

Um now he doesn't work in like it's complicated, but a lot of major decisions were made in like random caves in the Darkensburg, because like away from work, having a nice hike, sitting in a cave somewhere, we're like, huh, I just thought of something.

And um, so yeah, sometimes getting away from the the daily grind is yeah, critical.

Helps a lot.

Um, but yeah, other than that, reflection happens.

Yeah.

Oh, reflection is just a constant thing, yeah.

Yeah, yeah.

Um so uh 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.

I was just I my daughter has r recently gotten really into it and um I was 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, you know, how what was that like?

And because it seems like a natural fit for a programming mind, right?

It's it's through you're solving problems, and that's for my daughter who's 10, she likes the intellectual aspect of it um as opposed to just run har run harder or you know, the fact that it's solvable fits her mind quite well.

Um yeah, it's a puzzle.

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

It's uh yeah, you can really geek out about BJJ for ages.

It's super cool.

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

Um, and this mixed martial arts gym opened up near my place, and I was like, let me go see what that's about.

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

Um, so I ended up getting like seriously into it.

I've competed internationally.

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

Yeah, it was hard work.

Um 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, um, 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 just

And then um afterwards I needed a break.

I was just like, okay, I just need to like 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 um Germany, and I haven't found like another home gym um that quite fits um my personality, I suppose.

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

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

Um yeah, it's I don't know, my own head sometimes.

Like I really loved it for for a really long time, but I haven't I haven't managed to like five refined the love for it um in the same way.

I mean, I'm thinking of something in my life like to get the competitive part out of it and rediscover the 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.

Um that is a big deal.

Just to bring it back to that playful way it used to be, um, it would be nice.

Um I think it was also I don't know, my my coach was fantastic.

I find that I can push myself incredibly, incredibly hard if I'm like involved, like if there's um, I don't know, if there's somebody on my team that's also doing that.

So 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.

It's like it's you know, it's you miss one and then oh dear, it's really easy then to miss the next one.

And then it but to be in that routine of like, no, this is what I do, this is what I am.

I I am a jujitsu or I am a Tachi or I am a you know this.

I'm just a parent.

I'm yeah, I was gonna say, what I yeah.

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 that I just okay, world runner up, like

Um yeah, yeah, I think uh I think that's that's fair.

I mean it's

I was just gonna say thank you to Shina for coming on because I've really enjoyed the chat.

Um but if you've got something else to say to 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, uh I think I don't know if I'd had you been to a Django Con before a US one?

The Django community was just lovely.

Yeah.

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 gonna be cool.

So um we've just started organizing it and there hasn't been one yet.

Um so I think it's probably gonna be in around November next year.

Not sure which country yet.

Um, but stay tuned, it should be cool.

yeah, yeah.

Well, again, thank you for thank you for coming for coming on.

We're gonna have links to everything in the show notes, so everyone should check think check it all out.

Um uh we are at DjangoChat.com, chat Django on Twitter, I guess, if that's still around.

Yeah, yeah, we are we?

Well, I guess we'll do that.

We'll find out.

I'm I'm personally done with Twitter, so uh we're gonna move over there.

So uh okay.

Anyways, DjangoChat.com.

Thanks everyone.

Cheers guys see you next time.