CoRecursive: Coding Stories - Story: Software That Doesn't Suck With Jim Blandy

Episode Date: July 1, 2020

Building Subversion Software is just the tool and it should get out of your way. In this episode, we will discuss Jim Blandy’s insights on how to build and recognize improvements for a great developer tool and find out how he approached the question: “What's the worst software that you use every day?” “Everybody likes imaginary code because imaginary code is always perfect.” -Jim Blandy “You don't want to maximize engagement with your version control system. You just want it to do its job and get out of the way. And so basically if somebody says, you know, this doesn't suck. That's actually pretty much exactly the right thing.” - Jim Blandy “If you're making a series of small incremental changes to a large data structure, then the way that the persistent data structures are trying really hard to share as much data as possible really works in your favor.” -Jim Blandy Episode Page Episode Transcript Links: Subversion Jim's Email Mercurial  GNU Emacs

basically there was a co-worker of mine who said CVS's repository is indexed backwards. Right. It's, it's the CVS's repository is the software equivalent of a telephone book sorted by telephone number. And so, but, and so that's a funny, that's a funny lunch comment. Right. And basically I was just thinking about it myself, you know, doing the dishes every night. But the thing is, you can't just the dishes every night. But the thing is, you can't just accept something like that. You have to say, well, wait a second, if CVS is backwards, what would it look like if it were right? Hey, welcome to Co-Recursive. I'm Adam Gordon-Bell. Today, our topic is what would it look

like if CVS was not backwards? CVS is a source control management tool. Think of early 90s Git. Jim Blandy is my guest, and he brings us the story of making CVS better. I would guess that a number of features of your current source control tools that you probably use every day were influenced by Jim's work. I also think he has some interesting insights on how you build great developer tools, and also how to recognize when some improvements to the existing tools would topple the current market leader, something that he's done twice. Verify that you have the right one in Zoom. Yes, I have verified that I am using the right one in Zoom.

Do you want to stay focused on the version control side of things or? Okay, well, let's see where we go. We'll just tell the story. We start the story, the year is 1993. It's the year the Mosaic web browser came out. Email had been around for some time, but the web was fairly young. And CVS was the most popular open source source control system. So I went on this trip that I was going to go on in Europe and Japan,

and I came back to the U.S. and I had no job and no apartment. And my friend had gotten a job, my friend Carl Fogel had gotten a job working at the University of Illinois, Urbana-Champaign, on a gene editing mode for Emacs. And this is in Emacs, you visit a file that's full of genetic data and Emacs will bring it up and it'll apply colors to it. And you can like select, you know, rectangles and stuff like that. But he was living in Illinois at this lab at UIUC. And I was living in Indiana. And so we were collaborating across the net. And this was 1993, right? And so the way you collaborated across the net was you shipped

people patches, you emailed people patches, you FTP'd your sources. Network transparent version control was not a thing. But I had a friend, an old friend from college, who'd gone to work for a Silicon Valley startup, except he didn't want to live in Silicon Valley. He wanted to live on a commune in the hills of Virginia. And so they ran a frame relay line out to the commune, because, you know, rural telephone access, right? And there he was on this commune and everybody else was making hammocks and nut butter and he was

hacking on code for Silicon Valley. And so his income was probably a significant portion of the whole commune's income. But so there he was and he realized that it was kind of lousy doing this collaboration at a distance. His name is Jim Kingdon, and he was just an amazing hacker. And he sort of disappeared from the world after this, and I don't know why, because he's amazingly talented. What he did is he took the CVS version control system. This is, like I said, this is 93. It was designed for a situation where you have lots of people using the same computer. And so you have your CVS repository and one part of the file system that's shared by all the users.

And then people are checking out copies of the tree into their own home directories, making local changes, doing updates, doing commits, right? And so they're doing all of this activity, but it's all on one machine, right? It's all one local file system, right? Because people would share their computers back then because that was what you had to do. And so what Jim Kingdon did is he took this CVS version control system that was designed to work locally only. And basically by sheer forceized round-trip times to keep latency down and all this just amazing stuff, right?

It's a program that wasn't designed to be a networked program at all, and he turned it into a networked program. And then he used Kerberos for authentication, right? So this was like real network security back in 1993, right? And then he used it for collaboration with the startup that he was working for, which was Cygnus Solutions in Silicon Valley. And so, you know, it was this amazing thing, but he didn't publish it. He just used it.

He wrote it for himself and for maybe other people in his company, and then he just used it. And so I had heard that he had done this. And here I am trying to collaborate with my friend Carl in Illinois. And so I wrote to him and I said, hey, do you think I could get a copy of this code? And he says, oh, yeah, sure. But on one condition, you can't ask me any questions. Because basically he doesn't want to get into the support thing.

I think this is probably why he didn't publish it in the first place. That makes sense, yeah. And so I said, oh, yeah, sure, fine. Give me a copy. And so he sends me a tar ball of it and of the sources and so immediately i asked him a question he's like i told you not to ask me any questions and so carl and i started using it we're like holy cow this is amazing right because you set up a server on some machine somewhere and you do a checkout and you get the sources and then you work locally and nobody gets in your way. And then you just commit and poof, it's there for everybody else to see, right? It's just a whole new world. And so, you know, we were just blown away at how much better it was to collaborate over the net using network transparent CVS. So since CVS is GPL, Jim takes these improvements,

and he releases them to the world as a fork. At first, the official CVS, the mainstream CVS distribution was like, Oh, yeah, interesting work, but we have our own ideas about how we're going to do things. Because nobody likes existing code. Everybody likes imaginary code, because imaginary code is always perfect. Yeah, and you're like, we already have this. It's done. You can use it. Yeah, you could use it, but they didn't want it

because they wanted to do their own thing. But after a few months, it becomes clear that they don't have network transparency and we do have network transparency. And basically everybody is switching over to cyclic CVS, which is what we called it. And they capitulate and they say, okay, I guess we'll merge your changes. And that is how network transparent CVS came to be. And, you know, within

a year, all of the open source world was using this. Because when you think about the kind of collaboration that has to happen with open source, you know, it's all distributed teams. It's people from everywhere. You get volunteers, you have no idea where they're coming from. There's no physical locality to it at all. And it took over the open source world by storm. And within a few years, pretty much CVS was the standard. This network transparent CVS became such the standard, both in open source and in the corporate world, that Jim got some interesting contracting work, just helping people understand how to use it. One of the biggest thrills I ever got was when I was just going around to different companies and government

groups and teaching them how to use CVS. And I got an invitation to teach for a few days, I think it was a three-day course, at the Goddard Space Flight Center out on the East Coast. And so here I was, you know, teaching these folks who were doing satellite development and doing weather analysis. And I remember one day over lunch, one of them said, you know, we've been having this bug with CVS. I wonder if you could help us out with it. And so I said, sure. And so we walked down to his cubicle and he says, well, okay, here. And so he just checks something out.

He just checks out a tree with CVS. And I say, well, okay, here. And so he just checks something out. He just checks out a tree with CVS. And I say, well, what is it? And he says, oh, this is stuff that analyzes satellite data, satellite images to analyze hurricanes and predict where they're going to go. And there was just something like just seeing that checkout, right? CVS listing each file as it downloads it from the server and checking it out. It's like, whoa, I'm actually helping people do stuff, you know? Right? Here's this person who is just trying to, you know, track hurricanes, right?

And because we made this thing, they were able to do that, right? That is a really exciting feeling, right? That they're not really interested in your software. They're just using it to get something done. And that because you were there, they were able to do it. Jim and his buddy, Carl, they don't let this good opportunity go to waste. So they start a business, Cyclic Software, that offers support for Cyclic CVS for network transparent source control. Our little business failed to die in the first four horrible ways that businesses always die. We paid ourselves a salary. We earned back our initial investment. We actually made a little bit of money beyond that. And we had customers. One of our clients was Goldman Sachs.

It turned out that Goldman Sachs was using CVS internally, and they really liked network transparent CVS. And so Goldman Sachs wanted us to port it. I think they wanted reserved checkouts or something like that. And so we, here we are, are two guys basically we're grad student age and we're like okay we're gonna write a contract with goldman sachs and so we go consult a lawyer and stuff like that and we send goldman sachs our little contract right you know and they their their full legal department comes to bear on this thing and our everything that we wrote

them becomes exhibit a and and and then they have this big you know whatever is 15 pages of boilerplate that we have to uh it was all they fax it to your they fax to your lawyer is that well they fax i think they if they emailed it to us or they or they maybe they maybe they snail made it they snail mailed it to us i think those are the days you know uh so yeah but it fax would be reasonable we might have had a fax machine. But anyway, so I'm reading through this contract. And then I get to paragraph 15. And it says, contractors agree to submit at Goldman Sachs' request to drug testing.

I don't know where this comes from. So Carl and I are about as square as you could possibly get. I mean, we don't, we don't even drink, right? Not, not because of any, you know, moral issue. We just, we just don't, right. Uh, that's just not our style. And so, you know, we would have, we would have completely passed any test that they'd ever, they could ever get us to take, but also that's just obnoxious, right? What, what do they care? So I go back to Carl, I walk back into the other room carrying the contract and say, Carl, they want us to take drug tests. And Carl says, oh, we won't sign that. We can wait tables. And I'm like, you're the best. And so we write Goldman Sachs an email back and say, this looks great.

We're ready to sign it. However, paragraph 15 has got to go. So without any comment at all, we just get back another copy of the contract from Goldman Sachs with that paragraph gone. And we sign it and we do the work. And that was that. But we did hear from the hackers at Goldman Sachs later, the people that we ended up doing the work with. They told us later, it's like, nobody's ever done that before. Nobody ever complained about that.

That was cool. So, yeah, that was kind of nice. And that's the kind of thing that you can do when it's just the two of you, right? I mean, if I had had a family at that time or, you know, if we'd had employees, right, then you start to have to worry about other people, right? And it's like, it's not just, you know, your choice to do something or walk away. But when it's just the two of you, it's really nice. You can really just do whatever you please, and you don't have to do anything you don't want. So let's fast forward. The company was a success,

but eventually they move on to other things. And Jim joined Cygnus Solutions, where he was using CVS every day. And he starts to notice certain things about the tool that he does not like. So this is actually interesting. Like when you think about a repository, like a Git repository or something like that,

you think about it as a database. It's a database where you put in commits and you check out trees. And one of the most common things you're going to want to do in a version control system is you're going to say, hey, I have this version of the code and I want to pull all the changes that have happened since then. So please send me the diffs between this prior date

and this current date. Right? Okay. And ideally, if only three files have been touched between this, the old date and the new date, you should only get data about those three files. And the backing database should be organized in a way that makes that efficient, because these are very common things. This is a diff query, a diff between two revisions. This is a checkout. This is a merge. This is the common operation. was as a gigantic directory tree shaped the same way as the sources that you were managing, except that each individual file was an RCS file that held all the different revisions in it,

right? And there was no connection between the set of revisions stored in one file and the set of revisions stored in another file. If you did a commit that touched two files, there was no indication anywhere in that data that those two files, that those two commits had anything to do. They might have the same log message and the dates on them would be about the same, but there was no indication that that was a single atomic commit, right? That is something that we take for granted right now. Atomic commits. Without atomic commits, you can introduce inconsistency issues, especially if somebody is doing a slow operation, like creating a branch, which is going file by file,

and somebody else is pushing changes at the same time. You're not guaranteed that the branch will get all the files from the commit since they're happening in parallel, interleaved. Also, in this case, the lack of being structured as an atomic commit actually made the implementation slower. And so when you did a CVS update, the way CVS decided which changes to ship to you was it would scan the entire directory tree. It would open up every single file in the directory tree to see whether this might have been changed since the date that you asked. And actually what you had to do when you did an update, you had to ship to the

server the current versions of all of your files. And then it would actually check to see whether any of those files that do versions, and then it would ship you the diffs back. Right? So that's terrible, right? Suppose you've got 10,000 files, but only three of them have changed. You have to check every one of those 10,000 files when somebody does a pull, because the data is organized in a way that doesn't give you any sort of centralized indication of what changed. Well, the performance was so bad that when Cygnus Solutions, when they wanted to cut a branch, they would announce it ahead of time. They would schedule the branching

because you didn't want anybody else committing while you were branching because that would totally screw things up, right? And they'd say, okay, Friday at 2 p.m., we're going to cut the branch. And then all activity would stop. Access to the server would be cut off. They would start the branch. Now, remember, this branch requires walking through however, you know, 100,000 files you've got.

You know, Cygnus did GCC, GDB, GNU Assembler, GNU Linker, basically the entire GNU toolchain work. And so they had, you know, hundreds of thousands of files. And so they would walk across these hundreds of thousands of files and make a branch in every single one of them. And it would take like, you know, 45 minutes to cut this branch. And then you'd say, okay, we've opened up the branch, everybody can start working again. Right? That's crazy. That does seem a bit crazy, right? Jim is talking about how in CVS, the performance degraded based on the size of the repository,

not based on the size of the change set. This is something we kind of take for granted today, but now source control, the performance is related to the size of the change set. Change one file, that should be cheap. Change all of the files, that should be expensive. And branches, you're changing no files, that should be free. So Jim had been thinking about this design for a better system. And his buddy Carl, he got approached by a company looking to shake up corporate development by introducing ideas from open source software development. This was around the time that the Cathedral and the Bazaar essay was being written. There were a lot of companies that were saying, wait a second, why isn't our internal

software development as dynamic as what we see going on there? What is it about that dynamic that makes it work so well out there? And how can we bring that into our own in-house development? But what CloudNet was interested in doing, they saw CVS and they knew that it sucked and they were willing to fund writing a replacement for it. And so they approached, they approached Carl or Carl approached them. I don't know exactly how that happened, but anyway, they ended up working with Carl and we started, uh, Carl and I had already started drafting ideas for a replacement for CVS because there's something that a friend of mine said to me once, CVS is the worst piece of software I use every day. And that's a very interesting sentence

because it's got the word worst in it, right? This is the worst piece of software and it's got the word every day in it, right? It's like, if it's so bad, why are you using it every day? The answer is, I need this so badly that I'm willing to put up with the crap. When somebody says that about a piece of software, that's a good target for a rewrite. This mythical rewrite that Jim started planning, he called it Subversion. And he started talking about it with everyone.

This whole thing predates Git and Mercurial by five or six years, by the way. And so when I told the Cygnus people, oh yeah, I think Subversion's going to be able to cut branches pretty much instantaneously in constant time, they didn't believe me. They said, well, we'll believe that when we see it.

Cutting a branch cutting a branch is nothing it's it's it's just creating a name for a particular revision uh you know it's a free operation and so that was a big it was a big deal uh so yeah so we we had already started working on this new design for subversion and then collab net said this is great we'll fund you and we'll get other people to do the network stuff for you. There's a step missing or something. Like, when did you have come up with this design?

And did you like, what, email Carl and say, I have this idea or? Yeah, it was the design for the repository. Basically, there was a coworker of mine who said, yeah, CVS's repository is indexed backwards, right's it's the cvs's repository is the software equivalent of a telephone book sorted by telephone number right it's it's just exactly the wrong thing and so that's a funny that's a funny lunch comment right there was somebody says it and you're like oh that's funny that's really true and then but the thing is you can't just accept something like that.

You have to say, well, wait a second. If CVS is backwards, what would it look like if it were right? What's the proper organization for a version control repository? And basically, I was just thinking about it myself, you know, doing the dishes every night, and I ended up coming up with a design that actually other people have come up with. It's not original to me. I hadn't read about the other things,

but it turns out that I think Perforce actually has a very similar repository structure to Subversion. But basically the idea is that you want to share whenever you have a commit, right? And the commit changes, say, one or two files. You want to recognize that the directory tree before the commit and the directory tree after the commit are almost identical. The only difference between them is that there are these two files that have changed. And so what you actually want to do is you want to share as much of the structure between those two trees as possible. Go ahead and represent both trees, but have them share as much structure as possible. Right?

It sounds the same as like a persistent data structure. Yeah, yeah, yeah. You mean persistence in like the way functional people use that word. Yeah. This is a persistent, persistent data structure, right? The terminology is very confusing, I think. It's persistent in the sense that it's saved to disk, right? And it's not going to go away when you exit the program.

But it's also persistent in the functional programming sense. Yeah, if you have an immutable tree in your programming language of choice, when you make changes to it because it's immutable, it will make a copy but only of the elements that you need to change and update the pointers.

Exactly. Have you ever heard of Chris Okasagi's book, Functional Data Structures? I've seen the picture of it, and one of my friends bought it and said he couldn't understand it. That's too bad. Yeah, because Chris Okasaki goes into all this stuff, and it is hard to understand. But once you get it, it's kind of mind-blowing.

I think it's a worthwhile investment, because a lot of those algorithms play well with incremental contexts, right? That is, if you're making a series of small incremental changes to a large data structure, then the way that the persistent data structures are trying really hard to share as much data as possible really works in your favor. So you have this idea, and what happens next? Well, so I had this idea, and Carl and I had started working on it.

And then Carl gets this funding from CollabNet. And so that's fantastic. And suddenly we have a guy who's a web dev expert to do the protocol for us. We end up getting an office in Chicago. So I'm traveling up from Indiana up to Chicago to meet with Brian Fitzpatrick and Ben Collin-Sussman. And we agreed early on that we wanted to break it up into a nice reusable set of libraries. So there's going to be, if you want to work with subversion working directories, here is the working directory library that accesses all of our metadata. If you want to speak the protocol, here's a library that

does the protocol. If you want to, you know, have different backends for storage, you know, here's the interface to the backends. So you had your design and then what, there was a couple of you working on it and. Yeah, there was about five of us, I think. Did you split it up into modules and you're like, I'll work on the working directory part and. Yeah, I was working on the server part. Some other people took sort of the command line part.

There's somebody who took the working the the working directory uh library and things like that and so i think i think that you know for another kind of project you have to be much more careful because there's drift between one person's understanding of the design and another person's understanding of the design because the thing that you're building doesn't exist yet, right? Yeah. But in the case of Subversion, we had this very clear goal, which was to become a properly designed modern CVS, right? Network Transparent CVS. And the fact that we were imitating or replacing something that already existed, I think, created a lot of clarity in people's minds. And so I think it actually was a project that could be undertaken with a lot less coordination than you would normally need for something that size. Yeah. That makes sense. You like,

not only did you have an existence proof of something like this existing, like you knew it well, you were using it. I assume you were using it for, for subversion source control. Yeah. We had to, we had to use CVS at first. But then, you know, there was the day when we started being able to dog food. And that was a really great day, right? How did you guys like celebrate? Like if you were all distributed, did you?

Oh, we would go up to Chicago. We had this great office in, I think it was called Printer's Row in Chicago. It's a whole bunch of old buildings that all used to be full of printing presses for newspapers and stuff. And they had this cage elevator where you could see the elevator shaft through the iron bars of the cage. And if you looked down, you could see these gigantic relays that controlled the elevator. And it was a relay-driven elevator. And, yeah, oh, we partied.

I would drive up to, I would drive up to Chicago quite frequently. And, uh, we had a bet that whoever wrote the first security hole had to buy everybody else dinner. And so that was, I don't know if you want to call that a celebration or, you know, losing a bet or something like that. But yeah, so I worked on it for a year. But then I actually found it kind of exhausting. And so after a year, I really wanted to go back to working on GDB. I think Subversion started self-hosting within the next year after that. So Jim's design for a new version control system succeeds. It takes over the world, Subversion. Atomic commits, free branching, performance proportional to change size. These were all great changes. It quickly replaces CVS.

And then it rose to its heights within three or four years, I think. Um, but it was really nice. We got, you know, recommendation by these, you know, these consulting newsletters, like the Gartner group gave us a, you know, listed us as an essential tool or best of the breed or something like that, which is really funny because it's like, you know, we didn't do marketing research. We don't have any idea. We just know what we want as hackers.

And then you have these, you know, very serious businessy industry newsletters recommending you. And it's kind of ridiculous. The Gardner Quadrant or something? They probably had a graphic that showed. Yeah, it was exactly that. We were in the good quadrant right uh it was crazy but but yeah it was probably like somewhere there was a meeting of people in suits like figuring out like how far to the left you should be and how far to the right

yeah and it's very silly to have those people's attention you know but uh that's that's the way it works but within five or so years, it started being replaced by other version control systems, by Git, by Mercurial. And although probably some people are still using Subversion right now, Jim really doesn't think they should. Yeah, they shouldn't be. I mean, yeah, I actually had somebody come

and try to talk me into consulting about Subversion for him because he had this great idea about how. But in the end, I tried to really talk him out of it. I said, it's not people aren't developing it anymore. It's not actively supported. When you bring in developers, when you want to hire developers to work on your project, they're not going to know it, but everybody will know Git. I was in a funny position of trying to talk somebody out of using something that I was one of the original designers of. But yeah, I don't think anybody should be using it anymore. I mean, are you sad? I have Git. I have Mercurial. How can I be sad? I don't know. Yeah. I mean, the nice thing was that it set

a standard of usability. I think Subversion, at the time that it became popular, it set a standard of usability below which people just weren't willing to put up with, right? Git started out with a terrible CLI, and now it's only a mildly horrible CLI, right? The options are only sort of ferociously confusing and not overwhelmingly confusing, right? Yeah. And I think that that's a response to pressure from well-designed interfaces like Mercurial, which has a beautiful CLI,

and Subversion, which has a very fine CLI. So I think that you could have your influence in a lot of different ways, and that influence outlasts the use of the actual code. So Subversion is 20 years old this year, and Jim, he doesn't want us to use it, but its influence is still out there. A question I wanted to ask Jim was,

if Subversion was addressing shortcomings in CVS, what were the shortcomings in subversion that Git helped address? You know how Git uses content hashes to identify file contents and to identify directory contents? And it's a very beautiful model. And those hashes are really uh essential to the distributed nature of git because it means that basically if you've got data it doesn't matter how you got that data everybody can tell that you've got this branch and you don't need to be sent that data anymore somebody suggested that subversion do this what we were actually doing is we were just assigning fresh numbers to the nodes as we created them. And so somebody basically said, well, we should be using content hashes.

And this is the worst decision I've ever made, I think, in terms of impact. I said, no, we shouldn't do that because if you do a rename, if you modify a file and do a rename, there's no way to tell that the old version of the file and the new version of the file are related at all. And the only kind of indication that I can cite for this is that even now, Git doesn't really know about it. It just sort of looks at the file and says, yeah, they look close, seems to be. And then basically you give it some cheesy parameter that says how hard it will try to look for them, right? And it's such a kludge.

And it just reconstructs them post facto. So it doesn't even know anything about what happened. It just sort of guesses that this must be a rename of that, even if it's not. It's a total kludge. You know, when I started using Git, people were talking about this distributed case, and I guess it does happen. But the big thing that seemed different to me was just like merging was like free all of a sudden, merging and branching. And so you're the guy to answer this, I think. Why is that, right? It doesn't seem like there's some reason that distributed makes merging better.

No. Except you have to do it a lot. No, this is kind of a sad story. The great thing about merging in Git, and I'll just pick that as an example, but Mercurial is the same. The great thing about merging in Git is that it's just like, what is a merge? A merge is what I say it is, right? I say, I have this parent and I have that parent. And now here's a new change set that's got both of them as its parents, right? There's no restriction on what a merge means.

The mistake that we made in subversion is that we thought merges should actually mean something textually, right? That actually there should be a way to say, here is the reconciliation of these changes with that change. And I think we really just overthought it a lot. All you need to do is have some good textual merge tools that use whatever heuristics they want. Whatever heuristics work well for your project. We'll have some off-the-shelf mergers that do a great job in most cases, but if you want to have

a specialized tool, you just drop yours in. You can do whatever you want, and then when you say it's okay, that's the end of the story. It's interesting. Almost what problems you decide not to take on can kind of define things, right? Very true. Git just punted on this. They're like, let's not worry about it. Yep, absolutely. Absolutely.

So better merging of branches. You know, Git was distributed. It had content hashes. But better merging was really the big difference. Subversion was huge in its time, though. I imagine being the developer behind the tool that most other developers are using many times a day must be like being a celebrity. Jim said it wasn't like that at all, though.

Although I do remember one time that I had moved on to another company and we were using Subversion to hold a copy of the entire GNU toolchain, GCC, GDB, BFD, the Linker, Assembler, so on and so forth. And I think also a copy of the entire GNU toolchain, GCC, GDB, BFD, the linker, assembler, so on and so forth. And I think also a copy of the GNU C library. So it was a very large repository and we used it every day and it was fine. And the founder of the company said to me one day, you know, Jim, subversion doesn't suck. And he said, I hope you understand the way I mean that. And I said, oh, no, no,

I definitely get what you mean. Yeah. Thank you very much. I'm proud. The greatest of compliments. It really was though, right? What more do you want than to have somebody say, I use your stuff every day and it's okay. That's, that's like... I want more. I want more than that. Well, I don't know. Everybody wants to get five stars

or everything like that. I mean, when does anything actually five stars, right? Like, if I go to a bike shop and I'm trading in my bike and they treat me decently, right, I give them five stars

because that was what I wanted from the transaction. But it's not like I'm skipping home, right? Yeah. It's just a transaction, right? I give him five stars because that was what I wanted from the transaction, but it's not like I'm skipping home, right? Yeah. It's just a transaction, right? And I think a lot of software, right? It's, it's there to get, help you get your work done. It's here to help you get through the day. Especially at developer tools, right? A tool, like just by definition, a tool, like you don't want your hammer to do something crazy. You want it to hammer. You don't want to maximize engagement with your hammer, right? That's stupid. You don't want to maximize engagement with your version control system. You just want it to do its job and get

out of the way. And so to basically address somebody to say, you know, this doesn't suck. That's actually, that's actually pretty much exactly the right thing. All right. That was Jim, the first three-time guest, writer of software that doesn't suck. The thing about Jim's story that will stick with me, besides the guy at the commune, you know, making nut butter, but also building distributed software. The thing that will stick with me is Jim's question. What's the worst software that you use every day? Also this idea that software is just a tool and it should get out of your way. That's interesting. Nobody ever says that, right? Everybody wants to change

the world. He's like, I just try to build things that don't suck. If you liked this episode, if you like the podcast, tell your coworkers, I don't really know how podcasts spread. People say word of mouth. So tell your friends, tell your friends, tell them to open up their podcast app, search for co-recursive or, or search for Adam Gordon bell and hit subscribe until next time. Thank you so much for listening.