Know Your Limits: On Surviving Open Source by Carlton Gibson

Speaker 1: Thank you for having me. I'm Carlton. I'm excited to be here. I'm excited about the Django Nortes programme. I think it's just the best thing to happen in Django in so long. And so to get to talk to you is a real treat. You know, it's it's it's exciting. Um today's talk is called Knowing Your Limits and Surviving Open Source. So you're excited to be on the program. I'm excited about the programme. Everybody is exciting. So so excited like his Tim. I'm loving the energy from the latest Jang <unk> cohort Every meeting needs to be energetic, wanting to solve all the problems. I'm excited for the future of Django. So it's not just the program, it's not just being here, it's everything, right? Um But open source just isn't all rose always roses. It's just not.

Speaker 1: So I want to give you some thoughts on that and hopefully you can take those away and then all the excitement of the the program we can avoid the the the the bad bits that's the that's the high-minded goal of the talk um but if i'm gonna give you some thoughts on that then i have to really answer a question who on earth is this old man And why on earth should you listen to me? Um well my I'm Carlton. Well, okay, and this is me and there's my avatar there and I'm on GitHub at Carlton Gibson and I'm on Foster Don and I'm I've got a website where I blog and You know, I've got a podcast, Django Chat, with my friend Will that you should listen to. You should check all of those out. Please follow along. There's a RSS feed if you like that sort of thing. If you don't know me, then between 2018 and 2023 I was one of the Django fellows.

Speaker 1: And I got to be the Django fellows, they look after Django, right? They keep it on the road. And I got to be the Django fellow because I'm a maintainer of lots of things, Django. I've been using Django essentially forever. And as part of that, I spent more than a decade helping to maintain a number of the key packages in the ecosystem. So you might have heard of some of them, Django Rest Framework, Django Filter, Django Crispy Forms, Django Compressor, Django AppConf. I maintain the channels trio, channels, Daphne, channels Revis. At the moment I'm playing with Neopolitan, which is my take-on quick crud views for Django's and Django template partials, which gives named template fragments to the Django template language. Now all of that is just to say I've been at it a while, right? I believe in open source. I'm vested in open source. I think it's wonderful.

Speaker 1: And if you were to say to me, hey, should I do open source? I'm going to say heck yes. Right? But I've also been around the block. I know the potful the pitfalls. I've seen them in action. And so I'm hoping that my few words will be use to use to you in the context of the Jaggeronauts program as you step out on your open source journey. That's the idea. So while we're going, I want you to have a question in mind. I want you to think, what is it that's driving you? What is it that you're here for? Why are you doing open source? So let me just give you some reasons why you might be doing open source. Well, open source is an investment in your business. I began contributing to Django Rest framework. Because I was building my career, my business around Django. I was using those handful of key packages and I had to know that they were going to keep working, right?

Speaker 1: I couldn't have them just break. So by contributing to those packages, I could guarantee that that one of them wasn't just going to fall out under me. Like Django Crispy Forms, the reason I became a maintainer of Django Crispy Forms is because it was literally at the point of doing that. If I hadn't have stepped in Django 1. 8 would have been released and one of my key dependencies would have been broken. What what was I going to do? I'm going to take it on. Open source, where it's a great way to learn. I say it's a great way to learn. I actually think it's quite likely the best way to learn. You want to up your skills. Well, open up the source code of one of your dependencies, say Django. Start fixing issues, reviewing P cars, PRs, adding tests, depending on your level. You know, you think you know Django now, right? But you will do after you've done a few bits of open source, I promise you.

Speaker 1: The depth of knowledge increases. So I was building API backends for mobile apps for Django REST Framework. That I was also helping to maintain REST Framework meant that I knew it well enough that I could make the the the customizations that you always need in any project. Nothing's just straight out of the tutorial. You always need to do something custom. Well because I knew throughout the framework I could do that. And I think You're also learning on some of the best code out there, right? The code that you work on at work, it's probably not that great. It's it's it's start to get matched stick starts to go with glue, and that's how every application always is Well, open source code is generally a bet a level above that and you're learning from that code, so you can pick up a lot. Open source does wonders for your CV. It can help your profile, right?

Speaker 1: I think and that's at every single level you are. If you're a junior with no relevant experience to lean on, being able to point at the project that you've been active on shows exactly what hiring manager is going to be looking for in that interview And it's almost certain that none of the other applicants for that job have that experience. It makes you stand out from the crowd You can't always show work that you've done, right? There's probably some D NDA clause in your contract. But even if you weren't, this kind of proprietary private code, you can't show it. Well, they often want to see sample code. So if you can point to your open source contributions, that's something that you've done that is visible and which is publicly shareable. When I started on Rest Framework, it fundamentally altered the hiring conversation for me. Instead of them being skeptical, well, you know, can this do it?

Speaker 1: How do we can this guy do it? How do we know? Is he any good? I I was they were like, oh, you you um You maintain rest framework. Yeah, yeah, we're using that. And so it it just, you know, instead of starting here, you're starting all the way up here. It radically changed it. Now it it doesn't do that instantly. It takes time to build up a track record, but open source, it really opened an awful lot of doors for me, and it can do the same for you too. But I think more than all of these is open source is a chance to give give back. I think investing in your business, learning, building your profile, they're all great reasons to be involved in open source. I think they're valid, but I don't know anybody who's been doing it for a while who does it purely for those reasons. Python, Brett Cannon, who's a core contributor, longtime core contributor to Python, he's got this phrase, I came for the language, but I stayed for the community

Speaker 1: People talk about that all the time. In Django, we have this idea that Django is first and foremost a community, and then it's an ecosystem, and only finally it's a framework. So in Django, the Django bit, like that's the least of it. That's the bit that matters just the absolute least. It's the friendships we make, it's the relationships we build. They're the point of it. That's why we keep coming back. The community is built on the individual efforts that we each put into it, be that code, be that organizing a conference, be that a meetup, be that a program like Django Nauts. Right. But the community is more than these efforts. It's kind of like a commons that's a shared resource that we've built. And you know, in 20 the 21st century, that you get to be a part of that shared resource. I think that's a truly wonderful thing.

Speaker 1: You know, the hell anyway. So why are you doing open source? Right? What is it that brings you here Now it's important because there are dangers. And when I was typing up this slide, I spelt them the dangerous. And I don't actually typing it away. There are dangerous. I thought I'd leave that there. If you're clear on why you're doing open source, it it helps you to avoid the dangers, right? So that's why I want you to hold it in your mind. What is it that brings you to Django Nuts, to Django, to contributing? So A warning. Being an open source maintainer puts your physical and mental health at risk. The reality of open source is, well, you've got a full-time job. Maybe you've got a family to support, you've got rent to pay or a mortgage to pay

Speaker 1: On top of all of that, you're squeezing out time in the evenings and the weekends to work on your project. On top of that, you've got demanding users turning up on oftentimes being aggressive on your repo because, well, they've got an issue in their project that's somehow your fault And then there's a serious bug in the latest version that needs a new release on PyPI ASAP, and you haven't been able to get a decent session on the feature branch you're actually interested in in months. And people keep asking you in discussions about when that feature branch is going to be ready. Right? Open source contributors, they burn out. And with the stress of it, there's no wonder. In Django, we used to it used to be called the meat grinder Inde it was it's still dark humour. The meat grinder. Imagine it, like imagine it. Ganga would take

Speaker 1: New contributors that chew them up over a course of a year or two and then spit them up and so oh we need some more meat for the meat grinder, right? I mean That's what it was like. So I think in open source we have bad expectations. People treat open source pentains like they're being paid for it, as if you know not just that the maintainers are being paid the the the the the contrib the the the user was paying the maintainer themselves right rather than just sort of taking it for free. I need a new release. I need this feature added. I need this bug fixed and I need it now. And this never ends. The men maintainers, well, we come to identify as maintainers, right? I maintain Django, and that means that I'm expected to show up

Speaker 1: and to do so, even if that's the last thing in the world that I should be doing right now. When I began in open source, I saw I watched as heroes of mine in the Django community struggled with this problem to various degrees of absolute full meltdown. It's it's the biggest danger. Um, because of this, well, we've got the Django Fellowship Program, right? The Django Fellowship Program was created so that the fellows could do the day-to-day maintenance maintenance on Django and then make sure it keeps going. And it's absolutely clear to me that the fellowship program is the reason that Django was able to keep going until it's nearly 20 years old. Without the fellowship program, that just wouldn't have happened. It might have got to five, it might have got to 10, but it wouldn't have got beyond that period. Right, but here's the warning, you're not being paid.

Speaker 1: Right? Now you know that, you're painfully aware of it. We all know that. But we don't always act like we know that We've often give far more than is reasonable given the fact that it's a volunteer thing that we're doing. It has a consequence. Open source skews overwhelmingly white, male, and English speaking. The bottom line is that contributing to open source is a privilege that only a few can afford. We like to think it's a meritocracy. Well you do the time, you get the heart, you do the hard yards, you work on your project, you get the rewards, but well sorry, meritocracy my arse What's really going on is that pre-existing economic relations are being reinforced by the contributors leveraging the inequality of opportunity that those economic relations provide.

Speaker 1: Sorry, in English. If you let it, open source extracts such a cost, physical, financial, and emotional, that only that the only folks who can do it are the global rich. And only of those, the ones that are either directly supported by or can make their way around the patriarchy. English speaking white men. You notice I say it said if you let it. Or you may not have noticed you said if you let it, but I did. Because it's not all doom and gloom. Remember, I believe in open source. I invested in it. Remember, should I do open source, Carlton? Heck yes. Right? So what we're going to do is talk about, well, you know, what to do or how to survive open source. I'm going to give you a couple of tips that you can take you can think about as you go along. So tip one is know your limits.

Speaker 1: This was the title of the talk. right think about your limits limit the time you give to open source look after yourself correct the expectations at least for yourself right You you have to put your phone gas mark, right? You you're busy. You don't have a lot of time for open source. Well, that's totally okay. Maybe you have an hour a week and maybe you can glance at GitHub when you're at the bus stop. Well, that's it. Well, so be it That hour adds up over time, but if you're going to keep at it over time, it needs to be sustainable. So set that limit and then stick to it. And if there's an issue that needs fixing, that's not your problem. It will wait. You do your bit and that's enough Now if it helps, then those that'll just tell you that those who are actively involved in open source, they know this.

Speaker 1: You'll get pressure from random users on GitHub. After all these years, I have absolutely nothing I can say about how you stop that Right? You'll maybe give yourself exit the pressure. Oh, I should be fixing that bug. Well, that's exactly what setting a limit is all about. Right? If you change that expectation for yourself, you can take that pressure away. But you will essentially never get pressure from other maintainers. As I say, they know that they're not going to give you that, right? Think about your limits. As part of this, take an amnesty, there's a lovely website called volunteeramnestyday. net, which is every solstice, take an inventory of your volunteer responsibilities and any Anything that you think is too much, you're allowed on that on that day. You can just say I take an amnesty and I'm giving it. So summer solstice, winter solstice, take it. I love I love um volunteer amnesty day.

Speaker 1: Um I think it's just such a lovely thing And then while you're thinking about limits , think too about your project limits, right? So you've only got so much time, but that means that your project. . . uh has to fit in the time that you have available for it. So keep it tight. That means you have to say no to requests Something might be nice to have, but if you can't sustainably maintain it, then it's a harm to you and it's a harm to your project. So it's also, you know, no, it's also about fun. Code that gets too complex is no no fun to maintain. Or can we add this hook? Well it's dry. Oh but it you know if you add enough hooks your code becomes unreadable. It's no fun. Can we just add this keyword guard? Well, code that no one's using is so much fun. If you A user comes on and they demand this keyword

Speaker 1: ARG for this 1% of of use cases. It every user then has to read about it and realize it's not for them and understand it and your code becomes less fun to to maintain. So you add it, but then it's you that's on the hook to maintain it. And not even the user who originally you requested it is using it because they've gone off and they're using some other project. So keep your code tight. Don't think about the limits of your project. And then think about the limits of other people's projects too. Because there's a flip side. You want to make a contribution to a project, but does that fit within what the maintainer has available to give to their project? You're asking them to say take on something that has a cost. And you'll be upset if they say no. But like step back Do the empathy work. What's it look like from their end?

Speaker 1: Maybe there just isn't room in their project for your feature. You want more? Well, I want this feature. Yes, well fine. You want more? Well get help or help yourself. Right? If we actively think about capacity limits, we can build projects that are sustainable in a really wide sense of that word. But they can keep going, they can grow, they can stay the right size, they can not consume too much of the love, the life force that we give to them. Right. So know your limits, right? That's step one, right? Really think about what the capacity really is in open source. And then step two, well, tip two, that's maximize the juice. You're not getting paid. You don't have all the time in the world to make thousands of contributions. Well, so let's make the ones that you do make, let's make them pay.

Speaker 1: Right? So third point one of this is put it on your CV. Seriously, don't be shy. Oh, it wasn't enough to brag about. Rubbish, put it on your CV. Oh, everyone has better things to say. Rubbish, put it on your CV. Most people don't have anything to say. Hiring managers are desperate. They've got a mountain of CVs or ECVs. They're this big, right? And they're desperate to find something that lets them sort them quickly into the yes pile and the no pile. They want most of them in the no pile. So if you've got an open source contribution, even if it's just one, it makes you stand out from that crowd. Okay. Put it on your CV. And then keep a public blog. Like keep do keep a blog. Do a little Django app just for yourself, your playground. Put it online and then write about what you do.

Speaker 1: I cannot stress this enough. You do a little post, you think it's nothing. You end up in Django news news and a tech lead will subscribe to your RSS feed or they will follow you on Mastodon and then you'll mention that you're looking for work and then you'll suddenly get an email or a direct message. Why? Because you put it online. Need inspirations, or see the fellow reports that Natalia does on the forum. See the lightweight, T I L. Today I learned post. that people do. So you don't feel like, oh, I have to publish this 10,000-word definitive blog post on the, you know, the nature of the ORM abstraction. No. Today I learned that you can override the form set method that do this, right? Just put it up, lightweight things. The bottom line is that your contributions and your learnings they add up over time.

Speaker 1: Now, if you have a public blog. That adding up is visible and you can use it. But if you haven't got that public log, it's not visible and you can't use it. So it's up to you to make it visible, to put it out there, get yourself a little Django app, build it yourself, get it online, use it as your playground and log what you do. Then tell a story. So take a single issue you did and elaborate on it. Make it into like a case study Like write up exactly what you did and what you did. You go to an application, an online application, or you go to a job interview, and they'll say, tell us about the time that you use Superpower X to do wonderful thing Y. Well take the case the the case study that you've written up and then fit it into the template because it's always

Speaker 1: like I used my teamworking skills to achieve a thing. Okay, so I just oh I worked with other people to get this thing that I've written up done. Or use your reasoning skills. Oh well I you know or used your code awareness. Whatever the the how tell us about is a stock question Tell us about the time that you did X. You used X to do Y. And you the X and the Y, they don't matter. Take the one, take one thing that you do. And write it up in depth so that you can repurpose that for these interviews and you've got it ready and they're like, oh wow, this candidate really knows their stuff. And then the final section of this one, this is the career hack. Career hack is learn the tooling. Let's say you get a job. And let's say you turn up on the first day, there's a totally alien code base, and it's incomprehensible, and

Speaker 1: you can't do anything. But well let's say they don't use black. Well you can add black, right? Because you know about black because you've learned the tooling working on the open source projects Let's say they don't use ISOR, well you can add ISOR. Let's say they don't use Splay K, well you can add that. They've got GitHub or but they haven't got CI. Well you can set up CI or they haven't even got GitHub. They haven't even got version control You know, whatever it is, you can add those things because you've learned these tools working on the open source projects. They can't upgrade because they can't test the new version. Well, you know about tops, you know about testing different versions you could because you've learned them on the open source projects, or whatever. Well they have docs. Let's say their docs are like a few text files just stuck in a folder and that's their docs. Well put them into Sphinx, right? And then put a you know a site up with the the the fancy fulo theme that everyone uses that's nice to look at.

Speaker 1: Oh wow, isn't that great? And so on. By the time you've done all that, the team are like, wow, you're great. And their lives are a whole lot better than they were when you turned up. And You've had the time to get to learn the code base so that you're now productive on it. And it's like, well, this person was productive from day one. You weren't productive from day one. You added black. You added ISOUT. You added fake eight. You set up restructured text And in the that time you sneakily learnt enough to actually get some quote unquote real work done. You were enabled. So your review comes out, your annual review or your quarterly review, whatever it is, and you say to your boss, you know, boss, I'd really like that mid-level role, please. You think every team already does all this. You're like, oh no, but that's not going to help.

Speaker 1: Open source projects are doing more than the median team by a long way. If you take everything you learn on a best practice open source project and you take it to an employer, you are going to be valuable from day one. So that's more or less it. So I've been open source will know your limits, yours and others, and get help if you need it. And then maximize the juice. You're doing a good job. Tell people That's it.

Speaker 2: Well done. Thank you.

Speaker 1: I'm gonna stop sharing my screen now. Um

Speaker 2: That was excellent. I don't know if you saw in the Discord Mo said he was loving every second of this talk and I was that definitely was how I felt as well.

Speaker 1: I didn't see. Where was channel are we in in the Discord?

Speaker 2: Uh the general channel.

Speaker 1: General general general. Okay, brilliant.

Speaker 2: For everyone. Thank you.

Speaker 1: Thank you, Mo.

Speaker 2: What we will do is uh use the raise the hand feature, or if you want to type your question out, um we'll go that route. Uh I'm gonna start with one. Um Carlton, so you said uh the the last part there about learning some tooling. If someone wants to like improve their pure developer skills, do you have any suggestions on resources or places they can go to learn that?

Speaker 1: So I'd recommend for this kind of um tooling type point, I'd just recommend Adam's book. Um uh Which is called something about Django developer experience improving something. Ah Adam just get Yeah, yeah, yeah. Thank you. That's the one. And he goes through like the flakeates and the the blacks and the iSorts and the uh the the pre-commits and like all these these tools that we use and he's got um You've got a three-pack of books. Just get all three because they're all amazing. And just get the e-edition so you get the free updates for any updates. Like literally just invest in your career and go and buy those three books would be my kind of thing. Yeah, that okay, that's the answer. Get Adam's book.

Speaker 2: Thank you. Anyone else with a question?

Speaker 1: How do I add a reaction to prinus?

Speaker 3: I have a question, but I I can't find the the raise the hand feature. Yeah, it must be somewhere.

Speaker 2: It's under reactions

Speaker 3: It's under reactions. Ah, got it, got it. Okay, fine. Um

Speaker 1: Yes

Speaker 3: sound. So um I don't feel any pressure when I see people but like issues or all this kind of stuff. But I feel more pressure when I see other people that you've gotten to know kind of struggle with The random person being a bit more aggressive or whatever. Or also, so that's one version, and then also um uh when There's kind of like a disagreement between a bunch of people that you you like

Speaker 3: and they kind of just want it to um Yeah, progress in a nice way and all this kind of stuff.

Speaker 1: Yeah, yeah.

Speaker 3: The the dynamics I find uh more I feel more pressure from the social dynamics than I do from like the issues and things. Because I think, oh, maybe I should try and pitch in here and all this kind of stuff. Do you do you have any thoughts or opinions on on that?

Speaker 1: Yeah, I I have thoughts and opinions on everything. So certainly do on that. The people is the hardest bit. The people side of it just is the hardest bit. It's it like Oh, you know, apart from maybe some really deep thing in the ORM that might be harder than the people think. But so when somebody is being um um aggressive or inappropriate or whatever then the the analogy always have is that of a tag team so that's um when Tim Graham stepped back from being fellow I was the junior fellow at the time and I I that I spoke with the fellow committee about, you know, did I want to go more time or whatever? I said, look, I don't want to do it full time and I don't want to be the only fellow. And part of that is that I believe you need a

Speaker 1: support. Team, you need a network. I believe this Tim did fellowing like for five years or three years by himself. I don't know how he did that full time through by himself, but he did. Um but Since there were two of us, I don't think this should ever go back to being one because it's really the fellows are on the front end, which is why I picked them as a particular example. But there is often like somebody who's just being inappropriate and what you need to do is say tag me And the other person comes in and responds. It's why it's important there's a back channel in the, you know, in the chats. It needs to be, look, I need a bit of help here. And then someone else can step in and say, no, look. That I'm welling up at the thought of it. So that's my first thought is that you need support and you need to help each other when somebody is being

Speaker 1: because that just happens. That just happens. And then disagreements. You just everybody has to remember that there's good intentions in all things. And we're on the same side and we're after the same thing. And often the disagreement is because we haven't actually seen what the other person's viewpoint really is. We've got our viewpoint and we're busy arguing for it. And that's great because you must argue for your viewpoint. You must put your viewpoint forward. Otherwise you're not presenting your your case in the best light and we've got no chance. But you there's also that empathy job to try and see if and that's really hard and nobody's perfect at it and nobody gets it right every time but all of us are first and foremost more committed to the community than we are to our own particular You know whether or not we should use a keyword or have a you know a an attribute hit.

Speaker 1: Like no one care. It doesn't matter. Like I The bit of Django that I'm most committed to is less important to me than the community as a whole, but I'm still going to argue strongly for my case. Right, but so and it's not that we're falling out, really. I mean you might go, you know, if people do fall out, people do get crossed, but then you just oh okay, like It's like a piece of elastic, right? Human beings have emotions. And emotions come out even in open source forums, which should be perfectly rational. The point is the piece of elastic gets stretched and the question isn't does it get stretched, is can we unstretch it again? Because it breaks if you keep it stretched. So okay, that

Speaker 1: that conversation is a bit heated. Let's just step back and then let's try and reassess and let's try and okay. Look, I've had I've had another think about your thing. I see your put this is the bit I agree with, this is the bit you don't. What what works? It can be difficult. What works is when you're able to narrow between you, you're able to narrow down. Actually, the bit we disagree on is this really tiny bit here. And we can, you know, we we don't care about this really. So let's go, let's uh That doesn't matter. The shared agreement is much bigger than the disagreement. It turns out. But yes, it's intellectual and emotional labor. Yes, it is. And yes, it can be tiring. Does that leave anything unanswered?

Speaker 3: Uh no, I thought it was a it's a nice perspective because um uh There's also, I mean you also you made a particular point about you know having empathy and considering the spoks the scope of the project and all this kind of stuff. And most of the time when there's disagreements, it's around people suggesting something new or a change to the existing thing. And with both of those things, it's um Uh there's there's consequences. There's always consequences to this stuff. And uh But it yeah, I it

Speaker 3: I I've also found it interesting um meeting people versus how they interact just from text and stuff. That's also very interesting. Um But uh yeah, yeah, I I think it isn't as um heated as it maybe sounds on on occasion. I'll shut up because other people

Speaker 1: No no no no no You know, I didn't do a 45-minute talk, so we're trying to get it to chat. But I think it's one of the reasons why going to the conferences if you is you can if you can is is really helpful because you get to meet someone in person and then you realise that you you know they're actually they they they're you know they're just a great person and like the the the little disagreement you had online was about nothing and then the next time you chat online you're like oh I know you and then they're Their comment, you're like, oh, that's just them making they've got a smile on their face when they type that. That's why emojis are important, right? People people think emojis are unprofessional and stupid and all the rest of them. They're not, they're really important because emotion does not come across in written text So you have to put the silly little thing next to it so that they know there's a that you didn't mean it

Speaker 1: in that, you know, uh that straight way that it might have been read

Speaker 3: Yeah, 100%.

Speaker 1: But yeah, it's the most difficult one. Go.

Speaker 2: We're gonna put a Prius question in the chat. Um So Carlton Pri asked, sometimes while contributing to open source, one can get lost in the whole big code base. Reaching out to maintainers for help is nice, but there is always that slight hesitation about is this question good enough to be asked on a public platform? In the same context, one can end up spending a lot of time and adding to , in the worst case, adding no and ending up with no impactful contribution. Um how can you overcome that and know the limits uh of how much time can we spend on a particular issue before moving on to the next?

Speaker 1: Okay. Um yes, a big code base, it's just hard. Um and There's there's no there's no way out of that. You've it it Django's got a big code base, lots of codebases are big, but Django's got a big code base and You know, you want to dig into the RM, it's gonna take a while. It's gonna take you know a while. It's not and you know, not just the RM. You can dig through the views bit, it's gonna take a while. You dig through the the request handler, it's gonna take a while. Like that um Pretty much no question isn't good enough to be asked on a public platform. Right? If you phrase it like this, I've been looking at this for about the last three hours. And I found this bit and I just can't see how it goes.

Speaker 1: And you know, you you elaborate the backstory. It's like, yeah, no, that's a perfectly reasonable question because That's really complicated code that you've dug into. Why on earth did you expect to understand it? Let me see if I can point you to this file over here where it sort of unbars a bit unbelt. I don't know. But there is no question that isn't good enough to be asked on a public platform. Really, really there isn't. I don't believe you can, even if you spend months. working on a ticket and then it ends up being closed as like as actually this is resolved or we won't fix it or whether you've learned masses in that process. Um and so it depends what you mean by impactful contribution. If you mean Massive PR merged into Django. Well, no, you didn't get that. But the learning that you got from it was amazing.

Speaker 1: And take my sort of case study. How did you use Superpower X to do Y? Well I I spent months researching this to show to close this 10-year-old ticket that, you know, you can tell that case study to answer that interview question, even if the case study is I didn't in the end it didn't get fixed. In the end, it wasn't a quote unquote impactful contribution. It's impactful to you because you've learned a lot and it's one more thing that's close, one more thing that isn't going to be a dead end for a f a developer following in your wake. One more thing where we we've clarified the situation and we can move on with pushing Django forward. So I think all of these things are meanful. How much time to spend? Don't spend hours banging your head against a desk on your own in silence. If you give it half an hour, 40 minutes, 50 minutes, that's fine.

Speaker 1: Don't sit there four hours. Oh, I don't understand it. Ask for help. Like The embarrassment of asking the question on the public platform is is trivial compared to the wasted life force of you of you suffering by yourself. It just is.

Speaker 2: Thank you for that. Uh Sarah.

Speaker 4: Thank you for your talk. I have just one question we we all have faced at some point to imposter syndrome. So I guess you two, do you have like any types or anything to share related to that?

Speaker 1: Yeah, no, I mean I was thinking about that today. Um So Marish is stepping down as fellow after five years. And I literally think of as Marish as the rock upon which Django has rested for the time that he's been a fellow. And that's absolutely true. But the sort of implicit thing there is, oh well, he was a much better fellow than me. No, he wasn't. I was a good fellow too. I did it for five years. I was a rock upon which Jang arrested too. But I still I still have that. Oh no, but he but the thing is he knows his bit, I know mine. We worked amazingly as a team for all that time. But literally today I'm sitting there thinking about Maris and his end of time as a fellow and I'm thinking yeah

Speaker 1: I'm just holding him up on this pedestal which I can't compete it's like but that's just ridiculous like uh we're both Massively skilled and have done the job and know it inside out. And but still I'm like, oh no, but I can't compete with Mario's. Yeah, of course I can. you know, we just would just move away from the ORMs and into the view layer and you know things, you know, and but he's perfectly capable there as I am over there. It's like it's not a competition, it's not that, but that thought still comes up. Absolutely, absolutely. Um in general, imposter syndrome, you just the little hater, you just have to talk it down. There's no way around it. There's a you

Speaker 1: It's there for everybody. And I think just trying to be trying to be objective, trying to step back again and say and have a look at people, the people around you, say, hang on, am I really any worse than that? bloke over there and like no I'm not you know I don't there's no general solution but yes it affects me and it affects everyone Oh apologize if I get your name wrong. I couldn't find the

Speaker 2: pronunciation. Marjorie?

Speaker 4: Marike. Mareike. It's uh

Speaker 2: I try.

Speaker 4: It's my company name for a reason. Um, but um also regarding imposter syndrome, first thank you, Carlton. This is an amazing talk. I wish I had heard this like years ago. Um one thing about imposter syndrome, by the way, I always say people who have imposter syndrome they doubt themselves like, ooh, am I imposing And a real imposter knows they're imposing. So when you're doubting yourself, you're actually you know, that's that's sort of the mindset that I use. But that wasn't a question. It's a bit related. I have found myself um I've been a programmer for many years, but I I found myself just not really knowing all the internals of Django

Speaker 4: and Just like recently I found out there's multiple CSS files in Django admin and I found that out after I made a change and then Marius was like, oh you have to change it there as well And I had a couple of those things and at some point and I I was almost feeling like I was wasting his time and Thibaut said logically, well he's being paid for it, so you know But do you have some encouraging words for those of us stumbling around and not knowing what we're doing?

Speaker 1: Uh yeah. Just there's no way to get to knowing what you're doing without to i what is it? I know. Lao Zhu. In order to do something well, you must first be prepared to do it badly. Like you have to be a beginner to get to be a medium, to get to be as advanced. Like you just there's no there's no shortcut. Oh yeah, I end up I I I donged on the head and I suddenly recalled from the celestial spheres the internal structure of the Django code base. Like that doesn't happen, right? It's an experiential thing. The thought that came to me as you were asking the question was about like people have often asked me why is the review in Django so pernickety? And the bottom line is because it's one of the largest projects in the Python ecosystem

Speaker 1: and it's deployed on hundreds of thousands of projects, if not millions of projects around the world, constantly And the reason it's deployed is because its quality is so high. And the only reason its quality is so high is because nothing gets merged until it's as close to perfect as we can get it. And mistakes are made and you know, follow-up patches get made. But basically. The reason why it's so pernicky is that it's got to be right. It's got to be just right. And that's again a difference between what you do in work. It's that work you can be like, oh, that'll do and I can you know fix it later and that's just how companies work because they're on a c they're on a much sort of more cost driven get it done quickly type basis

Speaker 1: So why is Django any good? Yes, it is good. It's good because it's the reviews are pernicity and don't and so the sort of thought for the individual contributor is that's not about you. It's about the patch. And it's like literally, let's just go over the patch and let's make sure it's right. And the fellow's job is to do that with a fine tooth comb. And Marish is very good with the eagle eye at spotting the missing pull stop and the line wrapping and the, you know, he's just amazing at it in a way that I, you know. if that wasn't where I came from, I'd be like, yeah, that's fine. And Maris would be like, no, you know, but those little corrections are just like, yeah, merge that, merge that, merge that, merge that, done, we're finished. I don't feel I've quite addressed your question. I've sort of rambled around it a bit, but I'm not sure I've got quite to the heart of it.

Speaker 4: Well, y you make a good point. My point was just like feeling like I was wasting his time because he was picking up all the little bits of slack that I felt I had dropped because I didn't search well enough. To find that second CSS file, for example, or whatever. And but

Speaker 1: Yeah, no, I I Yeah, no, the the straight answer that is no, you're not wasting his time at all. That is that is he's just there saying, oh, and by the way, this needs to be done as well. Like, you know, so Quite often it'll be, I don't know, I'm trying to think of another example that isn't related to CSS, but like no one's obviously not coming to me right now, but they'll say there's a related change. It's like look, you need to make the related change over there. Oh, I didn't even know that existed Oh what you do now.

Speaker 4: Thank you, that was it. Um also the other question you answered was really great. Um and sorry to whoever I just interrupted

Speaker 1: No, no, no, don't apologize. I didn't interrupt.

Speaker 3: No, I I was gonna add to what you just said. Um kind of uh I I had a very similar experience when I first started, if this helps. Um uh felt like by the end what got merged in, I don't think I wrote any of it. I think I ended up uh I'd submitted something long You get the and you get the bombardments of reviews and your first review's got like ten comments and then you you you you resolve them all and others can suddenly like, oh maybe this is okay. And then you wait a bit and then you get another another review wave and all this kind of stuff. And there's definitely a feeling like um If they really wanted this done, they would have done it much faster themselves

Speaker 3: than having me just fumble around and go, oh yes, okay, good idea, why not? And oh yeah, okay, blah, blah, blah. Um and I'd say it does get better. Uh you become more uh familiar with Like, for example, with the stylistic things, with the line wrapping and the full stops and all this kind of stuff. Like you have people tell you and then now you remember and all this kind of stuff. And then it

Speaker 1: Imagine it before black.

Speaker 3: And then with the things with the CSS stuff, now you know there's two files and if you were to do it again, you know. And um it it does get easier. And then there was one other thing I wanted to say was uh when Carlton was talking about different types of people. And the people who are more challenging are people who raise issues with no um uh No commitment or follow-through to do anything. So anybody who's a doer, like if you're raising a PR or if you're trying to make a discussion on uh if you're a doer uh because this is not necessarily

Speaker 3: especially when it isn't something you raised you just want to try and get this closed and all this kind of stuff then you're You're already in another category of people where it's like you know it's it's helpful and it's very much appreciated.

Speaker 1: Can I just follow up on that point? So you asked a question before about, you know, um when there's disagreements of say about adding a feature. I think this is the key bit is If you if someone's proposing a feature and there's a concrete I'm gonna do it and I'm gonna be on the line for maintaining it, it's quite easy actually to get the the pieces to move, the continental plates of Django to shift out the way to let that feature in. It's when it's like, oh, wouldn't this be great? But then there's nothing. And it's like, and then at that point, not everybody, but everybody just goes, nope. And that that distinction between do-er and issue raiser, that's that there's something deep in that.

Speaker 2: Alright. I'm gonna take Carlton.