Crafting and Editing In-Depth Tutorials at Real Python | Real Python Podcast #287

Key Takeaways

Welcome to the Real Python podcast. This is episode 287. What goes into creating the tutorials you read at Real Python? What are the steps in the editorial process and who are the people behind the scenes? This week on the show, Real Python team members Martin, Brenda Wellshuk, and Philip Excenni join us to discuss topic curation, review stages, and quality assurance. We start by sharing the multiple roles our panel of guests perform across the editorial process. They describe the phases a tutorial passes through, including layers of review from technical accuracy to educational effectiveness. We also discuss our editorial independence, external authors, and the continuous feedback loop with our readers. This episode is sponsored by agent field. Most of us think of AI as a chat window. But what happens when agents move into your back end simulating market scenarios and acting on them? Routing patients across hospital networks, optimizing fleet logistics in real time, all autonomously. That's the AI backend. Agent Field is the open-source framework for building it. Search Agent Field on GitHub or visit agentfield.ai. All right, let's get started. The Real Python podcast is a weekly conversation about using Python in the real world. My name is Christopher Bailey, your host. Each week we feature interviews with experts in the community and discussions about the topics, articles, and courses found at realpython.com. After the podcast, join us and learn real world Python skills with a community of experts at realpython.com. All right. Well, I have a crew of people from Real Python. This week, I'm very excited to welcome back a couple guests who've been on a few times. Let me welcome back Martin Boyce. >> Hi. >> And Philip Exeni. Hello. Hello. And new to the show, first time on, we have Brenda Wellishuk. >> Thank you so much. It's so nice to be here. >> Thanks for joining me here. And we're here to talk kind of think we hinted about this when Dan came on the show about a month ago to talk about the editorial process and sort of our guidelines for editorial. I'm not as involved in the written stuff. I'm mostly involved in taking uh your guys' work and helping to turn it into video courses and also talking about it a lot on the show with Mr. Trudeau. I think the very first time I ever spoke about the whole editorial process was episode one with Garna and then episode 250 when we went to Dublin, Christopher Trudeau and I talked about the whole process that kind of is involved in getting the written stuff turned into video courses. And so if you're interested in that, you can check out both of those episodes. Yeah, we thought we'd do a deep dive and in the age of mass amounts of changes of content and so forth, like what's going on with us here and then also want to talk about contributors and who's involved in doing our writing and so very excited to have you here. >> Yeah, it would be super interesting to listen to episode one and see what changed since then. >> Yeah. Yeah, definitely. Maybe we start with a a little bit further introduction. Martin, you've been on the show a few times to talk about things, but uh your role has shifted a little bit. I think maybe even since last year when we had you on the show to talk about some of the changes and upcoming things that that we went through over the last year and a half. >> Yeah. >> Yeah. So, what do you do for real Python? >> So, I'm working as the head head of content strategy at this point. So, which means I'm pretty much heavily involved in deciding, you know, the direction of content. Well, that's I guess why it's called content direction of of what we're actually going to publish like what we're working on, what do we publish, what shape does the content come in, etc., etc. So, I've moved into some somewhat of a I guess not entirely, but somewhat of a steering position, but I'm still also part of the content creation team. So, I also still do reviews and occasionally even make a video course. >> Yeah. Yeah. >> But yeah, a lot of my time now goes into pulling the strings, I guess. >> Yeah. Cool. And Philip, you've kind of been doing some new roles here, too. So, you want to talk about what you do for real Python? >> Yeah. So, I mean, if Martin is pulling the strings, like I'm still one of the puppets. Uh, that's >> Wait, isn't it Marionette? Should we get this correct? So yeah, I'm still creating video courses and tutorials, but yeah, I would say like since is it half a year or something, uh we are actively looking for external contributors and I'm kind of like the hiring manager to look out for video course instructors but also tutorial writers uh who write for real Python. >> Yeah, and we'll dig a little bit deeper into that. It's something that gosh, I think the face of that has changed a lot and the ways that we approach that. I was involved in it quite a bit. So I know the amount of work that's involved in that whole process. So thanks for what you do, Philip >> and Brenda. >> Hello. >> So what do you do for real Python here? >> What do I do for real Python here? Well, in a nutshell, as editor, I make sure that all the written content we produce is instructionally sound and consistently presented and accurate. So those are the main three areas that I tend to and um as you know we have this amazing editorial framework in place that makes this possible. >> Awesome. Yeah, you have your hands on lots of areas also. you've been helping not only with the written tutorials but also in the video courses looking through our transcripts and making sure that they're they're accurate and and then you've been helping me with my show notes just kind of give them a once over. >> Yeah, absolutely. You know, all those little pieces we apply the same editorial standards to all of those other little pieces. So, making sure nothing is overlooked and that everything has that level of clarity and exactness that we pretty much pride ourselves on over here. >> Yeah, there's very little text that Brenda doesn't touch, basically. >> That's right. My fingers, >> she got ink all over her hands. >> Lots of ink. My eyes, my hands are on all of it. Actually, maybe we can talk a little bit about this sort of divide. We are all maybe technically considered core team members or internal members who work full-time for Real Python, but Real Python's always been a mix of internal and external people. And maybe we could talk about, we've kind of hinted at it with IL explaining some of the stuff that he's doing, but anybody want to dig into a little bit about what that mix is and what it's like to I don't know about all you started. I I guess Phil you started as an external contributor. >> Yeah. So since I know real Python at least there was always now and then an advertisement that flew into my inbox with a newsletter and I think it was 21 or something like that when real Python was looking for so-called pilot tutorial writers. These are external people writing for real Python. And back then I was like >> that sounds like a fun thing to do. So I applied. I wrote an tutorial as external person. We can talk a bit more about what that means in a in a bit. But lucky for me back then Reython was also extending a team and then I joined full-time after that. Yeah, it's kind of like this this nice mix like having a core team, people working full-time or almost full-time for real Python and then this diverse community of people contributing to uh to the whole platform as tutorial writers, video course instructors or podcast guests. I >> I think it's kind of amazing like what a global set of resources that we have. not only the people, you know, and voices that we have, you know, I'm one of two people that are in the US. And Philip, where are you located? >> In Berlin, Germany. >> And Brenda, >> I'm in Calgary, Canada. >> And Martin, >> I'm in Austria in in a city called Gratz. >> And we have people Gosh, Leodonis is in Serbia. Is that correct? >> Yeah. >> Yeah. And Bartage is in Poland. Uh Dan is in Vancouver, British Columbia. Stevens in London >> and yeah, Trudeau is in Toronto. Uh yeah, so it's a it's a real mix. Uh and uh we have contributors from gosh everywhere which is really I I think speaks a lot to the stories that they bring and and that I think that helps too sometimes of like well how is Python being used all over the world. So >> and one thing that's interesting about being such a distributed team too is that basically we're working all the time. There's always someone awake and working and usually you wake up to a flurry of whatever has happened on the other side of the world and then you do your part and then it keeps going. >> Yeah. Yeah. I think I heard your your your bells chiming uh briefly there too. >> So those might interrupt. So speaking about other parts of the world, >> they like to chime in. >> Yeah. Nice. Yeah. Yeah. Do you want to talk a little bit about like what we are currently looking for in tutorial writers? >> Yeah, absolutely. And uh to to follow up on what we were just saying like the nice thing about external authors is like if we would have a map of our globe, there are people from from everywhere and it's not just kind of like their place but also their background. So that's something which is very important to us to find people with different backgrounds who are excited to write about Python. And since it's a part-time job, that means people work in different fields and write on the side and bring in their experience to their ideas to their writing to uh the topics that Martin then kind of like chooses and yeah >> as you mentioned and I don't know if that's how you got on board also Martin is you know for fairly often we have requests for looking for people and that's how I came on board to do video stuff. It was actually when that was new. I think that's when you came on board too, Martin, was that Dan was looking for to take a lot of the written content and make video stuff. And I had a real mixed background, which people have heard me talk about a whole bunch. But that's how I came on board, too, was uh just looking at this email and going, gosh, I think I'm a good fit. Is that true for you too, Martin? Yeah, I think we both like you were a little before me, but I think I started writing or making content also starting with video in 2018 or 2019, one of those two. >> Yeah, 19. Yeah. >> And yeah, it was a similar thing like uh there was the I I had just completed um making a whole Python course for Coding Nomads, a company I was working with before. And so I felt like it was a good fit for me to also make some content for real Python and try to bring some fun into, you know, the delivery, which is kind of what I like to do when I when I try to teach this just because it fits my learning style. So >> yeah. Yeah, totally. >> The good thing there is like that means I know there's at least some people out there who like learning like that. >> No, I would have to argue your stuff's pretty popular. So, Brenda, did you answer like a similar ad or was it something like a more of a referral because the editorial process seems to be requiring a little more specific background? >> Yeah, absolutely. So, you know, I've been here for about two years now and when I was looking for a new opportunity two years ago, I was working as an instructional designer and which I really loved. I don't know if you know much about instructional design, but it's all about creating learning experiences that create a certain outcome for the learner. And when I saw this job ad, well, even before instructional design, I worked as a technical writer and took a left turn from that and was teaching as well, a tech as a technology teacher in a school. So, I ended up combining all of that together and thinking, "Yeah, I'd love to do something in that technical education space and I saw this ad for real Python looking for an editor and I thought I would be like other than the fact that I knew nothing about Python and you know Python, I thought I would be >> checking off all the other boxes." >> Yeah, exactly. >> I would be great for this job. So, yeah, it worked out really well. It's been, you know, two years, which feels long enough that I feel at home now in the editorial process, but at the same time short enough that I remember how much there was to learn about Python in the beginning, which was a lot for me. >> Yeah, totally. You know, like I said, I discussed this whole process of going from written tutorials into video courses and kind of, you know, shephering them through this process. We wanted to try to do the same thing here. It's a little more detailed in the written process and which is kind of amazing that you know that there's still even more, you know, stuff that we do to make sure that the video stuff is done. So maybe we should start with like how do we find the topics that we're going to cover? And I guess me Martin, you might be a good person to to start this conversation. >> Yeah, I mean uh that process has also changed uh since you know I've started working here. But I think historically we've always been starting off with the written content. This was kind of like the thing the the content that we put, you know, like the most research behind before before deciding to whether to work on it or not. And then a lot of the other content and percolate, is that a is that a correct word? Sure. Perculates from it. I can say that. I have our language person on here and she >> That's a great word. That's a great word. >> Saw her not. So I mean yeah that's good >> thumbs up. >> Yeah in a way this is still like that. So we just established you know the strongest pipeline I would say around that that written content and it's proven to work pretty well to go like that. The research behind the topics I would say has changed significantly since since then. I think a lot of it at the beginning was people proposing topics, external authors proposing topics of something they want to write about, which is not a bad way to go, I think, because if you're primarily relying on, you know, people externals that that are in the field and they're working like like Philip mentioned, >> expertise. Yeah. >> And they have an expertise in a certain area and they want to write about it. That's great because you're probably going to get pretty good pretty good content from that. And that's still part of it too. But uh we've moved a lot more towards looking at data that we collect to to figure out what the audience that we're writing for is actually looking for. You know, what what's the topics that that are important for the people that that we do this whole thing for, right? You know, because we're right >> in the end, we're trying to deliver quality information that's relevant and useful for the people learning Python. So yeah, we we're leaning more into doing user service and also we're collecting some data about for example from the PI coders newsletter what are people actually interested in like what do they find interesting what do they go to research what do they go to read more about so all of that kind of mixes together and well I guess there's more than that there's we also have like we've built up a significant body of of content on the site at this point you know we've been going for a long time really and like >> you might think like what else can you write about the standard library. I mean, outside of what comes in every new release of Python every year, which we do dive pretty deep into, >> but I mean, it's it's absurd. The ecosystem is giant. Like, I don't think you could ever stop writing about this because there's so much there's so much like >> that keeps coming out, but also even like just what is out there. You can there's so much you can do with Python. It's >> new libraries, all the things added on. >> Yeah, it's immense. And then and then it's not just that like you have, you know, a topic and it's covered. Once you have your your one Django article out there, you know, you've covered it all. That's that's not really how how it goes because there's also different needs for learners. And I I think that's like something I've I've tried to move our content towards more a bit as well is like the what are the intents of the people that are actually looking for answers on the site or or or why are they coming here, you And there there's in learning theory there's like different ways of why why do you want to learn something or why are you I guess engaging with with learning content and and I've tried to work out a real Python version of that so that we can really address this this needs of the the different needs that people have when they come to our site or find us in search or or in an AI chat or wherever they they find us. Right. >> Yeah. >> So that's that's a big part of it too is actually went kind of astray here. What what I wanted to say is we have this big body of work and we have learning paths that that kind of string that together and sometimes we identify also like okay so there here's a step missing this is not really taking a person or we get the feedback that people are like confused about how do I get from from this knowledge piece to the next one and then then we also identify okay so here's a gap this is something we should fill with with something that's we've learned from the user feedback aha this is what's confusing about it so either we go in and fix it if it's a small fix or or otherwise we're like all right there's a genuine gap let's let's add a content piece here as well and then I'm still talking sorry about that there's one more thing I got to mention though which is like just like big shifts in industry that are making their way you know just on top of all of us in a way you know so I mean what's happening at the moment with AI assisted development obviously is like is a huge change that is happening really quickly and that's also something that we believe being somewhat at the forefront and which is where we need to be with this because we also try to teach people you know what they need to know in the workplace and how they how they can like continue to be working in this field and also like upskill what they do. So there's a lot of changes happening there and this industry shift is something that is also on the top of our minds always. So we identify topics based on that as well. And then all of that together including suggestions by authors. >> Yeah. >> That that's still around but there's a lot of additional research around it. And but we also choose people a little bit external authors depending on what is the direction that we are trying to move the content in. >> Help fill in some of those steps in the path that are maybe missing. >> Yeah. >> Yeah. Because ideally you you want to have a great match between the author and the topic like that you either know about or you're excited about things like that because that makes a good content piece in the end. >> Yeah. Comes through in the writing. One of the things that as we go through this process kind of at the beginning of it here talking about selecting topics and figuring things out there is a I think this again was mentioned in my conversation with Dan. There is a landing page about our editorial process and it's realpython.comeditorial-g guidelines. And so if you want to there's this really nice infographic that Alderin has created for us uh that you can kind of follow along if you want that dives a little deeper into some of these things if you have questions on it or >> maybe we might miss some things but if you want to follow along it's there. I guess kind of step one and two, this selecting the topic and then the topic being chosen, I'm guessing, is by not only us and and potentially the writer and kind of making that match, >> right? >> And then we kind of move into I would say step three, which is okay, now we need to figure out well what's actually going to be covered and go into an outline. >> I just wanted to add on to this step one and two. I mentioned at the beginning that like a lot of it was author driven at the beginning of real Python like or external author driven which we all said like has this advantage that the person actually knows what they're writing about. So it's still important to to find the right person for a topic even if they're not necessarily the person selecting or proposing the topic. Right? So we have a a research to make the topics that that go on the board that are there to choose from basically to to make them aligned with what our users need. And then there's a matching process then to find the right person to find the right fit for that topic that we want to present. Yeah. >> Yeah. >> Yeah. And that's that's one of the first nice experiences like that's both we as an as a core team have sometimes like when we're starting to write something we kind of like can get into this uh I want to say room but it's basically like like a board where we have all the topics and it's kind of like you you you pick the dress you want to wear uh for the next couple of days and weeks and as an external author you basically once you are accepted as an external author you are presented with this big pool of topics you can write about and your first task is to make a decision. And sometimes it's hard because it's it's a little bit like a candy store for some about topics that you always wanted to write about. But yeah, the goal is to pick one topic for uh writing about and then sticking to it through the whole process of course. >> Yeah. So what goes into step three here of the creating an outline? You guys have both done it quite a bit. Philip, you want to speak on that? >> Yeah. So when you pick a topic you uh also what Martin was saying there is kind of like an intent behind the topic. So that means for example it's kind of we had a tutorial about UV versus PIP. So it's basically you you have a clear intent what your tutorial should should cover and the first step then is to create an outline because you could write pages and pages about something but uh also >> control your scope >> as a reader who has time for that and >> as an author it's also something which is important to us that it's it's a scoped experience and uh you have a really clear picture of what you want to write about and that's where the outline comes into It's you can think of it a bit of kind of coming up with the table of contents and saying like okay I will tackle like these parts and this is my vision for the tutorial. So not writing it yet but kind of sketching it sketching it out roughly and you don't necessarily start off with a completely clean slate. So like Philip mentioned we have this different intent so that have directions of what the content should solve for the person reading it for the learner and there's like certain guidelines essentially that are already come when you look at the card. So, we're doing this on a on a Trello board. So, that's why we keep talking about cards and they have descriptions on there that that give you some sort of Okay, so how should this uh tutorial like work for for a reader and uh what what what is it? >> Right. You have like outcomes and things that you're interested in, right? >> Yeah. And and how should it address the content too? It's like there's a difference for if if a reader wants to, you know, accomplish a task like they're in a work work situation and they run into a problem. they they don't really want to go deep and like really research a topic at this point. They really just need to solve their problem. And so that's a different template than if it's really about deeply understanding a topic, for example. And there there's some guidelines about that already in the card. So that that makes it or is meant at least to help the the writer to help them with their their outline and scoping the content and giving it a direction. I've talked about this process just as uh creative stuff generally. This idea that having someone else potentially set forth guard rails and sort of narrow your scope and say it should be this long. It should be about this. These are the things that you should hit. just makes it much easier than like, oh, I'm just going to write about this thing and then your brain sort of like just >> Mhm. >> goes, you know, too far. And you, for certain people, I think it can be the opposite of inspiring. You kind of like get stuck. And I feel like writer's block is helped by having constraints and and maybe some of these constraints there. I haven't written one of these articles, but I definitely see it in the other things that I do. >> Can can I tell a stupid little story? Sorry, Philip. >> Sure, go for it. I'm always up for stupid little stories. >> Going through school, back when I was in school, I always had the most fun when I would get an assignment, a homework assignment or something that was scoped in a certain way. And I always had like the most fun when I found a way to still fulfill what this was about, like what the assignment was was written down as, but it was very clear that I'm not fulfilling the intention of the person who who gave me the task. Does that make sense? >> That was like one of my favorite things to do when I was writing stuff. >> So that fulfilled your little devious, you know, >> high schooler mind. >> Do you still do it? >> Was very satisfying. No, I don't think I do it so much. But um I guess uh what >> you're following guidelines but not maybe the intent. >> Yeah, I guess that's probably what it was back then. Yeah, follow the guidelines and not the intent. I would like probably at this point I would do the opposite. >> Yeah. >> Because of the understanding of like the intent is actually because I mean school is a funny thing too you know because you don't really write this thing for >> it should be the time when you get to do these things >> and in this case it's like I'm actually there is a reason for for making this content right like that >> there's a point in having it because I'm trying to help people. So that's a different uh it's probably a little inverse. >> Not not entirely a writing exercise at this point. >> Yeah. Not not a conversation between you and and your teacher. It's it's it's uh designed for you know instructing someone else hopefully at the end. Yeah. >> Thank >> maybe we could just get into like again we talk about this idea that there's a lot of reviewing that happens in this process. So yeah, >> the person takes the parameters that we've assigned already to this card and say, "Okay, this is kind of what we're looking for." They've selected the card. The first point of review to make sure that they are staying within the scope and within the intent of what we're looking for out of this piece is to review that outline. How soon does that happen? And is is there a back and forth in that process? >> Well, it happens very soon. So basically that's the the idea of our whole process is to to have multiple iterations. So uh that you don't try to write the perfect things thing from the get-go but uh that we basically as a team take care of shephering this article to the end and iterating on it and the outline review stage is one of the first moments where you get the the reviewer in this process and that's also the moment where you basically meet your reviewer for the process. So one special thing about the processes at real Python is that you will have a person on your side through the whole process. There are multiple people reviewing it, but this is kind of like your core reviewer, a person from the core team who gives you an outline review and later technical review. We'll come to that. And this person basically and like you were just saying Chris, it's it's usually more about the scoping of like to to really make sure that the intent is met, but also that you don't put too much into an article. So sometimes it's suggestion of splitting it up and keeping one idea in the backlog for maybe another tutorial and then requesting some minor updates in order to kind of have this blueprint before it goes into the writing stage. So usually that's kind of like one update request for the outline. Sometimes it goes through immediately. Sometimes there are two rounds, but I would say like there's usually one feedback round before uh the author is greenlighted to go into writing. A quick word from our sponsor, Agent Field. Most developers still think of AI as chat bots, but move agents into the back end and something wild happens. agents running simulations to optimize pricing. Orchestrating logistics across warehouses and carriers, triaging security incidents automatically, resolving insurance claims end to end, not a human using a chatbot, but autonomous software. This requires real infrastructure, identity, authorization, and scale. Agentfield is an open-source framework for building backends that reason like APIs and microservices, but intelligent. No DAGs, no rigid pipelines. They're defining a new category, the AI backend. Search agent field on GitHub or visit agentfield.ai. So then we're on to potentially an internal person writing it themselves or this external author basically doing a draft. Is that right? >> Yeah. And and maybe also to mention it's it's us as people in the court team. We go through the same process. So it's >> you have each other review uh what's happening. >> Exactly. And but you always have like a person from the core team reviewing it and yeah then it goes into writing. You basically uh start with the the blinking cursor. You have your outline but uh then it's uh basically filling the outline with with life. That's the hard part. That's also the part that takes the most time for for you as an author. And it's also the most fun I would say in a way because that's the creation phase, right? This is where you actually get to put your ideas out there. >> Exactly. And depending on on the topic of the tutorial, that's it has multiple levels. So it's it's not just kind of like you start writing, but you research something during the outline phase and you basically revisit these parts while writing. And sometimes that happens. It's kind of like, well, I thought I researched this in that way, but now the deeper I dig, the more I think like that it's actually not that way. So, there are also micro decisions. That's why it's good that you have this person on your side to communicate with, to check in with. If it's technical content, which is it usually is, you're building a project on the site, trying things out, trying to scope the project down. So it's not just about scoping the writing, but also scoping your your code in order to not kind of like to diverse into too many things and keeping we we'll say this probably very often the intent of the tutorial to really uh stick stick to that. >> Yeah. And uh then ideally you come come out of this uh writing process with a first draft that is kind of like a good starting point to discuss the technical side of things and iterates over over that draft. >> That was one of the things I was thinking about and Brenda you brought it up briefly this this idea in your background of being a technical writer. A lot of people I think think of technical writing as potentially, you know, writing documentation for varieties of things. Sometimes they forego like narrative elements and and so forth and and making the user feel like they're part of it. It's an interesting hybrid that we have. Would you agree? >> Absolutely. Yeah, for sure. So I mean as far as technical writing goes, it really spans the gamut of types of documentation that you know the writer can write. In my case it was systems documentation. So it was mostly all technical. >> Okay. >> And that served me well. But ours is really a unique combination because we are not just being purely analytical in it. We are um we respect the readers. I'm not saying that with systems documentation you don't respect the reader time and intention to learn but that's something that we really focus on is >> right >> you know the reader's intention to learn something and do something useful with the information in a really friendly way. >> Yeah. So we always like to write in a way that it feels like there's a really friendly and accomplished developer sitting beside you and walking you through the content as opposed to do step one, step two, step three, step four. >> Right? >> So we call that handholding and you know we make it a you know you learn much more effectively if you feel comfortable and if you're in an environment that's familiar. And a big part of our creation process and our review process is making our content have a certain real Python feel and you know a real Python look that our audience expects to have and that's that's where that level of familiarity comes. >> Yeah. I mean there there were people programmers or what have you that literally they enjoyed reading manuals you know and and going through that but that's a very different experience you know to do something like that to you know literally lead read a technical manual or you know read the the core library documentation and and and I think it varies you know I think a lot of the libraries and things that are out there for Python I think are friendlier in some ways and and have been written by people that potentially have come from other realms and and want their stuff to be approachable. But it's very different for what we're doing. And in fact, we've changed a lot of our structural stuff over the years. Uh at least I'm watching it from the sidelines, you know, not being a writer, but just like things that we feel like, well, these are important. We should include these things. U these are things that people want to know when they want to get into things. And there's a lot of people who just skim stuff and so you want to be able to catch their attention and and and bring them in. And I don't know if we want to talk about that a little bit just briefly kind of interrupting our flow through the process, but can you think of some things that we've added? specific things that we've added that come to mind. Just we've kind of changed our introductions over the last two years or something like that to be kind of like targeting this this people who who don't really don't have a lot of time and I want to you know quickly identify whether this is content that is a good fit for them. Exactly. Like a a quick a quick assessment basically. So our the beginnings of our tutorials now try to to give you a very quick breakdown of what you're going to learn in there. Um so that you then know is that like is that actually relevant for me? Am I ready to commit to the I don't know like 10 to 60 minutes that it's going to take to go through the content. >> That's new too, right? Do we have a time that's on a lot of our stuff now? >> Uh yeah. Yeah. It has like >> I don't that's kind of new, right? >> I don't know how new that is, but maybe it is new. Yeah, I'm not sure. >> Yeah, >> but we definitely have it. I know like Yeah, it's it's calculated, you know, like how these things are based on a on an expected reading speed that is that I think we tuned down a little because there's a lot of technical information and also code blocks that we have in there, >> right? >> And I think it's it's a pretty good match. Like I think we we tried it out a bit and it seems to be a good a good approximation of how long it might take you. Of course, don't feel bad if it takes you longer or I guess feel great if it takes you shorter if you want. Just always good to have a reason to feel great. >> People absorb stuff at different speeds and that's totally fine. Yeah. >> We've also I'll just chime in here for a second. We've also added an FAQ section at the end of our articles, >> right? Yeah. >> So, if people just want to quickly grab, okay, what were the main things covered? um they may even find an a question that they have about the topic that they didn't even know they had. They can just quickly click in there and get the really fast and dirty questions and answers related to that topic. So, I think that's been pretty valuable, too. >> Again, I I think these things are great because they're just kind of moving beyond pure technical writing and and having uh empathy for the reader, the person who's coming to this whole thing. and and trying to like set them up so they have the best experience going into it. >> And the FAQs, um, another reason for having them is also that there's like I don't know if you've encountered these or if they still exist that much, but there's this snippets that you get in search results where where Google picks out questions related to search search queries, >> right? So that's that's another way giving a chance for people to you know like first of all get their question answered in a real Python manner which means like that it's going to be technically sound and well researched and well written. So if they just want that answer they can maybe get it in one of those snippets and then also if they had that question and they want to learn more then they have a have a way from there to get to the more in-depth tutorial and learn more about it. >> Awesome. So, the reason I brought all this stuff up is because that's really our next step is the the technical review and we noted a few things here, but like what what would be some of the key elements? Uh, I don't know, Philip, if you want to kind of speak on this one, like what what goes into a technical review for an author? >> You can think of the technical review like a code review of your article. And that's the interesting part about writing tutorials. It's uh like we mentioned before, it's not just a text, but you will have most likely code examples in there. So once you hand over the tutorial to uh the technical review again, like it's the reviewer on your site that's doing uh that for you and uh this person will read through your tutorial, basically follow the steps that that you outline and check if everything's working. more often than not like there are little like bugs in there and these are the things we we flag to get a bit more technical here. you're writing as an markdown and you push your tutorial later to GitHub and it's basically a code review on a GitHub PR a pull request where your reviewer will kind of point out lines in in your tutorial where something maybe there is a typo in a variable name things things like that or there is like something doesn't work on the machine of of your reviewer and these are all things that could happen to readers later so sure >> it's good that we're we're checking these things And then there are parts which are more on the writing side but kind of like with a technical angle is for example the the classic that's it's less likely nowadays but once there was a switch from Python 2 to Python 3 the print statement became a print function >> terminology. So we want to make sure that when we are using certain terms in the tutorial, they're also technically correct. And uh that's where the technical review uh is going in. And yeah, that's often to again uh speak about how many iterations we're going through. It's one, two, three rounds until we're happy with the tutorial and the content that's in there. And also to mention I think we we haven't talked about this much but our tutorials come with materials right so basically if you have a little project or something uh like that in your tutorial we also provide this project to our readers so there is also this time a literal code review of your project uh and that's everything happens at the stage and it's a bit annoying because if there is a change in the written tutorial we also want to make sure to reflect this in the material so there is a little bit of kind of like jumping between those uh those two pull requests to make sure that everything is fine before it then uh goes into the next stage. >> I wanted to touch on something briefly as you came on board to write for real Python across this thing as a developer and somebody maybe who's been using git and and using you know version control and and using diffs and things like that. Was that welcome to add that to your writing? >> Can you rephrase that question? I'm I'm not sure if I >> So like I I think it's interesting as an author you probably normally write in maybe maybe you work in Markdown but often I think they would work in like something like Microsoft Word or some other kind of writing platform and and in this way you're writing using the tools that you use for development and I would wonder if there would be hiccups in that process and maybe there isn't. Maybe it just felt natural to to write almost like you're you know going back and forth with your code. >> Yeah, it's it's an interesting question because so far I think we never had big hiccups. We we changed the process a little bit. So when I started you got your review as comments on a PDF. >> Okay. >> Which was a little bit >> that's really clunky I would imagine. >> Exactly. So if you kind of want to go back and forth about something like it's it's a mess or it becomes quickly a mess. And we realized since it's usually people with a development background writing for real Python, people know GitHub by by now. Yeah. So, it's kind of like a process that you know and it usually makes sense to uh most of our external authors and if not we also have like with your reviewer on your side and we have also our internal documentation and everything. So, we got you covered in order to get you up to speed in in that. But then I think it's kind of like a nice way of like reviewing the writing because we can already propose suggestions where you can just like commit this to your tutorial and really point out things line by line. Yeah, you can see those changes. Yeah. Yeah, it's interesting. And accept them. Yeah. Or potentially propose other things. Yeah. >> Always open for that. I think it's actually interesting. I I Yeah. I realized that this is like such an intimate and normal process for us here, but I realize that probably people reading real Python content have no idea that >> Yeah. >> Yeah. I'm I like this deep dive >> that we're doing essentially development work with with GitHub and and uh pure markdown uh and PR reviews. >> So we are using software development principles while making our content uh which is which is maybe interesting piece of information. Yeah, I kind of wanted to flag it because I think that's really interesting and it seems like it would really help because the embedded code because of the other kinds of things and it kind of makes sense that the tendency to use lots and lots and lots of tools is really I think frustrating for a lot of people. You know, having worked in in offices and in other situations, it's like why do we have 17 tools and you know and everything's kind of spread across. So like the ability to kind of maybe narrow the tools down and focus it and and maybe reuse a tool that actually >> you wouldn't think of initially, but that actually is a good fit. >> I mean, it is a great fit. It's just version control, right? Like it's that's exactly what we're doing. We're starting with a draft. We're iterating over it to make it better. And we want to keep track of the changes, be able to propose changes, talk about those changes, and then come out at the end with a with a better product, you know. So >> yeah. Yeah. >> Yeah. It's a great tool for it in my opinion. >> Iterating to perfection, that's what it's all about. >> So, I I want to speed up just a little bit because we're kind of getting these side things which have been fascinating and and really instructive, but maybe we could dig into this next area and actually let Brenda speak a little bit on it. Our dactic review, is this something where you come in or is that still maybe the person who's been added on the card already who's been helping them? Yeah. So, this is exactly when I jump in. Um, I'm not involved in those first two phases that have already been discussed. So, >> the planning and the creation all happens before I come onto the scene. And once the tutorial or resource comes out of TR, that's when I begin my dactic review. So, I know a lot of people don't really know what that's involved, so I can talk about that. just heard it as an insult sometimes. >> Yeah, exactly. It's a wonder. I know. >> It's wonderful. This is so important. >> Exactly. It's very important. This is this is dactic in a good way. >> It sounds very very high brow, but that's why we just call it DR for short because, you know, it's just more accessible. >> So, I like to describe the dactic review as a teaching methodology assessment. And during this stage, I make sure that the content is instructionally sound and is delivering on that learner intent that Martin was talking about earlier. So if the tutorial is about, say, building something, then it's, you know, nine times out of 10 going to be a step by step. And I just make sure that all those pieces that comprise the step by step are there. And the other things I look for are you know making sure that concepts are explained clearly and build logically so ideas are moving from foundational knowledge to more advanced concepts. >> Yeah. Yeah. >> Yeah. Because it's always ideal right if complexity is layered gradually and there are no unexplained jumps and if there is a jump I just make sure that the author includes some sort of signal before moving to advanced ideas. This is like the microlearning path versus the macro learning path we discussed earlier, Martin. >> The gaps. >> That's it. It's all about the gaps, but you know, sometimes there are knowledge gaps. So, I'll flag those and say, "Hey, we need a bit of a bridge here." >> Yeah. And to be honest, this is one area where my somewhat limited Python knowledge has come in handy because I get to review the content from their shoes, right? from the perspective of the learner. And from that vantage point, it's quite easy to detect when learning material is instructionally off because there's just something missing and you're like, what just happened? So I think and that's natural because when you know the content, you don't have that beginner mind and you know the knowledge, you can develop some blind spots. So yeah, I bring that at this stage as well. Other things I look for are I'll un I'll I'll flag any unclear technical details and also provide structural feedback. So I'll just make sure that there's a real structural intentionality to how the content is flowing. We normally only use a certain number of subheadings and if it exceeds that number then I'll flag that. I guess the bottom line for this stage and I guess all stages really is that nothing's random or accidental because the process is so deliberate. So if I see anything that's off instructionally, >> yeah, >> that goes into the dactic. One of the things I you know we've talked about the external authors and I just want to highlight I think this is one of the areas that maybe if they've been writing on a blog or writing stuff for you know maybe their work or what have you this is an experience I almost want to say universally but maybe not where people are like I got so much out of writing for real Python. I learned so much from just this process. Would you agree? I mean, I guess there could be people that would say, you know, like they felt like I didn't, you know, I didn't get anything out of this. I'm already a perfect writer. >> No, absolutely. I think most authors would say, I'd be surprised if they didn't actually that they come out the other end a better writer because they're taken through this process and then of course they have to become intimate with our style guide, which is a whole other topic. And that's something else that >> I will introduce them to if they haven't already been introduced to it at this stage. We have a certain >> consistency to our our visual presentation. So that's when all those micro style details come into play and we need to make sure that they're all in place. So I think the first time an author writes for us >> it's a lot in a way because there's so much to take in and you know second third it becomes old hat and they're like oh yes I remember I have to bold these headings and I need to add this part and I have to introduce the code blocks this way but it it all it all just creates what people recognize as this is a real Python article. I I recognize it. It has all the pieces and then they're familiar with our process. >> And I also think it's like you probably I was a writer getting started with the style guide at some point. I know it's evolved also since then. >> Yes. >> But a lot of the things in the style guide just really make sense. Like they're not there randomly. sen but they're but they're there at a German word creeping but they're really there because they they have a dactic meaning like they they have a reason for it you know if you think about it from that mindset then it really enhances your writing and and your teaching you know because you're like okay oh yeah I understand parallel structure of course it makes it much easier to parse this list or all right yeah the code block shouldn't just pop up but I should have an introduction for it so that the reader's mind is primed for what's to come and then you have a rehash of what happened after like it's all it's all very um fundamental dactic principles I would say that that just have a a certain shape that's encoded in our style guide and yeah I agree it's it's overwhelming at first but I feel like the authors that take the most from this process which by the way we put if it's hasn't come clear yet we put a lot of effort into it right yeah the ones that take the most from it are the ones that that engage with it and think about okay so what what can I take from this? What's what's the reason behind this? What's the dedactic meaning for me to to format something in that way? And I think like Brenda's really great at explaining uh that as well and give the reasoning for why she's requesting some dactic changes to to the content piece. >> A thanks Martin. >> She comes across as such a mean person. So >> yeah, right. For me, what's so rewarding coming out, you know, watching these authors come out of dactic and then going through the rest of the process, the publishing occurs and then they come back and write for us again is seeing how they've actually applied what they learned the first time through and without me having to say anything, without them h having to remind them. And I I just love seeing that because you're realizing, okay, like you said, Martin, they're understanding the purpose behind it >> and then flowing with it, which makes, you know, all of our jobs easier. >> Yeah. Yeah. Yeah. I have I have this feeling like that. Um I mean, this is absolutely not our stated business or whatever or what we would make any money from, but um one job that we do is educate uh technical writers. I think you know >> that is so true. >> A lot of our energy goes there and and and also time and effort. >> We should have a separate course. >> Yeah. Exactly. The separate side school. >> Yeah. But also like what what I am trying to keep in mind as a writer is not just about that you become better over doing it again and getting feedback, but it's also to minimize the frustration of potential readers. That's like we're we're talking about people all over the world like that's even more true for for for the audience and people have different skill levels and different interests uh at hand when they encounter a tutorial and I mean every one of us has been there to have a tutorial where it's a just do that and it works and you're there and it doesn't just work and like there was something something missing there and it's just a frustrating experience. We try to minimize as much as possible by always saying like in which file do you do this and even we have like one important note in our style guide like never use words like easy and simple because nothing really is and so that's all the part that that comes in there. >> It all depends. >> Yeah. It can be a bit infuriating as a reader to to see like nothing is easy. >> Yeah. Yeah. So, two other steps in the writing process here. The, you know, moving beyond the DR, the dactic review into the language edit. Is that still in your hands, Brenda, or is it maybe potentially somebody else that might do some of these steps? >> No, that is that is squarely in my hands. So, okay. Once the dactic review has been resolved with the author, I just perform a final pass making sure that all the dots, the eyes are dotted, the te's are crossed, the, you know, grammatical structures all make sense. I resolve formatting problems. So yeah, it's just a clean up, a polishing of the language. >> Yeah. >> And it's also when I focus on the tone and the clarity of the language. So if something seems a little unclear, I'll just go ahead and make the change. I don't go back to the author and say, I think we should, you know, slightly rephrase this. At that stage, I'll just make it and, you know, it's usually something quite small and insignificant, but significant in the long run. >> Then going back to that visual consistency piece, I make sure that everything looks good. So, I'll look at it on my phone. I'll look at it online. I'll make sure that there's no extra lines that the formatting all matches up. And um yeah, just make sure it's, you know, in topnotch condition for publishing. >> And also something I feel like mentioning here is like that brand also really like we talked a little bit about the you have a harness and then the creativity can flow inside of that harness, right? I feel like that's the case both with uh with the uh you know the guidelines for the structure of the tutorial and the intents and then and then also the style guide around it. There's still a lot of work that Brenda does in preserving the voice of the author. So it's not that everything while everything has a real Python feel, it still also has the feel of the person who wrote it uh and the the personal part that they put in there as a writer. And I think that's really important and and you know that makes it so rich also like going back to what Philip mentioned that we have so many voices that write for us and and I feel like this voice gets preserved as much as I mean this all sounds a little like I don't know a little high nosed or whatever as if we're like creating this diamonds there or something. I know it's just it's just learning material, right? But but we do care about it a lot and we do care about the quality a lot and and also like about the the people doing it. So yeah, we wouldn't uh Brendon would never go over something during a lang language edit and make significant changes so that you don't recognize your tutorial anymore when you wrote it. So it's it's nothing like that. It's like >> I would never ever do that. Thank you for bringing that up. That's actually a really good point. And that's a big that's a big thing for me is making sure that the end result still it sounds like the author's distinct voice and that you can see that because The voice is really the author's personality on the page. And it comes from different things. It comes from word choice. It comes from the length of sentences and rhythm that the author uses, the formality with which they write, the um well, of course, their point of view, but they all work together to create that distinct voice. and um you know as opposed to just feeding it all through an LLM and publishing whatever that spits out on the other end. >> So there's an intentionality to it >> stylistically. >> Yeah. >> So it's important and I think if you look back at authors who have written for us more than once or twice and read their work, you can detect their distinct voice in each of the pieces, which is pretty cool. >> I definitely noticed it. I mean, I I talk about offhand doing my own like review and and sort of uh wanting to hype and and talk about the different things on the show. And so I I I definitely noticed it, you know, across the years like, "Oh, this there's another Garina piece. Okay, I know what this is going to be." And, you know, a handful of the other external people like uh somebody new like Rodrigo, he's got a very interesting style and I think it's been maintained. Uh Steven is another one. So, yeah. It's time to shine a spotlight on another real Python resource. Do you feel it's time to stop copy and pasting Python code from chat GPT and learn to build projects with an AI agent that lives inside your codebase? If AI only helps you with small tasks, you're not using the wrong AI, you're using the wrong workflow. The developers who learn Agentic coding workflows now will be building at a different speed 6 months from now. Our two-day live course gets you there. It's titled Cloud Code for Python developers hands-on agentic coding. And your instructor is also one of my guests this week. Philip Exeni, Real Python core team member, and he's going to take you through getting oriented, setting up the agent in your terminal, scaffolding a project from a single prompt that you can use for all your future Python projects, integrating Git and GitHub, all handled by the agent, setting project conventions and making the agent follow them, building your first feature end to end, finding and fixing what's broken, and then building a fullyfledged terminal app with UV that cla code can access from anywhere on your system. It's a two-day course. Both days are 4 hours of live hands-on instruction via Zoom. You can code along in real time, all with Q&A available throughout. Check out the live course. It's scheduled March 21st and 22nd. You can enroll today at realpython.com/live. That's realython.comlive. Well, we have one final sort of review process involved here, which is a final QA. >> So, yeah, that goes back to the internal team that's been doing the TRS before. This is usually a different person who did the TRS, but it's one of the people who do TRS. >> Sure. >> If that makes sense. And uh that's like the final step before we we move a tutorial in front of our audience's eyes. And here yeah this is essentially doing a final quality assurance. That's what it is. It is going through the the tutorial as a learner and making sure that there's everything still makes sense that there's no nothing that changed accidentally through the previous phases that that would make something not function or I don't know there's things that we catch sometimes in there. We have this line highlights and sometimes those slip through through an edit that that happens in there. So that's something that that gets changed there. It's like a technical thing sometimes like of like highlighting lines of the code or right other things that that could potentially by putting it into the system or whatever could get messed up. And so it's almost sort of like making sure all the that everything's been preserved going through all the systems and and making sure nothing's gotten altered. >> Yeah. I feel like it's it's the you're the first like entirely I would say technical reader audience to go through it and still flag and highlight anything that seems off there and with the eyes of someone who's been doing this a lot and has a lot of experience with real Python articles just because it's on the internal team and so we we spot a lot of stuff obviously also style guide related things if there by any weird chance is anything left over after Brando touches it which usually isn't the case, but then there's another person's eyes on it and there's some some edits at that stage as well and then it gets scheduled and yeah gets ready to to go in front of our members eyes. And we mentioned one of the tools that we use during the writing process throughout this whole process. I think we briefly mentioned that we use Trello, which is a canban style tool where you can have cards and and move them along. uh maybe people in other creative fields have have have seen something like this or even work on projects and so this is kind of the next step is like okay move it into that scheduled field and is there anything unique that goes into that or how far out does stuff get scheduled >> that depends a bit how much content we have ready to go we try to if you're a real Python member then you get to read the tutorials as soon as they're scheduled basically but then we have a publishing date that's usually further in the in the future. So with this, we also want to give our members, our paying members an additional >> Yeah. some perks here. Yeah. >> Bonus. Yeah. That they get like early access to these tutorials that then later also come out on this publishing schedule that we follow later on. So we schedule soon once we have the content ready and then there's another date which is the publishing date which yeah like I mentioned for us a certain publishing like a calendar and goes out on certain days. >> Yeah if people haven't paid attention to it we basically have uh articles come out on Mondays and Wednesdays. Tuesdays is usually when a new video course would be highlighted and Fridays of course is the podcast. So, am I missing anything there in the publishing schedule? >> We also publish other things. We publish quizzes. They're a little less advertised, but yeah, we we publish quizzes. They kind of go out on Tuesdays and Thursdays, but it's not such a strict publishing schedule as as it is with the other content pieces. But yeah, we have we have a lot of quizzes, a growing amount of quizzes as well. We're also doing the backlog of our quizzes for for tutorials uh that didn't have them in the past and for video courses that didn't have them. We're working on getting dedicated quizzes separate for a tutorial, separate for a video course to to give people a chance to test their knowledge with interactivity that is I guess forced interactivity because every tutorial and video course can be interactive if you make it. So >> yeah, >> but but the quiz you Yeah, it needs to be. And we're also working on on coding exercises. So that's something >> that's something new. Yeah, >> new that's coming soon which is going to expand on we already have code questions in quizzes but it's expanding on that making it more solid and a really nice much nicer experience for you to practice the concepts that you're learning about in uh in the content. Yeah, one of the things that I focused on with Dan uh near the end of our conversation is that we've been doing a lot of requests for feedback and I I hope it's not overpowering people in a way. I know that the world is asking everyone for feedback all the time, but we read all of it was something that we focused on a lot and we are almost continuously looking at our existing content and looking at ways that it can be improved or updating. And I don't know if you want to just if we can briefly talk about that and maybe what maybe goes into you know why would you take an old piece and rewrite it or uh restructure it. >> Uhhuh. Yeah. I mean this tech field is moving very quickly which is exciting in a way but it's also a little overwhelming you know uh for for everyone. For me it is for sure. uh like how do you keep keep track of everything that's happening and if you are managing a site with so much content as real Python it's especially overwhelming because it's like okay so did this just went out of date or did something that's been going through this wonderful process that we have and it was technically sound when it came out is like not working anymore because something changed you know yeah we need to I guess like keep track of this necessary updates it's a big job that I wouldn't say we have like have it figured out all the way yet. At this point, >> we're constantly addressing it across, you know, not only the video courses and the written courses and all that stuff. >> So, what we're doing is like Chris mentioned, if there's a feedback coming in, that's definitely something we look at and then uh put it try to implement it. If it's a quick fix, we implement it. If it's something that requires, you know, a whole process or or a larger rewrite, we put it uh we note it somewhere and put it put it on the backlog and then >> it gets a card on that Trello thing there. >> Right. Yeah. And then what goes into deciding is is a mix of how popular is the is the topic like is this going to serve a lot of people a lot of our learners if we go in and updated this you know how how severe is the problem and then are we actually going to manage to do this right now or is there something else we need to focus on more so there's there's some balancing to do there but I mean ideally I would want to make sure that everything is always up to date um >> right >> I haven't entirely figured out the way to do that but We're Yeah, we're definitely thinking about it. >> Yeah. One of the things I wanted to focus on across the whole thing is just that there's a lot of humans involved in all of this stuff. It's not that we are opposed to using tools. In fact, we've been exploring a lot of that lately and maybe we can touch on that briefly, >> but our content is not written through LLMs. We definitely are opposed to like having automatically generated content and obviously in our case we're looking for you know stuff that is again didactically sound uh is in trying to help people learn new things and so forth but at the same time we you know we got to figure out ways to continue creating content all the time >> and you know these tools can be handy like you know for like in the review process especially things like QA kinds of things like okay we found that this is kind of missing or this punctuation is wrong or things that as a human being as you look at I don't know how many articles in a week it could be handy. So anybody want to speak on that? >> Let me like speak about it for a second just because you uh we talked about the updates before. I feel like so I'm working on things there to to try to use also a gentic workflows to figure out these tools are very powerful at this point and it gives me for example a chance to to highlight an LLM can read through all of our tutorials can pull from the web what is currently the upto-ate version >> find some of those gaps in our learning paths sort of automatedly. Yeah, >> that too. Yeah, that too probably. But I was just thinking about updates like so literally to content that that is going out of date like it it can just read through the content figure out what is the current version of a library and where there are any breaking changes because it can just ingest that change log and ingest the tutorial that that we wrote and then figure out if there's any problems. So it's yeah I'm working on tools that can help surface stuff like that for example for me so that I can then figure out the next steps of what are we going to do with this content? Is there something that I can assign to someone to to update it? Can I have the LLM read over it and identify what Okay, so this is just a small change. Uh something's broken here. You need to use this other method because this one was deprecated or something, you know. >> Sure. And that obviously gives a lot more reach into the content to have a chance to work on work on that high goal of having everything up to date all the time which is something that's probably far out but it's like uh something I would like to get closer to. Yeah. So that's an example an example use case. Yeah. I think I've mentioned this on the show a lot that we use Django that we are a Django shop that is our content management system and there's a lot of custom code that's been written in it and one of the things that has been built into our system is a tool to to do a check you know like we've talked lots of checks and lots of areas where human beings are looking at things but still you know like one of the things that I have a problem with sometimes because I'm copying and pasting ing and assembling show notes for for the podcast. I miss like okay I got a bunch of weird white space and you know you can't see it unless you're you know doing something and so we have a tool that does a pre-flight. It just goes through it also looks at my links and says are any of these links dead you know or don't go anywhere or they you know things like that. kind of fundamental almost spellchecking kinds of things that are you know related to that in in the system and we didn't really talk about that but there is some you know it's it only makes sense to have some automated systems for a publishing house you know like we are >> absolutely I think and I think what it provides us with is it removes some of the toil from our day-to-day so we can you more clearly focus in on, you know, the meat of what we're doing and where we bring value as team members here as opposed to, you know, doing all the transcripts by hand like I used to do. Right. >> Yeah. So, it just frees us up in a little ways in little ways here and there to Yeah. focus more completely on those important parts of our job. >> Yeah. One of the things that as as we start using you some of these tools, they use this term dog fooding very often in the world of technology like you know are these companies using their own tools to kind of do this sort of stuff. And since we're writing about these tools and and getting introduced to them and and figuring out ways that we as a you know again a publishing company here, how can we use them and make ourselves efficient with them and and what are effective uses and potentially not effective uses uh as we kind of go through these things? Are there other things that you're thinking about with that, Martin? >> Yeah. No, you mentioned the pre-flight tool like some automated checks. I I I can totally see uh also a version of that that is powered by a language model where we have accumulated so much experience in reviewing content in the different stages in the outline or in technical review and we've been providing this this pre-flight checks to authors already like they they upload something you know and we encourage them have been for for years to encourage them to run this checks this automated checks to make sure that the tutorial is in a better shape before it goes to the the person who reviews And I can totally see like extending these two. >> It's like linting almost for them. >> Linting. Yeah. But but now with large language models that this can go way beyond linting. That's that's the exciting part like you know like it can actually reason about language and it can reason about code. It can spin off agents that execute the code that you have in your tutorial uh and and see whether it runs or if there's any issues with it. Can even do research like what I mentioned about the updates. can go in there and look at the documentation and figure out whether you got something wrong or whether there's maybe been a release since you've started writing this this piece of content that you should address because it breaks something or or who knows what, right? So, I can totally see also that I I would say like we're not there yet at this point where but we're experimenting with this like figuring out how we can have automated feedback to our writers as well that helps them improve the content before it then goes forward to to their reviewer which like Brenda mentioned is going to save us time and bring the content quicker to a great stage that that's then like approximates the ideal of the real Python content that we want to provide for our learners. And I think as coders are maybe comfortable with linting are comfortable with code suggestions and and other types of tools often if they can catch a lot of these things themselves before it's brought to the human being to do the review. They're happy to eliminate that from the conversation. We joke all the time about like code formatting shouldn't be part of code review. like that shouldn't be what we're arguing about. If stylistically you can hit all those things and and get all the little goofy red marks out of it, the process, I think a lot authors would would >> like that. So I I agree that that makes a lot of sense. And and another part there is too like uh like I mentioned at the beginning this is like there's a big industry shift happening for software developers and we're there at least for Python I like to see us as a center of of teaching people who are uh working with Python right and and helping them not just get started with Python but also helping them in their professional roles to you know keep up to date. So this is definitely something that we need to learn about and address so that we can also be professional and good at teaching what's what's the relevant parts to you know our members and and our audience. One of the things I wanted to focus on, kind of wrap everything up, is that we have this internal team, this core team that does a lot of this work behind the scenes that a lot of people maybe aren't aware of, and it's kind of nice to be able to shine some light on it. But at the same time, we really do try our best to like shine a focus on all the different contributors. If you get to the end of basically any of our content and you get to the end of a video course, you get to the end of one of our articles, you'll see, you know, the author, but then you'll see these contributors. You'll see Brenda's name because she was involved in it or potentially people who have been doing some of those roles in the past. Philip, you wanted to talk a little bit about that. The idea of like we like giving credit. I know that's a big part of what makes Real Python real Python. >> Yes. because it's also one motivation that people who want to write for real Python also have. It's kind of like it's it's cool to have something out there being it for real Python or or anywhere. And as a reader, if you read a tutorial of real Python, like the the first thing after the title is like who who was the author of this tutorial? And like you were just saying like if you scroll down in a tutorial, you see all the people who worked on it. And also to to note like there is always aluld in it because every tutorial gets a handcrafted artwork >> which uh I think is amazing that we have our own artworks there and I think as a reader that's kind of hopefully gives you trust that went through those iterations but I think it's also nice to see like there were people like doing this for you as a reader to give you a good learning experience and that's what kind of what I like before I joined real Python like I like to visit the site and now that I know more about the behinds, I also appreciate all of this iteration and this feedback. It takes time and it's hard sometimes, but it's cool to have something in the end that that helps people. >> Yeah. And I mean, if people have never clicked through on that stuff, please do. Like, if you like the way somebody writes, uh, again, us trying to keep their style and, uh, their voice in there. If you like that part or the topics that that person seems to be interested in when you drill into what their name is there, it it will show the other work that they've done for real Python and potentially link out to other stuff that they do. And so, you know, we definitely want to give credit. Any one of us, you click on it, it's going to be a avalanche of stuff because we've touched so many things um across the board, but it's least categorized. So, I guess one last note that Dan wanted to help us bring home is that we are an independent organization. We we write this stuff because we want to write it for our audience. We may feature a particular library or particular service or what have you, but this is our own independent thoughts on these things and we want to kind of focus on that. Anybody want to speak on the editorial independence that we have here? I can just say like when I was listing the reasons reason reasons why we pick topics that wasn't part of it. I didn't even think about it because that's just always been like that here at Python that there's no >> it's inherent. >> No, but yeah, that's that's just not it's not a factor when picking content uh topics and we're also pretty proud of that that it's that we're really focused on providing the most value for learners. And that doesn't mean we're not going to talk about a tool that is also maybe uh for purchase or something, but we're not going to talk about it because they asked us to or they're giving us money to do it. That that's just not happening in our in the company. But it it only happens if we generally have the feeling that this is something we or an external author whom we're working with has like a a good reason to use and generally finds helpful for solving, you know, the the problem that they have. Yeah, there's a true firewall between the people that do our sponsorships and, you know, our editorial staff. I don't think we speak about any of that stuff in between there. >> We don't even speak to each other. >> Yeah. Hardly. That's a whole that's a couple other people. So, >> yeah. And something else to mention when we're talking about tools is that we're honest in our um content about tradeoffs. So, if something increases cost, we say that. if it, you know, adds complexity, we say that if there's a better alternative for certain use cases, then we'll point the readers in that direction. So, we're just really coming out from a >> yeah, >> purely unbiased um viewpoint. >> And there's some opinions there, too, like from, you know, the authors and their voices too about, you know, what they're what they think of the thing. So, >> yeah. >> And yeah, one of the in intents that I talked about that we've introduced to our content is a comparison type where it's okay. So there are a couple of options for this and maybe you know about all of these options and but you don't know how to decide basically and then that is an intent that readers have or that learners have that use the site. So um yeah, we present them with the options and give them a breakdown of uh why they might want to choose this one or that one and then give them you know depending on it's not like biased towards one or the other but it's like this is what we think and why and then you can take your own choice basically. >> Yeah. Yeah. Well, I want to thank everybody for helping me go through this deep dive into real Python's editorial uh decisions and our process. >> Fun to talk about it. We don't really talk about it that much. We just we do it a lot but we don't really talk about it. >> Yeah. >> Yeah. It was even a more of a discussion in some areas here which has been cool. >> Yeah. Thanks for having us. >> I'll do oneonone here. So, uh, Philip, thanks for coming on the show again. >> Well, thanks again. >> And Brenda, thanks for coming on the show for your first time here. This was great. >> That was great. Thanks for having me. >> And Martin, thanks again for coming on the show. >> Thanks for having me. Thanks again to Agent Field for sponsoring this episode. A thousand agents coordinating autonomously. That's not science fiction. That's what they call the AI backend. Agent Field is an open-source framework for building AI backends that reason, just like you'd build APIs and microservices today. Search Agent Field on GitHub or visit agentfield.ai. AI. That's agentfield.ai. I want to thank Martin, Brenda, and Philip for joining me this week on the show. And I want to thank you for listening. If you like the episode, a great way to help us grow our audience is to share it with other Python users who you think might enjoy it. You can also leave a rating or review on your podcast platform of choice. If you or your company are interested in sponsoring the podcast, you can find all the information at realpython.com/advertise. You can find show notes with links to the topics we spoke about inside your podcast player or at realpython.com/mpodcast. And while you're there, you can leave us a question or a topic idea. I've been your host, Christopher Bailey, and I look forward to talking to you soon.