CLAIRE: 00:00:00
Welcome to Talking Postgres, where we discuss the human side of Postgres databases and open source. For regular listeners, I want to point out that this podcast has been renamed. It is now called Talking Postgres. And I want to thank the team at Microsoft for sponsoring the community conversation that we have here on this show about Postgres. I'm your host, Claire Giordano. And today's topic is Becoming a Postgres committer. And I'm really excited to introduce Melanie Plageman as our guest. Melanie is a Postgres committer and major contributor. She's one of two Postgres developers who became a committer earlier this year, back in April. And the other awesome new Postgres committer is Richard Guo. Melanie works at Microsoft and spends the majority of her time working on Postgres open source, specifically focused on performance. As we were preparing for the show, Melanie told me that most of her work these days is on vacuum. But she's also worked on the executor and the I/O subsystem and was the primary author of pg_stat_io, a new capability that was added in Postgres 16. Melanie lives in Pennsylvania, so on the east coast of the United States. And in addition to her work as a developer, Melanie also does quite a bit of volunteer work in the Postgres community. She serves on the organizing team and the program committee for PGConf.dev, both for the one earlier this year and also for the upcoming event for 2025. And Melanie serves on the Postgres contributors committee. Finally, she's a runner. And so she often listens to Postgres videos and podcasts while on a run and we'll be sure to talk about that later today. Welcome, Melanie.
MELANIE: 00:01:50
Thanks for having me, Claire. That was quite the intro.
CLAIRE: 00:01:53
That was quite the intro. It was a lot longer than usual, which maybe is just because I've gotten to know you the last couple of years, so I had a lot to share. But it's time to dive into today's topic on becoming a Postgres committer. So let's go. To start, you once told me about this odd decision you made to become a Postgres developer. And the fact that you called it an odd decision, I found kind of odd. So I really wanted to start with that and ask about how did that decision happen?
MELANIE: 00:02:26
Yeah, so I don't have a background in computer science, or a lot of, I didn't have a lot of experience as a programmer. And I was doing IT consulting and teaching myself programming. And I, you know, we used a lot of databases, and I had a chance to use, start using Postgres. And I thought it was amazing that you could, I didn't have a lot of experience with open source, but I thought it was amazing that you could see the code. And I wrote a Postgres extension, a C language extension. And I just felt really like the comments were really good. And it just felt really readable. And so I remember I went to this talk by, it was a Rust developer relations person that was giving a talk at a conference. And he said, you know, systems engineering is so cool, because you don't, you know, there's no magic and you sort of get really down to it and have to understand what's going on. And you can ask questions and get all the way to the bottom of the stack. And I thought, that's so cool. And I think like, what I decided was to quit my job and to basically try to get a job working on Postgres, which looking back on it, like, I didn't know how silly that was, because like, there aren't that many jobs where you get to contribute to open source Postgres. And I said, you know, basically, like, from the start, my goal was to have my first job as an engineer be working on Postgres. And it kind of was like, I think now looking back on it, it's unusual to have that be, you know, I don't want to do anything if I can't work on Postgres. That was my goal. So I ended up getting the opportunity to work at Greenplum, which is a fork of distributed fork of Postgres. And part of our work, the work I did was open source, but I got familiar with the code base. And I think over and over, I sort of chose Postgres, because I felt like the values of the community in terms of quality and what they're trying to do, like, were really consistent with my personal values, like I want to do good work. And I want to do it with other people that are also trying their hardest to do good work and that don't have an agenda, but other than wanting to do meaningful good work and to have it be out in the open, basically.
CLAIRE: 00:05:02
I think I want to make sure we quote that and share that somewhere along the way. I've heard that again and again from other guests that just this commitment to the customers and the users and the quality and trying to, quote unquote, do the right thing for the Postgres community. I just it's a common theme. So wait a minute. I want to go back to you decided to quit your job and try to get a job working on Postgres. How long did that take? How long were you out of a job? And usually people will look for a job while they remain with their current employer. So why did you not do that?
MELANIE: 00:05:42
Well, so before I left, I started saving money because I knew that being a consultant was not for me, because the way you advance your career is by, you know, in that sense, it's like selling work and doing less coding and doing more consulting. Right. So but once I was out of work for, I think, a year and a half, I'm trying to think. Yeah. A year and a half. But I didn't start interviewing at first. I just was like, I need to learn everything about being a good programmer. I need to learn about operating systems. And so my my now husband was really great. He basically was like, here's a list of the things you need to learn to be a good programmer. And I was like, OK, let me learn these things. And I didn't want to just be a programmer. I wanted to specifically work on database internals. So I took some online classes and I spent a lot of time on things that weren't just Postgres. But I think writing Postgres like C language, Postgres extensions is a really good way to get exposed to the code. And then sort of the style of, you know, some of the abstractions and APIs that Postgres has internally, some of those you can use when you're writing functions. And like it's sort of a way to not have to think about all the subsystems and know everything about database internals, but still create something that you can access via SQL. And I think at that point, I underestimated the complexity of contributing to Postgres, because when you don't know anything, it doesn't seem like that big of a deal. So it took a bit to get that. And I think, you know, Pivotal took a big risk on me. Right. Like I didn't have a track record of contributing to Postgres or writing code for databases. And I think, you know, back then, people questioned whether or not it's the right decision to bring in people that are just starting. But they had a culture that was really focused on collaboration and pair programming. And I had people, mentors that spent hundreds and hundreds of hours programming with me and teaching me about databases. And then, you know, I took classes at CMU and I listened to every Andy Pavlo lecture ever. And I think one of the reasons I feel like not very many people have the opportunity that I have. We can't count on that being the path for most people to become Postgres contributors, because like, that's pretty lucky. Right. That I happened to get a job where I could work on Postgres code and then have hundreds and hundreds of hours of other people's time mentoring me. So like, how do we sort of, I just really feel compelled to pay it forward as much as I can, because I was so lucky.
CLAIRE: 00:08:43
Well, and you have been paying it forward when I think about some of the community work. And I know the topic of this episode is becoming a Postgres committer. But actually, I was wondering, like, does some of the community work that you do, like serving on the organizing team for PGConf.dev, serving on the program committee for PGConf.dev, which is an annual conference that happens in Canada, that is really geared toward the Postgres developer community. Like, do you think that was a factor in or consideration by the Postgres team that said, hey, we want you to be a committer?
MELANIE: 00:09:20
Well, I will caveat this with saying that I have not yet, because I just became a committer this year, been part of the process of selecting new committers. So, you know, new committers are selected by existing committers. And there is a private mailing list where they discuss. And so I haven't been part of those conversations. And I was a little nervous about talking about this today, because I was like, what do I know about being a committer? I actually have no idea why I was asked to become a committer. But I think in conversation with some existing committers about, you know, the selection criteria, what they think, I think definitely like community work is part of it. If for no other reason than you're showing a commitment to stick around, it takes a long time to be productive writing Postgres code. And then inevitably, other people invest time in you, they review your work, they, you know, try to help you. And so if you do, you know, you don't want to make someone a committer, and then they just like fall off the face of the earth the next day, because you kind of, you spend all that time deciding if they should become a committer and reviewing their work and whatever. So ideally, you have people that are going to and also once they commit work, you want them to stick around and support it and maintain it. And if you're not sure if someone is going to be available to do that, then like it doesn't make sense to make them a committer. So I think that it must be part of the criteria is community work because it's showing, you know, it's one way. There are other ways of showing dedication to the community and intent to stick around, but it is one way of doing that, I would say, for sure. I want to get to the conversation to ask you about what does it mean to be a Postgres committer like what is it because there may be people listening, who are new to Postgres and don't even aren't even familiar with the different terminology about what is a committer what is a major contributor. So let's touch on that, just to catch those people up. So, being committer just means that they add your SSH key to a file on some server and then now you can push code. Technically, that's the only difference there's like nothing other nothing else cool that happens to you. But that means you can have code and that has, you know, sort of, you were the one who committed it in the official Postgres core code base. There are people that are committers to some of the other ecosystem projects and drivers and things like that. But in this specific instance, I'm a committer for the, like, core Postgres code base. And that doesn't mean that you author all the things you commit like, I think that's actually not, you know, ideally, you would work together with other people and review and get their work to become committable. And so you might push other people's work. I think there are, that's the literal role, but there are other implied responsibilities, like you're responsible for maintaining everything that you commit, maybe not solely, like, obviously, hopefully other people will help and support you, but you're sort of taking on what my, I guess, my understanding is a lifetime commitment to supporting everything you commit. So, and trying to help move forward work in the community that's authored by other contributors, because we obviously want to support people who are not working on Postgres full time or people who are users that have work that they're doing, that they're not going to get it to the point where it's committable, like they don't have time or that's, you know, whatever. We, part of being a committer is taking responsibility for, you know, supporting and promoting and moving forward the work that's important to the community that you didn't author as well.
CLAIRE: 00:13:34
Got it. One of the things that Daniel Gustafsson just threw into the chat is that a committer in Postgres terminology is often called being a maintainer in other open source projects so I thought I would throw that definition out there as well. And I know I, I'm working on a talk for PGConf.EU, the one that's happening this October in Athens, Greece, and I've been partnering with Daniel Gustafsson on doing some research relating to that and I know for every commit that happens, usually the committer is recorded, but so is the primary author right as well as who the reviewers were for that patch. And sometimes there are shout outs to other people who were involved, maybe in testing it or validating it, am I getting all that right?
MELANIE: 00:14:23
Yeah, if it's a bug fix whoever reported it. And anyone involved in getting the patch to where it is at the end except for, perhaps, people that just participated in technical discussion, but didn't review the code
CLAIRE: 00:14:39
Ok, actually I mean makes a lot of sense for anyone who's worked in other open source communities attribution is really important, right, giving people credit for the work that they've done and visibility for that contribution whether it is reporting the bug, or QAing it or code reviewing it etc so anyway, it certainly made our job, a little bit easier that all of that is recorded because we've been looking at all the different contributions and and trying to do an analysis of that. So, can you see the chat Melanie? Robert has said that we actually expect Melanie's corpse to continue supporting the stuff she commits. I guess he's talking about your lifetime commitment here.
MELANIE: 00:15:23
Yeah, exactly. Or I have to put in my will who I'm passing down my maintainer responsibility to.
CLAIRE: 00:15:33
Okay, so this odd decision that you made when you quit your job and spent a year and a half, both learning as well as probably looking. How many years ago was that?
MELANIE: 00:15:46
That was in 2016, and I started work in 2017 on Greenplum.
CLAIRE: 00:15:54
Okay, and became a committer in 2024. Yeah, is that seven years then. Right, approximately. Yeah, depending on the months. Okay, cool.
MELANIE: 00:16:05
So, I'm very aware that I think like, it's pretty unusual for such an inexperienced programmer to probably be in this position. But I think I try to be really aware of where my weaknesses are and where my inexperience might lead me to come to the wrong conclusion or look at things from the wrong perspective and I think that's one of the reasons why I've sought out mentorship so aggressively, is that I am trying to make up for some of that sort of inexperience if that makes sense.
CLAIRE: 00:16:43
Well, you gave a talk last year at PGConf.EU that I was only able to attend part of because I was taking a lot of photographs and so I had to hit three different talks during your session, but I was in your session for part of the time, and the title of it was Making Your Patch More Committable. And what I liked about it was first you were sharing with other contributors to Postgres kind of what techniques. I thought were helpful. You know, we're going to make it far more likely for a patch to get committed rather than to sit out there in the ether for a year. And, but I also like the thoughtfulness that it showed that you were thinking about, is my email clear. Am I making it easy for the committer that I'm trying to work with to understand what I'm trying to do, or am I making them have to work really hard by writing these really long obscure emails. That's my takeaway from it but I wanted to pitch it to you to tell me why did you give that talk? What was your goal?
MELANIE: 00:17:45
For a year we have a few Postgres conferences and I, if I want to speak I try to think about what do I have that's unique to say, and usually that's based on what did I learn that year, or, you know, what do I feel like what has been my, it's influenced my focus whatever my focus was that year. And in the past. At the beginning I mean I was very focused on technical things like just being able to write the patch and that kind of thing. But in the last couple years, I've been more focused on, you know, how the strategy, and how to break a project down into smaller pieces that are individually valuable, and can move the project forward in a small way, and that serve that larger projects and the same thing that I've heard from people isn't required and all projects like maybe an open source projects but, you know, for people that are working as developers, they may have a feature they're working on and then when it's done they can just like committed they don't need to individually market and sell smaller sub projects, and like, hide their end agenda. I get it but you're everybody has limited attention, and none of us are being like the whole project is it doesn't have a PM that's saying these are the goals or whatever right. So, you have to really think about how can I use that limited amount of attention that I might be lucky enough to get from some other person on the mailing list. How do I hook them how do I get them interested and then how do I give them all the information that they might need. And, like, you know, sort of be as clear as possible, and I sometimes struggle with this because I'm a rambler, I like to talk I like to I have lots of thoughts and kind of stream of consciousness. So like, just being really clear and thinking about what information is actually important to this other person and putting yourself in their shoes and that kind of thing. And even just like the ordering of the commits, the individual pieces like what is the minimal thing that goes in this commit and like, how can I make it if I look at this diff and I wipe out everything I know about this project, how can I make it as easy as possible to just like know what it does right away. And that stuff is hard it's hard for me at least. And because that was what I was working on and struggling with and trying to get better at. I figured that other people might also benefit from that. And I've also had the privilege of working with, at that time I was you know it's not a committer and I was being, I was able to work with a lot of committers and the feedback they would give me on all of my patches like I would try to extrapolate how does this apply to other things how does this apply to other work when I've been successful. Why has it. What was ultimately the thing that led that patch to actually get attention or to getting in, and then sort of put it all together into like a plan or a set of steps that you could use if you're trying to do the same thing. And, you know, give other people the benefit if they're not getting to meet and talk to committers about their individual patches like what could they do also.
CLAIRE: 00:21:02
Is it fair to say that you try to use the same or that you do use the same analytical skills that help you navigate the code and solve problems in code, you try to apply those same analytical skills to how do I work with people, how do I improve this process, how do I make sure I know why this patch was successful, so that I can do it again.
MELANIE: 00:21:28
Yeah, that's definitely true it's like having a hypothesis and then, you know, trying different things and seeing which one works, there's definitely an aspect of that. And then the other thing is being able to, you know, have empathy and I think I, the more I spend time as a programmer the harder it is for me to relate to other people which is kind of funny like you, I spend so much time alone now just like thinking about code and problems and so to take a step back and to actually say, okay, someone that wasn't working on this, what would they think it gets actually gets harder over time, which is interesting.
CLAIRE: 00:22:14
So you feel like you're losing some of your people skills because you're spending so much time alone in your office working on code.
MELANIE: 00:22:22
Definitely that is happening. Also my tolerance for other people.
CLAIRE: 00:22:29
I think I don't see that I what I see from you is that you have a lot of empathy like I know when you reach out to me to ask me to collaborate on something or help with something. until you've put thought into our discussion and what your goal is and you're trying to use my time efficiently. Which I think shows that you have empathy still. So anyway, maybe you are losing some of your people skills, but you've still got a lot. (chuckles)
MELANIE: 00:22:58
Oh, thanks Claire.
CLAIRE: 00:22:59
Yeah. There's still a lot there.
MELANIE: 00:23:01
I think anytime you focus on, this time of year, this like post, once the focus is less on the last release and starts to be on the next release is like the R&D part of the year is kind of how I think of it. And I struggle with this time of year actually more because I'm sure it's different for other people, but for me, there's a lot of sitting alone and thinking really hard and like just getting further and further in your own head and not necessarily like when it's closer to, when you're iterating and getting review and feedback and discussing something, you get to hear from other people's perspectives more. And I think it builds that sort of awareness and empathy more because you're interacting with people and hearing their perspective on your work and thoughts more. So I think actually like different types of work, 'cause there's the phase of a project where you're building and thinking about it and strategizing and designing and writing code. And then there's the part where you're incorporating other people's thoughts and feedback and correcting course and pivoting. And I think when you're doing one type of work versus another, it can be easier or harder to see the like bigger picture and take a step back and not just think sort of tunnel vision around what you're trying to do.
CLAIRE: 00:24:29
Yeah, and there definitely are seasons to the Postgres development process that you're referring to when you talk about the different times of year. So again, for someone who's new to Postgres and not familiar with those seasons, can you give us a quick primer?
MELANIE: 00:24:44
Yeah, so we typically have a feature freeze in April and that is like for, we do one release a year, or not, I mean, not one release, like one major version is developed each year. And then there are minor versions and bug fixes and such and released on a regular cycle. But that means that the code freeze doesn't tell much later, but that means that all of the feature work has to be done by the beginning of April. And then we spend time stabilizing the release, doing bug fixes, like improving documentation, adding tests, though there should already, you should already written tests. But, and that's sort of the summer and the PGConf.dev, formerly PGCon is kind of like right in that time where we just finished the feature freeze and now we're thinking about, hey, what are we gonna work on next year? And you go and you talk to other developers about it and come up with ideas. And then GA is actually next week for Postgres 17. So that means the in focus is basically entirely now, except for bugs on developing Postgres 18. And so that's kind of the schedule.
CLAIRE: 00:26:01
And then how many, there's this thing called a Commitfest Can you tell everybody what that is and how many Commitfests are there each year?
MELANIE: 00:26:09
Well, they're usually every other month, but then there's like one month we skip. I don't, it's, is it January or December? I don't know, but it's usually, it's like mostly every month. Right now, September is one. And to be honest, I don't know actually how much Commitfest, I've actually been meaning to do this analysis to see how much more is committed during a Commitfest than otherwise. But hypothetically, it's when everyone focuses on reviewing and committing things. And then the other month is for developing and proposing new things. But the sort of most, I would say the most important part about the Commitfest is that the Commitfest app is where you register patches so that you don't forget they exist and lose them forever. So it's like when you have something you would like people to look at, you go and register it in the Commitfest app, but that's pretty detached from the actual process of having Commitfest. Like we could just have that app and yeah.
CLAIRE: 00:27:11
There's some great comments in the chat, which I just want to share with you. When you were talking about how you may lose some people skills, you spend so much time doing deep thinking, particularly at the beginning of a release cycle. And Robert Haas said, you can get too lost in your own head sometimes. And so he thinks it's important to anchor it back to making sure you reach out to other people and discuss things with other people pretty regularly. And then Daniel Gustafsson chimed in that that whole asking for help and asking for feedback process is just so critical in programming, particularly in open source work and specifically remote development work. So it's interesting, 'cause I do, I have seen you ask for help. I have seen you ask for feedback. And you, like you said, you reached out. I think you reached out to Robert Haas along the way to ask him to be a mentor, is that right?
MELANIE: 00:28:11
Yeah, we started working together a year ago, or meeting and talking, and actually like even the project that I'm working on right now, he's taken a lot of time to talk to me about it and what direction it should go. And so I'm very lucky to have people who I can go to and when a project is in those early stages or anytime to talk about it. And one of the things that I've noticed as I've been in the community longer is that we say everything happens on the mailing list, but a lot of people are having one-on-ones and meeting and discussing because there's so much that happens before a patch gets on the mailing list. Like there's so much work and thought and versions and discussions. And so sometimes those are happening off list. Some people propose their idea without the patch set first on the mailing list and get feedback. But I think it's sort of human to need to talk through things and not be ready to put them out in the world in a archived permanent place right away. So that's something that I think people that are contributing don't always realize. And one of the things like Robert started a mentorship program for Postgres. And I think one of the things that is great about it is that there are more venues for people who aren't necessarily as plugged in with people who are major contributors to talk about Postgres development. 'Cause you kind of need that, you need to have those, this is what I was thinking or how do you approach this problem or whatever. It's like, I don't know that people can really be productive without having some of those conversations. And we didn't really have anywhere official to do that kind of thing before.
CLAIRE: 00:30:12
So I feel like maybe that's part of what got you from the stage of quitting your job and looking to become a Postgres developer to seven years later being a Postgres committer was you were focused on finding those mentors, getting that feedback, getting that advice one-on-one from people. And I don't know, I feel like that's helped you. Has it?
MELANIE: 00:30:34
Yeah, I mean, I would be doing nothing. I think I would still be unemployed if it wasn't for mentorship. But I think like, at least my perception is that taking feedback is like the most important thing that you can do and demonstrate that you can do in any role. But especially like if you wanna become a committer, I think like if you're not willing to take feedback and adjust course and change what you're doing, then it's difficult for other people to see how to work with you and to understand how to work with you and to trust your judgment.
CLAIRE: 00:31:11
You're just reminding me of this phrase that I've loved my entire career, which is that feedback is a gift. It is truly a gift and it's a mindset change. A lot of times people who start working in tech tend to be pretty smart, right? They're analytical. And so it is possible that when you get feedback, particularly constructive feedback, negative feedback, maybe criticism of how something could be better, it does upset some people and they don't like it and they don't feel good about it. They're taking it personally and I feel like that gets in their way. But as soon as you shift your mindset to the fact that, hey, this feedback is a gift, it's gonna help me get my patch committed earlier. It's gonna help me be more successful with what I'm trying to do. I just feel like everything changes. I don't know.
MELANIE: 00:32:04
Yeah, and I also think the interesting thing about getting feedback in the Postgres community is that what is committable is not really about how clever it is or the standards or the criteria is not the same as it would be sort of in a vacuum or for your greenfield project or whatever, right? So if you're getting feedback from committers on your patch that you need to take a different approach or this isn't going to work, you have to think about it from their perspective of like they want you to not create more work for them, right? Like ultimately what we want, like there's things that are the right thing for the project and the right thing for the code base. And so when you're getting feedback, it's not necessarily about whether or not you're good at engineering or your patch is a good patch. It's about like whether or not it's the right thing for Postgres. And I think like not taking things personally and thinking about it more from the perspective of like, how can I make my work a better fit for Postgres makes it hurt a little bit less, I guess, but it's still hard to hear that your code is no good, especially 'cause it's so much work, like it takes so long to write some patch that can even be proposed, but yeah.
CLAIRE: 00:33:32
You're reminding me of one of my favorite Stephen King quotes, which is, I'll get it wrong, but it's something like kill your darlings, kill your darlings, be willing to kill your darlings. And I feel like the same thing can sometimes be true with writing, right? You can write words and they can be, you can love the way that sentence sounds or love the ideas in that sentence, but sometimes it's just a distraction and it needs to be deleted or it needs to be left on the cutting room floor. And that can be very hard for writers as well.
MELANIE: 00:34:01
Oh, a hundred percent. And that was very hard for me at first was, but I worked so hard on this. And it's like, you have to take a step back and think about if someone was asking you about that idea and what you would say if you hadn't written it, right? Like if someone points out a major technical flaw, as you put together a patch set or work on a project, in order to have something you can show people, you have to make a set series of assumptions and decisions. And so when you get to the end, someone, you know, and have a proposal, someone might point out, hey, there's this major flaw in this, or, you know, I think that's probably where discussing with people along the way is useful, but there still might be something that's a major issue. And you kind of have to like really think about if it might hurt that I did all this work and it has to be thrown away, but like, is this the right thing? Like, is this person right? Okay, they're right. Then I need to be okay with just throwing this away and doing something else and be glad that I learned something. And I think that's really hard, but it's also the only way that you'll keep going is if you still feel a sense of accomplishment, even if the percentage of your code that actually makes it into Postgres is very small compared to the amount that you write and the amount that you work on, like very, very little of it will actually go in. And if you can still get up in the morning and not wanna, you know, and wanna keep doing it, then like, I think you have to have that resiliency and in order to keep going.
CLAIRE: 00:35:42
Well, and I feel like sometimes you just have to accept that the process is such that some of the work that I do is not gonna land, but I have to go down these dead ends. I have to go down these segues. I have to try on these different hats for size, even if I don't buy the hat, even if the hat doesn't look good in order and I'm throwing out analogies left and right, and I know it, but that's just part of the process of getting to that end result, which is what you kind of are trying to get to.
MELANIE: 00:36:13
And the hard thing is knowing the difference between when you had to do that thing and learn that lesson and throw away that work in order to move forward versus when you need to grow as a person and stop doing the wrong thing over and over. That's hard for me at least. Not picking the wrong project or whatever, you know.
CLAIRE: 00:36:35
Yeah, you don't wanna keep hitting your head against the wall. All right, you mentioned, I think a few minutes ago, and I really wanna go back to it, this mentorship program that Robert Haas has started within the Postgres developer community, and it's brand new, I think. It started just a couple of months ago, if I recall. I first heard about it at, I think it was at PGConf.dev back in May, but maybe it was, I don't know. Could have been right before, could have been right after. So I know you're involved in some capacity, and I wanted you to just share with us a little bit about that. 'Cause my sense is this is relevant to becoming a Postgres committer, and it's relevant in two ways. One, I think your community work probably does show a sign of commitment and may have influenced that decision to have you become a committer. But two, I think it's super helpful to helping future Postgres committers get there, right? Having more mentorship. So talk to us, tell me about it.
MELANIE: 00:37:34
Yeah, so I am helping with program evaluation, and I volunteered to do that because I've had the benefit, like I said, of so much mentorship, and I've been in many different mentor relationships with people that work in different ways and have different ways of talking and thinking about things, and had to try to figure out how to get the most out of that relationship. And more recently, I've been helped mentor a few people, but I have less experience with that. So I wanted to help with how can we most effective, like how can we help mentors and mentees get more out of this? Are there things that the program should do to support people? What does a mentorship program look like in the community, and what can it achieve? What should it achieve? And that's the reason I wanted to be involved in. So I've had many meetings now, and met with almost most of the mentors and mentees in the program. And I think it's early, it's pretty early, but it seems like there's a lot of valuable interactions going on. And I think like some of the parts that are hard about being a Postgres contributor, that some of those things that we feel like we can't address systemically in the project are things that can sort of be addressed in these one-on-one relationships. And I'm thinking, for example, of like, so when you write a patch and put it on the mailing list, if no one responds to it, it's an email, and eventually it disappears, and everyone forgets about it. Maybe someone finds it one day in the archive and decides to reply to it. So people who are newer to the community or have less prominence, have done less work, are really looking for someone to sort of like validate or support them and sort of bring attention to their work, or even just bump the thread and say, "Hey, I looked at this." And part of that is everyone has limited time. So other people in the community, like especially committers, if they see that another committer has said, "Hey, yeah, this idea kind of has legs," or "This seems really simple, and if we wanna do it, we should just do it," it kind of makes it easier for someone else to then say, "Oh, okay, like I can take the time to do that." Sort of the initial evaluation of whether or not something makes sense at all. And when you have a personal relationship to someone, you feel more responsibility to pay attention to them and their work. So I think like one of the things that I hear a lot from people in the program is having this one-on-one relationship with this person, it means that they pay a little bit more attention to me in my work, and that has impacted what I feel like my visibility is in the community. And one of the things that I hear from people a lot, contributors a lot, is that they feel invisible or like they don't know how to break through the noise in the mailing list, and they don't know, "How can I improve if I'm not getting feedback?" is what people say to me sometimes. And "How can I improve if no one reviews my patch?" "How can I make it better if no one pays attention to it?" "How do I know if it was a bad idea, or I just phrased it in the wrong way?" or "I sent it at the wrong time of day," or whatever. And so just having someone talk to them about strategy or even just bump the email thread is a big deal. And I think there are like a few of these sort of systemic issues that make it hard for, that contribute to attrition, that contribute to people leaving, or to people not growing, and not writing more committable code over time. And I guess all we can hope for the program is that this alleviates some of that. Like maybe there are systemic changes we could make. You know, maybe we could have a bug tracker or a, you know, you name it, all the things people have suggested. But it's really hard for a group of people with, we have trouble making decisions and like picking things and moving forward. And for a lot of reasons, both good and bad. And so this is a sort of hack. It's an alternative approach, which is like, can we alleviate some of those things in a different way? Can we take like this different tack? And that seems to be what people are using the relationships for, a lot of them are, which is, I think, promising for us as a project.
CLAIRE: 00:42:27
Robert Haas just shared a link to the blog post that he published back in. Well, it's a list of mentoring related blog posts, but the one that he published in July said there were 34, at least at that point in time, 34 applications for people to, I think, be mentees and nine committer mentors who initially offered to mentor at least one person. Is that, have those numbers changed dramatically? Do you know?
MELANIE: 00:43:00
Yeah, it's not like on, like he picked the mentor, the mentors and mentees picked each other. And then that's like, we're gonna reevaluate in a year or we haven't defined it exactly yet what to do.
CLAIRE: 00:43:15
And is the focus of the program on mentees predominantly like how to help them or are you also, or is Robert also putting in place anything to help mentors figure out how to be a good mentor? 'Cause I haven't talked extensively with people, but I have had a conversation with at least two or I think it was three Postgres developers. And they were each like, yeah, I haven't done a lot of mentorship. I'm not sure I fully understand like what the expectation is of me. So is that part of the program as well or is?
MELANIE: 00:43:50
Well, we didn't want, I mean, at the beginning we talked about how much of it would be formal and because this is the first time something like this is being done, I think Robert had suggested that we should keep it the informal and not have specific requirements and then kind of go from there and adapt and iterate.
CLAIRE: 00:44:11
That makes sense.
MELANIE: 00:44:13
Yeah, but in the mentor feedback sessions, like in some of them, we have been talking about what are things that you could do? And 'cause I talked to the mentees also, like what are things that mentees wish you would do that you're not doing or what are some strategies you could use to be more effective in helping your mentee? And that's definitely something like we'd want it to be that anyone who wants to can be a mentor. And if they feel like they don't have the skills like that, they could get the support that they need for sure, that's definitely in my mind would be a good goal for the program.
CLAIRE: 00:44:49
Okay, so there could be a whole podcast episode just talking about mentorship and talking about Robert's program and maybe I should--
MELANIE: 00:44:58
Yeah, probably have to have Robert.
CLAIRE: 00:44:59
Yeah, maybe I have to invite Robert to be on the show and then we can talk about it more. So I'm gonna pivot to some of the other things that I wanted to be sure to cover today about becoming a committer. And one of them, like you've already partially answered, like I had a question about what, if you were to articulate or enumerate all the skills that you feel like you have brought to the table that helped you become a Postgres committer, what are they? And you've already talked about empathy, empathy with the other committers and developers, and you've already talked about that asking for feedback, right, seeking that help that you need. Are there other skills that you wanna make sure to shout out to that worked for you, which is not to say that everybody will have the same journey to becoming a Postgres committer?
MELANIE: 00:45:48
Yes, so again, like I'm not sure which of my skills or characteristics were relevant or instrumental but for being selected, but I will say like what people have told me in general that's important is that people can trust your judgment and that if you never commit anything, then the worst that can happen is that it was a no-op, right, like making you a committer. But if you commit things that aren't committable, then you make more work for other committers. Like we have, of course we always want more contributions, but we have a lot of contributions that we don't have the bandwidth to make committable. And so like really, you know, you shouldn't have to be a committer to contribute to Postgres. Like we have lots of people who aren't, right?
CLAIRE: 00:46:43
Oh, wait, I wanna call that out. When you say you shouldn't have to be a committer to contribute to Postgres, like you don't have to be a committer to contribute to Postgres. There are tons
MELANIE: 00:46:53
You shouldn't even have to have it be your goal. Like, you know, you should be able to just say, I wanna, like when I'm a user and I have a feature I want and so I'm gonna write a patch 'cause it's an open source project. And like, you don't, like we want it to be that people can, who don't work full-time on Postgres can contribute. And that, you know, not everyone has to eventually become a committer or, yeah. So like we want a robust contributor ecosystem basically.
CLAIRE: 00:47:24
And there are, there's a long, if we look at like all the people who contributed to Postgres 17, I would hazard a guess that there are many more non-committers who were the primary authors and who were contributors to the release, right?
MELANIE: 00:47:39
There's a ton of non-committers that author patches and features for sure.
CLAIRE: 00:47:46
Okay.
MELANIE: 00:47:47
But I think that's sort of to the point of like, being a committer is about a lot of things, but part of it is like helping that happen and alleviating the bottleneck on getting good work into Postgres and also rejecting work that isn't right, the right fit for the projects and having some idea of like the strategic direction that, and the, you know, sort of architecture and design of the project and what direction we're trying to go in and what kinds of things contribute to that direction and what kinds of things don't, like that sort of the steering and that kind of thing is part of it. But I'd say like, just in terms of what you need to become a committer, like, I think my understanding from talking to people is a lot of it has to do with them trusting your judgment and trusting that, you know, you will probably not make too many messes than the ones you make, you'll be there to help clean them up and that you will help to, you know, widen the funnel of like, and alleviate some of the bottleneck of getting work in and that you'll be conscientious of like, all of the other people that have to work on this project. So you won't commit comments that are half-baked or don't make sense and that you'll think about the whole ecosystem and how does this work when with upgrade and what about extensions? And there's so many things that aren't written down, actually, you know, that you have to think about and that you have to sort of like, like, so far, it seems like more of it is about not messing up than anything else. But like, I think just becoming a committer is the beginning and not the end. Like, I think I used to think it was a reward for doing a good job, but I think actually, it's more like a responsibility that other people think that you might be ready to take on and that you'd be interested in taking on, that you like, want to be in a role of service to the project and that you intend to do that for a long time. And so I think like, taking that seriously and demonstrating good judgment, like taking on risks, like projects that are interesting, not just interesting, that are touch parts of the code base where you have to show judgment, that you understand what's okay and what's not okay, like, or reviewing things and weighing in on issues and demonstrating that you understand what's not acceptable and what is good enough to go in, not just good enough, but like, what will make the code better and not worse and will make the experience of everyone that you work with on this project easier and better and not worse. Like, it seems like it's more about that than it is about designing super cool, awesome, big features because if you do that and, you know, who cares if you make Postgres 20% faster if you make everyone else 50% less productive, like, right? So maybe, and I'm not sure because I haven't been part of picking new committers yet, it seems like understanding that, the weight of that responsibility and the fact that you're not really there to do super cool stuff, you're there to protect and like, you know, sort of, not protect, but like help the project move forward and to be in service of the project and the other people that work on it.
CLAIRE: 00:51:42
Now, I know that the committers work at a variety of different Postgres companies. So for someone familiar with Postgres, we all know this, but not everybody listening to this is, you work for Microsoft. Previously, you worked at Greenplum. Are those the two Postgres companies that you've worked for?
MELANIE: 00:52:04
Yes, those are the two.
CLAIRE: 00:52:06
Okay, and I, you know, I know there are people on this call who work at EDB, maybe some from Amazon or Crunchy Data, right? I mean, people who contribute to Postgres are from many different companies. So I don't know, is there something to talk about here? Like-
MELANIE: 00:52:25
Well, it's really important that we have contributors from different companies so that no single agenda can sort of drive the project. So it's truly a collaborative open source project and isn't one or two companies controlling it.
CLAIRE: 00:52:41
Got it. Yeah, and that's absolutely kind of how it's worked out. Right? There's the, I guess what I'm curious about is since you work at Microsoft, does that influence the kind of problems that you tackle? Like, do you tend to go after more cloud specific problems versus like, I don't know, something, go ahead.
MELANIE: 00:53:10
Oh, I was just gonna say, I think when the system is working well, people, the companies they work at, that you work at, help you get exposed to more user problems and give you like sort of make you more connected to what users are actually going through. But that ultimately the decision about whether or not something goes into Postgres is based on what's good for the project and not your employer.
CLAIRE: 00:53:39
Got it. Okay, that makes sense. There was a question that I was supposed to ask you earlier and I have to know, did you have to apply to become a Postgres committer or were you, actually you kind of, I guess told me this earlier, you were invited and you don't really know what the decision making process was, right?
MELANIE: 00:53:59
That's correct, yeah.
CLAIRE: 00:54:02
Okay, so when you were invited, was your decision to become a committer an immediate yes? Like, was it an email? Was it a phone call? Was it a face-to-face? And, you know, did it take you two seconds to answer or longer?
MELANIE: 00:54:16
No, my answer was no right away, immediately. (laughs) Yeah, but not because I didn't want to, but because I didn't feel ready. I mean, I've only committed like two patches and it was like a one-line bug fix and a test. So I knew that I wouldn't be prolific even if I was a committer. And so I didn't feel like it made sense because I was, I guess I was less worried that I would mess something up because I knew I would be conservative and more that I felt like it would be maybe, not just a waste, but that maybe people would pay less attention to what I was doing 'cause they'll think, "Oh, she knows what she's doing." "I don't need to watch out" "or like review her work or whatever." I was afraid that it would mean that I would get less course correction from other contributors. And so I discussed it. It took a couple of days of thinking and discussing with some different people. Joe Conway initially talked to me about it. And then I talked with Andres Freund who's works at Microsoft and has, for the last few years has mentored me and given me a lot of guidance on being a Postgres developer. And no one really had any good answers and/or was helpful, like no offense to them. But I think ultimately I know that this was what I wanted to do in the end because I love working on Postgres. Every day I wake up and I'm super excited and I would do it if I wasn't being paid. Like I would do it just for fun on the side. So like, it's what I eventually wanted. So I was like, I think it's the right thing to do to say yes, to demonstrate or make it clear that I'm interested, but to still ask for help because I'm definitely need help still. Yeah.
CLAIRE: 00:56:22
Got it. So after, it was just a couple of days between that no and the yes.
MELANIE: 00:56:29
Well, I didn't say no. I was like, I need to, I said, Joe, I really don't think that's a good idea. (both laughing) And then, you know, I said, I'll get back to you. Yeah. And yeah, it's, I mean, it's such, it's obviously an honor that people feel like their judgment is there, but I just want to do a good job and not mess everything up.
CLAIRE: 00:56:57
I actually think it's a good sign that you were thoughtful about it, right? That you weren't like, you didn't go guns blaring and that I'm gonna do this. Yes, I'm ready. I'll do it, right? You were thoughtful, which is exactly the same skill that probably will make you a really good committer. So looking at it from different angles. Okay, so wait, you just said something like you've only made two commits so far. Is that right? Just two?
MELANIE: 00:57:26
And I also got to revert something. So that was like three.
CLAIRE: 00:57:29
Oh, you gotta count the revert. Got it.
MELANIE: 00:57:32
Yeah.
CLAIRE: 00:57:33
Okay.
MELANIE: 00:57:34
Yeah, no, I haven't been very prolific. Part of it is that.
CLAIRE: 00:57:37
Yet, yet.
MELANIE: 00:57:38
Yeah, yet, I had all these plans. Like, I'm gonna review so many patches in the Commitfest and like commit like comment fixes and help people with like small things so that I, you know. And it's just, the problem is that I get fixated on like, I'm working on this project right now and I have, keep thinking that I'm two days away from figuring it out and finishing it. And so then, yeah, I've kind of put it off, put off helping more. I would really like to be more helpful and to commit more of the sort of, or to even just like review things that are early on in their development and need input. And that's, I constantly feel guilty about that for sure.
CLAIRE: 00:58:24
Daniel Gustafsson in the chat just said that getting the commit sweats is nothing unusual. So you're not the, what is that? Many of us who have committed to public facing big projects still double check and triple check, even the smallest commit in fear of messing up.
MELANIE: 00:58:43
Yeah, there's a lot of sweating. I think for the very first thing I committed, Robert actually texted me and was like, if you don't commit the, 'cause he was on the release management team and he was like, if you don't commit this bug fix, I'm gonna just do it. And I was like, okay. It took, 'cause I was going over it and going over it and going over it. And it took like threats to make me actually commit it.
CLAIRE: 00:59:06
I feel like there might be this transition that you're going through. And I don't know if the other new Postgres committer, Richard Guo, who we invited to join this podcast, but due to a bunch of logistical issues, he was not able to join and I'm hoping to get him on the show in the future. But I don't know if he's in that same boat yet, but there's gotta be a transition. I recently joined the board of directors for PGCA in the Postgres community and I'm seeing all the work fly across and I'm feeling like I'm not doing enough, I'm not learning fast enough, I'm trying to absorb information as fast as I can. But there's, I don't know, it's a big responsibility. And I just don't feel ready yet to really dive in the way that some of the other folks are.
MELANIE: 00:59:52
Richard and I, once, we have one-on-ones. We basically, I was like, let's think of ourselves as a cohort. And then whenever we're scared about something, we can ask each other. And that's kind of how we've approached it as like, I don't know how many other people can fully identify with where we're at or remember what it's like anymore to just not really know if you're making the right changes to transition from being a contributor to being a committer. I know that I should probably change more about how I'm working to focus more on other people's work. But yeah, so we kind of like try to support each other through that and figure out what it means and what, if anything, we should change about what we're doing and what our responsibility is to the community and to each other. It's all very anxiety-inducing.
CLAIRE: 01:00:47
I mentioned earlier that I'm giving this talk at PGConf.EU, and it's an analysis of contributions to Postgres made during the PG17 timeframe. Not just to the code though, to other parts of the ecosystem as well, like conferences and such. One of the resources that Daniel and I started with when we started doing the analysis was a blog post by Robert Haas. And he publishes a post, it feels like every year, that just goes into the source base and looks at the commits and looks at, okay, how many people have authored and contributed to this release or in the, I don't remember if it's by release or by year. But he has a section in it, which is about, I should go dig it up so I get the description exactly right, but it's about how many committers committed patches for which they were not the primary author.
MELANIE: 01:01:46
Yeah, yeah.
CLAIRE: 01:01:47
You mentioned that earlier, and I think that's really important. It feels like that's a big part of the responsibility. It's not just you and your teammates for whatever company you work for, but it's also helping the broader community and reviewing their stuff and getting it in.
MELANIE: 01:02:01
Yeah, it's a really hard balance to strike though, because like, so the people that can probably do that quickly and effectively, like sometimes they have, often they have the competing tension of needing to also do the architecturally significant big projects. Like those are hard projects to do as a new contributor. So a lot of times the most senior people are the ones who are doing those projects. And those take a ton of time and focus and energy. So how do you split your time between, you know, adding AIO or parallel query or whatever to Postgres and then reviewing patches from contributors and getting those in. And like, I think at least what I've noticed is that it seems like it's something that senior committers struggle with a lot. And there, you know, some people you'll note, people have seemed to have different strategies, like some do one thing for a while and then transition, or, you know, maybe I'd have to ask them how people typically deal with it. But I think it can be really hard to figure out how you should split your time, because if we never do big, there are things that we as a project need to do, like multi-threading or some other big, significant projects to move forward as a project. But also like, if we don't ever spend time on contributors patches, first of all, we would fall out of touch with users and their real use cases. And then like, we'd kind of be missing the point of being an open source project, right? Like, so I think it's really important to highlight those, you know, committers that are committing work that they are not the primary author of, because there's not that much glory in that, you know? Like, you don't, a lot of times they, you know, if they didn't, like, a lot of times they'll make the decision not to list themselves as an author at all, maybe, or if they do not as a primary author. And so you don't show, maybe you don't even show up in the release notes, but like, I know committers that have spent a lot of time on a patch set and then still not listed themselves as an author because they wanted to encourage the contributor to feel like they, you know, accomplished and like wrote this patch set and get credit for it. And I think that can, it can be hard. It's like, well, if I go tell my employer, hey, I committed this person's patch that you don't have an agenda and getting like, it's not strategically important to wherever, Microsoft or, but it's important for the project that contributors patches go in. Like no one's giving, you're not gonna get your flowers. Like basically that Roberts blog post is the only place where anyone tells you high five for doing that. So it's really important that we have people doing that. And it's not always the most glamorous part.
CLAIRE: 01:05:00
Okay. I just-
MELANIE: 01:05:06
Oh, and I also just wanted to say bug fixes and like that kind of thing, like looking at pgsql-bugs, I see Tom's here. So shout out to him, like responding to all of those emails and like getting back to users and like basically support the support that we do on those mailing lists. Like also like no one is giving, you know, like there's not in the release notes, like Tom responded to 27,000 emails and pgsql-bugs this year, you know, like, and so I think a lot of the things that people do for the community, it's hard to make that decision and they don't always get like visibility for the really important work that they do. That isn't just, hey, I did the headline feature in the last release because like the incentives are all whack.
CLAIRE: 01:05:53
Okay, so we need to talk about this for a minute. And one of the things you just touched on is in this Robert Haas blog post that we'll include a link to in the show notes and that I dropped in the chat. He also has a section listing, here are the people who sent at least 100 emails to pgsql-hackers in 2023. And yeah, if you extended it to the other Postgres mailing lists as well, it might include more people. But Tom Lane was absolutely at the top of the list followed for 2023 by Andres Freund and the list goes from there. But you can see that collaboration, those responses to people, that's important too.
MELANIE: 01:06:34
Yeah, it's really important because you need, they're giving people like feedback on their projects and like advice on what direction to go and like work wouldn't get done if, you know, senior committers didn't spend time doing that and other, you know, all contributors. And there's that aspect of like giving guidance to existing projects. And then there's like responding to bugs and answering questions that other developers have about how do I do this or how questions users have. And so they're like, it may seem weird that one of the metrics or the things that we highlight is how many emails people send, but there is so much meaningful work getting done in those emails, but it really represents like how much are you enabling people in the community to move forward?
CLAIRE: 01:07:26
On the blog post that we're talking about from Robert Haas, there's actually this section about which committers did the most work to commit patches for other people, right? And Tom Lane is also at the top of that list as well. So-
MELANIE: 01:07:42
There's someone who is very prolific. (laughing)
CLAIRE: 01:07:47
Now I will give a shout out for this podcast. The guest for the October episode of Talking Postgres is gonna be Tom Lane. So we're gonna do that live recording on October 9th and it'll get published a couple of days later. And there's a whole bunch of us who are really excited for that conversation too. So-
MELANIE: 01:08:06
I'll be there asking questions.
CLAIRE: 01:08:08
I know you will be. (laughing) And you're opinionated. And one of the things when you join the live recordings, you're obviously very active on the chat and it makes it fun for those of us who are talking. So, all right, I'm switching gears to go back to our conversation points. And I feel like this might be a good time to talk about the committee that I mentioned when I was doing the introduction in the beginning because you've been serving, I'm not sure for how long on the Postgres Contributors Committee, is that right?
MELANIE: 01:08:42
Yeah, I think it was since April or March. It was like the spring of this year, so not too long.
CLAIRE: 01:08:53
And who else is on it? It's you and is it Joe Conway?
MELANIE: 01:08:56
Yeah, and Christoph Berg.
CLAIRE: 01:08:59
Okay, cool. So three of you right now. And talk to me, what's it about?
MELANIE: 01:09:05
So, one of the things about contributing to Postgres is that there, so first of all, like the release notes every year have all the people who contributed code, but there are so many people that contribute non-code. Like the community is about much more than just code. And also like, I think there are people that contribute over many releases. And so the Contributors Committee is really about recognizing, you know, on there's a specific page on the postgresql.org, website that recognizes people who are contributors to the community. And this is code and non-code contributions. And it's actually really, really hard. It's super important because like how, you know, there's no, it's not like at a company where, you know, you get more money, you get a promotion, you get, you know. So like, how do we sort of give people recognition for all that they're doing to make the community run? But also, you know, as the committee, it's difficult because like you may, your bias plays into it. So I may hear more about what a particular person is doing because I know them or I follow them on Twitter or whatever, like they speak at conferences, but then there might be conferences that I don't go to, or I haven't heard about where they're super involved in making the Postgres community work in that region, or for people there, they're running pugs in that area. So a lot of it is trying to pay attention to everything that's happening in the Postgres community as much as possible and correct for your own bias. And then once there's someone that's nominated either by outside or by us, we have to do research and see like, okay, what are all of the ways they've contributed and when were those contributions made and what kinds of contributions were there? And then are there other people who have contributed the same amount as them that are not recognized? So before we recognize someone, we try to make sure that anyone who's at the same level of contribution that hasn't been recognized, that we also recognize them at the same time. When I was not on the committee, the fact that they did that made me like so annoyed because I was like, okay, well, that's so crazy that you can't recognize, like I applied and I listed all my contributions and they're like, okay, well, we need however long to figure out if there are other people who are contributing the same amount. And it felt really frustrating, but I think there's also, it's really difficult, like fairness matters a lot because in the community, like we're a global open source project and a lot of, I think it's really easy to just recognize the people who are in the in crowd and that's like not what we wanna do. So our mandate is sort of to try to be as unbiased as we can and recognizing people that are contributing to Postgres for a sustained amount of time.
CLAIRE: 01:12:12
Well, and I can validate from this research that Daniel and I are doing for this talk, how much work it is to gather the data about the contributions that people are making, the non-code contributions, right? Where there isn't a source base and you can't just query the commits to find out who did what. It's work and it's tedious and it's manual and I haven't found a way to automate it. And so one of the things I'm hoping to do after it's all done is to, I don't know, maybe make some recommendations as to how we could make that process easier.
MELANIE: 01:12:50
Yeah, there's so many places to like, you could be like, how many questions are they answering on Stack Overflow? Are they active in the Postgres Slack? Like, are they, like I said, volunteering for a local pug that we haven't heard about because I'm not always up to date on what's going on in the Nairobi pug or whatever, right? It's hard to know if you're getting a full picture.
CLAIRE: 01:13:14
Yeah, okay, so we've covered a lot of ground on this journey that you've been through on becoming a Postgres committer. Is there anything that I didn't ask that you wish I had? Or that you expected me to? That you want our listeners to know about what it's like to contribute to Postgres?
MELANIE: 01:13:38
I have a list of things and I'm just looking at it right now. I mean, I guess, it's not really a question for you, but on the chat, if there are things that the other committers who are in the live audience feel like I missed that are, I'm very scared about misrepresenting this because I have so little experience as a committer. I'm afraid that I'm vastly misrepresenting the process requirements and selection criteria. So that's something that I would be interested in knowing.
CLAIRE: 01:14:12
Well, and just to clarify, like you're this, the invitation to you was to tell your story, right? What your experience has been. And for anybody who's listening, like everything I've learned tells me that the different Postgres contributors and committers, each have had very different journeys. I mean, in the last episode, we had David Rowley on the show and he talked about how working in a cheese factory is what ultimately led him to Postgres, right?
MELANIE: 01:14:40
Yeah, that story was amazing.
CLAIRE: 01:14:42
Yeah, wait, so is cheese in your background too, by the way?
MELANIE: 01:14:46
Yeah, well, when I did the IT consulting, one of our clients was a, cheese company. And that was like some of the first sort of database schemas that I saw were for, they tracked like their high-end cheese makers. So they were very aware of their entire supply chain down to like the veterinary exams of their cows and everything. And so they had all of their database schema for like all these different things had so many cows and cheese in it. And I was just like, felt like giggling in every single meeting because it was just like kind of surreal thinking about every, all businesses have tech, right? Like underlying it. And they did also dealt in like milk futures. And so there was like a whole, sort of database for all the analytical information they needed for that. And it just kind of is crazy if you think about it, like every business needs to store their data in a reasonable way so they can query it. It's crazy.
CLAIRE: 01:15:54
Yeah, it is crazy. I think Andrew Atkinson also chimed in on Twitter saying he had cheese in his background as well.
MELANIE: 01:16:01
Yes, the Provolone to Postgres pipeline. So what he called it, I think.
CLAIRE: 01:16:05
Oh my goodness. Okay, but the point is, I got a little distracted by the whole cheese thing is that there's no single path. There are lots of paths in. So for anyone who's listening and wondering is being a Postgres contributor in their future, you don't have to have cheese in your background. You don't have to quit your job and be unemployed for a year and a half. You don't have to work at Greenplum first. Like there are different journeys. And that's why I invited you here, not to talk about the general process, but to talk about what your process was. So I don't think you could have misrepresented things by that measure.
MELANIE: 01:16:44
I think the only thing that I guess we didn't talk about that I maybe wanted to say was that it wasn't, there were many times where I wanted to quit, like trying to contribute to Postgres because like you can spend a lot of time feeling invisible because especially if you contribute full-time, so there's no one at your job who's really paying attention to what you're working on. And if none of the work that you do in the community goes anywhere, and then you don't do other work, you can feel like basically what's the point of working? Because like you never produce output that actually isn't software that anyone uses. And you never come up with ideas that are good enough for anyone to even listen to, let alone like commit them. And I've talked to a lot of other new contributors that feel that way. And I've talked to many that have decided not, they wanted to work elsewhere and not continue to work on Postgres because they started out with this idea that Postgres is so great. It has such high standards. Like there's so many smart people there. And really like part of the reason I've stuck around is 'cause there's so many good people. People who are really nice and have just like want to do the right thing kind of. And like, that's all true, but it's also true that you have, I guess, like just liking it is definitely, just like loving what you do, it's really important. But you also have to kind of either be okay with having 99% of what you do go nowhere or like sort of believe that eventually that will be different. And I guess what I'm saying is, if you're in that position where you feel like you're not getting traction, that it's possible for that to change or it's possible for you to learn to live with it and to find other ways to feel validated and seen and to still, to move forward in the community. And I guess it's a message of hope and hopefully other people can know that they're not alone. And I hope that we find a way to lose less people to that, I guess, yeah.
CLAIRE: 01:19:25
Well, and I think that's why you shared some of the things that you shared in this discussion today, right? That's why this new mentorship program has been created, right, with Robert Haas taking the lead, but you're one of the contributors to it. At PGConf.dev this year, I know that there were some half day sessions that were really useful for people who wanna commit patches or want to contribute patches. There was an intro to hacking on Postgres session. There was a patch review workshop as well. And I know that you as one of the conference organizers were involved in saying, "Hey, we wanna do more of that to help people who are becoming contributors or get through this process with more hope, with more effectiveness."
MELANIE: 01:20:11
Yeah, I want people to hear like, "Hey, we want you here." If you're like nice and try hard and wanna be here, like we wanna help you, we want you here. Maybe every email you write won't get a reply, but like there are people who try to help you and that you're wanted basically.
CLAIRE: 01:20:35
That seems like a perfect note on which to end today's discussion. Melanie, I wanna thank you for spending the time, coming today, also coming to the soundcheck beforehand and sharing your story with us. And for all the times you've attended the live recordings of the podcast as well, chiming in with your opinions because you often have good questions and lots of good opinions as well.
MELANIE: 01:21:03
Thanks Claire.
CLAIRE: 01:21:05
The next episode of Talking Postgres will be episode 20 that will be recorded live on Wednesday, October 9th at 10 a.m. PDT. I think it's still gonna be PDT then. And the guest, as I mentioned earlier, will be Tom Lane. And the topic will be How I got started as a developer (& in Postgres). So if you wanna mark your calendar now to save that time so you can attend the live recording, just go to the link aka.ms/talkingpostgres-ep20-cal. And you can get to past episodes and get links to subscribe to this podcast on all the different podcast platforms at talkingpostgres.com. Transcripts are included on the transistor pages for these episodes as well. And if you've enjoyed the podcast, please tell your friends and your teammates and the other database people you know, whether that's in person or on social media, however you share recommendations to your friends and followers. The hashtag is #talkingpostgres, all one word. And word of mouth is really one of the best ways to help people discover this show. Big thank you to everybody who joined live as well. All the great comments on the Discord today were super helpful to me and hopefully to you also, Melanie. Although, are you gonna go reply now or were you paying attention during the show?
MELANIE: 01:22:30
No, I'm gonna go look now.
CLAIRE: 01:22:32
Okay, great, I will too. Again, thank you. It's a wrap!
