An interview with Tim Graham, the inaugural Django Fellow, who has played the largest single role in Django's advancement over the past 4+ years.
Carlton Gibson 0:05
Hi, and welcome to another episode of Django Chat. I'm Carlton Gibson. I'm joined here today with, as usual with will.
Will Vincent 0:11
Hi, Carlton.
Carlton Gibson 0:12
Hi. Well, and we've got a special guest today, Tim Graham.
Tim Graham 0:15
Hey guys, Tim.
Carlton Gibson 0:16
Tim is a well, what can I say about Tammy? Django is number one all time contributor and he's been the Django contributing to Django for as long as I've been using it. And he's just finished four years straight as the Django fellow so we're so privileged to have him in and we wanted to talk to Tim and get his taken.
Will Vincent 0:37
Well, hope you enjoy it. So Tim, I know you've spoken about this Django under the hood, which will link to the video, but I was wondering if you could quickly just talk about your background and how you got involved with Django initially.
Tim Graham 0:48
Sure. So back in college, I had an independent study project, and somehow I got involved with Python and then Django as part of that and just fell in love with the documentation and the tutorial and seeing how much functionality you could get with a few lines of code for the admin and it's been a journey
Will Vincent 1:10
since then. So what version of Django is this when you were back in college?
Tim Graham 1:14
That's a good question.
I'm thinking maybe you're on one floor. So,
Will Vincent 1:20
okay, so more stable than pre 1.0? For sure. Yeah. And then how'd you how much had you done with other web frameworks and programming before Django itself?
Tim Graham 1:33
had done a little bit with Java in school and also PHP was what I did a couple of small sites with. Pick that up in school.
Carlton Gibson 1:44
So that's cool, because I started with PHP is where everyone seems to go from PHP into Django and Python. It's like for me, I always describe it as that glass of iced water, you know, it's like, Ah, what a difference. I know PHP has the same feel. Yeah. Okay, so one thing I wanted to ask about was the beginnings of the fellowship program and how that came about. And you know, its origin because Django is kind of dependent upon it. Yeah. So
Tim Graham 2:14
I worked at Google for a while I worked at a startup after I graduated school. And then we were acquired by Google and work there a little while. And then as our, as our software was transitioned over to the Google stack, they didn't need our team anymore. So I decided I wanted to stick with Django. And so I took some time off after I left Google and then sort of did the fellows job on a volunteer basis for a number of months, even though it wasn't a formal thing. And that that kind of kick started the Django Software Foundation Board to get the program going Finally, and run a pilot. So when you say you're doing that on a volunteer basis, is that you're putting in like a lot of hours there. Yeah, probably Part time, maybe 20 hours a week or so. So that's a big commitment. That's a big, you know, that's a big
Carlton Gibson 3:07
ask for someone to give voluntarily.
Tim Graham 3:09
Yeah, it was just fun for me at the time. But that
Will Vincent 3:12
was a lot. That was a lot of tickets ago.
Carlton Gibson 3:14
Yeah. What was it? Do you remember the sort of rough ticket number when you started contributing? Because we own about 30,000? Now,
Will Vincent 3:22
I found it I have I found the link, right. I found the link that you mentioned in your in your talk actually.
Tim Graham 3:28
9347.
Will Vincent 3:30
So 20 20,000, or something ago,
Tim Graham 3:32
was 10 years ago.
Will Vincent 3:35
And so, so well, I'll just jump in since you were both Django fellows if you could talk about, you know, how, how did Django work before there was someone even part time focusing on the releases? And, you know, because I think a lot of us are used to modern Django, which has a regular release cycle, like 2.2 just came out, what was the process and who was involved before the Django fellowship program
Tim Graham 3:56
started? Right. So I know James Bennett Jacob Kaplan moss for the releasers and that they weren't necessarily triage and all the new tickets and margin most of the poor across like the fellows do today. So it was more sort of like, when the, when there's a consensus on the mailing list or something that it releases ready, then we'll do it. There wasn't there wasn't a formal eight month release schedule, like we have now. It was just sort of, you know, when things are ready, then we'll release
Carlton Gibson 4:26
and so it'd be like more feature basically that okay, a year might go past and then Okay, we've got a group of features together and put those out.
Tim Graham 4:33
That's my understanding. I wasn't super involved with the processing those days. Okay.
Carlton Gibson 4:39
And how did the lady say the board because of your activity, the board kind of got together and came up with the fellowship program, but was that because they were like, yeah, we've got to keep this going. We've got to find a role or what is
Tim Graham 4:53
Yeah, I think they saw the advantage that having a person full time or semi full Time had and really help move things along and
Will Vincent 5:05
and then I went to something you both are aware of, but I only in the last year learned about was sort of Django core things such as the Django under the hood conference, which I guess no longer exists but was a gathering in Europe of contributors to Django. I was wondering if you could talk about just the community, especially when you started to today because you know, your best based based in Pennsylvania to global community, how do you know that there are these in person meetings? Right, it's not completely online and digital.
Tim Graham 5:39
Yeah, I really enjoyed those conferences, the under the, under the hood in Amsterdam. And at that time, I feel like the last few years, the importance of the core team has kind of decreased. In fact, there is a proposal floating around to sort of get rid of the core team and that's another topic
Carlton Gibson 6:00
I thought and the core team probably I think it's like a good thing in that there's all these people who like, I wish we had a hall of fame or something where all the contributors that have made massive contributions in the path of rec pastor recognized, but that the this this thought that there's 50 people that are contributing to Django, it's just not the case. Right? There's, there's Simon Claude and you and, you know, john and a half a dozen, but there's not, you know, there's not this, this massive roster of the great and the good. And to get rid of that as a as the governing body, I think is probably a good thing. What exactly we replace it with? I don't know, right. That's what I tried to do on the website with the
Tim Graham 6:43
technical team. In other words, like, these are the people that are actually active so we can see that as opposed to the core team, which is just you only add people in that room. Yeah.
Will Vincent 6:54
Well, I think I mean, again, I can speak as being the newest agenda of the group. I think it's important And then kind of mind blowing to find out who's actually doing the work. Because so many people are doing so much work, almost everyone on a volunteer basis. And they're not doing it for Pat's in the back. But I think it's important for people to know who they are and how much they're contributing, because Django seems this amorphous. millions people use it thing, but then, I mean, Carlton, discussed this in his talk at Django con, where we first met last fall, it's, it's really just a handful of people doing the majority of the work. So I think they should be recognized a little bit more.
Carlton Gibson 7:30
Yeah, it's my
Will Vincent 7:31
no disagreement among this group. Right.
Carlton Gibson 7:33
It's my one concern about the dissolution of core proposal is that the people who are doing the work need, they got to be recognized, we've got to say, you know, we've got to put our hands together and say, well done. Thank you. And, and that bit is missing from the proposal as it currently is floating around. So I, that's my one concern is all I can say.
Will Vincent 7:52
Yeah, well, maybe it'd be great to have Tim if we could have you just talk about the work of a fellow and how you've evolve that over time, because I think that leads into you've really helped train Carlton who's now training, another Django training wondering
well, the evolution of the role maybe and kind of things you, you know how you spent your time and what you thought about when you started off 10 versus, you know, now as you're handing it off
Tim Graham 8:22
to. So I'll just go through some of the tasks that are listed on the sort of job description. Each time the fellowship opens up, they put out a post on the Django blog as mitering, the security Django project comm mailing list, ensuring security issues are acknowledged and responded to properly. So there's a security team of about maybe 10 to 15 people who are active in various capacities. There's a funny story, one of the guys who worked with he sent a report to this security less than he he's on the he was on the Django team for a while. And he's like, I thought there would be like this magic group that would just, you know, take care of my issue. And it turns out, it was a lot more complicated than that. And nobody really knew how to solve it. So it's to me it's a real group of people with limitations. And
Carlton Gibson 9:16
yeah, just trying to do the best, right? You don't necessarily know what, you know, a security issue comes in, you're like, Okay, yeah, I see. It's a problem. But how is it to be fixed? You know, it's not clear that, you know, I don't know, and people on the list of knowledgeable and between the group, maybe we can come up with a good solution.
Will Vincent 9:33
I think, too, as well. Tim, when you started the full time role, there were a number of just tickets and security things that were kind of languishing, right, because contributors weren't getting the feedback that they wanted. Whereas when you were able to come on part time that really sped up development, right, because to have someone who could really push these things through and do the hard work of getting consensus on things, is that right?
Tim Graham 9:56
Yeah, there's a couple of big contributors who had proposed it. Have pull requests, and they just sat there and get any attention. So when I started working on them, and that really kick started those people's future involvement with Django,
Will Vincent 10:13
and then the security team, I assume it works in a similar way as the way you got involved as you were focusing on documentation. And then you were invited, is that the same thing? It's people who are already contributing to a security on Django and then, at some point are invited to join the the core team. Is that how that works? Yes, that's right. And then is it? Does it just keep growing in size? Or at some point people sort of back away? Or is it? How does that work?
Tim Graham 10:40
I have tried to send out mails to the security team and say, you know, like, if you're not involved anymore, maybe you want to remove yourself from the list. And that's worked reasonably well. I think,
Carlton Gibson 10:51
yeah, I think people are happy to step down. You know, they know they're not active. I think some people sometimes people feel bad that they're not active and you shouldn't feel But equally, they can
Will Vincent 11:02
step away. So beyond security, and there's some other things as well that the fella does.
Tim Graham 11:07
Sure, fixing release blockers and helping to ensure timely releases. So as we talked about previous to tango follow program releases server hopping whenever they were ready. I did a community survey a number of years back and based on the feedback that we adopted the eight month release schedule. So there's some people, I think the choices in the survey were six 812 on something like that. And I guess we landed on eight months sort of middle ground in terms of having to upgrade too often or there being a big lag between features and bug fixes and when they were actually released release blockers or regressions since the previous stable version of Django or bugs and new features. So the fellows All work on Exynos issues to help ensure that releases are on
Carlton Gibson 12:04
on schedule. Yeah, because those ones can't just sit there they, you know, they need to be fixed timely. Can you explain Tim about the long rate long term, long term support versions and how those fit in with the major releases in the version numbers because will was asking me about this in another episode and I, I sort of bumbled through it not knowing exactly, but you probably help you probably create that policy will help create that policy. Could you explain about sure
Tim Graham 12:31
how the version numbers work. I mean, like, look that up so I can just talk through it. So starting with Django 2.0 Django uses a loose form of semantic versioning such that each version following an LTS will bump to the next zero release. So starting with 2.0 2.1 2.2 will be the LTS and then following that, it'll be 3.03132 will be the LTS So the idea there is that in Django 3.0, for example, some deprecated features will be removed. So that upgrading from 2.2 to three point now may require a little work on on your end. But you should be able to upgrade from 2.0 to 2.1 and 2.2 without much work.
Carlton Gibson 13:23
And there was one bit that I really wasn't sure about something about, you should be able to upgrade from say one point 11 to 2.2 or from one LTS to the next without having to go through the intermediate versions. Is that right? Or if I just pick that up right here?
Tim Graham 13:40
Well, the Django upgrade guide recommends upgrading one version at a time. That's what I would suggest, at least locally, you know, install. If you're on one point 11, install a 2.0 and get your test passing there and then good at 2.1 because there can be some backwards incompatible changes and each version but there should be relatively minor hopefully.
Carlton Gibson 14:07
But in principle you meant to be able to jump to the LTS or is that not really the case?
Tim Graham 14:12
Well, the idea is you could you can jump without having to make changes for deprecation. Well, okay. Okay. If your code is running deprecation for you on one point 11 then you can jump to 2.2. And be alright. In theory.
Will Vincent 14:30
Yeah. Okay. Carlton sweating, because that was the advice he gave us as well. Yeah, I in our episode, and I I literally before walking in here, someone in my co working space uses Django. I was like, Hey, 2.2 came out. And he's like, Oh, yeah, like I'm on the long term support thing. So I should do that. And I was like, Oh, you should listen to the podcast. You should
Carlton Gibson 14:48
feel that at least the what I said last time ties in with what Tim just said.
Will Vincent 14:53
Yeah. What you said. Yeah, you said similar things, Carlton, so Okay. And
Carlton Gibson 14:59
so the other big thing for me is the triage work because there's like every morning, they'll be, you know, 234 or five new tickets opened up. And so I guess the two of those, tell us about that. And then the follow up is, how do you sort of maintain a rhythm with that? Because it can sort of this. It's a bit incessant.
Tim Graham 15:19
Yeah. So Gog involves trying to reproduce bugs. A lot of times reports will be against maybe the current stable version. And then maybe that bug has been fixed in master. So part of that is just making sure that she's still valid on master. I try to put the commit hash where I reproduce the issue on the ticket. That way, if somebody comes along later and says, Oh, this has been fixed since then, then you can easily bisect and find out the commit where where the issue is fixed, and then you can check if an appropriate test was added. Along with that. let's
commit
another aspect of triage and maybe the ticket is a duplicate of some issue. So looking at tickets for a number of years, you sort of get to know most of the issues. And I usually use Google to search tracks if you put cycle and code Django project calm into Google and then put in a few keywords, you can usually I can usually find the ticket that I'm thinking about as a possible duplicate. Yeah, and that's where your knowledge of the issue tracker really like just stands out. Because, you know, I'll try I should take a number Oh, you know, this, this, this, this and then Tim, so and this is a duplicate of this one. It's not our Thank you, Tim. Because there's like 13. You can also use the,
Carlton Gibson 16:46
there's 1300 open tickets,
Tim Graham 16:48
if you use the component filter that can help to just quickly look through and see if any keywords are matching. Yeah,
Carlton Gibson 16:55
narrows it down a lot, like from 1300 say 100 or makes it easier,
Tim Graham 16:59
and I think that's a good A good way for new contributors to, to look attractive is just think about an area you want to work on and focus it down by by component. Like maybe you want to do something with migrations. You can look in the migrations component and you'll see maybe 50 tickets instead of
Carlton Gibson 17:18
1001. What do you think about new contributors? Because it for me, I was maintaining Django filter in Django rest framework and crispy forms outside of Django for a long time. I wasn't contributing to Django itself, I was a bit like, okay, eventually I got there because I had a bug, which affected crispy forms. I was like, Oh, I need to do this. And actually, it wasn't that bad. But, you know, I was a, you know, a maintainer, and yet I was still a bit intimidated. What's your thoughts might have advice for us as the, you know, how we can make it easier for new contributors, or is it just necessarily how it is?
Tim Graham 17:52
Yeah. I think how you came to having a problem that you need to solve is a good way. It seems like a lot of people come along And they don't really have a problem. They just want to get involved. Yes. I think it can be hard there, especially if you've never used Django. Yeah. Because you don't really know what the real problems are. I mean, there's tons of open tickets of small minor inconveniences that aren't really high priority. And if they're not a high priority for anyone, then fine leaving the ticket open
Carlton Gibson 18:25
for as long as it takes.
Will Vincent 18:26
So, Tim, I'm wondering, what would you say are the major issues in Django in terms of like, what are the sort of areas that you look at and go from that's maybe New Thought is involved or, or some sort of breakthrough? Or are there specific ones that keep coming up? I mean, you know, the admin right? That's, that's one that for legacy reasons, but I'm curious what else as a fellow kind of,
Tim Graham 18:50
I don't have a lot of complaints. But on the other hand, I don't use Django a whole lot
Carlton Gibson 18:56
these days. I know we're interviewing Tim, but I've always got an opinion. The the admin like, it's great. It's super, but there isn't much room, I think for adding new features. And you know, because it's so complicated already, the API is so big on it. It's like, Oh, can we just leave it alone? Like, it's good. It's powerful, but until we, until we tidy it up a bit. I'm a bit scared of let's add on another bit of API, another option on the model admin. It's like hard, but there's 50 already.
Tim Graham 19:23
Yeah, no, I feel the exact same way. Every time. There's a new ticket for like, coming up with this new hook to customize this. It's like, we're gonna have so many hooks that it's just gonna be unmaintainable. I feel like
Will Vincent 19:35
so if we had a magic bullet or a million dollars, which I think was the cost estimate to rejigger it, like how, how would each of you write if you had unlimited time and money? What What would it take to properly redo the admin?
Tim Graham 19:48
I don't, I don't know that it needs to be redone. Fair enough. I mean, it's supposed to be four, four basic scaffolding of like a simple admin interface. You're not supposed to build your user facing UI, and it's not supposed to be pixel perfect. And I feel like all the requests are just, we want to do every single little thing. If the admin
is not sure if that's
Carlton Gibson 20:14
feasible, sometimes it might just be easy to build a Django view. I mean, if we could, we could extend it a slightly so you could route views so that they appeared within the admin interface more easily. That might be quite handy, because then people could, and I mean, there are third party packages that do that, but maybe in addition there, I agree with him. I don't think it needs to be replaced. I just like some work. You know, if somebody were given three, six months of good effort, and they knew what they were doing to tackle a lot of the bugs and maybe tidy up some of the more messy parts of small refactorings just to make it clearer. That would probably be enough. I think it's super powerful. And
Will Vincent 20:50
yeah, well, maybe that's a chance to talk about again, you You both are well aware of this, but I'm I wasn't until recently shocked that I think it's the total budget. Is $200,000 a year for the? Is it the Django Software Foundation? of which the fellows is part of that? Do I have that? Right?
Tim Graham 21:07
That's the fundraising goal sit on the website and not
Will Vincent 21:10
to Okay, that's the goal. But I mean, that as we were offline discussing, I mean, that's, that's like an entry level salary at a Fang company. I guess to me, I think, well, what, you know, what, what would be done? If, for example, it was a million dollars a year? Or is it just, you know, it's so much of it as volunteer anyways, that money isn't really going to help because you just need super dedicated people who,
Tim Graham 21:31
yeah, I'm not really sure I can get one data point you should have put in. When you apply for the fellowship, you can request your hourly amount. And I put in an amount that was not when I think back to it, it's it was roughly one third of my compensation at Google. And then as a contractor, you don't get any benefits or you don't get any vacation. So I don't know how the other fellows are coming. sent in but at least for based on us standards, it's quite a bit lower than if you're being employed at a company. But also like, You're, you're in Pennsylvania, right? I'm in Spain. These aren't marriages in Poland. These aren't Silicon Valley. This isn't Los Angeles, San Francisco, Boston. My question like, should the DSF continue that and just take advantage of that geo arbitrage and hire programmers where the dollar is stronger and where the cost of living is low?
Will Vincent 22:32
from an outside perspective, it seems crazy that that's even a question because it should be the best person. But of course, given the limited budget, that's a legit question. I mean, I used to live in Silicon Valley. I don't anymore for that reason, but given how much of an influence a Django fellow has, that seems crazy. Again, you guys won't disagree with me.
Carlton Gibson 22:54
I just a, I think, you know, historically, Tim's just been the best First, quite simply, and I'm not going to talk about myself I'm, you know, I do the best I can. But Maris is just I'm so excited about marriage being hired, I think, you know, I was worried when Tim was stepping down. I'm like, Oh, my word Tim stepping away. He knows so much. And then they chose marriage. No, no, well, I can't actually think of somebody bad. That's just super. So I'm not sure that the financial situation means you don't get the best person. Like, it's just
Will Vincent 23:27
that, you know, money isn't going to be the reason why someone would do it for
Carlton Gibson 23:33
you. No, they did. DSF sponsors, Django girls, they give money towards the Django cons, they, you know, the conferences in Africa and other places where they're trying to grow the community. So it's not just, I mean, the fellow pro version problems, the biggest expense, but Frank said at Django con that you know, it is he could raise more if there were specific problem projects to fund.
Tim Graham 23:58
Yeah, I think it'd be interesting. To talk talk to maybe the president or someone on the DSF board and get their take on Yeah,
Carlton Gibson 24:07
I did. Yeah. I mean, I did want to talk ask you, Tim, about how you handle the sort of how you don't get burnt out, you know, to do the federal role for years full time, you know, how you handle that incessant nature of it. And it's not just because you're okay, as a fellow, you're paid, but volunteer, open source maintainer. So you suffer from burnout all the time.
Tim Graham 24:27
Yeah. I think I did get a little burned out. And I think some ideas about how to avoid that, if I had to do it over would be to set up a separate email account. So that notifications about chango stuff didn't come to my personal email, especially on evenings and weekends. And that may be what let me disconnect a little bit more. Yeah, ever, that I don't really have the same excitement for the work is when I started and that could just be part of Lazarus doing the same thing over and over again. It's kind of monotonous. But Django development was less structured back then. And it was really fun to set up a continuous integration. So before I started, we actually didn't have a continuous integration. So the committers would just apply patches, and then run the test locally as best they could maybe not on all the databases. And so then we ended up with someone with committed passion and say, Oh, it's broken on my sequel or something. And so the build would be broken for a number of days until somebody got around to fix it. So So I set up Jenkins integration with
with a GitHub pull request, so you can see the status
of the checks there. And so that really helped. And at this point, feel like I've done enough where the development is structured and things can continue to plot along on me.
Carlton Gibson 25:55
So there's two parts of it, one that you're stepping down right now you know you finished two days ago. Officially. And so for one question is, how do you tend plan to turn off now? because presumably, you need a period to clear your brain of this of the responsibility. And then the other the other part after that would be we're going to see you again. Yeah.
Tim Graham 26:17
So, I mean, I plan to remain sort of involved at least once in a while and like yesterday, helping you with or at least a little bit and just tidying up loose ends. I have some other interests. I coach high school baseball, as so that's going on right now. So that takes up a fair amount of time, especially in the afternoons, evenings. Enjoy vegetable gardening, playing clarinet and saxophone. And one of the big things that's sort of increased in the last year or so is coming from my mom has dementia. Okay.
Will Vincent 26:57
Sit Do you think it's is it Django and specific that you need a break from or do you think it's tech in general? Because I often sometimes to myself think is it? Am I just tired of Django? Or do I just really need to not look at a computer for a while?
Tim Graham 27:13
Yeah, I think not looking at a computer is definitely something I'm looking
Will Vincent 27:19
at wonder if you both can speak about again because as a little bit of an outsider what it? What is it? What was the process of mastering Django because Django fell? It's easy to think oh, that's to the extent anyone really knows Django. That's someone who does what, what were the if you can remember the milestones in terms of when things click together, and I guess each of you came from PHP. So you already had a background in web frameworks, right? Because for me personally, Django was the first web framework I really worked with. So a lot of the pain around just how the web works. I assigned to Django and was only when I worked with a couple other web frameworks that I got some perspective on it. So I'm curious, just We'll start What does it feel like to know Django in and out? And what was that process? Like, if you can recall all those years back?
Tim Graham 28:06
Yeah. So when I worked at the startup company, we're using Django as our framework. And, and I was contributing to documentation. And, as best I remember, I pretty much did all that without looking at the source code, which is kind of nuts. In retrospect. The great dogs, you mean, so you were you were writing hot? Because I think you were writing the documentation for source code stuff, right? Or maybe well, it was mostly about fixing documentation. Maybe not writing new, new documentation so much, but okay. And I guess I had to look at the source code, at least a little bit to do that. But I don't remember having intimate knowledge of Django as much as I do now, until I actually started diving in and reviewing pull requests for code. And at that point, yeah, it definitely helped with that. Django
Carlton Gibson 29:00
Yeah, no entirely. I was too. I started off building API's building apps and websites in it and API's with Django and Django rest framework and kind of to use Django rest framework, kind of read the docs, but got into the source code and then started contributing. And that's when you got to know that. And then it's only doing the fellow role and having to triage this, the bugs that come in, it's like, oh, okay, I better really Open this bit of code, right in the middle of Django that I've always avoided. That makes me do that. And so now a year in, I'm like, okay, you know, I can open up say, compiler.pi, in the middle of the ORM. And I'm, like, kind of comfortable with it now. But when I started the federal role, wasn't there. You know, it's, it's literally the job of triage, seeing and reviewing the patches that teaches has taught me, you know, you could use jangles, you know, quite happily very well, as well as anybody but that level that working on the source code every day, really, that's, that was the next step up.
Will Vincent 29:59
Yes. I agree. So how does that I mean, how does that feel for you guys, because I've noticed just personally, it's in the last year that I feel like I finally, I finally can take a 30,000 foot view of, of Django like after how many years, six years of using it, I finally feel like I sort of get a sense of how it all fits together. And I'm aware of areas where I don't have total depth, but it finally clicks. For me. I'm wondering if Did you guys have that sort of, Oh, now I see how the pieces fit together, or was it more of just a gradual thing for each of you working, you know, on all the tickets?
Tim Graham 30:35
Well, a gradual thing. I mean, there's still areas where I'm really comfortable.
Being one so
Will Vincent 30:43
that's crazy that you say that, but that's
Carlton Gibson 30:45
got to be true for everybody, right?
Tim Graham 30:49
Yeah, I mean, like, if I get a patch for the RM, it's basically unless I see something really obviously, wrong. It's sort of like do the test pass. And does it go like reasonable? And is it covered by tests? And they're sad, and it's good to go.
Carlton Gibson 31:06
But also there are there are there are a number of contributors, regular contributors who really know the LRM inside out. And without those for me, it just wouldn't be possible. It just couldn't do it yesterday.
Will Vincent 31:18
Yeah. Well, that's I mean, that's the thing about programming is we, you know, I don't think about what I know, I think about what I don't know. And so I guess that leads into the, you know, imposter syndrome, no matter what level you're at, you're just looking forward, you're not looking, looking back, which makes it fun, but sometimes leads to burnout. So do we fully discussed the handoff process to Carlton or is there anything, any lessons you have from slowly stepping away? I mean, that's hard. in any position here, there's such a immense amount of responsibility you've really had. Just yourself.
Tim Graham 31:50
Um, yeah, I guess I would say it's, it's been somewhat difficult for me to give up control and something that I've shepherded so closely for a number of years. But ultimately, I think we have to remember that we're all replaceable. And that can be humbling and also relief.
Will Vincent 32:07
What are you Carlton? What How is it? What was the onboarding kind of process
Carlton Gibson 32:11
super like? Like, you know, I? So first of all, I'm like, Well, where do I begin? Tim? Tim gave me some starting points. And then as I did that for a week or two, and then I'm like, Tim, I need a bit more help. And, you know, and then Tim's very good. Like, when I'll do something, if I haven't done it, right, give me a nice little tip. And, you know, a year later, I'm feel okay, I got kind of got the hang of it. I still, like I just still don't have Tim's amazing eye for the for the, you know, the really fine details which he catches every time and I miss, but I'm getting better and I'll continue to improve and I just aspire to, you know, be to that level of just proficiency. I you know, Tim's really has guided the project he, he has taken it from,
Will Vincent 32:56
you know, without ci and all these other things, too. It's it's really Very well structured now. And you know if anybody is responsible for that, then Tim is. So for the, you know, I have to say thank you from the whole of the Django community for that, because we really do owe you and we love you. And I hope more people know who you are because I, I didn't know your name until a year ago. So maybe that reinforces the replaceable ness. But also, I think just the the sort of veil of Django just sort of works. And, you know, there's only for me is only really going to Django con being like, Oh, this these are people who wrote the docs, it just feels intimidating. And a lot of what Carlton and I are trying to do this podcast is sort of humanize Django and make it seem less intimidating. And yeah, and and the people and companies behind it, because it's such a big group. So anyway,
Carlton Gibson 33:44
thanks. Thanks again for joining us, Tim. It's been wonderful to have you on the show, and thanks for listening, everybody. We'll see you next time. Bye bye.