Talking Postgres with Claire Giordano

CLAIRE: 00:00:00
Welcome to Talking Postgres, a monthly podcast that was previously called Path to Citus Con, but we renamed it back in July 2024. In this podcast, we focus on the human side of Postgres databases and open source. I want to say thank you to the team at Microsoft for sponsoring this community conversation, and I'm your host, Claire Giordano. Today's topic is how I got started as a developer and in Postgres. With an amazing guest, I want to introduce Tom Lane. Tom is a Postgres committer and major contributor. He works at Crunchy Data, and he is prolific when it comes to Postgres development. Tom is a member of the Postgres Core Team, and he started contributing to Postgres, I guess about 26 years ago, back in 1998. And over time, he has worked on most parts of the Postgres code. He likes working on the planner and anything that involves SQL semantics. Tom earned a PhD in computer science from Carnegie Mellon University and has been involved with the Postgres project, like I said before, since 1998. Welcome Tom.

TOM: 00:01:11
Thanks for having me.

CLAIRE: 00:01:13
I'm really excited. Today's episode will probably be a little bit longer than usual, but we'll see how we do. Today's topic, how I got started as a developer and in Postgres, is I think fascinating because it's so interesting to find out how people got to be where they are and also why they do what they do. So let's dive in with, hmm. We'll start with when you first got involved in programming.

TOM: 00:01:41
Okay. Well, I was in high school. The math department at my high school had a teletype, an ASR 33 teletype that was hooked up on dial-up modem to Honeywell, something or other, I think a 316 that lived down at the county school building, a school board building. And they would spend maybe like one or two regular math class sessions on programming. But the machine was just sitting there after hours and kids could go and play with it after school if they wanted. I was a geek, so I wanted to play with this thing. And there were maybe about a dozen others who felt the same way. And we would go and write little programs. We had, let me see, the Honeywell had a BASIC interpreter of some kind. And we had a couple of spare teletypes on which we would punch up our programs on paper tape so that when we went to the live machine, we could just feed them into the tape reader rather than having to type online. And let's see, the only program I can specifically remember working on back then was I wrote a program to solve cubic equations, not because I had a need for that functionality exactly. I found an algorithm for that in a book and it seemed like the right size problem to learn BASIC with, so that's what I did.

CLAIRE: 00:03:20
All right, so you hung out after school in the math lab, started programming. You already knew that you were a geek apparently. And then you went to Carnegie Mellon for university, is that right?

TOM: 00:03:37
Correct.

CLAIRE: 00:03:38
Okay. And it was not your plan to become a computer person. I know this because you told me before the show. Your goal, is it true that your goal was to get a job designing pinball machines?

TOM: 00:03:51
Exactly. I loved and still love pinball, pool, bowling, anything involving aiming at a target. I'm not any good at those things, mind you, but I love it. And I just thought that the coolest job there could possibly be would be to design and build pinball machines for a living. So when I went off to CMU, I got accepted into the College of Engineering and the way they work things there is you don't actually have to declare a specific major until your sophomore year. Before that you're just an engineer. So I took the introductory courses for mechanical engineering and electrical engineering, figuring that probably mechanical would be the thing to do because back then pinball machines were mostly mechanical. Obviously, if I had foreseen what they'd be like now, I would have thought a lot harder about the electrical side of it. But at any rate, I took those introductory courses and the double E's sent their best, most charismatic professor to teach the introductory class because they understood they were in competitions with the other departments to get freshmen to sign up with them. And meanwhile, the mech E's made no impact on me whatsoever. So there I was, I became an electrical engineering major as a sophomore. I also took an introductory class in computer science just because it was there. As I said, I did not foresee that as being my future. But I did okay in that course and the professor who was teaching it pulled me aside and said, you really ought to go apply to be a research assistant in the department because you're good at this. And so I said, okay, because I needed a part-time job and that sounded way better than flipping burgers. So I went and applied and got the job. And I forget what they had me doing for the first year or so, but after that I got involved with the Hydra project, which was one of the very first symmetric multiprocessors that ever existed. And spent evenings and weekends and summers hacking on that for two or three years. And that CS101 course is actually the only formal training I had on computers until grad school. Everything else I knew I learned from being a research assistant. So it was a very unstructured way to learn anything about computers.

CLAIRE: 00:06:49
And as a research assistant, when you were learning about computer science and programming, was that all like self-taught or were you actually spending time with some of the professors or some of the other grad students or TAs who were teaching you as well?

TOM: 00:07:05
I can't recall if there was any formal training going on. They would say, go do this. And I would learn whatever I had to learn in order to do it. And was the pay as good as that of flipping burgers? Slightly better, but not by much. So the four years go by and you graduate and you have a degree in electrical engineering from CMU and you enter the job market.

CLAIRE: 00:07:37
And then what happened next?

TOM: 00:07:40
Yeah, well, the job market was fairly decent that year. So I had two or three job offers and I went to Hewlett-Packard just because they were the coolest of the bunch. And went to their, at the time it was called the desktop calculator division in Colorado. And what they made were, they were not the people making the iconic handheld calculators. That was a division in Oregon. But what the Colorado people were making were things that sat on a desk and typically would run BASIC or something like that. And they were basically just the supersized brothers of the handheld things. I fit right into that because at the time HP really didn't want to hire CS majors. I guess they thought it was a fake specialty or something. But since I had a double E degree, you know, I could get in the door. But nonetheless, you know, they were building these things that desperately required operating systems and BASIC interpreters and what have you. So they really needed people who could program. And there were not that many of us in the building. So yeah, I fit right in and I did okay there. And we made some pretty cool stuff. The machines that I had the most to do with were probably about the equivalent power of

CLAIRE: 00:09:29
VAX-11/780, but they sat on your desk. They weren't in a cabinet full of equipment. So I was, you know, and back in the day it was about one MIPS was what these machines could do. You know, there was a lot for the time. I think it's fascinating that these, these were effectively desktop computers. You're talking about the HP 9800 series. But they were marketed as calculators or desktop calculators. And apparently, and I've learned this from doing some research on Wikipedia. So you tell me if I'm right or wrong. But it was to make purchasing and sales and procurement easier because apparently some companies had different procedures for purchasing computers. So HP found it more effective to sell these as desktop calculators.

TOM: 00:10:17
I can believe that, but you know, I was, I was an R&D engineer. I had nothing to do with sales, so I can't say with my own knowledge that that's how it worked.

CLAIRE: 00:10:29
And you said it was the coolest place to go, HP, at the time compared to your other job offers. Like what, what was cool about it back then?

TOM: 00:10:37
Well, they just had a reputation of being an engineer's company. But it was very decentralized kind of situation. The founders, David Packard and Bill Hewlett were still active at that point. And they would show up fairly regularly and just wander around the labs and talk to people. Management by walking around was, you know, buzz phrase then. And that was what they actually did. I don't recall I ever met them in person, but it was probably at least 50/50 chance I would have if I'd hung on another couple of years. And in general, the place was very much, another buzz phrase that they had was "design for the next bench, build something that the guy sitting beside you would want to use." So it was very engineering driven company. And I get the impression that our culture has gone entirely, but I left there for five years, mainly because my wife did not like Colorado and wanted to come home to Pittsburgh. And so, yeah, I needed an excuse to leave without burning any bridges. And so going back to grad school was the easiest thing to do there. Okay, so you moved back to Pennsylvania and grad school.

CLAIRE: 00:12:08
So we're talking Carnegie Mellon again, is that right?

TOM: 00:12:11
Right, right. Because, you know, I'd been involved with the department as an undergrad for, you know, for years before that. So I knew that I would easily get accepted if I applied. My professor, Bill Wulf, who had run Hydra, would certainly give me a good recommendation letter. When I got back, he told me that I walked into his office and he said, "Some of the guys on the team started asking where you were after you left." I said, "Oh, I haven't seen him." And Bill said he graduated and they said, "Oh, what? I didn't see his thesis defense." They all thought I was a grad student apparently. But nope, I wasn't at the time, but now I became one. And so I had expected to sign up with Bill as being one of his students. But the second thing he said to me was I'm leaving because he had gotten a job as, I recall if he went immediately, but sometime later than that, he was director of National Science Foundation. And he'd been given either that job or some precursor to it. So he left and there I was stuck looking for another thesis advisor. Ended up with Jon Bentley, which was fun, but then he got a job at Bell Labs and left. And so my third advisor who finally stuck around long enough for me to get a thesis out was Mary Shaw.

CLAIRE: 00:13:54
Okay, so I think it's nine years start to finish at CMU. Is that right?

TOM: 00:14:01
Yeah, it was a long time.

CLAIRE: 00:14:09
There's something I just have to ask you about. Apparently grad students back in those days, I don't know if it's still true if you're getting a PhD in computer science at CMU, but you had all these kind of boring and menial tasks that you had to do. I guess the professors and the staff wanted to kind of get the most value out of their grad students.

TOM: 00:14:30
Something like that. You know, there's the idea that grad students are unpaid slave labor, basically. I don't know how the other schools run it, but at CMU's CS department, they had a list of things that needed, it's called the Lieberman queue, I guess, after whoever invented the, you know, this way of running things. And you're expected to take a job or two off that list and do it while you were there. A lot of them were pretty low level jobs. One I specifically recall was loading the departmental Coke machine, which actually wrote something up about it after the fact. There was a USENET group that was interested in history of computing, and I wrote a little thing about how that all worked. And I believe there's a link to it. Hopefully Ari will stick in the chat. But a lot of them were just not very exciting jobs like that. But when it was my turn to go and, you know, sign up for something, one thing that was available was running the USENET news software there. And I thought that sounded way more interesting than loading Coke machines. So I signed up for that. There I was being their USENET sysadmin for, I don't remember how long, several years. I didn't really have to run the hardware or anything. I just had to keep the software up to date, correctly configured and going. So yeah, I'm looking at your write up on the only Coke machine on the internet.

CLAIRE: 00:16:25
And there's a whole bunch of...

TOM: 00:16:26
Which was true at the time. It's not anymore.

CLAIRE: 00:16:28
Yeah. But I think one of the things you wrote is that no real programmer can function without caffeine. So the machine is super popular or something like that.

TOM: 00:16:38
Right. Yeah. I recall hearing that had the highest sales volume of any Coke machine in the area for some period of time back in the seventies. So yep, there was a lot of Coke being consumed and I consumed a lot of it too. It's still my drink of choice. I've got a glass of Diet Coke beside me right now. Got it.

CLAIRE: 00:17:04
For me, I had my double espresso this morning, so I'm done with caffeine for the day. And anyone who knows me well will say that one double espresso is enough. I try to talk slower on this podcast than I do naturally in life. Okay. The Usenet sysadmin job though that you had, obviously in parallel with your graduate student work and your work on your thesis and all of that, was the software that you were maintaining open source?

TOM: 00:17:33
It was.

CLAIRE: 00:17:34
Okay.

TOM: 00:17:35
So that was my first exposure to open source in the sense that we know it today where there's an intentional desire to make code freely available. There was obviously, you know, in the academic environment, there was a ton of code kicking around that was effectively unlicensed because nobody cared about that. And you could have a copy of it if you wanted, but there wasn't a formal license saying that it was okay for you to use it. Whereas with the Usenet code, there actually was a license saying, you know, this is available and free to use and so on. So that was kind of my first exposure to that concept.

CLAIRE: 00:18:24
Okay. Which obviously becomes very, very important as you progress in your career. All right. So nine years at grad school, trying not to have to fill the Coke machine, a sysadmin job for Usenet. Could you live on your grad student stipend? Did it take all of your-

TOM: 00:18:46
No, not really.

CLAIRE: 00:18:47
Okay.

TOM: 00:18:48
If I had been single and living in a garret, it might've done, but I had a wife who did not want to live that way. So I needed an outside income and I met up with a guy who was interested in doing the aftermarket support for those Hewlett-Packard machines that I'd worked on.

CLAIRE: 00:19:10
Desktop calculators.

TOM: 00:19:12
Right, right. Because, you know, this was a few years later and HP was no longer particularly interested in doing new software for them or anything like that. So they were aware of what we were doing and they were fine with it. And made a decent living for a few years of that. That was part of the reason why it took nine years was because I was spending a good chunk of my time off doing that rather than doing grad studenty things.

CLAIRE: 00:19:49
And then you've got your undergraduate degree, you worked at HP, you're working on your PhD. You've got your first exposure to open source, but had you taken a databases class yet? Did you know, have any inkling that you would someday spend all of your working hours focused on a database?

TOM: 00:20:10
No, there was at that time, as far as I can recall, there was nobody at CMU who cared about databases at all. Certainly nobody thought they were cool.

CLAIRE: 00:20:22
Okay, so Andy Pavlo was not a professor there yet?

TOM: 00:20:26
No, I don't know when he came, but it was after my time.

CLAIRE: 00:20:31
Okay. So when do you first get introduced to Postgres or any database, relational database for that matter?

TOM: 00:20:44
So going back to this outside business, which was called Structured Software Systems, and that's where the SSS and my still existing domain name came from. Like I said, we've been doing aftermarket support for HP's machines for probably about 10 years. And then that market started to dry up because HP weren't making those particular models anymore. And the demand for support was going downhill. So we looked around for something to do and we said, you know what we'll do, we will get rich in the stock market by modeling price series. And maybe this was a crazy idea, but it actually worked for a while. We spent a year or so developing some algorithms and writing support code for this. And when we were ready to trade, we said, oh, we need databases for our trades so we know what we've got and what we need to sell or buy. And we were starting this on a shoestring, right? Because we were living off what we'd built up during the years of working on Hewlett-Packard stuff. So we didn't have a lot of money to spare at this point. And I went around and looked at what was available in open source databases. And there are basically two alternatives. There was Postgres and there was MySQL. And we also looked at Oracle for about half a second until we found out what the licensing fees were like. So I went and looked at the code base of Postgres and it was pretty clean and readable. And I said, you know, this looks decent. And I looked at the code base of MySQL and it was poor. No comments anywhere, very unreadable coding style. And I said, I do not trust this thing. I'm not going to use it for something that my income depends on. And so we chose to use Postgres. And we set out, we started trading. We actually made some money for a few years. But then it seemed like the markets changed and the algorithms we had didn't work as well anymore. I think what was actually happening, there are still people making money with that sort of trading, but they're doing it on these incredibly short time scales. They actually worry about speed of light to the exchanges. And they, you know, they're doing it on millisecond trading levels. So the same thing we were doing, but we did not have the resources to do it in that kind of way. So after a while, our trading models stopped working very well. But in the meantime, I had just gotten involved in Postgres. The first thing that I had to fix in it was, we wanted to run it on HP machines, obviously, because that's what we had. And there was a port to HP-UX in existence, but when we tried to use it, we found a few bugs. And so I had to send in patches for that. And the next thing that I ran into that didn't work as well as I could wish was, we wanted to use the listen and notify commands that Postgres already had to send signals between the machines we had that were doing the trading models and the machines we had that we were actually trading on. And I don't recall the details of what was wrong, but there were things about listen and notify that didn't work very well. So I had to go fix them. I had to fix some other things, this, that. And gradually, I just got sucked down this rabbit hole of discovering there are actually all sorts of interesting things about this piece of software. And particularly the planner, I got really interested in as time went on. So after two or three years of this, I realized I was basically shirking SSS work completely and spending all my time on Postgres stuff, which was clearly not terribly sustainable. And right about then, Great Bridge started up, which was I think the first Postgres focused company. And they offered me a job to come and spend full time hacking on Postgres. I said, I'm in. So that was where I switched over from just doing this as a dilettante to actually getting paid for it.

CLAIRE: 00:25:51
Okay. So you were a user of Postgres before you became a contributor in the context of this trading model that you and your partner at Structured Software Systems had built, right? Did you hear me? Sorry. Is there something wrong with my microphone?

TOM: 00:26:14
No, but you seem to trail off without actually asking questions.

CLAIRE: 00:26:19
Oh, okay. So no, I was just confirming. You were user first at Structured Software Systems before you started submitting patches to fix the problems with listen and notify, etc. Is that right?

TOM: 00:26:32
Correct. So, yeah, initially our intention, my intention was just to be a user and not particularly to get involved with it.

CLAIRE: 00:26:42
But then there was a rabbit hole. Okay, but we've jumped over something. After you got your degree and while you were still at Structured Software Systems, presumably working on this trading model, you also got involved in image compression and JPEG.

TOM: 00:27:01
Right.

CLAIRE: 00:27:02
You have software running on Mars, so I think we've got to talk about this. Like how did that happen?

TOM: 00:27:08
Okay, so as you said, this was right after I graduated. I felt that I graduated from grad school, not undergrad. I had this shiny new PhD. And a good chunk of that I could be thankful to US taxpayers for because that was where that stipend was coming from. So I felt like I had to give something back. And the obvious way to do that was to write some open source code for something or other. But I didn't know quite what to do. And what I remembered was when I'd been Netnews admin at CMU, I had a huge problem with the amount of bandwidth that was being spent on GIFs being shipped around on Usenet, because everyone wanted to put up their cat pictures and what have you. And so base64 encoded GIFs were the technology of the day. And they were enormous, at least by the standards of the T1 line, that was the best anybody had for passing news around. And if you were interested in photographs, GIFs do not have very good image quality for that. So that was a sore spot that had existed for some time. And right about then, there was this new standard that came out, written by the Joint Photographic Experts Group, which was a committee of, I think, ISO and I forget the name of the US standards body that is equivalent to ISO, but that was where the joint came from. And they had written this image compression standard based on an entirely new mathematical approach called discrete cosine transforms. And we were hearing great things about it. So both as to how well it could compress and as to the quality of the resulting images. So I said, let's see if we can write something here. I don't want to sound like I did it all myself. There were about a dozen other people who were involved at the beginning. And people had gotten together through being interested in image compression on USENET. And we wrote this code and it actually worked. And it wasn't terribly fast, because we didn't know how to optimize it. But when you're talking about an image you're sending across a dial-up line, it doesn't really matter if it takes you an extra 10 seconds to decompress it. So that wasn't a problem. And it really solved the problem nicely, because for a tenth of the size of a GIF, you could have a significantly better looking resulting photograph. And so a factor of 10 better is the kind of number that gets the world's attention. And that meant that our code just took over USENET by storm, pretty much. And then people started using it on the World Wide Web, which was a new thing. And that's how that all ended up. Other people have tried to supplant that original JPEG stuff off and on. But it's kind of hard to do, because if you don't have that factor of 10 advantage over what's there, you can't get people's attention. So I think it'll be a while before that goes away.

CLAIRE: 00:30:57
Well and the--

TOM: 00:30:58
But that's the original point. Yeah, the engineering cameras on the Perseverance rover, I know are using libjpeg, because Joe Conway pointed me to a paper that said so. And I'm, not, less sure about other Mars missions. I recall hearing that some of the orbiters had JPEG-based code, but it was not based on our library. It was some other implementation. But I know for a fact that Perseverance is using my code.

CLAIRE: 00:31:33
And then I have a quote in front of me that focuses on the open source side of things, too. And this is actually a quote from you, I think. "30 years later, it's still the case that the existence of libjpeg with liberal license terms is why JPEG is everywhere, and the potential alternatives are not." You said that, right?

TOM: 00:31:53
Yeah, that was part of the discussion we had before the show. Yeah, what I was describing just now was the technical merits, but I think the fact that libjpeg was open source also had a great deal to do with the ease with which it got taken up. And that is another thing that some of the folks who have tried to replace it but didn't quite grasp. They would put out stuff that had some kind of restriction on it. It wouldn't get used. So those are the two bits of the recipe that I have for the next person who wants to revolutionize the world. It has to be good. It has to be free.

CLAIRE: 00:32:34
Okay, so once you got involved in Postgres though, and like you said, you realized you were shirking your Structured Software Systems work, I'm assuming you also had to hand over your libjpeg work too, as Postgres took up more and more of your time. Is that right?

TOM: 00:32:52
Yeah, yeah. I kind of, after about '97, '98, no, it must have been later than that, '99 or so, I kind of stopped having any more time for libjpeg. I was feeling extremely guilty about that for a period of several years, but eventually some other people stepped into the breach. The current crowd is led by a guy, I believe by the name of Darrell Commander. I haven't spoken to him in a few years, but they're still out there maintaining it. It's now called JPEG Turbo or something like that, maybe. It's descended of the same code.

CLAIRE: 00:33:35
All right, so let's dive into Postgres now, because that's what you did back in the late '90s. How did you, like what parts of the systems did you work on the most? You mentioned the planner earlier, and why? What were you drawn to? What was the magnet?

TOM: 00:34:01
It's kind of hard to say, really. I just found it interesting as a concept that we've got this exceedingly non-procedural language and something has to figure out how to make that into something that a computer can execute. It's a little bit, I should back up here. In my grad student days, I'd been mostly into programming language development and compilers and things like that. So I understood how those worked, but they were all quite procedural languages that directly express an algorithm and you could translate into that into something that a computer could do. Whereas with SQL, it's not procedural at all. You have to devise a query plan. Something that your code knows what to deal with. So that's probably what attracted me to the planner. I did spend a lot of time on all other parts of the code, but most of that was in the vein of fixing bugs, because one of the things that was salient about Postgres in the early days was it had been academic software in its origin. There's a great quote from Joe Hellerstein to the effect that Postgres is bloatware by design: it was built to house PhD theses.

CLAIRE: 00:35:41
I love that.

TOM: 00:35:44
That's what it was. That was what it did. And one of the principal attributes of PhD theses is that you're not required to fix every last bug in what you've written. So they didn't. And we were trying to make it into production quality code and we had to go around and try to find and fix all those bugs. So that was probably how I came by the... How I got to a state where I could say that I'd looked at most of the code at one time or another. In the last five or ten years, enough people that aren't me have been doing enough stuff that I can't really claim to be familiar with all of the code anymore. But there was a period where I could be.

CLAIRE: 00:36:39
And then I think you mentioned Great Bridge a while ago. But I know after they folded, because they folded, right? Then you went to Red Hat.

TOM: 00:36:48
Yeah.

CLAIRE: 00:36:49
Then Salesforce.

TOM: 00:36:50
Yeah. They collapsed in the 2001 dot com bust, which a lot of us were not particularly happy about. We thought, if companies are feeling poor, then there's all the more reason to be interested in open source stuff. So we thought this was a great opportunity. But the people who were running the company didn't see it that way. And they just decided to shut it down. But I was fortunate. I got a job at Red Hat where they let me continue to work on Postgres. And they said, well, you got to spend 10% of your time packaging Postgres and MySQL and a few other related packages. I said, yeah, I'll take that trade. And that's what I did for... I was at Red Hat for a good 10 years doing basically that. And then after that, I went to Salesforce for a little bit. And that was fun, but it was basically eating too much of my time doing non-community stuff. And I decided I didn't like that. So now I am at Crunchy Data. It's an even better deal. They basically let me spend 100% of my time on community Postgres. So I can't complain about that.

CLAIRE: 00:38:12
So amongst all these companies, though, other than maybe Salesforce, you've been able to spend the bulk of your time working on Postgres open source. Is that... I mean, that's pretty awesome.

TOM: 00:38:23
I thought so.

CLAIRE: 00:38:25
Yeah. And you still think so. But it's an interesting aspect of the Postgres open source business model that there are employers, not just Crunchy Data, but including Crunchy Data, who pay people to work nearly full time on upstream open source. It's kind of how... I don't know. It's just part of the economic model, I suppose, that keeps Postgres alive.

TOM: 00:38:53
I mean, most, if not all, of these companies have derivative products or things that they build on top of Postgres. And so they have economic interest in the open source project continuing to thrive. And I guess that's why they're willing to pay us to do what we do. But yeah, it's the kind of model that you might not think would come to exist. But here we are.

CLAIRE: 00:39:20
All right. So I have the rest of this conversation today. We've spent a lot of time figuring out how you got your start as a developer, as a programmer, how you learned, where you learned. But now we're just going to talk Postgres for the rest of the conversation. And I have... Most of my questions are about your work as a developer and contributor, author, committer, reviewer, et cetera, et cetera. But you're also on this thing called the Postgres Core Team, which I don't want to assume all of our listeners even know what that is. So can you tell us what that is and who you serve with and why it's important?

TOM: 00:40:07
So the Core Team is basically the steering committee. Where it started was that back immediately after Berkeley had decided Postgres was not research anymore, there had been a few outside users of Postgres even back when it was research. But not that many. I don't know exactly how things worked, how they communicated with the university. Once Berkeley decided it wasn't research anymore, they kind of put an open source license on it and threw it over the wall. And some of these outside users picked it up and decided to start making it into a product essentially, or sorry, into a product quality thing. There were about four people who were initially doing all the work of fixing bugs and integrating patches for other people who were also fixing bugs. So that was the genesis of the Core Team, I think there were four to begin with. And on both of them, I think the only one who's still active out of that original group is Bruce Momjian. Mark Fournier is still around on the fringes of the project, but he doesn't do anything with the code anymore. At any rate, originally those guys basically were the project, and so they had say over everything like when releases would be and how we would deal with this and who would get to be a committer and so on. But obviously a group of that size can't deal with it all. This project gets bigger. So there was a period of basically delegating responsibilities. And over time, I was about to say we, and up to now I was talking about cores being some other guys. They added me to core in I guess '99 when Great Bridge first approached the community and wanted to know how they could be involved in a nice way. And so the four guys who were part of core at this point said, "We better get some more people involved so we can talk to them with a more representative group of the community." And so they added me and Jan Wieck, and at that point there were six people on core and we went off and talked to Great Bridge and helped them organize. They ended up hiring several of us, not just me. But at any rate, moving on from there, it became obvious that we needed more people involved in running different aspects of the community. So a large chunk of what core has done since then is to delegate responsibilities originally were theirs by default. So there are now separate groups running, for instance, fundraising. The infrastructure is managed by a separate group of people. Code of conduct committee is, sorry, code of conduct committee is a different group of people and so on and so on. [Security] And what security team, right, release team, that there's overlap. Most of the core members sit on one or more of these other subcommittees as well. But there are a ton more people involved and all of them taken together. And what core remains to do basically is deal with stuff that those committees don't want to deal with. So occasionally step in for like discipline problems or if people can't come to a solution. But I don't quite want to say we're figureheads, but we don't actually do that much day to day as core. Obviously, we're all quite busy, but to the extent we're running the community, most of the work we're doing is done via these other subcommittees.

CLAIRE: 00:44:47
Okay. So there was a question on the chat that I want to make sure we touch on before we move on. And Melanie was curious about when that flip happened. When you were a user of Postgres who started getting interested in these rabbit holes, you were submitting patches, was there a moment when you realized that you wanted to work full time on Postgres or that you might want to drop your other responsibilities and have that just become your job full time?

TOM: 00:45:27
Oh, I actually did that, you know. I joined Great Bridge sometime in 2000. And probably for about a year before that, I've been having feelings of something I might want to do. But it wasn't until they made me an offer that I said, yeah, I'm going to do it.

CLAIRE: 00:46:02
Okay. So it sounds like it was a combination of your interest, but also the opportunity being given to you. Is that in your memory?

TOM: 00:46:10
Yeah, very much so.

CLAIRE: 00:46:11
Okay. Okay, cool. So earlier, I asked you to confirm that you were a Postgres user first before you became a developer and a contributor and author and all of that. I'm curious whether you think that influenced you. Did your work at Structured Software Systems, where you had to rely on Postgres to store various things in your trading model, has that influenced how you look at the Postgres project, what you think about when you're authoring things?

TOM: 00:46:49
Yeah, it made me aware of, I guess, the need to talk to end users. One of the things that I missed when I was at Hewlett-Packard was that the engineers all sat in our R&D lab and we'd talk to each other and the next bench only goes so far. You're really better off if you can talk to actual people using your product, but at least at HP, there were layers of sales guys and so forth between you and them. So one of the things I really like about the Postgres environment is that you are interacting on the mailing list with actual everyday users and you get to hear about their problems. So that's why I pay as much attention to the mailing list as I do, is it gives me ideas about what do we need to improve and maybe even ideas about exactly how to do it, but at least I get a feeling for where the pain points are in a very direct way that I think you have a hard time getting in a traditional company.

CLAIRE: 00:48:10
Yeah, there can be, especially in a large company, a lot of levels between you and a user. Although I suppose the internet has closed some of those, right? There are some feedback loops that can be direct. Someone complaining on Twitter about a product, I suppose. Okay.

TOM: 00:48:33
Some companies I think do that better than others. It's certainly possible to interact directly with your users if you choose to do so.

CLAIRE: 00:48:46
And then I started to do the math. I was watching this interview with Ed Sheeran and he was talking about this classic thing that you hear about, musician Ed Sheeran, I mean, this classic thing that a lot of people talk about. Maybe I think I first heard the term from Malcolm Gladwell, but I'm not sure what the source was, but this notion of 10,000 hours, this notion of it takes a lot of commitment and time to become expert at something. And so then I did the math based on your 26 years in Postgres and you have spent, I believe, more than 10,000 hours on Postgres.

TOM: 00:49:28
Oh, that's, certainly.

CLAIRE: 00:49:30
And then I guess the question is, do you feel like you got better over time? If you look at, say, your early patches versus your current patches, how have things changed?

TOM: 00:49:42
Yeah, I mean, obviously quite a lot of years to reach the point of having looked at most of the source code and I continue to learn things about what's connected to what and what sort of development methods lead to something that's going to be maintainable down the road versus not so maintainable. So yeah, clearly gotten better at this as I went along and I think I continue to do so. It's just, you got to be good at anything. It just takes a lot of study and work.

CLAIRE: 00:50:26
What about failures? Like have you, I think it's fair to say that some people are intimidated by you or a lot of people look up to you, but you're human. I'm assuming there've been failures along the way and do you have any, do any stories come to mind and do the failures actually make you better, or?

TOM: 00:50:50
Sometimes you learn not to do that again, but we're all far from perfect. If you look through the commit log, there are plenty of places where I've fixed problems that I created earlier. It's just something that happens and you've got to deal with it. I think that's one of the interesting things about working in open source is that your failures are inherently extremely public. You can't look the other way and pretend it didn't happen because there it is in the commit log. Anybody can see and you just have to own up to it and deal with it. I've gotten better at that just by force of experience. Let's see. It's discussion about, for the show, I recall if you specifically asked me about what I thought my worst ever bug was or if I came up with that as a topic myself, but anyway, I do have a candidate for what that is. Bug was actually a security problem, CVE 2013-1899, which rose from what I thought was simple refactoring, just moving some code around. What I was sloppy about there was the separation between trusted and untrusted command line switches, which enabled somebody who was just attempting to send a login. They hadn't even gotten authenticated. They could send some stuff that would be interpreted by the server as a trusted command line switch. The attacks that we mentioned in the commit message were bad enough, but there were things that the security team thought of that we still haven't admitted in public 10 years later because they were so awful. I don't remember the details, but I remember that they were pretty awful.

CLAIRE: 00:52:50
I think you just touched on something really important, though, which is when you work on an open source project, there's a lot of sunlight on your successes, but also on your mistakes. I don't know if that means you have to develop a thick skin or you just have to develop grace to accept that everyone's going to make mistakes sometimes and everyone's going to be human, but you have to kind of help each other find those mistakes before they impact too many people, I guess.

TOM: 00:53:25
Yeah, yeah. I think there's some of both of that. I think I've learned a little more grace as I went along in this project, at least at the extent of trying to be more polite on the mailing list and things like that. It's also true that you need to have a thick skin to some extent because, as you said, all this is just happening in public and you're going to be embarrassed in public. There's just no way to dodge that fact.

CLAIRE: 00:54:07
And I guess one of the things that I've tried hard to do is if I'm not careful, I can dwell on my mistakes, almost like a replay in your mind. And that's just not productive. And it doesn't help. It just creates stress or anxiety or whatever. So I don't let myself do that anymore. It's kind of like you process it, you learn from it, but then you're going to have to let it go. I don't know about you, but that's what I do.

TOM: 00:54:35
Yeah. I don't find that I tend to dwell on my mistakes. Think about it and see if I can learn from it. It's still true that one of the best debugging techniques I know is when you identify a mistake, to look around and say, where else did we make the same mistake? So yeah, it's sort of a version of learning from your mistakes, I guess, but it's something you have to do as best you can. I've never heard someone put it just like that before. Where else did we make this mistake? And then you canvas for it and hopefully fix more. Okay. I like that.

CLAIRE: 00:55:29
You mentioned mailing lists. Now for people who are not familiar with the Postgres community's development process, I'll try to summarize this, you tell me if I'm right or wrong, but there are these public mailing lists. You can search on PostgreSQL.org, Postgres mailing lists, and you can find them on the internet. And everything is out there for anyone to see. And a lot of the developer communication happens on a mailing list called pgsql-hackers. And that is different than other open source developer communities, I think. Maybe there are some other ones that use mailing lists as the primary form of communication too. But...

TOM: 00:56:16
Well, I think back in the 90s that was what everybody did, because that was about the only technology that existed. As time went on, other people have switched to other methods like GitHub or web forums or whatever. And the Postgres community is maybe a little stuck in the mud in that we haven't changed that. It is interesting, you know, we're sitting here doing this on Discord, and I see that Robert Haas started up a Discord server, and there's some conversations happening on that now. So I don't know if that will become a bigger thing or not. But as of today, it's still the case that the mailing lists are the main thing.

CLAIRE: 00:57:11
And then over the years, over the 26 years that you've been participating in and contributing to the Postgres community, do you feel like your, I don't know, email etiquette or email best practices have gotten better? And I'm curious if there's particular things that you've had to get better at.

TOM: 00:57:34
As I already mentioned, I think I've gotten more polite or at least be more aware of trying to be more polite. And there's a bunch of skills involved in that. But one thing that I think is worth mentioning is that when you start working on something, you have an idea for something, you really have to learn how to sell that idea to other people in the community. Because otherwise, it's probably not going to get accepted. Even if you're a contributor, you have to convince other people this is a good idea before you can get away with committing it. So you have to develop skills of presenting your idea, explaining why it's a good thing or why it's better than what we have. And interacting with people. Almost always, somebody else will have some ideas that make your idea better. You have to be able to hear that feedback and say, "Oh, yeah, that is a good idea," and adapt what you're doing. So we always encourage people to try to do that before they've written a whole lot of code because otherwise, they may end up throwing a lot of it away and doing it over. So there's that, and I already referred to listening to users' problems to see what needs to be worked on. Do you have any other thoughts?

CLAIRE: 00:59:23
Tone of voice is just an interesting thing in email. I sometimes find myself dropping an emoji or I probably use too much punctuation, but I'm trying to sometimes be positive and make sure that my words don't get misinterpreted with the wrong tone of voice, with a more negative or more critical tone of voice. So it's tricky. You said something to me earlier, though, about how certain... You call them verbal mannerisms. I don't know if you have an example. There may be figures of speech that you do not use because you feel like non-native English speakers may not understand those. Is that right?

TOM: 01:00:10
Yeah. If I'm in a vacuum, I'll tend to write things that might be... I guess you might call it faintly archaic English. It was sort of a way that I tend to write a lot.

CLAIRE: 01:00:35
I need an example to understand that.

TOM: 01:00:38
Oh, yeah.

CLAIRE: 01:00:39
Putting you on the spot, sorry.

TOM: 01:00:43
I'm drawing a blank, but you probably wouldn't have to go back further than a couple of weeks in the hackers list to find instances of somebody complaining about, "This comment in the code looks a little strange to me. Is it really good English?" I say, "Yeah, it's perfectly good English. I wrote it." But at the point of fact, it was written in a style that you don't see people using all that much anymore. I think...

CLAIRE: 01:01:15
Maybe someone on the live chat will come up with something and give us an example. Or maybe you'll think of one later in today's conversation. But the point is you have these faintly archaic English mannerisms and you try to avoid them. So that more people can understand you. That's the gist of it.

TOM: 01:01:41
Yeah. Particularly over the last, I don't know how many years, it seems like we have more and more contributors whose native language is not English. And I'm more aware of that than I used to be. And I try not to write things that might be hard to understand. I don't know how well I succeed at that, but I know that it's something to worry about.

CLAIRE: 01:02:10
All right. So I want to ask you, okay, a little bit of context. Years ago, I took a year off to write a book. I wrote a book. It's a trunk novel. It'll never get published because it's so bad. But as I did that, I paid a lot of attention to what should my writing routine be every day and what do other successful published authors do? And one of the tips was that you sit down and you don't get up. You can't make tea. You can't make toast. All the millions of things that might distract you or cause you to procrastinate or whatever, no, you stay sitting and you focus on writing until it's all out of your system. Now that's different obviously than being a developer on Postgres. But I'm curious what your routine is every day. What time of day do you work best? Do you time box different kinds of work? Do you have particular weird eccentric habits that maybe make you a better problem solver or more creative? You already mentioned caffeine. So we know about your Diet Coke that's sitting on your desk.

TOM: 01:03:16
I don't know. My normal routine is I get up and before breakfast I look at the mailing list, see what's going on. And David Rowley alluded to this in his podcast. You frequently don't find out what you're going to work on that day until you've seen what problems came in on the mailing list. And if I see something that looks like a bug, I think I know where to fix it. I might go off and spend the day doing that. If nothing like that happens, then I'll pick up on another project that I've been working on. Or lately that actually more often translates to reviewing somebody else's patch rather than working on something that I'm originating. I'm definitely not a morning person, so I'd say I probably do my best work in the afternoon. One of the things that is hard about this sort of working from home, I should probably back up about three steps here and say that the last time I went into an office on a regular basis was probably about the third or fourth year of grad school. Since then it's been almost exclusively working from home. So one of the bad things about that is it's quite difficult to separate work from not work. And that's why you often still find me responding on the mailing list in the evening hours. If I have a reason to go out of the house, I'll just continue to sit around and think about Postgres most nights.

CLAIRE: 01:05:18
My husband has commented that about me too. Ever since I started working from home, which would have been for me 2020, I wonder why that was. I already worked a lot, but he says I work more now than I used to. And it is that difficulty of separating it. But I think if you love what you do, I'm not going to feel guilty about that. Do you feel guilty about it? [Not in the least] Do you feel like it hurts you? Wait, you said not in the least or in the least? Wait, what did you say?

TOM: 01:05:56
I said not in the least.

CLAIRE: 01:05:59
Okay.

TOM: 01:06:00
So you enjoy it? I do. I mean, it's something I'm good at, something I enjoy doing. So, otherwise I would have gotten burned out long ago, I'm sure.

CLAIRE: 01:06:23
Would you describe your work on Postgres as more creative or more analytical?

TOM: 01:06:29
More an analytical kind of guy. I don't think of myself as being particularly creative. I have found that as things go on, as time goes on, I frequently am able to suggest ideas that other people maybe hadn't thought of. But it often feels to me like I'm suggesting something that's just obvious based on all my experience, rather than something being really novel.

CLAIRE: 01:07:15
I'm guessing that it's probably not just obvious to everyone though, just because your experience is so different. So what's obvious to you is potentially novel to someone else. And I think that works in all sorts of directions. We all bring our background and our history and our baggage with us that sometimes will make us see things that other people don't. So you think of yourself as more analytical, but I can't imagine how you do the work you do if it's not also creative. So we're just going to have to agree to disagree on that one, I suppose. I want to know if there's any favorite tools you use in your development work on Postgres, or any unfavorite tools too. What tools do you use? Period.

TOM: 01:08:15
Most of my development habits were set a pretty long time ago. I use Emacs for editing and mostly GDB for debugging. There are pretty standard tools like perf. I've occasionally played around with--not even sure what the word I want is here--visual development environments. I just never felt like that was the right thing for me.

CLAIRE: 01:08:56
OK, dumb question here. When you use modern day Emacs for editing code, does it have all the syntax highlighting that the IDEs have these days? Because I know back when I used vi for editing source code, there was no syntax highlighting.

TOM: 01:09:26
The main thing I rely on is it does auto-indenting and stuff pretty well. I actually don't like syntax highlighting. I find it hard to read. It's an eyesight kind of thing more than anything else.

CLAIRE: 01:09:46
You told me before you have a really big monitor. Is it just one or two? It doesn't matter.

TOM: 01:09:51
Just one.

CLAIRE: 01:09:52
OK. [Just one] So what do you do when you go on vacation and you want to bring a little bit of work with you? Maybe you leave it all behind. But if you did bring your laptop with you, do you also bring a monitor?

TOM: 01:10:08
No. I carry the biggest laptop I can get. These days it's MacBook 16 inch. I can work on that. I just prefer to have more screen space.

CLAIRE: 01:10:25
All right. So now, before we go back to Postgres, the technology, I'm also curious about time management. And you talked about how you do all that interrupt-driven work. First thing in the morning, you're looking at the mailing list over breakfast, over Cheerios, if I remember correctly. But are there any other time management techniques that help you get things done by, I don't know, whatever the deadlines are, the CommitFests, which happen every other month? Is that right? And obviously, the Postgres releases once a year and code freezes in the spring and the actual GA releases in the fall. And I'm talking northern hemisphere spring and fall there, I guess. But are there any other time management techniques that you've developed over the years that help you?

TOM: 01:11:23
I'm pretty awful at time management, I would say.

CLAIRE: 01:11:31
When I get sucked into a problem, I can get into the zone and just sit there and think about it for hours. Even if there's something else I should be doing instead. I'm glad that didn't happen today. [Laughs] I'm glad you're here and not sucked into a Postgres problem.

TOM: 01:11:55
That's because I have a calendar app. I do use that.

CLAIRE: 01:12:01
Okay. I actually think it's really cool when you are so deeply involved in a question or a problem or a project that you lose track of time. For me, it's a sign that you're doing the right kinds of work.

TOM: 01:12:19
Yeah. I mean, if you never find yourself doing that, then you have to ask yourself if you're in the right line of work, I think. At least for people like us who are fortunate enough to be able to be in this sort of job in the first place, you really have to look for something that just fits your way of thinking and fits what you find interesting to do. Because if it doesn't, you can go find something else that does fit you better.

CLAIRE: 01:13:04
All right. So let's pivot to Postgres for a second. You talked about the importance of reading emails and interacting with people who are actual Postgres users on the mailing list. But I know that there's no one setting a roadmap for Postgres, right? It's not so many software projects, particularly ones that are primarily run by a single company. There is someone setting direction, like saying this is going to be the theme of this release, or these are the kinds of features that are a must have for our enterprise customers or whatever. But Postgres doesn't have that. It's very, in many ways, bottoms up in terms of what patches get submitted. So how do you as an individual decide what parts of Postgres you're going to work on for each release?

TOM: 01:14:03
Well, I don't have a roadmap either. I mean, maybe I could develop one, but just it's not something that attracts me to have. I have relatively short term, well, usually relatively short term things that I think about and work on for a few months and that's done and I go on to something else. I can only think of one really large multi-year project that I've done in recent past, which was the thing to attach outer join nulling information to variables. I probably don't even want to try to explain what that is on this podcast, but it was something that took several years to get done. And there's fallout that's still being worked on by me and other people to actually derive the advantages that the idea has. Richard Guo has committed some stuff recently, for example, that fell out of that work. But mostly I prefer to work on smaller projects where you can get some gratification in the period of weeks or months rather than years.

CLAIRE: 01:15:35
Okay. Well, so that actually is a perfect lead in to, let's talk about how, if you were to step back and assess how your time gets spent, right? There's contributing as an author, as a developer, but you also spend time reviewing other people's patches, committing other people's patches, collaborating with other people on their work on the mailing list in particular. Do you have a sense of like percentage wise, how much time you spent in kind of each of those different areas of focus?

TOM: 01:16:16
Lately, it's been mostly reviewing and committing other people's patches. That's probably more than half my time. And then there's been another big fragment, just interacting with community that goes down to looking at people's problems and things like that. The things that I do that are totally my own work or just not that big a part of my day any more. I miss that a little bit, but until an idea comes along for something that I want to work on, it's hard to make that part the bigger part of the day.

CLAIRE: 01:17:12
And among the different things that you do, whether it's answering like pgsql-bugs emails, or reviewing other people's work, chiming in on the mailing list, do you have favorites? Are there things that you find more, I don't know, motivating or that make you happier?

TOM: 01:17:29
I still like designing and writing code the best. And helping improve somebody else's code is a little bit below that.

CLAIRE: 01:17:48
Okay. But obviously helping improve someone else's code is, I suppose the reason you do it is it helps you get scale. It helps the project get scale.

TOM: 01:18:00
Yeah, exactly. If the project were still the size it was back in the late nineties, we would not be anywhere near where we are today. So I have to spend a great deal of my time on helping out other people. It's just the nature of the beast.

CLAIRE: 01:18:22
All right. So I also wanted to talk to you about time zones. And this is something that I struggle with. Now there's tools where you can schedule an email to be sent at a particular time of day or schedule, I don't know, in my case, a Teams chat or a Slack chat or whatever it is to be sent later. But the Postgres community is global. Nighttime for you is morning for someone else. But some people, if they receive an email from you, might feel like they've got to jump on it now, even though it's Friday night at 11 PM where they are or a weekend or whatever. Someone gave me feedback once that said, "You really shouldn't send Teams chats to your employees after 6 PM because it makes them stressed." And I was like, "Well, but we work different hours and that's okay. There's no expectation that they respond when they're having dinner or when they're out with friends that night or whatever." But anyway, I struggle with it. So I'm wondering how you think about time zones and that whole giving people grace so that they can take a break from their work and they don't feel like they have to respond to you right away.

TOM: 01:19:48
Well, I certainly never expect that somebody has to respond to me right away. I think one of the big advantages of email is that it is asynchronous. You can send a message to somebody who maybe is on the other side of the world and is asleep right now or at least not at their desk. And when they get back to you, you will no longer be awake. So it slows things down a little bit, I guess, but it just is a good way to work for a project that's as spread out as we are. You just have to not expect there's going to be an instantaneous answer.

CLAIRE: 01:20:50
You mentioned something about friendships. I mean, you've worked on this project for 26 years. I'm assuming there's a whole bunch of friendships that have come up along the way.

TOM: 01:21:03
Mostly people I see at conferences. I've been going to conferences with them for, well, decades now. It's a big part of the reason why I stay in the community is I'm friends with a bunch of people.

CLAIRE: 01:21:30
Well, and when it comes to conferences, so I think it's fair to say that you're, not to stereotype, but you're more introverted than I am, I'm guessing. Would you describe yourself as an introvert?

TOM: 01:21:44
I definitely would.

CLAIRE: 01:21:46
Okay. But you still enjoy Postgres conferences. You don't need to be an extrovert to enjoy them, right?

TOM: 01:21:54
Well, uh...

CLAIRE: 01:21:55
I'm trying to lead the way.

TOM: 01:21:59
I enjoy them and I'm not an extrovert, so there you have it.

CLAIRE: 01:22:04
Okay. So, no, the reason I bring that up is I guess I'm leading to the fact that I think, for me, I feel so at home at Postgres conferences, which is pretty amazing given that I've only worked in this community for seven and a half years, compared to your 26 years. I don't have as many years in the boat. And to that extent, my friendships aren't as deep as yours probably are, but I go to these Postgres conferences and it's just wonderful. It's really cool. I think I've met people who are contributors to the community and they also feel like that, but I've also met a lot of users at some of these. I was just at PGConf New York City last week and PGConf.EU is coming up. It changes cities in Europe every year. This year, it's usually in October and this year it's going to be in Athens, Greece. PGConf.dev is where I last saw you in person, right? And that's the one that happens in Canada, usually in May. So I guess I'm fishing for if somebody is listening to this and they are a user of Postgres or maybe a new contributor, but they've never been, and they're wondering, should I go? What would you tell them?

TOM: 01:23:22
I'd tell you, yeah, if there is a conference that is convenient for you to get to, you should give it a try. This is, I think, a wonderful community.

CLAIRE: 01:23:36
All right. So I think I'm going to drop the link in for PGConf.EU in particular. I don't know if it's sold out yet or not. It usually does sell out before the conference day. But if anybody does listen to this after we publish in a couple of days and they're available the week of October 22nd and it's not yet sold out, I just want them to know about it. I also think that all the talks from this year's PGConf.EU are going to be, well, not all the talks, many of the talks, the ones where the speaker has given permission are likely going to be published on YouTube afterwards, which is pretty cool. Yes. And I just got confirmation from Daniel Gustafson. Talks will be recorded. There's another conference I'm involved in called POSETTE: An Event for Postgres. It's put together on behalf of or by Microsoft, but we have participation from people all over the world from all sorts of different companies. And what I like about that is it's all virtual. So you don't even have to travel to participate and to benefit. All right, I'll get off my talk soapbox now. So I suspect, Tom, that it's hard to remember what it was like to be new to the Postgres project because that was 26 years ago. And I certainly, there's a lot about 26 years ago that I've forgotten. And also the Postgres project is totally different now than it was in 1998. I hazard that there are more contributors, more components, more features, different tooling, like lots of things are different. But...

TOM: 01:25:21
Yeah, I think it's also our standards have gone up enormously. I remember that, you know, I've been around the project for probably not much more than about six months of doing a serious amount of work. And they gave me a commit bit saying "we're tired of committing stuff for you." And now, obviously, it's usually a multi-year journey for somebody to become a committer, which is basically because there is just a bigger amount of code now that you have to be familiar with in order to have a reasonable chance of not breaking things. So we have to be more careful. We use whatever tools we can to try to catch bugs. We have, that's why we have all this testing infrastructure that didn't exist back in the day. It's just a bigger, more complicated environment than it was when I got started. But I guess the advice I would give for a new person is to try to pick some small area to make a difference in and study that area. Pick something that you're interested in, that you have ideas about how to make better. And even then, start small. If you start with a very ambitious patch, it's going to take forever to get anywhere and you're likely to get burned out before you get done. So pick some relatively small idea to do first. And I talked already about getting feedback on the mailing lists about how selling people on your idea can help make it better. So that is how I would approach things, I think, if I were coming in new.

CLAIRE: 01:27:32
I think that's the thing that doesn't come naturally to a lot of people, particularly people who aspire to do really good work. It's very easy to toil away on your own to make sure that what you're producing is really, really good before you share it. And learning that hack, if you will, that, hey, sharing something early, even before it's polished and perfect, is going to yield something better in the end. And I don't know, it took me years to figure that one out.

TOM: 01:28:11
I actually can give an example. Very recent, something I'm still working on. Somebody complained on the mailing list that if they were writing an extension script and it had an error in it, that our reporting for that totally sucked. There's no context as to what the error was or where it was. So that's an instance of -- and I got interested in doing something about that, which is an instance of the pattern I mentioned before about listening to users. And I wrote a quick hack that was by no means meant to be committed and put that up on a list just to say, what do you think about doing something like this? And it's been through three or four iterations now and still not committed. So if you went and looked in the CommitFest, current CommitFest, you could find that link pretty quickly. But that I think is sort of development process works well in this community is to share something early and improve it over time rather than expecting that you can show up out of nowhere with a perfect patch. It's just really the hard way to do it.

CLAIRE: 01:29:45
I love that example. But it's still hard. Particularly if you feel like you're going to be judged. And maybe the idea still has warts or rough edges or hair on it. So how do you get past that? That notion that -- and it's public, right? It's all out there for everyone to see.

TOM: 01:30:14
Yeah. This goes back to the thing we discussed earlier. Of needing to develop a little bit of a thick skin. Because if you approach it wrong, you're going to take any comments on your idea or your patch as criticism. And that is not a good way to react to it. You have to understand that everybody wants to make things better. And if they comment on your patch and say, "Why don't you do it like this?" They're hoping to get to a better spot and you ought to respond to it in that spirit. The other thing that I'm not sure that people entirely get all the time is that, you know, frankly, an awful lot of ideas are not good. Yeah. You come along and say, "Why don't we do it like this?" And there are actually good reasons not to do it like that. So that's another reason not to spend too much time on something before you present it. So maybe somebody will shoot it down for good reasons. So it's just a mindset you have to adopt that, you know, you're looking for ways to improve Postgres and some of your ideas will be good and some will be bad and some maybe get to be good with some tweaking.

CLAIRE: 01:32:04
Yeah. I've often told people that in the kind of work that I do where English is my programming language now, right? No longer, other than, you know, YAML and HTML and some website stuff, I'm not an active developer anymore. But I'll often say my rough drafts suck. They're just really bad. But that's okay. And getting my rough drafts out there and getting that early feedback makes the end result so much better and gives me new ideas. And sometimes I'll pivot. Sometimes I'll just leave a lot on the cutting room floor. But yeah, you've got to have to embrace that mindset. All right. So if anybody's listening and they are a developer and they're thinking about getting more involved in the Postgres community, where would you point them? What should they go look at? We talked about the mailing list, obviously.

TOM: 01:33:13
We talked about the mailing lists. We have a thing called the CommitFest app, which is sort of a scoreboard of patches that are being worked on. If you're interested in, oh, I should back up here and say that one of the best things to do to help learn about the code, if you're a new person, is to review other people's patches. Because that will help you look at the code and look at what other people are doing. And along the way, you can actually make a useful contribution, even if you don't know very much. At the very least, you can say, boy, this is not obvious. Can you make it clearer or at least comment it better? So even in very small ways, like just testing a patch to see if it does what you would like it to do. So I would encourage new people to try to review patches. And the way to find things that are in need of review is to look at them on the CommitFest app, see what's going on there. We also have, I mentioned earlier, testing infrastructure. There's a thing called BuildFarm, which is a pool of machines running all different operating systems. And they're just continually running all the regression tests we have against whatever the current development tip is. So we keep an eye on that, see what's breaking BuildFarm. Let's see.

CLAIRE: 01:35:05
I know that in the last episode of Talking Postgres, we had Melanie Plageman here as a guest because she and Richard Guo, who you mentioned earlier, are the two newest Postgres committers. They were both invited to become committers earlier in 2024, back in April, if I remember correctly. And Melanie said she does a ton of learning. She's a runner apparently. And she does a lot of learning by downloading conference talks from Postgres conferences and listening to those as she's running and listening to some of the Postgres podcasts as well. So it's a way she can get two things done at once. I don't know if that'll work for some people. But I thought I'd throw that out there. Well Tom, unless you have other tips about ways to learn more, I have made it through all of the topics. I mean, we went through a lot of chapters, right? We talked about high school, your undergraduate years at Carnegie Mellon, Hewlett-Packard years, grad school, the Coke machine, Structured Software Systems, libjpeg, and then Postgres. And I really appreciate you taking the time to walk us through kind of how you ended up here. And I suppose if I'm going to ask one last question, it would be if there's a favorite part of the Postgres community or something that is like a magnet or an North star that kind of keeps you coming back to Postgres day after day besides the paycheck from Crunchy Data to do so.

TOM: 01:36:52
Oh, I don't know. I just, hold on a second. My cat's doing something weird over here. I'll be right back.

CLAIRE: 01:37:04
No problem. I'm allergic to cats. So maybe one of the benefits of this, this podcast being recorded remotely is that I don't have to be near your cat.

TOM: 01:37:15
Right, okay. He's stopped. He was making a distressing amount of noise for a little while there. No, just, you know, I enjoy being part of this community. I enjoy working on this code. I don't have anything deeper than that, I'm afraid.

CLAIRE: 01:37:41
So the technology and the people, and all these longstanding relationships. Cool. All right. Well, I want to say thank you, Tom, for joining us, and the next episode, Episode 21 of Talking Postgres is also going to be recorded live and that will be on Wednesday, November 13th at 10 AM PST. Because we will have changed time zones by that point in November. The guest is Andrew Atkinson and the topic in November will be helping Rails developers learn Postgres. So if you want to mark your calendar now to be part of that live recording, you can go to aka.ms/talkingpostgres-ep21-cal You can also go to past episodes and links to subscribe on all the different podcast platforms at talkingpostgres.com and transcripts are included on the episode pages on talkingpostgres.com too. And before we leave, if you have enjoyed this podcast, and I hope you have, please tell your friends, in person, social media, however you share your recommendations to your friends and your followers. If you use social media, the hashtag is talkingpostgres, all one word. And word of mouth is definitely one of the best ways for people to discover this podcast. And a big thank you to everybody who enjoyed the live recording and participated in the text chat today on Discord. Thank you, Tom. It's a wrap.

TOM: 01:39:16
Thank you.