Who put me in charge? Moving beyond day-to-day coding in Django with Jay Miller

Speaker 1: Alright, so we are almost in the home stretch, which means it is time for like my favorite part of this conference, is where we get a bunch of professionals on stage and we ask them embarrassing questions. I'm kidding, there will be no embarrassing questions asked, however. Given the nature of this talk, we were going to be talking a lot about leadership. There might be talks about some mental health things, but there's also going to be talks that cover everything from When do you want to pull your hair out to Frank my goodness what happened? So I say that by saying that nothing that is said on this panel, except for Frank, because he runs the joint, is the views or opinions of any of our employers.

Speaker 1: Um and we have to say that by law. Um everything that we're saying is our own opinions, these are our own experiences, these are our own thoughts. And with that being said, welcome to the panel that is called, wait a minute, who put me in charge? How do we get beyond the day-to-day of coding in the Django community? Uh let's start by introducing our panel and I will let them do it because I will mess up names because I'm very bad at that. But go right ahead, Charles.

Speaker 2: Hello, hello, hi. My name is Charles Rajonis. I am a IT director at the University of Pennsylvania and And I am coming up on my 25th year there.

Speaker 3: Hi everyone, I'm Andrew Godwin. Uh I'm currently a principal engineer at a company called Astronomer. I'm coming on my third year there, to be fair. But I've been doing Django and Python stuff for about 20 years. So I feel somewhat almost as qualified as Charles here.

Speaker 1: No claps for you.

Speaker 4: a leader people manager for over a decade now and been working in Django and web development and tech for about 20 years. So in Total. So and I live here in Durham.

Speaker 5: Hi, I'm Elizabeth Garrett Christensen. I currently work at Crunchy Data and I primarily do PostgreSQL advocacy. And previously I have managed engineering and consulting teams. And before that, various other applications and support teams and stuff like that.

Speaker 6: Hi, I'm Frank Wiles. I'm the founder and president of Repsys, and I've been working in open source in various capacities and managing people for about 25 years now. Al

Speaker 1: also for completeness sake, hi, I'm Jay Miller. Um I am a senior cloud advocate at Microsoft. I have been in the Django community for X years because I don't really remember. Um it hasn't been long. I just lose track of time and my keys a lot. So with that being please don't clap for me. It's fine. That being said, I do have a quick question for the audience. How many people in here are currently managers? Okay, not a lot of people. How many people at some point in their life and career would like to become a manager? What what are the rest of you doing here? I'm sorry. Okay. How many people in here write code every single day at work?

Speaker 1: Every single day at work. How many people plan on doing that for the next five years? Ten years? Fifteen years? Twenty years? Yes. There we go. Oh okay, okay. So on this panel Um I I want to start. Did did everyone else have the same enthusiasm that the the audience here had 20 years in, 30 years in? writing Django code every day and making migrations, running servers. Was this the plan? I I know we do have someone who is still technically an IC, so we'll start with you, Andrew.

Speaker 3: Yeah, I mean I still have plenty of enthusiasm if that's what you're asking about. But and then you know to your point, right? Like I used to write code every day, right? In my first like five years of my career, like that was the job. Um These days I write code some days of the week, right? Like the job of a principal engineer is partially to write code. Um But also the job is much more than that. I often tell people I work with, you know, people underneath me often, like The job IGM it's it's software engineering, right? And the software engineering code is one part of it, but there are many other facets The wonderful folks here on the panel represent some of the other facets of that job. I mostly do sort of the architecture, top-level technical design, system design role. That's kind of where I fit in, where I found my career is best. But in terms of enthusiasm,

Speaker 3: That gets me up in the morning, right? Like I have taken my love for code and I have taken it and I found like that's the niche I really love. It's the thing where I'm like, yes, like we can take these bigger systemic pieces. and put them together in the same way one puts code together. And I found, you could the same enthusiasm, the same drive that got me like doing my first freelancing at age 15 is still there. It just comes out in a bit of a different form sometimes.

Speaker 1: Anyone else?

Speaker 4: I just want to add that I think it's there's enthusiasm, but it's also important for you as a manager who's managing developers is to understand what are they working on. When you get so far removed from the day-to-day of the people that are actually reporting to you, how are you able to assist and help them address their needs? There's an article written about this a couple years ago that really really um points this out and I think is really relevant that you like making that switch back and forth between manager and individual contributors is imperative and in this space.

Speaker 1: I think there's also something beautiful about it not necessarily have to start with I write code every day. Um many of the people that I've met that have been longtime managers, principal advocates in in my role. They started with I write the docs and I help formulate the tests and I gather people and just make sure that like we have coffee and and you know hopefully gluten-free donuts for me, but you know, donuts for everyone else.

Speaker 3: Yeah, I mean along those lines too, right? Like I think a really big part of my job is communication. And like often it's not sort of drilled into you enough as you start in in this industry and whatever career track you're in, but like half of my job is talking to one group of people and talking to a different group of people and working out they're both doing the same thing and making them then talk to each other. Um that's you know it happens, you've all seen it I'm sure in differ different senses. But also in terms of like it's my job to communicate plans upwards to executives, but also downwards to engineers. And you've got to manage that flow. And management's one side of that, right? You can have kind of execution operational part. My side is more like technical complexity and sequencing. Like there's a lot of talking, there's a lot of people work. And I used to be like when I was in university

Speaker 3: my first year, I was an incredible introvert. I I wouldn't say almost anything. I'm still kind of an introvert. Like I go to my hotel room and recharge during conferences. like it's a skill you've got to work on it and like you can improve and get better. I think often people don't realize like you've got a code, sure, but documentation is communication. Meetings are communication. All these things are super important to making a team write good software.

Speaker 1: So it it sounded like that excitement decode is still there, and now I'm gonna talk to arguably who I think probably has the most longevity. on this stage, which is Frank, because I pick on Frank as much as I can.

Speaker 6: It's the gray beard, right?

Speaker 1: It's it is. Like when when you do get the opportunity to sit down in front of your computer and and write some code, is that is that same passion from the first time you picked up what was it uh assembly

Speaker 6: rub rubbing two sticks together punch card um yeah no I I Everybody you have those days that I don't want to work on this, right? And that that happens to everybody in every job everywhere. But yeah, on a regular basis, I'm still like, oh, that was really neat. I I really enjoyed building that. That's really cool. I'm really helping these people with this code. But yeah.

Speaker 1: I should also clarify Frank has approved my my horrible jokes toward at his at his behalf. So I'm I'm sorry to the Code of Conduct Committee. I know we don't do that here. So we we've talked about a lot of the skills that were required to kind of get into this position and to kind of last it day to day and throughout a career. How does that work when you switch over to management? I know Elizabeth, uh, in our conversation before, you mentioned Going from IC into management into kind of different roles. What were some of the skills that you know gave you the confidence to make those steps?

Speaker 5: Um that's a good question. I I don't know if it's as much a skill as it is like being genuinely interested in the people that work for you. Um I think Personally, what I love about managing people in teams is just learning everyone's really unique and beautiful skills and kind of being able to put those together in a team or or with a project and kind of really like being able to sort of be a per a Lego builder, but with people. And I think, you know, really being able to listen to people and know what they're good at and sort of, I mean, we Charles and I talked about this earlier, being a little bit of a a

Speaker 5: parental role. Um I think some of those skills are really helpful when you can know what someone is good at and know what they need help with and kind of support them to do the things that you know they need to do to get their job done. I think is is I that makes a good manager.

Speaker 1: Yeah. You mentioned Charles. Charles, did you have a

Speaker 2: I do. Um So I was thinking about what we were talking about, and it was interesting to see how few people actually are like, yeah, I want to be a manager. Sign me up. If you'll indulge me, I actually have a short story. I promise it short.

Speaker 1: We have a code word up here.

Speaker 2: Yeah, it's like he's gonna he's gonna get closer and

Speaker 1: if you hear flask, that means wrap it up.

Speaker 2: Yeah So um I have two sons and when they were little they would ask, you know, four or five, they'd say, so daddy, what do you do when you go to work every day? And I'd say, well, you know, I I write the instructions that tell the computers what to do so they can do stuff like play Minecraft. And they're like, all right, okay, cool. That's good. They got that. And then so fast forward a few years and you know I'm driving them around everywhere because that's what you do. And we're talking, they're they're asking me more questions about like, well, okay, do you still just write these instructions? I said I had kind of progressed from that point and I was no longer just sort of an individual contributor. I was managing individual contributors just a few years later

Speaker 2: And they say, so what do you do? And I say, well, yeah, I still code a little bit, but what I do is I I I talk to people and I sort of listen to the problems that they have. And we try to come up with solutions to it. And some of the solutions are, and I was trying to reach for an analogy that they would understand. They're like potholes that come up in the road while you're dry. You know, sometimes because I've been around a little bit now, I can sort of see a pothole coming. You know, either a technical pothole or maybe uh a political one or a legal one or a or a financial one and say okay there's a pothole coming up and then maybe we can just steer around it instead of like driving straight into it And so that's part of what I do.

Speaker 2: And they were like, oh, you know, that kind of makes sense. And so fast forward again a few years and like, dad, you know. Is that that pothole analogy? There is no daddy anymore. It's like, dad, that that pothole analogy. Is that still what you do? And at this point, again, a few years later, I was managing managers. And but it and the analogy is like you can look at this as like if you've advan advanced to sort of the principal engineer level You know, let's say you don't want to manage. Let's say you sort of progressed and now you're like, you're not just a coder, you're like a senior, you're an architect, you're you're different things. I said, you know, okay, so now I sit in the meetings and people talk and I just listen And sometimes they talk about like a potential pothole that or sometimes I'll hear them talk about something and I'm like, oh that sounds like that's gonna be a pothole, but I don't say anything now nowadays.

Speaker 2: I just sit there quietly And if somebody else says, hey, isn't that going to be a pothole, I'll be like, wow, that's a good catch. You know, that nice work. Good, good, good, good thing catching that. Excellent. And if nobody notices it, then maybe at the end of the meeting I'll be like, hey, I got a question. You know, there's this thing that I back a couple of minutes that I kind of I kind of you know heard that I was curious about. So What is my point here? What is what is the point of this story? The first point is I spent way too much time in my life explaining stuff to children. That's the first that's the first thing. But the second thing is this whole concept of progression. Rather than I I'm not going to sit here and be like, well, here's what a good manager is. It's this it's this concept of progression where

Speaker 2: You know, you start out and you're you're developing and you have the skills that help you develop and you know, you know, if comes before then and that kind of stuff. But then after you've done that for a while, you know where the technical problems are, and then you start to see where the political problems are, and you start to see where the financial problems are. And so your input is valuable at the technical level, but it's also valuable recognizing that, oh, this project looks like it could very quickly increase in scope financially. Let's get ahead of that as well. And then, you know, you get to the point where your val your your input is not just Being able to directly say, okay, this project might be a problem. It's when you get other people to the point where they can see

Speaker 2: the project may be a problem. And they're now you're grooming the next generation of leaders to to come in and you know take over for you. So So sorry, that's sort of a long story, and I apologize for the length, but that's sort of, I mean that I see that as sort of really kind of critical for you in your not just your progression into being a being available, progression to you guys being managers, every single one of you, but the you know the progression in your career. Yeah. So

Speaker 1: did anyone else want to

Speaker 6: Ken, please.

Speaker 3: Yeah, and it's very interesting. So um for reference, I did some time as manager, I came back to the IC role. Right. And like one thing I will say, and I I I strongly agree with most of what you said, because as both of those tracks, and they are parallel tracks, right? Management is a different career, it takes different skills, you have to learn and really lean into it I switched back because I found that the IC role, the sort of engineering leader role in that sense, was something I enjoyed more. I don't think I was a bad manager, but it just took more effort and there are other people like some of the folks here who are better at it naturally. But like the skills do at some point converge, right? Like you talk about solving political problems or operational. Like I do the same thing just from a different vantage point. And at some point, like in every company You do

Speaker 3: you do end up with like a lot of the very senior folks on both sides of those fences are doing similar things. Like, can you escape management in some sense by being an IC forever? Yes, I guess you could do. Like the line management aspect of people management probably won't be there, but a lot of the same challenges are still there. And I I want to re like reiterate like a lot of what Charles said here, that applies to my role as well, right? Like you don't get to escape that if you want to become senior in any sense. It just behooves you to figure out what flavor of it you're going to end up doing, I think.

Speaker 1: I kind of have a follow-up question for you, Andrew. How hard was that transition of going from manager back to IC?

Speaker 3: Going back was so so the key thing is, right, going back, you've got to be the responsible person hand over proper. properly, right? Like you've put you've been put in charge of a team of people. It's your job to make sure that the new man and no, we hired a manager to come in and replace me. So like I had a particular person I could hand over. We sat down for weeks, I swapped notes, we, you know, we did the thing, we were like, oh, this person's trained to this, so give them this kind of work. And like most of the hard work was making sure the handover was smooth, that all the people I was managing felt like they were looked after and cared for. And then honestly, then I was just happier because it was more the work I wanted to do. So like I the one thing I will say is like you do lose a little bit of political sway. Um manager roles tend to have more impact than

Speaker 3: IC roles. That's I think just the trade-off for the work you're doing. Like you are doing more work with people and so you represent more folks. So I think that just does come with more sway just as as a default.

Speaker 1: And did did anyone else on the panel have that experience going from management maybe back to IC or maybe to maybe a different lane in management? No?

Speaker 6: I pretty much have I mean I I still code most days, you know, even though I'm managing. Um but I I never really went like after managing I I guess I did. I guess you're right. I guess I did. I I managed a team at the journal world at the company that was owned by the journal world. And then I left and was a freelance consultant just me for quite a while. So I guess I did kind of have that, but I was still fairly technical even back then. Um it was nice and enjoyable to go from sitting around talking about computers all day to actually getting to do some code and and touch computers again. you know, for more than email. But it it it felt kind of like coming home. Like it was, it was not a it was not a it was not a rough transition except for I I picked 2007 to start a business.

Speaker 1: I mean we all make mistakes sometimes. So I I'm looking at the panel and as we were getting kind of getting to know each other a little bit better, um one thing that one thing kept coming up, and that was the word like consultancy I've actually talked to a couple of people who work at consultancies in here. And for those who are maybe a little newer to the developer community, what are some of those benefits of Maybe starting in a consultancy or in some folks' case on the panel, starting a consultancy.

Speaker 4: I think one of the big benefits Yes. One of the big benefits is that you can try lots of different projects, right? You are not stuck working on the same thing all the time. It's always new problems, new people, and It's just rapidly paced experience and just jumpstart. So

Speaker 6: Yeah, you never get bored for sure. Um and and then you start to see that The kinds of problems that happen with this industry are really similar to the same kinds of problems that happen in this industry with this one extra little legal or regulatory or or societal twist to it. It's, oh, that technique we used for fisheries management 15 years ago will actually work for you know managing people at an event or something like that that sort of data structure or that that technique we used is real similar and and you get to see that. But as we were talking, as we were getting prepped, sometimes I do long for getting to focus on a project for like a really long period of time and like really like deeply put that really nice level of polish on something.

Speaker 3: Yeah, you you do often end up though. So like, you know, the grass is always greener as we were joking about in the green room, right? And like I did agency work for several years and was It was incredible. I credited with a lot of my growth as a sort of early engineer. But at the same time, like working at a company for long enough that your own design bugs come back around again. three years later invite you is actually also quite a sort of validating experience, right? Like when you when you can blame yourself, but also you've seen that product or around you like and both of them are good. I'm not here I think none of us here are gonna say like do one or the other, but like there is a lot of value to both. I've switched throughout my career. I think several of us have switched in in different ways and there's a lot of value in both sides.

Speaker 1: Do you still bill for those bugs that you caused? Who wrote this code?

Speaker 3: Well, I mean one one of them was a pricing system. I should have just like, you know, siphoned off one cent of each transaction.

Speaker 5: I was just gonna add kind of one thing that I noticed that um after several years and consulting um is that you know you tend to specialize in a a something, right? Like either a a piece of software or a type of development or or perhaps something on the back end like a you know, a DevOps kind of thing, but people tend to kind of get specialized in consulting. And then at some point, what happened? Um to me and and my husband who we work together is that we kind of decided like we were sort of curious about how to to work outside of consulting and to work more in kind of a product type of role. And so one of the things that we were talking about when we kind of prepped this is that there's sort of options if you're trying to get out of

Speaker 5: day-to-day coding um and you know there are sort of the consulting lane and then there's you know working at a you know, a a business or some kind of where you're part of the development of a larger business. And then there's also sort of another option, which is working for a product company that builds developer products. And and that's kind of an interesting pivot to make once you're out of consulting, is that there is kind of a whole world of people building products for people. like you and productivity software and lots of different things. And that's kind of an interesting place to go after or before consulting.

Speaker 1: I I I do have kind of a add-on question with this. As as y'all were just now talking, I was thinking back to some of the conversations we had, but uh also uh Daniele 's talk uh yesterday about imagination. And I remember someone brought up the idea that, you know, when you're working at a consultancy, when you're working for a client, when you're doing contract work. You you do the job and you you they don't they don't want your imagination, they don't want your opinions, they want you to do the j unless that's what they're paying you to do. They they want you to do the job. Do you struggle sometimes with with balancing that or still finding creativity in your code when you're, you know, you don't really have much direction

Speaker 1: in the code that you're writing?

Speaker 6: I mean I think that you you're able to use that imagination to like like to go back to Charles's point of like figure out how which direction do we turn to avoid the pothole, right? Like it's it's maybe not imagination in code or architecture. It's imagination of how do I convince this person to do it my way? Because I'm pretty sure I'm right. But how can I do it without like because I can't They don't work for me. I can't make them do it this way. But I'm pretty sure this is a better way. Like how you know get imaginative of how to how to convince them. And like in on it's almost like a sales process in some way, like I mean convincing them that this technique is better than that technique or this process is better than that process.

Speaker 3: Yeah, and and kind of sort of as a balance to that too, right? Like when you're in a company for a long time, one of the skills you have to learn, and you know, I learned this a bit from my consulting days is you will always have grand visions. You'll have imagination imagination or how these are this amazing three or four year plan you just can't do those either right like a a good technical leader breaks a plan down and does three month chunks, there's good milestones, you have a basically a plan because like companies change at any given six month interval, the entire world could shift and your project is now upended. And if you designed it correctly, you will have something to show for it. But like you have to always counteract that kind of long-term planning that you can get out away from agency or consultancy. work, but have the same idea of like, well, yes, there is more stability and more longevity, but you still gotta be responsible and make sure that like you're not going on a two-year all-or-nothing project

Speaker 3: because that is the kind of project It's usually doomed to fail, I think.

Speaker 4: One thing I want to add in terms of that convincing and you know in coming to problems is in human-centered design, right? And when you're working either in consulting or in product and us as developers, you know, a lot of people think, oh I'm a developer or engineer. I have no business in doing human-centered design, actually talking to users, talking to people, and understanding what they need or want. And I think that's really where a lot of your imagination and the way you think as coders. The talk right before this around accessibility, wonderful talk. If you didn't, if you weren't here for that and want to see you know definitely see that because at the end of the day we're building things for people right no matter who is paying you to do it you're building things for people to use them and so it is vital to to be doing that and then you're going to

Speaker 4: to then bring that into however you write your code, the way you write your code, the way you think about it.

Speaker 1: So we're we're actually doing really good on time. Um so before we jump to the grand finale, um Charles, you and I had a conversation after we planned about when do you think you're ready? to take that step into maybe no longer an IC, maybe I try management or maybe I I have start having those conversations. How do you identify some of those initial indicators that maybe this is for you?

Speaker 2: That's a good question. I think that going back to what we were talking about earlier, it's similar to the question, you know, when do you think you're ready to have kids? You know, you just

Speaker 1: A, you're not.

Speaker 2: And and B, it it's actually you're more ready today than you were yesterday. But you're not nearly as ready as you're gonna be tomorrow. So at some point you're gonna have to to to kind of make that determination that you You know, you want to you want to go ahead and do it. Um I think that as a metric though, one of the things that that kind of convinced me that I was kind of ready to to to when when they said, hey, you want to run a team. The thing that made me ready is is sort of when you start looking at the other managers or you start looking at the managers that you see that you have that are around you. And you you don't feel like they're magical in any way. You know, they they they have they're making their decisions based on the same kind of information.

Speaker 2: that you can see and you're like, oh, I see why they did that. Or, you know, I I kind of understand their thinking. Or you maybe you're even at the point where like, ooh, I wouldn't have necessarily done it that way. then then you're kind of, you know, then you're a peer of them. Then you're you're sort of ready to to take your place amongst them. And, you know, it I realize that there's sort of a couple of going back to the original question, you know who put me in charge? Some people are tapped. You know, that you know a manager comes to you and said, hey, you know, you've been doing a lot of good work. We'd like to give some give you somebody to help you. Or, you know, there's the you're this team lead over here is left would you like to to take over and that's sort of one way of doing it or you know and that that way you have the the the support of your business infrastructure

Speaker 2: you have your boss trying to help you succeed you've got But sometimes you you leave a place because maybe there's no upward growth and you have to go to a new place and you start as a manager and that's a little bit more that's a little bit more tense because you know know they're you're coming in and and they're saying well you're coming in as a manager you clearly know how to manage and so that's a bigger a bigger jump but then you also don't have the the kind of of the stress of managing all of your old friends that you used to be peers with. So it sort of goes both ways. I think it really is when you it it's it's a little bit like that imposter syndrome talk. was on it. I think if you can look at yourself and look at the managers around you and say, you know, I'm not really seeing this giant gap in understanding or knowledge, then you're pretty much ready.

Speaker 1: Yeah. Anyone else want to?

Speaker 6: Yeah, I think that um for for me it was a slow process. Somebody got me like a a a part-time assistant and then I had a full-time assistant. And then it's like, hey, we could really use a developer. And so it kind of slowly happened over time. It did end up being actually friends of mine, which was kind of weird and uncomfortable in sometimes. But um The uh I think for me it was when I started to really deeply understand what was going on in those other departments. It wasn't just like I am been told I give this form to the HR department and they do something with it. It was like, I know what happens that from there. I know the two or three steps deeper in. Then I was like, okay, I'm I really have tentacles and I understand the organization. I think I can lead this section of the organization, right?

Speaker 5: I was just gonna add that I think my first management job for people came out of writing documentation for the department. And you guys are all software engineers, so I don't have to evangelize documentation, but I do think. I do think like being Being really good at documentation has always benefited me in my career and and particularly in management. And documenting like the full life cycle of things and knowing how things start and how they end and and like Frank was saying, like how pieces of what you do touch other things. I think that's always a, you know, if you're angling to be in management, we're in your position now, um, writing really good documentation and sharing that with your team is a great way to kind of show

Speaker 5: some initiative and show a a comprehensive understanding of how things work. And it'll be helpful for you when you're managing the team.

Speaker 3: Yeah, and and you know, kind of almost a little bit from the outside, right? Like my favorite managers both currently and in the past have been people who you know, I can work with m sometimes as a peer, sometimes underneath, right? As you get more senior it kind of varies as an IC. But like they are people who are experts at understanding the organization, where to turn to who to who to talk with, how things fit together. Like that's the skill. Like when you work with a great manager, you can just sit back and be impressed by their ability to take a problem, decompose it, handle it, like offloaded other people and like if that's a thing you are excited about maybe that is actually the career for you right like it is not that far from engineering it really isn't like we had the Lego

Speaker 3: blocks analogy earlier right like Is you are taking a system, a system of people, but it's still a system with its own needs and wants and good and bad parts. And I have so much respect for people who can do that well because It makes my job so much easier to be able to give that to folks who are just m amazing experts at it. Right.

Speaker 1: And I I also want to acknowledge the like DSF Leadership in the room as well by thinking about something that we talked about in our planning, which was sometimes your ability to contribute the way that you used to changes with just how life goes. You know, I have a five-year-old. She was kind enough to let me get on this stage. And you know, I know a few folks here have, you know, kids who are in college. Um, some have kids who are grown and are looking, you know, closer to like grandchildren. And and when those things happen, you're like, My my time and my priorities and my ability to contribute differently all

Speaker 1: shift. Do any of y'all want to kind of go into detail about how, as life changed, maybe your your impact in direct lines of code maybe change to conversation.

Speaker 6: Yeah, I mean I think that like for me uh you know your early twenties you can stay up all night and then still go to work the next day and and you know it's fine. I don't know how much of this is having kids and how much of this is just getting old. But um but like you know I I can't do that very often anymore. Right. Like I need three days to recover if I have a 12-hour day, you know, that, you know, because of necessity. Um, and your priorities change, right? Like work 's important. my career's important, you know, taking care of my team's important, but my kids are important too, right? And you gotta make time for them. Even if I might be mentally thinking about some problem, I'm really trying to play Legos with my kid, you know.

Speaker 4: I want to just make the point that it's not about having kids. Like it honestly being a manager for me is not about having kids. Spending time with my kids and my wonderful husband is is definitely a priority. And making time for myself. And I think that's the most important thing is making time for yourself and what that looks like because this work can't is just it's impossible sometimes. times and you have to step away from it. I think the very first blog post I ever wrote, I wrote in like five minutes and it was like, I'm just gonna walk away from this code right now. I'm gonna go take a walk and I'm gonna come back and then I'm gonna write what happened. And then I figured it out afterwards. But I think it's about taking the time for yourself. And as a manager, that's what's the most important

Speaker 4: is knowing when to say, having the boundaries of saying, this is when I'm available. This is when when I'm not available and for yourself and and others. So yeah.

Speaker 1: And I brought up the DSF in that I'll let you go in just a second. I brought up the DSF in that because uh what we've seen kind of recently is this expansion beyond the only way to contribute to Django is through A documentation, B code. what else maybe a Django Con here and there. There are more ways, so if you don't feel like you have the bandwidth to contribute on from you know the tracker maybe there are ways that you can contribute otherwise where you do have that bandwidth and that space sorry Go ahead.

Speaker 5: Oh, I was just gonna kind of add that I've my kids are just starting to get like older and I just sent my first kid to college and I have a kid in high school. Um, so I'm sort of where I sort of committed my whole life. Unlike Julie, I did not carve out time for myself. I gave my kids everything. everything and made bad decisions. But you know, I sort of didn't didn't have time to to do anything other than like go to work. You know, I didn't like go to meetups and I didn't participate in open source communities. And like I could have done those things and found those people. I I live in Lawrence and I met Frank this year and I met Jeff like yesterday, which tells you how bad I was for 15 years at getting out of the house.

Speaker 5: Um, but you know, like if if you're in that phase and you have small children at home, you know, the this does kind of end and there is sort of this whole world that kind of awaits you once your kids are gone and you know if you can't participate in the community now and you don't have time for it there you know there there may be a day soon where you will

Speaker 6: Kind of similarly, I I know some people who've are empty nesters now and people who've retired and that transition is kind of rough because you kind of you've got all this stuff to do and then there's just like silence and there's nothing nothing. And um, you know, you should have some sort of plan for like what am I going to do with that time. But also like from a one of the things that I did uh when I first started kind of really managing and I wasn't really having any sort of uh individual contribution sort of thing was I made sure like my me time was actually like working on some fairly unrelated open source. thing, right? Like it kept my skills fresh a little bit. And it and it was it was fun for me, but it was like I I didn't then try to dive into my staff's problems because I'm really bad about doing that.

Speaker 1: Awesome. Well we've got about one minute left. So I wanna take one minute left for each person here. Not one minute left total, one minute for each person. I wanna ask each person what's next? Or is it is it back to more day-to-day coding or something else?

Speaker 2: That's an excellent question because as Frank was talking about empty nesters, I just sent my last kid off to college a couple of months ago. And so, you know, as Elizabeth was saying, you know. When I had them, I didn't think about I didn't think about meetups, I didn't think about my own side projects. I mean I had to drive them places or go to their things. or do that kind of stuff. So I'm actually kind of at what Frank was talking about, where I sort of need to step back and think, well, okay, what am I going to do with my time? you know what what what's next I mean you know I'm I'm I'm not quite retiring yet um so uh I've got a little I've got a little time to decide what I want to do and and it's a it's an open question. I'm not sure.

Speaker 1: Andrew?

Speaker 3: Yeah, I mean so for me it's a bit different, right? So like on one hand I'm doing a lot more sort of like volunteering in my community kind of like in In the sense we're talking about here of like having a thing that is not coding, right? Like just like local hands-on groups doing things that have almost no code whatsoever On the other hand though, right, like uh for an IC, while the path to sort of your principal distinguished level is already murky, beyond that, it's basically just a torn-off map with the word heavy dragons on it And so, you know, my goals are not entirely clear, right? Like at some point, like there are some variations of this CTO role I think I would do quite well at. But we come back round to that, well, you're also maybe not a direct manager of managers, but like being an executive is again a different job. And so there's a whole path there where like

Speaker 3: I'm trying to figure out exactly How do I build my skills or my abilities up to that? And will I enjoy it crucially, right? Like maybe I'm just happy doing you know architecture level stuff for another 10 years. Maybe I'm not. But like I'm being open, I think, is the most important thing thing and making sure you do what you like.

Speaker 4: And for me, um, I got into people management because I love people and I love helping people. It's like here for me. And so I see myself continuing to do that, but always being open, as you're saying, to other ideas and other avenues and where wherever the wind takes me because one thing I do know about myself is I love also very hard problems ones that seem impossible to be able to to fix and so I'll continue to be doing both of those things.

Speaker 5: Um I don't a hundred percent have a plan but um I guess I'm like where Charles is but I have really been um enjoying like teaching people um about like software or databases or different things and um I am so impressed with all the Django girls stuff that I have seen and I'm extremely jealous and I wish that Postgres had some like that. So my sort of little baby community goal would be to do something like that for for the Postgres community to kind of do some advocacy like that. So anyway. Yeah, it is. It it is. Yeah.

Speaker 6: So I've actually probably been doing too much coding for what my job really is uh lately. And so my My kind of near-term goal is to actually do way less uh coding than I have been. Um because I'm doing Yeah, Jeff's yeah Jeff Jeff's been on my case about this for a while, and so now that it's on video, I guess I have to do it, right?

Speaker 1: Well, um first of all let's give our panel a hand or host thank you thank you And we understand that there might be a hundred questions in here. Unfortunately, we have two minutes left, so we're not going to be taking questions here. But some of the panelists did agree that they were going to be in the lobby and they will be happy to sit down and chat with anybody. Maybe you are considering making that next step in whatever it is your career cycle looks like. They will be happy to assist you there. But yes, for and please enjoy our closing remarks coming up and thank you for being such a lovely audience for this period.

Speaker 1: Thank you