[CLAIRE] Welcome to Talking Postgres. In this podcast, we explore the human side of
Postgres, databases, and open source, which means we want to dig into why people who
work with Postgres do what they do and how did they get there. Thank you to the
team at Microsoft for sponsoring this conversation about Postgres and I am
your host, Claire Giordano. It is my privilege to introduce Robert Haas.
Robert has worked with Postgres for more than 25 years, first as an application
developer running on Postgres. In 2008, he became a patch reviewer and in 2009,
he became a Postgres committer. Later became a major contributor and he has
made contributions to incremental backup. Parallel query might be the biggest
thing he's done. Also index-only scans and unlocked tables. He's based on the
East Coast of the United States and works as a chief architect and VP of
database servers at Enterprise DB. Welcome, Robert.
[ROBERT] So happy to be here.
[CLAIRE] Today we're going to be talking about mentorship and why mentor Postgres
developers. The reason is that last June, so what is that, seven months ago
now, you kicked off a new mentoring program for Postgres code contributors.
I guess let's just start with why. Why do you care about mentoring? Why are
we talking about it?
[ROBERT] Well, I think there's a couple of ways to answer that
question. I think on a personal level, one of the things that I really enjoy in all
aspects of my life is seeing people succeed, seeing people go out and
start out having trouble doing something and then after a period of time, you know,
becoming good at it. I think that's a lot of fun and when I have the opportunity
to mentor people, you sort of get to participate in that journey a little bit.
People's accomplishments are always their own. If you're mentoring somebody
and they go out and do great things, contribute wonderful features to
PostgreSQL or become a committer themselves or whatever it is that they
do, that's their accomplishment, a hundred percent. But I enjoy being with people on
that journey and I think that's one of the reasons why this is sort of
personally important to me. From the viewpoint of the PostgreSQL community,
it's obviously very important as well because nobody works on an open source
project forever. Some of us will move on at some point to other open source or
closed source communities or other kinds of jobs altogether and even if we don't
do that, eventually we're gonna all get old and stop working on Postgres for
some reason or another and I think we're all hoping that there will be more
people coming along after us who want to pick up the torch and continue to make
PostgreSQL amazing. But I think also we'd like to not just sustain the
community but to really see it grow. We'd like PostgreSQL to have more developers
in the future than it does today and to have a greater pace of development than
it does today. And I think that mentoring is a way that we can maybe try to help
that happen at least a little.
[CLAIRE] I think it's important that the Postgres
community grow and change and evolve and so I think anybody listening would
probably agree with those goals. It makes sense.
[ROBERT] And just to be clear, there's a
big difference between the PostgreSQL community growing, which I think it
definitely is, and the developer community specifically growing. And I'm
thinking here specifically of the developer community for PostgreSQL
itself. So there's lots of ecosystem projects out there that hopefully are
growing as well in terms of the number of those projects and the number of
people working on them. I don't actually know what the numbers are around that or
what is happening there exactly. I do statistics on development on PostgreSQL
hackers specifically. I've been doing those blog posts annually for a number
of years now and from that I know that the development velocity of PostgreSQL
itself has increased a little bit but nowhere near as quickly as other things
about PostgreSQL have probably increased. I think the increase in the
number of people who are using PostgreSQL, advocating for PostgreSQL,
organizing PostgreSQL events, and doing all of the other cool things that people
do with PostgreSQL has probably increased at a much faster rate over the
years that I've been involved in the project than development specifically. So
I want to be clear that I'm not trying to devalue all of those other forms of
contribution. They are important and I think they're hard, right? But this
is the area of contribution that I have the most familiarity with and I see that
I think we're struggling a little bit with scaling in this area and I'm
hopeful that mentoring can be something that helps to move the needle there at
least a little bit. I guess, you know, we'll see the degree to which we're able
to make a difference but we're almost flat. We're just a little bit better than
flat in terms of the number of people who are contributing code specifically
to PostgreSQL itself over the years and I think we'd like to do better.
[CLAIRE] So how did this new mentoring program start? I mean, I think it started in
Vancouver last May at PGConf.dev but maybe it was born of conversations and
inspiration that came before that point?
[ROBERT] Yeah, definitely. I mean, I've been at EDB
for a long time now. I started at EDB in 2010, April of 2010, so I'm not quite to
15 years yet but I'm getting close and during that time I've been really lucky
to be able to mentor quite a number of people within EDB and a few outside EDB
as well. And that's been a good experience. I've really
sincerely enjoyed working with those people and saying, "Hey, maybe, you know,
this patch would go better if you presented it to the community this way," or
"Maybe you need to think a little harder about that thing." Those, I think, were
sort of foundational experiences that pushed me in this direction. But the more
imminent thing that pushed me in this direction was Melanie sending me an
email, Melanie Plageman sending me an email, and basically saying, "Hey, you know,
would you be willing to meet with me once a month and give me some mentoring?"
And of course I said, "Sure, I'd love to." And I think it's really great but also
really difficult that she was willing to send that email. You know, writing an
email to someone on the internet that you don't know and who you might view as,
you know, very senior to you or very busy or somebody that for whatever reason
you're not supposed to reach out to or whatever, that's hard to do. And I guess
it's also kind of hard to do well. And so I think that really started to get me
thinking. So Melanie knew what she wanted and she figured out how to get
it. But how many other people are there out there who either don't quite know
what it is that they're looking for or who maybe aren't quite so assertive in
reaching out to try to get it? And that really made me start thinking about, you
know, it would be great if we had a program for this so that, you know,
committers and maybe eventually other people who have been around for a while
and have some expertise to share could have a way to volunteer to do that. And
people who are interested in being mentees and receiving some of that
accumulated wisdom or, you know, what we hope is wisdom would feel comfortable
asking for it without it seeming like something that was an exceptional case.
So yeah, I think that was the genesis of it.
[CLAIRE] And so I think this kicked off in June of last year, so a month afterwards. So
you left the conference, you wrote a blog post with all your kind of
learnings and perspectives about how to grow the community, if I remember
correctly, and then a month later this new program came into existence. So I
have a ton of questions for you, but for somebody listening who doesn't know what
"this new program is," can you give us a quick summary and then we
can we can dive in more?
[ROBERT] Yeah, absolutely. So there's kind of three things that I'm
trying to do right now. And the first one is that we have a
relatively small number of people who are in one-on-one mentoring
relationships with particular committers. That's something that I've found to be
very helpful for people in the past, and I wanted to try to provide a
vehicle for people to get matched up. So we did a round of matching after PGConf.dev
last year, and we can talk about that, and we're planning to do a reorganization
soon to maybe change some of those matches or add some new ones or whatever
it is that we can do. So that one-on-one mentoring is the first component of it,
which I initially thought would be mostly for people who are already pretty
well-established and looking to kind of take it to the next level. Then the
second component of it, is I've been organizing monthly what I call "hacking
workshops", where the audience is a little bigger, people could just sign up, we all
watch a talk in advance, and then we get together, talk about it, answer questions.
And then the third component is we have a Discord server for the program as
well, which anybody can join and hop in and ask questions, and you know, you might
get a response from Tom Lane or from me or something like that, which, you know,
hopefully people find that cool.
[CLAIRE] Hopefully we can include a link to that
Discord server in the show notes afterwards for anybody who's interested
in joining or starting to lurk in the background, maybe become part of the next
cohort or something like that. So how many people were in the first cohort in
terms of mentees, in terms of people who wanted to be mentored? Are we talking
like a hundred or ten?
[ROBERT] It was more than ten, it was less than a hundred. I was, I'm
actually wondering if you might have that statistic on hand, because I think
you included it in your talk, as I remember, but I don't remember the
precise number offhand. I want to say it was in the teens?
[CLAIRE] Okay, I did include it
in my talk and I will dig that up. So I think it was in the teens. Okay, and each of
those people that's being mentored was mapped to an existing major
contributor or committer, is that right? So we have an equal number of mentors.
It's not many to one or one to many, is that correct? One to one?
[ROBERT] So we do have some mentors who are mentoring more than one person. I think
each committer is mentoring either one or two people, or maybe the
committers are mentoring zero people, but everyone who's involved in the program
is mentoring either one or two.
[CLAIRE] Okay.
What was the feedback like so far?
[ROBERT] I think the feedback is pretty good. I
think it's a little bit variable, right? So you have some people who expressed
interest into the program and were accepted into the program and they were
just like exactly perfect for this particular effort. They were at the phase
of participating on hackers where they had a pretty good idea, you know, A) that
they wanted to be there, that they really wanted this to be a big part of their
career and what they did going forward. B) you know, how things worked there, how
to take things forward. But they had questions. They had questions about
projects, they had questions about procedures, they had questions about
people. And I think the people who were in that category have probably had the
best experience and have also given their mentors the best experiences, as
far as I'm able to tell. I mean, I don't want to speak for the experience of
everyone, but that's my impression. We did also accept some people to the
program who were, you know, more aspiring hackers. They mostly had some presence on
the list. They were people who were around a little bit, but they maybe had
not already sort of taken that plunge off the deep end and, you know, decide,
"Hey, no, this is what I want to do for my career or this section of my career."
And I think those people have probably benefited a little bit less from the
program, because you have to remember that this is new to the mentors, too. The
people who are doing the mentoring are not necessarily people who have ever
been asked to mentor before in their career or really have a clear idea of
how to do it, and they basically just volunteered. They said, "I can make myself
as available as a resource to talk to somebody and to try to answer their
questions." And so the pitfall you can fall into there is if you get on the
phone with somebody and like, "Well, I don't have any questions," then what do you do
exactly, right? I think there are probably good answers to that question or at
least better and worse answers to that question, but it's a little harder,
I think, because people don't, you know, as I say, they're not necessarily trained.
I'm certainly not trained as a professional mentor, and so when somebody
shows up and says, "Hey, I want to know this, this, this, this," you're like, "Oh, this is
great. I can answer those questions. I've been around." But when somebody shows up
and what they want is a little bit less well-defined, then I think it's a little
bit more difficult for the relationships to be rewarding and the results are a
little bit more variable.
[CLAIRE] I think one of the things that's challenging for an open-source project
like Postgres is that unlike with, you know, proprietary software that's being
developed by a company where there are professional managers, some of whom are
really great and some of whom might not be, you know, there are managers, good and
bad and in between, whose job it is to think about, "Is this person getting the
right kind of mentorship?" They don't all do that really well, but there are,
there is work that's happening to make sure that when there's a new hire, when
there's a junior engineer, that they're paired with people who can guide them,
who can kind of give them tips, pointers, suggestions, feedback, all that kind of
stuff. And I think open-source projects don't have that. There is no management
structure per se. There is a lot of structure, actually, within Postgres.
There are committees, there is the core team, there are committers, right? There
is a way of doing things and all sorts of development processes, but I do think
that with this program you're filling a gap that was there. It was perhaps too
informal and not accessible by everybody, right? Not everybody is...
[ROBERT] I don't think we've completely solved the problem, but I think you've diagnosed the
problem really well, you know, and one thing I would add is that not only is
PostgreSQL an open-source project, but it's an independent open-source
project that is not controlled and has never been controlled by any one
particular company. So even in some open-source products, you know, that
company might take certain level of leadership in determining, say, the
direction of the project or who they want to be more and less involved in the
project from among the pool of people who are available, and we really don't
have that. So we have a bunch of people whose core skill set is highly technical,
they're good at using GDB and using the shell and writing C code and other kinds
of not very people-oriented skills, and then, you know, suddenly they're
trying to figure out how to work with all of these other people, and as you say,
nobody really knows who's in charge or who should do what or what direction the
whole thing should be going or anything like that. So I think it's even more
challenging for Postgres than it is for some other projects.
[CLAIRE] In the chat, one of the things Melanie is saying that the majority of committers
she's talked to have never themselves been mentored, and so what that means is
that people who are in these leadership positions or, you know, have all the
knowledge with which maybe they could mentor, you know, they haven't had role
models themselves. And so that makes it tough to figure out, well, what's the
right recipe to mentor, because they never really were on the receiving end,
right, to feel what worked and what didn't, to build those skills.
[ROBERT] Absolutely true, yeah, 100%.
[CLAIRE] So I'm guessing that's maybe one of the challenges in front of you, and I think
both Melanie Plageman and Andreas Scherbaum have been
supporting you in this project, and I'm not quite sure in what roles, and maybe
you can explain that, but, you know, how are you gonna help the people who are
mentoring build that muscle?
[ROBERT] Yeah, that's a question to which I don't yet know the answer.
[Okay.]
I would actually love to hear from your audience or really anyone who has some
good insight on that to offer, because I'm convinced that this is an area with
a lot of potential. But there's a difference between something having a
lot of potential and actually being in a position to take advantage of the
potential that's there, right? I think everyone who has tried to become involved
on the mailing list, regardless of how well that went for them, knows that it's
hard. There's a lot of email, there's a lot of people, there's a lot of
personalities, there's an enormous amount of technical information that you have
to absorb, but even if you absorb every bit of technical information perfectly,
you're far from done because of all of these human factors that also exist.
And I am pretty firmly convinced that we could do a lot to expand the
development community, to make the people that we have more successful, to reduce
burnout, to do all kinds of good things, if we could improve some of the human
parts of these relationships, how people work with each other, how people learn
from each other, which can encompass mentoring for new people, but also the
long-established people work with each other. But I think it's really, really
difficult to figure out how to do that because we've just done so little of it.
A lot of the things that the PostgreSQL project does well are things that the
project has done over and over again, and so the people who have done them many
times are very good at them, and the next people who come along look at what the
existing people do and they copy it. And that is the real recipe for success.
It sounds a little silly, but one of the great ways to avoid making obvious
mistakes is to look at what somebody did before you that worked out well and to
do the same thing that they did. But with this mentoring stuff, we don't have any
track record. It's not something that the project has historically done very much
of, and what has been done has been done privately within companies, for example,
or off-list in other kinds of ways. And so I think we're just at the beginning
of a long learning process where we have to kind of try to experiment and figure
out what works and what doesn't, and then as we understand that better, we can
figure out which of the things that we want to double down on and which of the
things that, you know, maybe are not quite going to work out.
[CLAIRE] Well, and I think the thing about people is that they're all different. So what I
mean by that is the way that you would mentor me would be different than the
way you would mentor David would be different than the way you would mentor
Melanie. I'm just making up names here. You know what I mean? We each have
different strengths and weaknesses and experiences that we bring to the table.
And so even as a mentor, you kind of have to be adaptive to the situation, to
the person, to their needs. And even that person today is different than that
person in 12 months. So I just think...
[ROBERT] This is... sorry for jumping in there, but that's actually something that I have
really struggled with a lot, in my own mentoring, the fact that people are
different. Because my mental model, which is very naive, and you'll hear just how
naive it is as soon as I say it, is often that, you know, "everyone is just like me,
but some people are worse at it than I am." And that's so obviously ridiculous and
wrong and insulting and tons of other things. But my brain sort of tends
to default to that mode that everyone kind of is working with the same...
Everyone who's working on Postgres is kind of working with the same skill set
that I am, except some of them are better and some of them are worse at it.
And one of the things that I've really learned in my time managing people and
mentoring people and stuff like that is how wrong that really is. But even though
I keep learning that over and over again, it's hard not to fall back into the
pattern, because of course you know yourself better than anyone else. If
you're trying to explain something to another person, it's very natural to
think about, "Well, how did I first understand this? How did I first make
sense of this concept?" And then you relate that to them in language that
made sense to you. And sometimes that's just not the right approach at all.
Sometimes you're even not talking about the right subject, or sometimes you're
not explaining it in a way that will make sense to that person. So yeah, it's
really challenging.
[CLAIRE] So have you had a chance yet to try to do research into
some of the other open-source communities and how they've tried to
attack this problem? Or is that something on the list of things to do as you
evolve these? I mean, I know it's an experiment, right? And it's a process and
a journey. But I'm curious if...
[ROBERT] Yeah, I haven't done that. I wouldn't even
necessarily say that that's on my list, because honestly, just keeping up with
everything that's going on right now is a pretty significant time investment to
me. And I just do not have time to go and start learning how other open-source
communities do this kind of stuff. But I would love for that information to
somehow be transmitted in the other direction, either by people in the
PostgreSQL community who already know, or maybe people who do have some
bandwidth available to do some research. Because I think it's really important,
but I don't think it's a project I can undertake myself.
[CLAIRE] Well, anybody who's
listening to this podcast, if you have suggestions or ideas or projects where
you think there's a mentorship program that is working really well, obviously
folks can reach out to you through the Discord, or reach out to me through the
Talking... this Discord, the one where we host Talking Postgres. So I know that
Melanie just commented that she has talked to the Linux Foundation and Hive
and other open-source projects, and so far she hasn't found a program that is
sufficient for the needs of the Postgres community. So we can perhaps delve
into that, but let's go into the wayback machine for a second. We talked
about role models earlier, right? Obviously anybody's perspective on
mentoring is probably influenced by their own experiences, particularly maybe
when they were early in their career or junior or their first kind of mentoring
experience. I'm curious if you have a favorite mentor in your past, and if you
can tell us what that was like and why that was a good experience for you.
Obviously you're different. Everyone is not the same as you.
[ROBERT] Yeah. Yeah, I mean, I think one of the things that I've had a few people who
have done for me is just understand where I was at and what I was good at
and what I was not good at, and instead of pressing on the stuff that I wasn't
good at, they just sort of provided gentle encouragement and then an
occasional suggestion that, "Hey, maybe you could think about being better about
this thing," or whatever. I remember, you know, as regards programming, when I was
very small, I don't even know how old I was, I saw my Dad and he was working on
some program in Fortran, and I asked him a question about it, and basically the
question had to do with how variables work in subroutines. And he just
explained it to me, right? He didn't say it was a dumb question or that I
didn't need to know the answer or whatever. He just told me
how it worked, and I got it. I was like, "Oh, I get it. Every time you enter a
subroutine, all of those variables kind of get a new copy, a new instance of
themselves," which is a concept that everybody who is a programmer sort of
probably intuitively understands at this point, but if you haven't programmed
before, it's not obvious at all that it's not the same copy of the variable when
you re-enter the same function. I remember in high school, I worked for a
guy named Dave, who was very much the same, who would just kind of
give me a lot of praise for whatever I accomplished, and then every once in a
while give me a hint for how I could handle certain situations better or how
I could overcome some obstacle. And later than that, I worked for Margo Seltzer, who
gave the keynote at last year's PGConf.dev in Vancouver, and she was much the same.
She would always tell me how great it was that I had accomplished all of
these things that I'd gotten done, and then maybe once in a while a little
suggestion would creep in. And I think all of those people understood the style
of mentoring that worked for me. They understood that I was a little full of
myself, and they didn't press that point and try to cut me down to size.
They just found a way to be encouraging and help me improve
without making me feel bad about anything that I was already doing.
[CLAIRE] Well, I think in each of those stories, you mentioned the encouragement, the
praise, the positives, the steering you toward doing more of what you were good
at versus focusing on fixing your gaps or your weaknesses. And obviously
not everybody needs that, but it clearly as a recipe worked for you. And by the
way, that would work for me as well. If someone is just critical, critical,
critical, critical of all the things I'm doing wrong, I would just be so
discouraged. I'd want to just go hide in a cave or under a table. I
wouldn't hide under a cave. I would probably just get a good night's
sleep and come back at it and keep fighting. But I do think there is
something to balancing the positives with the negatives.
[ROBERT] Absolutely. But I've also worked with a number of people over the years who
really valued a list of what needed to be different. Not about them,
but say about a patch. Somebody's working on a patch and if
you give them a comprehensive list of 17 things that you want changed or fixed,
they're like, "This is amazing. I have exactly what I need. I'm going to go
through all of these 17 lists and I'm not maybe even interested in exercising
my own judgment about any of those questions. I just want you to tell me
what I need to do." And they're happy when they know what it is that you want
them to do. So whereas I tend, and it sounds like you probably also tend, to
push back on that a little bit and to be like, "I know what I'm doing. I don't
want to be given super specific instructions. Give me some creative
freedom here." But people are in all different places with regard to those
kinds of things. And some people like much more specific, much more
direct feedback about like, "This is exactly how it needs to be," or "This is
exactly how you should do this task in order to be most successful." And they're
like, "I got my marching orders. I understand what I need to do now." Other
people don't like that at all. So feeling your way through that's
definitely, I think, part of the process of establishing a good relationship with
somebody.
[CLAIRE] Well, and maybe part of that is the difference between people
management and project management. Or how do I mean? If I was working on
writing a blog post, I would really value the 17 things that are confusing,
ambiguous, missing, wrong, broken, right? So that I can go fix them, right? Just get
those things fixed. So kind of like a patch. But if I was looking for feedback
as to how I could be a more effective leader, how I could be a more effective
communicator, then that's, I don't know, I don't think that lends itself
as well to, "Okay, here's the 17 things you need to go fix." Maybe it does. Maybe I do
have exactly 17 things.
[ROBERT] I think that's true but I think another part of it is definitely cultural.
I've noticed that working with people from different parts of the world is very different. I have a lot of
colleagues in India. I've noticed certain ways of working together are different. Like on average,
individual people are all over the spectrum, but it does, I think, make a
difference to the average. People from Japan, we have a lot of very important
PostgreSQL contributors from Japan. You know, they have a different way of
communicating, a different way of thinking about things, and it's not just
a language difference that, "Oh, we speak English and they speak Japanese." No, it
goes beyond that. People actually sort of think about different things in different
ways. Even when the words were understood with the correct meaning, it doesn't mean
that the interpretation of that meaning is the same or that people relate to each other
in the same kinds of ways or consider the same kinds of interactions to be positive
or negative or constructive or not constructive or whatever. I think you saw that in the session
that we did last year at PGConf.dev, where communication styles really came up
quite a bit in the discussion of building a more inclusive community. And the slightly
diverse group of people that we had as panelists for that all had somewhat different views
on what a good communication looked like or how things should be phrased. So, yeah, some
of it is personal, some of it is cultural. It's a very complicated set of things.
[CLAIRE] I think I'm going to dig up the YouTube link to that panel discussion, because it was
recorded at PGConf.dev last year. And it was called "Making Postgres Hacking More Inclusive,"
and it was you and Melanie Plageman, and I think it was Amit, right?
[ROBERT] Amit Langote and Masahiko Sawada.
[CLAIRE] Okay, great. Yeah, and it was really interesting because you had four very different people,
very different communication styles. The four of you live in three different countries,
right? And you had a couple different languages in terms of like your first languages,
your native languages. And so, yeah, I was fascinated by it. And it is online. I found
the link, so I will get it shared out there.
[ROBERT] Excellent.
[CLAIRE] Okay, so when you first started mentoring people, when did that happen? Are there any
stories you have to share from those experiences? Was it hard? Was it easy? Did it come naturally,
like a duck to water?
[ROBERT] I think it really started after I joined EDB. I had a few jobs prior to EDB where
I was somebody's manager, but it was usually the case in those instances that they were
doing something that was pretty different from what I was doing. So it was a different
kind of relationship. Whereas at EDB, I managed a bunch of people who were doing work that was
stuff that I was well-qualified to do myself. And I would say on the whole, it went pretty
smoothly. I mean, I guess maybe it didn't go smoothly for everybody. Certainly, there
were people who left EDB and maybe that was because they got a better opportunity elsewhere,
or maybe it was because they didn't click with having me as their manager or a combination
of things. I don't know. But I do feel like on the whole, it went pretty well. I feel
like I developed a lot of good relationships with people at EDB that were people that I
really enjoyed working with and still do enjoy working with. I feel like I made some of my
best work friends through those conversations. And a lot of those are people I still keep
in touch with from time to time.
[CLAIRE] When you were first starting out in your career, did you have it in your mind that you wanted
to work on Postgres?
[ROBERT] No, not at all. I went to college with not a real clear idea of what I wanted to do with
myself. And of course, the first question that everybody asks you is, "Well, what field
are you going to go into? What's going to be your major or whatever?" And I just kind
of started saying computer science because I'd been doing computer stuff for a long time
and I didn't really have another good answer to that question. And well, once I said that,
I ended up taking computer science classes. And then I eventually graduated and I had
to find something to do with myself. And I ended up getting a job at a small startup
company that needed some web application stuff built, which I did. And then I had a series
of jobs, as I think I may have mentioned to you earlier, that were basically that, just
building small web applications for different kinds of people. And the thing that got me
interested in working on Postgres was I had this one particular job where I was building
an internal-facing web application. And over time, it got more and more and more complicated
and it had more things that it did and more features that went in there. And eventually,
after it got to a certain point, I started running up against the limitations of PostgreSQL
itself. In particular, the fact that PostgreSQL couldn't do any form of join removal at that
time was making some of my queries annoyingly slow. I was like, "Huh, I wonder how hard
it would be to fix that?" So that's how I ended up reading the mailing list and eventually
getting involved.
[CLAIRE] So you just went to the mailing list and started, what, asking questions or contributing ideas?
Or do you remember your first patch?
[ROBERT] Ah, I almost remember my first patch. Well, I think I do remember my first patch. So I
started reading the mailing list and one of the first conclusions that I remember coming
to is that this Tom Lane guy seemed really smart. I thought he had a lot of good things
to say. I mean, sometimes they were abrasive things, but you could just tell, I could just
tell that this was a really, really smart human being. And a lot of people on the mailing
list were really smart. And I just love that. I love the intellectual engagement of being
able to discuss ideas about an interesting topic with a bunch of other people who were
really interested in that topic and had really clever things to say about it.
And the first thing that I did is write a lot of email, like a lot of email. And then
the second thing that I did is I started getting involved in doing patch reviews. And the question
I tried to ask myself as I started reviewing actually really a lot of patches, I was very
prolific as a reviewer back in those days, I kept asking myself, you know, "what is Tom
going to say about this patch?" And could I say the thing that Tom is going to say before
Tom says it, so that by the time Tom sees the patch, some of these things have
been improved and maybe the patch will get committed whereas otherwise it would have
run into trouble. And that was kind of my approach. I don't really know how successful
I was at it. I think I didn't know how little I knew at that point. You know, I mean, I
fancied myself a good programmer, but I didn't really know anything about Postgres internals.
And I think if you went back and looked at some of my posts from that era, you'd be like,
wow, I really didn't know very much back then and still had a lot of bold opinions,
which would be absolutely true. But yeah, that's how I started getting involved. And
then eventually I started writing a few patches of my own. I'm not 100% sure, but I think the
first one was adding a grantable privilege for truncate. So you could say grant truncate on
table whatever to whoever. And I found that project on the todo list. And the todo
list is, in general, not a great source of project ideas, but I happened to find that project on
todo list. And I was like, you know, I think I could probably figure out how to do this. I didn't
really care about it for its own sake, but it just sounded doable. And I went through and I
grepped for all the places in the source code where we were doing something with acl delete,
which I figured out was the symbolic constant that controlled the grantable delete privilege.
And I just modified them all so that they did something similar with truncate with appropriate
modifications. And then I tested it and submitted patch and it got committed. And then I was
off and going on my PostgreSQL hacking journey.
[CLAIRE] Do you feel like the going through a lot of patch
reviews first before making a first contribution? Is that like a typical pattern for a lot of
contributors? Or are there lots of different paths? Like do some people come in with their
first proposed contribution before even doing a patch review?
[ROBERT] I think some people definitely do.
I think that for me, the experience was really helpful because, you know, I
didn't really know what I was doing with respect to PostgreSQL specifically. And I knew that.
Like I knew how to program in C, but I could tell just looking at the PostgreSQL source code a
little bit that there were all sorts of things to know about this code base specifically that I
didn't know. And I also knew that I had no experience contributing to PostgreSQL or any
other open source project. And I didn't really have a good idea of how that worked. And so
reviewing patches for me was a really helpful way of getting my feet wet because it
allowed me to look at a lot of different areas of the source code and start to become familiar
with things. And of course, you're not going to remember everything you see the first time you see
it or even the tenth time that you see it. But I think it really helped me to get my head around
the culture of the community, or to start to get my head around the culture of the community,
as well as how the source code worked to be able to compile the source code and run the regression
tests and do all of those things. And some other people come in and they propose a patch straight
off. And I think for some people that works fine. I would guess that for people for whom that works
fine, they probably have a little bit more grounding in working on open source projects
than I did when I started out, or they're just better at this kind of thing than I was.
I do think there are people who try to get too ambitious straight off and they go straight to
proposing a patch, maybe a patch for some quite large feature, and they don't really understand
how many things they don't know. And I know I did not fully understand all of the things that I
didn't know, but I did realize it to some extent. And I think I'm really glad that I started with
reviewing because I think it really put me in a good position to be able to do a lot of things
later.
[CLAIRE] I mean, I guess when I think about other spaces, right, to look for analogies or to look
for things that are common in like the human condition, like to be a good writer, most good
writers also read for hours and hours every day, right? So, and they've consumed a lot of other
writings created by other people. In sports, every athlete has also watched other athletes, right?
Attended a lot of games, watched game tape, studied their own, you know, videos of their own
performance. Like there is a lot of observation and dissecting like what's working and what's not
and learning from other people, like standing on the shoulders of giants or whatever. And I think
that's true in Postgres. Like it's got to be. One of the things Melanie told me once is that
as she was learning Postgres, like she would listen to other conference presenters,
both to learn about whatever the thing, the technical thing often they were trying to teach
in those conference talks, as she would be out for a run and listening to, you know,
some downloaded YouTube conference talk on, you know, in her earphones. But
you're also learning about how to give a good conference talk at the same time.
[ROBERT] Yeah, 100%. I mean, I think one of the things that's hard is that when you participate in
hacking on Postgres or anything else, right, could be participating in the Postgres community
in some other way, could be participating in some other kind of community. You probably think there
is a problem or at least something that could be better. And so you want to bring your own
knowledge, your own ideas, your own viewpoint to bear on whatever it is that you're doing.
And that's absolutely true. That's a right thing for people to want. But at the same time,
you also want to sort of acknowledge and understand that, you know, there's a lot of
wisdom that's already embedded in that community, and that's why it exists and how it managed to
get as far as it did before you came along. And so finding the right balance between those things,
the right balance between sort of flexing or accepting the way that the community is,
even if it's not what you personally would like or what you personally would prefer,
and promoting your own good ideas and trying to change things and make it more into the way
that you think it should be, that's a really difficult balance to get right. And I think
probably everybody who participates in the PostgreSQL community is at some level
familiar with the delicate balance there.
[CLAIRE] The mailing list, I think the word that
Melanie used to describe it is there's a particular groove to the communication style
that exists on the mailing list. And so, yeah, people have to learn what that is, I guess,
and understand it and pick up on those techniques and those ways of, I don't know, it is different.
[ROBERT] Yeah, I mean, I think one way that I've heard it stated is that, you know, people are very direct,
right? People tend to give very direct feedback without, I don't know, beating around the bush.
They're just like, "This is what it is." And that can come across to some people as hostile,
which admittedly sometimes might even be true. I mean, we hope not, but
we're all people with emotions, right? We all have bad days.
[CLAIRE] I'm glad you're not having a bad day today, Robert. I'm glad I'm not too.
[ROBERT] But yeah, it does take some time to sort of get used to it and understand what people are really
saying. And I think, you know, when you've been doing it as long as I have, things that
some people say on the mailing lists start to even creep into your vocabulary and you find
yourself using an expression that somebody uses on the mailing list on a regular basis when you're
talking to your family or whatever. And you realize how much time that you've spent on this
mailing list has really infiltrated your whole way of thinking. And that's not altogether good,
of course, because the particular turns of phrase that Tom uses or I use or whoever use on the
mailing list aren't necessarily anything special. But you do have to figure out how to work with
people. You have to figure out how to communicate with people in a way that feels respectful enough
to them, but is also direct enough to get the job done. And, you know, also just enables you to work
together and accomplish more as a group than any of you could accomplish individually.
[CLAIRE] Does anything specific come to mind in terms of these turns of phrases that have become
part of your, I don't know, everyday life?
[ROBERT] Ooh, I'm not thinking of one right at the moment, actually.
[CLAIRE] Okay, well, maybe one will pop into your head as we're proceeding here. I did notice that
one of the things that's important is that people not get defensive, you know, like,
[yeah,] one of the things when I used to work in the kernel group at Sun is when you know that
your software product is, I don't know, potentially going to be used in an air traffic control tower,
or whatever, right, when it is being used for life or death scenarios, or scenarios that have,
like, a huge financial impact on people. I don't know, you really want to get it right.
You really want to make sure that it is going to do what it's supposed to do without bugs.
Of course, there'll always be bugs, but...
[ROBERT] I think people who are new to the PostgreSQL community or to PostgreSQL development often
underestimate how difficult it is to keep bugs out of the product,
or the project, I guess I should say. You know, we don't do a perfect job at that.
Obviously, there are bug fix releases every quarter, and we make mistakes all the time.
But I think it's often not visible how much care and how much effort goes into making it as good as it
is, which can make people very frustrated because they're like, look, I'm just trying to get
something done here. And they don't realize that the last time, you know, somebody was just trying
to get something done, there was a lot of picking up the pieces that had to happen there. So,
being open to that negative feedback and not getting defensive about it, as you say,
and just realizing that people are worrying about things because they've been burned before
is a really important part of it. But another thing that I notice in that way,
an error that I have made uncountable times, is somebody writes something on the mailing list,
and you read it, and you hear that person saying whatever it is that they wrote in your own voice,
and you attribute to them the emotional state that you would have if you had written those words
down. But that's not necessarily what they were feeling. That's what you would have been feeling
if you had written the thing that they actually wrote. And a trick that I have found to be very
helpful when I start to get really pissed off at somebody on the mailing list, especially if it's
someone that I've met in person multiple times, is I read the email again, and I imagine them
saying those things out loud in their voice, the intonation that they would have if they were
saying those things out loud. And very often when I do that, I realize, "Yeah, this doesn't actually
have nearly as hostile a tone when I hear them saying it as when I say it, because their word choice and the
way they express approval or disapproval or agreement or disagreement or whatever is different
than the way that I would express those things. So I think that's the other reason not to get too
upset when somebody says something that sounds critical. They may not actually mean that the
way that it sounds to you, because you're almost always projecting a little bit of yourself and
your own communication style onto them. And sometimes that may be exactly what they meant,
and they weren't being very nice. But I've found that surprisingly often it actually boils down
to different people expressing the same sentiment in different ways.
[CLAIRE] I have never in my life heard
that trick, or certainly not heard it described in that way. And I think it's really cool. It only
works if you have met the person, I think. [Yes.] You know, that ability to imagine them, their word
choice, their facial expressions, etc. Although, actually, maybe that's one of the benefits of this
podcast, right? I'm trying to help people in the community or future people in the community,
people who are not yet here, but thinking about joining the Postgres project, to get to know some
of the folks who contribute and get to know why they do what they do. And so maybe if someone has
heard you speak here, or maybe heard a recording of a conference talk, then even if they haven't
met you, maybe they could apply that trick.
[ROBERT] Yeah, and I think it's also really helpful.
It's a reason why events where people can get together are really helpful, right? We're
currently planning PGConf.dev in May. And that is a time when a lot of developers will get there
together, and we will get to hear each other in person and see each other in person and see each
other's faces and see how people react to things. And I do think those kinds of events are a really
important part of building community, because they just make it not an abstract voice on the internet
telling you that you're wrong. They make it a specific person that you know, and that you
hopefully don't think is a horrible person, telling you that you're wrong, and probably in a
very specific way about a very specific issue, rather than, "Oh, they're just telling you you're
wrong about everything in your life." So I think everything you said is true. And to that,
I would say, I would just add that those in-person opportunities, when we have them,
are also a really valuable part of that.
[CLAIRE] So let's talk about PGConf.dev for a second.
It's going to be happening in Montreal in the middle of May. It is the second year after this
annual event focused on the development of Postgres has been kind of rebranded. So it was
formerly the PGCon event that used to happen in Ottawa each year. So last year was the kind of
first year post reorganization and rebrand, and that was in Vancouver. And this year will be in
Montreal. And the conference is focused, if I can say it well, you're on the organizing team,
is that right, Robert? [Yes, yes, that's right.]
Okay. It's focused on the development of Postgres. So a lot of the contributors
come, other community members as well. I plan to be there. And there's opportunities for like,
there's a patch review workshop. And there's a lot of focus on how do we help contributors get
better at their job? How do we help tomorrow's future contributors and committers? I don't know,
I'm putting words in your mouth. You tell me.
[ROBERT] Yeah, no, I think I agree with everything you
said. I mean, I think the core content tends to be sort of more technical developer focused stuff.
But I personally believe that it's really good when we grow beyond that. Right? So,
you know, your talk that you have there this year, I believe, I think you had a talk at PG Europe.
But I've heard you give a few talks that were about some of these community building topics.
We had the, you know, the "Making PostgreSQL Hacking More Inclusive" session last year.
There's a lot to talk about that's more than just the patch that I'm hacking on right at this moment,
or the patch that I just finished hacking on, or the patch that I'm about to start hacking on. And
I think, you know, the core constituency of this is really the group of developers and people do
and should want to spend most of their energy talking about the development itself. But
mixed in there with that, I think it's really valuable to have some discussion of community
building topics, working together topics, all the things that aren't just what's in the patch.
Because ultimately, our success or failure as a project, or even our success or failure,
specifically, if you just think of the community of people who are developing for core PostgreSQL
itself, the patches are only part of it. And acknowledging those other parts and working on
those other things as well, I think is an important part of what we want to be doing along with the
hardcore hacking.
[CLAIRE] Well, and I know from talking to Melanie, how much work is going on in the
background to make this thing as successful as it can be. And there's an unconference on the last
day. So, and that everybody seemed to be engaged in last year. Right? Just...
[ROBERT] I think last year,
we had a great event, a huge shout out to Melanie and Steve Singer and Jonathan and everybody who
was involved in bringing that event together. There's usually a developer meeting and some
other bits of, let's say, alternative content on the first day of the event. And then we have two
regular days of talks and then we finish up with the unconference. And there's always an amazing
hallway track going on the entire time with people just standing around and talking about
patch ideas or community ideas, getting to know people, putting a face and a voice to a name,
all of those kinds of things. And I think it's just such a valuable event for the community.
So if you are at all interested in that kind of stuff, you should definitely register for the
event. Maybe you should convince your company to sponsor the event. I think it's a great event for
the community. And I think that team that was involved last year, which did not involve me,
did really, really well. And that's why I wanted to volunteer to be a little more involved this
year and to try to help keep things rolling.
[CLAIRE] You mentioned earlier when you talked about
your first patch that you got it off the to-do list, but that wasn't a particularly good list
to necessarily find a first patch on. And then Tristan Partin in the chat commented that
Tomas Vondra, who is another Postgres committer and who is now a teammate of mine at Microsoft,
but he apparently keeps a list of good first patches that people might do. And I don't know,
is that something that's come up a bit in the whole mentorship program? Like where people...
[ROBERT] It comes up all the time. It's actually a huge issue because, of course, people need
getting started patches. People need things to work on. And they want suggestions that are
things that are perceived as valuable by the project, that are likely to be accepted if they
do the work, but that are also doable for somebody who doesn't yet have a lot of experience.
And what I've seen is that if those lists get out there on the internet, they tend to become empty
extremely quickly. I don't know if Tomas is better at keeping his list filled than I've ever been at
keeping any list that I've ever seen filled, or if it just hasn't quite made the rounds yet.
But I think there are a lot of people who are really keen to be involved in development with
the project and who would love a project for beginners. And I have to tell people
"I don't have anything for you. I'm sorry." on a really regular basis and every time
I hear about somebody who has a list, I'm like, "[whistles] really?" Because there's always, always, always
people who are looking for projects.
[CLAIRE] Well, maybe you can take a peek after the podcast recording
is over. Tristan dropped a link to Tomas's list and tags there. So I don't know. Maybe that's
something that will help the mentorship program too, just having more eyeballs on it or having
it grow even longer than it currently is.
[ROBERT] I would also love to see other committers or
senior contributors in the community publish their own lists for things like that and
try to keep adding things to them. Because I think without those kinds of project ideas,
it really does become very difficult for people to get involved. And so the more of those kinds
of ideas that we generate and record and find ways to filter out to people who want to be involved,
probably the more people are going to end up getting involved.
[CLAIRE] Have you ever, I don't know, gone back to your alma mater or given talks at local universities
and tried to, I don't know, sell the value of working on the Postgres open source project?
Is that something that you've done or are thinking about doing? And if you have done it,
what's the story you told? How did you try to entice tomorrow's future contributors?
[ROBERT] I'm going to be honest, I've never really tried to do anything like that.
[Okay.]
I think part of that is, I mean, part of that is probably short-sightedness, but part of that,
I think, is also that I think one of the ways that we're sort of struggling as a community is
to figure out how to get people plugged into the development dynamic in a useful way when they do
show up. And the thing we were just talking about with project lists is, in my opinion,
a pretty big part of that. I mean, I think there's a lot more to it than that, but that is,
you know, that is good evidence of a problem, right? When lists of projects that are good
for new contributors empty out really fast, that means that you have more people who want to be
involved than you know what to do with. And I do think that's where we are. I think people show up
on the mailing list and they're interested in getting involved. And, you know, there's a variety
of things that can happen that you've had conversations about as a community, and I
think we're doing better with some of those things. There used to be a lot of complaints about people
getting very rude responses on the list when they showed up to post there. And maybe that still
happens from time to time, but my personal impression is that that's actually gotten
much better over the years. And I very often see someone post the list for the very first time,
or even the second or third time, and they get a very encouraging response from whoever writes back,
a very, probably a much more patient response than an experienced contributor posting the same thing
would get. So I think that's really good. I think that is a sign of progress. But I think, you know,
the fact that we don't have great project ideas for people, the fact that we probably need a much
more extensive mentorship program than we've already got, probably a bunch of other things
kind of make it hard for us to absorb all of the interest that we get. So I don't think our main
problem is finding more people who would be willing to dip their toe in the water. That's probably
part of the problem. Maybe that part of the problem deserves more thought than I've given it.
But I think a lot of the problem is actually more along the lines of, well, okay, great,
somebody showed up, but do we have any way of making them feel like they're accomplishing
something useful? Because if they don't feel that way, then they're probably not going to stick
around.
[CLAIRE] Okay. So the to-do lists are super important. The reception people receive, that
welcomingness, is super important. And then obviously when people get further along, because
I assume they're a little bit further along before they're motivated to join any kind of mentorship
program, obviously that's why we're here, because that's also an important part of the recipe,
another ingredient. And I'm sure there's more ingredients beyond these.
[ROBERT] Yeah. I mean,
so we haven't talked much about the monthly hacking workshop that I've been doing.
[Let's talk about it.] But those have been really interesting in regards to the point that
you just made, because we really get people of all levels who show up to participate in those
discussions. We get people who have never posted an email on hackers, and we get committers,
and everything in between. And so I think that that, it isn't necessarily true that people don't
want mentorship before they have gotten involved, posted their first patch, written something on
the mailing list. I think even before that, there's an opportunity to do better at welcoming
people and pulling them in. I don't know that we've exactly figured out how to do that, but in
my opinion, that hacking workshop has been an extremely successful part, possibly the most
successful part of the mentoring program, because you have a lot of people who come back every month.
They're at such a wide variety of levels. They seem really engaged and interested. I mean,
of course, there's usually somebody who isn't engaged and interested, but on average, the
level of engagement is very high. The questions are great. And I don't know, I just have the
feeling that there's probably a lot more potential there than we've quite figured out yet.
[CLAIRE] Well, one of the, two of the things that I really like about what you've done,
maybe three, is first of all, I like that you use Discord. And in particular, that Discord is open.
I mean, yes, you have to create an account and you have to log in. So there is a little bit of
a wall, right? It's not out there on the public internet per se, but anybody's welcome to do that.
And so I can imagine a mentorship program where you could have had this totally walled garden,
where only the mentors and the mentees and you and Melanie and Andreas were in there,
and nobody else was allowed. But instead, you've got over 700 people that have joined this
Postgres Mentorship Discord. That's a lot, right? A lot of lurkers. Obviously, 700 people are not
coming to your monthly workshops, I assume. But, you know, they are popping on there occasionally,
looking at the chat, looking at what's going on, maybe paying attention to what the next topic is
going to be. How many people are you getting in these monthly workshops? Do you know?
[ROBERT] Yeah. So I think we've been, I think the recent low has been like 36 signups. And then the highs
have been like, I don't know, mid 40s. Maybe we've been over, we've probably been over 50 at some
point. We usually do it as two or three sessions so that you don't have a giant number of people
in an individual call. But yeah, I think it's been great discussion. I've really enjoyed the
discussions. And I feel like both that and the discussion in the Discord kind of show that
there's opportunity to find more ways to engage with people. So these are some things that I've
managed to find the time to do. And it does take a fair amount of time to organize it.
But I think that, I really hope that if other people are listening to this who are
established PostgreSQL developers or established in the PostgreSQL community in other ways, that
you'll also think about what you could do, because I really believe there's a lot of
untapped potential here. I think when you look at not even so much the 700 people who joined the
Discord server, but the much smaller group of people who comment regularly in there and chat
and ask questions and participate in the discussion, and especially when you look at
the people who are coming to the hacking workshop month after month and are taking time out of their
day to sign up for the workshop, to watch the talk, to show up for the session, to ask some
questions, to seem interested, to seem engaged. You know, those are people who we're bringing
something to them that just otherwise wouldn't have existed. Right. But this is just one idea.
This is an idea that occurred to me to help people who are doing a very specific thing, which is
thinking about hacking on core Postgres, you know, to have a little bit of exposure to senior
community members and to some of how the development process works. But it is not believable that like
the first or second idea that I had about how to improve things for people is 100% of what could
be done. I mean, it's probably not even 5% of what could be done. So I think there's huge untapped
potential to find ways of connecting with people who are interested in becoming more involved in
development or other aspects of the community and finding ways to really get them involved and to
become, you know, a big part of what we do. But I'm not sure what we know. We know what those ways are
yet.
[CLAIRE] Okay. So for anybody listening to this podcast, we'll include a link to the Postgres
mentorship, Postgres hackers Discord that Robert created in the show notes for the podcast episode.
And then when you go there, there's a #hacking-workshop channel that is open to anybody
who joins this Discord, right? You don't have to be one of those mentors and mentees.
[ROBERT] Absolutely. And I do also post the signup links every month on my blog. So if you go to
my blog, you'll see a monthly post there as well, inviting people to sign up.
The advantage of joining the Discord is that you then get to vote on which talks
we should cover each month. And you get to discuss those talks in the Discord with anybody else who's
also discussing those talks. But Discord is not mandatory. You can participate just by checking
the blog and using the signup link there. But you get to do a few extra things if you
tap into the Discord as well.
[CLAIRE] So when you say invitations for February's workshop have
been sent, where does the workshop happen on what forum or what platform?
[ROBERT] Workshop happens on Zoom.
So EDB graciously provides me with a paid Zoom account. And I'm familiar enough with Zoom to sort
of be confident that I can, you know, handle anything that might unexpectedly happen during
the workshop. So that's the tool I've been using. I know that's probably not to everyone's taste.
Some people would probably prefer Google meet or Discord itself or something else.
But I just picked a Zoom because it's already paid for and I'm sort of confident of my ability
to administer it as may be required.
[CLAIRE] And the topic for the February workshop,
is that Heikki to talk about the wire protocol? Is that right? Or am I confusing January with February?
[ROBERT] So we just did Andres's talk on NUMA, non uniform memory access. And I think Heikki is next. Yeah,
he's one of the ones that I recall is coming up. In fact, I think our first session is tomorrow.
Yeah, first session is tomorrow. We'll have three sessions, I believe, over the next three weeks.
And at some point in there, we'll open signups for March when we'll be doing,
I'm going to get this pronunciation wrong, but Louise Grandjonc Leinweber has a
talk about planner statistics. So we'll be doing that one in March.
[CLAIRE] And Louise is such an amazing presenter, speaker, technologist. I've always enjoyed her talks.
[ROBERT] Yeah, I don't think she's a hacker in the sense of writing code for PostgreSQL itself.
But the talk is so relevant to the task of hacking on PostgreSQL that I think it's going to be a
great discussion.
[CLAIRE] Very cool. I'm trying to make sure before we wrap that we've talked about,
I don't know, all the things that you want a listener to know about the new mentorship program.
Let me ask this, is there going to be a second cohort? And like, when should people be on their
toes if they're interested in potentially applying to be part of the more
formal mentor and mentee aspect of the program where you're matching people together?
[ROBERT] Yeah, we're going to be doing that soon. Just yesterday, I sent out an email to the current
mentors and mentees and asked them to provide me with some feedback, some specific questions about
their current mentoring relationship. And what I hope to figure out on the heels of that is,
you know, which of those relationships might come to end for one reason or another, and then how
much potential do we have to absorb some new people into the program? And then when I've figured
all of that out, probably sometime in the next month or so, there will be an email to PostgreSQL
hackers and a post on my blog letting people know that signups are open. I don't know how many
people we'll be able to accommodate. You know, I think there are a good number of current mentors
who are happy with their current arrangements and want to continue mentoring the same person.
And I think that that may mean that there aren't that many slots available for new people,
but we'll see. Maybe we'll have some more committers volunteer to participate who haven't
in the past, or maybe some people will volunteer to take on an extra person, or I'm not sure exactly
what's going to happen yet. I don't want to set expectations too high, but do keep an eye out if
you're interested over the next month or so. There should be something coming out where you can sign
up and we'll do the best we can with the volunteers that we have.
[CLAIRE] Okay. And do you have learning chat,
or maybe you haven't done this yet, because you're not really at the exact end of cohort one yet.
But I'd be really curious to know, for the people who are in the mentorship role,
what, I don't know, what things they want to learn from each other, right? What parts of it they
found hard? What parts of it they struggled with, or they wish they, like, how do you deal with this
type of situation? I don't know. Is that something you're going to be surveying them on, or maybe you
have already?
[ROBERT] Well, Melanie did, actually. Melanie had a couple of meetings, I think, back approximately
in September of last year with the mentors and mentees to sort of gather feedback. And I confess,
I was a little bit blindsided by this. I sort of thought that it was kind of obvious what you
were going to do as a mentor. But some of the feedback that we got is that it either wasn't
obvious at all, or that the stuff that I thought that you would want to do was not necessarily the
right stuff. So this is another example of when you first start doing something that you haven't
really done as a project before, you have to make a bunch of mistakes before you start to try to get
things on better footing.
[CLAIRE] If I can tease you a little bit, maybe it's also another example of
Robert thinking that "the rest of the world is just like Robert, except maybe worse."
[ROBERT] Oh, 100%. 100%.
It's silliness and arrogance on my part, completely...
[CLAIRE] But that is normal, by the way.
There are so many people who think of themselves as the model for the world. I mean, it's just,
it's, I don't know. You're not the only one.
[ROBERT] You know yourself better than you know anybody else,
right? So you got to start somewhere. I don't remember exactly, I can't do justice to
the results of Melanie's conversations with people. She did do a write-up on it, but I
haven't looked at that lately, and I don't want to try to say something off the top of my head
and then get it completely wrong, because that would be unfair to her and to the work
that she did on it. But I do think we're going to have to continue talking to each other.
Mentors are going to need to talk to each other. Mentees are going to need to talk to mentors.
We've definitely gotten some feedback from some people that, hey, the kind of mentoring that I'm
getting is not really the kind of mentoring that I need, right? And that's very fair, because
everybody, you know, is an expert on what they want, what they themselves want. So we're just
going to have to figure out how to slowly get better at it, right? We can't necessarily do
all of the things that everybody wants. Some of the things people want might take too much time,
or just nobody's interested in doing the work. This is a volunteer effort. It's an open-source
project. Nobody is getting paid by their employer specifically to do mentoring. I think, you know,
my employer has actually been very good about supporting the time that I've spent on this, but,
you know, it's not the main thing that they're hoping for me to get done either, and I suspect
it isn't for anybody. So there are a lot of limits on what we can realistically do here.
But at the same time, it's totally, totally true that there's ample opportunity for us to get
better at doing this in many ways. And I think as we slowly understand, well, what exactly is it that
the mentees would like, and how does that differ from person to person? What exactly are the mentors
doing, and which of those things are working better, and which of those things are working
not as well? And is that because the things that people are doing are better or worse, or is it just,
you know, a question of doing the right thing for the right person, as opposed to the thing I'm doing,
could, doesn't work well for this person, but it might actually be perfect for, something, somebody
else. That's all stuff we still need to find our way through, right? And I think, you know, the
thing that I would say to everybody, whether you're involved as a mentor or a mentee, or you're not
involved at all and have no interest in being involved, or wherever you are with it, is just
that, you know, we're all human, and we all make mistakes, and that's okay, right? We shouldn't
give up on this process, because it isn't perfect on the first try. I think what we've accomplished
in the last year is limited, but I think it's good, and I'm hopeful that, you know, as we continue to
sort of mess around with it, and we're honest that we don't really know what we're doing,
but that we're trying to figure out how to do it better, I'm pretty hopeful that we will improve.
I think being willing to admit that you're wrong about your patch is a really important
part of learning to write better patches, and I think being willing to admit that you don't
really know how to do mentoring properly, or as well as you'd like to be able to do it,
is an important part of getting better at that. So we're just gonna hopefully try to
continue and fumble through it, and I hope that people are encouraged rather than discouraged
by the fact that we're trying to learn from our mistakes and grow and do it better in the future
than we have in the past.
[CLAIRE] Well, I want to say thank you. I mean, I really appreciate that you've
kicked off this experiment. Of course there's going to be mistakes or things that you decide
to improve or change or iterate on in cohort two, but I think it's important, and I'm really glad
you're spending time on it, and obviously a lot of other people, all the mentors, all the mentees,
everybody who's participating in the monthly workshops. So change doesn't just happen. It
takes effort and energy and motivation, and anyway, I'm very glad that you're doing it and
that you were willing to come here today and talk to people about it so that more folks who might
want to become involved in future cohorts will hopefully learn about it and bring their own
contributions to the mix.
[ROBERT] Yeah, absolutely, and I'd also like to, by a similar token, thank you for
sharing your stage with me today so that I can talk a little about this and how it's going and how it
might be better in the future and how I'm thinking about it because that's a valuable way for other
people to learn what's in my head, and it's also maybe a prompt for some of them to give me their
own feedback on what they think can be improved in the program. So thank you a lot for having me.
[CLAIRE] We can't leave, though, without me asking you about cheese.
[ROBERT] Oh, really?
[CLAIRE] I don't know if you know, there have been a couple of guests on the podcast.
It first started with David Rowley, whose path to become involved in the Postgres project
literally started in a cheese factory with a forklift, and then it turns out that
Melanie Plageman had a cheese story and Andy Atkinson had a cheese story in his path,
so I'm just curious, did you ever have a job that had to do with cheese
that was formative in your journey toward Postgres?
[ROBERT] No, I can't say that I have. I do enjoy good cheese, 100%, but as far as I know, that's
pretty separate from Postgres hacking.
[CLAIRE] Okay, got it. Just had to fish for it because it seems to be a trend somehow. Don't know why.
All right, well, thank you very much, Robert, for joining us today. I really appreciate it.
And for people who want more of this podcast, the next episode, episode 25, will be recorded live
on Wednesday, March 12th at 10am PDT, and our guest will be Dawn Wages, and we're going to
talk about why Python developers love Postgres. Dawn is very active in the Python community.
So if you want to mark your calendar, you can use this link aka.ms/talkingpostgres-ep25-cal,
and you can always get to past episodes and get links to subscribe on all the different podcast
platforms at talkingpostgres.com. Before we leave, if you have enjoyed it, please tell your friends,
in person, on social media, in DMs, however you want to spread the word about this podcast.
Word of mouth is probably one of the best ways for people to discover a show like this.
And also a big thank you to everybody who joined the live recording and participated
in the text chat on Discord. Thank you so much.