The Changelog: Software Development, Open Source - Stacked diffs for fast-moving code review (Interview)

Episode Date: May 27, 2022

This week we're peeking into the future again — this time we're looking at the future of modern code review and workflows around pull requests. Jerod and Adam were joined by two of the co-founders of Graphite — Tomas Reimers and Greg Foster. Graphite is an open-source CLI and code review dashboard built for engineers who want to write and review smaller pull requests, stay unblocked, and ship faster. We cover all the details -- how they got started, how this product emerged from another idea they were working on, the state of adoption, why stacking changes is the way of the future, how it's just Git under the hood, and what they're doing with the $20M in funding they just got from a16z.

this week on the changelog we're peeking into the future again this time we're looking at the future of the pull request workflow and we're joined by two of the co-founders of graphite thomas ramirez and greg foster graphite is an open source cli and code review dashboard built for engineers who want to write and review smaller pull requests, stay unblocked, and ship faster. We cover all the details, how they got started, how this product emerged from another idea they were working on, the state of adoption,

why stacking changes is the way of the future, how it's just get under the hood, and what they're doing with the $20 million in funding they just got from Andreessen Horowitz. For our most loyal listeners who want to skip the ads and get a little closer to the metal, check out our membership at changelog.com slash plus plus. A massive thank you to our friends and our partners at Fastly for making our podcast super fast globally. Check them out at fastly.com. This episode is brought to you by our friends at Influx Data, the makers of InfluxDB.

In addition to their belief in building their business around permissive license open source and meeting developers where they are, they believe easy things should be easy. And that extends to how you add monitoring to your application. I'm here with Voyjciech Kajan, the lead maintainer of Telegraph Operator for Influx Data. Wojciech, help me understand what you mean by making monitoring applications easy. Our goal at Influx Data is to make it easy

to gather data and metrics around your application. Specifically for Kubernetes workloads where the standard is Prometheus, we've created Telegraph Operator which is an open source project around Telegraph which is another open source project that makes it easy to gather both Prometheus metrics as well as other metrics such as Redis, PostgreSQL, MySQL, any other commonly used applications and send it wherever you want to. So it could be obviously in FluxDB Cloud, which we would be happy to handle for you, but it could be sent to any other location like Prometheus server, Kafka,

any other of the supported plugins that we have. And Telegraph itself provides around 300 different plugins. So there's a lot of different inputs that we can handle. So data that we could scrape out of the box, different outputs, meaning that you can send it to multiple different tools. There's also processing plugins such as aggregating data on the edge so you don't send as much data. There's a lot of possibilities that Telegraph could be used to get your data where you are today. So we've permitted metrics, but you can also use it for different types of data. You can also do more processing at the edge and you can send your data wherever you want. Voychek, I love it. Thank you so much. Easy things should be easy.

Listeners, Influxdata is the time-series data platform where you can build IoT, analytics, and cloud applications, anything you want on top of open source. They're built on open source. They love us. You should check them out. Check them out at influxdata.com slash changelog. Again, influxdata.com slash changelog. Again, influxdata.com slash changelog. So we've got Tomas and Greg here from Graphite. Welcome to the show, guys. Thank you. Good to be here.

Thanks, Jared. Excited to be here. We're excited to have you. You're working on something very cool and very right in our wheelhouse. Code review tooling. So Graphite is your company. Still early days. Join the wait list kind of situation as we record. It's an open source CLI and a code review dashboard

built for engineers who want to write and review smaller pull requests, stay unblocked, and ship faster. If that sounded like I did it very well, it's because I'm reading it off your homepage. You're reading, Jared. I'm just reading. I'm not just coming. You did it well. Very well. I'm actually pitching to be on your marketing department. I feel like that's a pretty good pitch. I'm going to be honest. I heard the pitch and was like, wow, he's really got this stab. And then he told me you're reading. I'm like, well, that's because we wrote it. So. Yeah. That sounds really good. Their little secret. If you want people to like you,

just repeat their own words back to them. They'll tend to like you. So take us back to the beginning of Graphite and maybe a little bit of how you two met, the backstory. There's a college involved, I believe. There's Facebook. There's Airbnb. There's all these engineering jobs you've had and then brought you here. Give us the quick version and we'll find out why you're building these kind of things.

Yeah, I can speak to that a little bit. We have three co-founders. We have Tomas, myself, and another guy named Merrill. All of us have been friends since college. Merrill was a couple of years older than us, but we were all in the same computer science clubs. Tomas and I were in the same year. We were project partners on nearly every class in college, late nights doing operating systems, just getting beaten up by algorithm problem sets. And every summer we'd be interning out in San Francisco, sharing housing, going on adventures. I think during our junior year, actually, I was talking to Tomas and I was saying, wouldn't it be cool if we got internships out in New York and we tried out a different city? San Francisco is very cool, but New York sounds amazing too. Tomas thought it was a good idea. And I lined up a Google internship. He lined up a Facebook internship. And then very last minute, I swapped my Google. They said, hey, you know, we got this kind of boring Google Docs

team in New York, or you can be on this cool prototyping team in Area 120 in San Francisco. And I said, you know what, Tomas, last minute, I think I'm going to go take this even better team in San Francisco. Fast forward, Tomas is out in New York full time, still working with Facebook. Him and Meryl are spending time every weekend talking about startups. I'm out in San Francisco still, this time with Airbnb. And it really wasn't until we started Graphite that I got to complete the circle and finally get pulled into New York, work with people I love, and a very exciting city on a product I love. Yeah. And what's funny, Jared, to answer your

question, when we started this company, we didn't actually start as Graphite. So we started as Screenplay. The idea of Screenplay was to help you roll back iOS apps the same way you can roll back a website. So let's say you push out a bad update to the store. You realize like, oh, that's actually broken. It's crashing on users. Give you just a feature flag to revert it by packaging it with the old version of the app and then doing some deduping to get the app size down. It was in building that, that we started

to actually think, hey, like, we need some developer tooling ourselves. At that point, we were fortunate enough, we had had one of my old teammates, Nick, join us. And Nick and I coming from Facebook, which had had different code review tooling, sort of looked at GitHub with, I'd say a set of fresh eyes. And we're like, yeah, like there's, there's some stuff from Facebook. We miss, we, we get how this works. We tried to force ourselves to use it for quite a few months. And then we were like, well, let's give a shot at building some of the things we had or tooling inspired by what we had a shot. And this was back in probably like January, February of 2021. The whole early part of this company was an experience. I mean,

we unintentionally started like day one of the pandemic. Uh, company was an experience. I mean, we unintentionally started like day one of the pandemic. We, cause we, you know, we, as, as, as co-founders and friends do, we had been talking about working together and starting a company and we put in our notices like three months in advance and we leave our jobs and like set out and we start shaking hands with venture capitalists. And literally like the weekend we quit, the weekend and the week we start raising was like March 15th of 2020. Like everything's closing down. Like we're in the,

we're like the final meeting in the room in San Francisco. We're like bumping our flights up earlier to get back to New York. So yeah, the whole journey has been unexpected. That was a crazy week. I remember just so vividly shaking hands with different venture capitalists and every one of them would be like, yeah, when's your flight back to New York?

And we'd be like, well, like Sunday, I think. And they would be like, listen, I have a friend who has a friend who told me flights are going to be grounded. So you better move those up. Like that things are about to get real weird. And so we ended up moving them up to Friday, I want to say. I like the part where they were like, yeah, you know, they'd be like, make sure you use hand sanitizer. We won't shake hands. But otherwise, like, yeah, cram be like, make sure you use hand sanitizer. We won't shake hands. But otherwise, cram into this small meeting room with 15 people. This is fine. Just don't shake hands.

Pandemic craziness aside, we built this tooling out for ourselves and it was then last summer that we pivoted to doing code review full time. It's interesting how many stories are like this where it's not your main product, it becomes your main product. I think Slack, wasn't Slack like the internal chat app? They were trying to build games and they're like, wow, this Slack thing is pretty cool that we built and started selling that and obviously became a big deal.

Same thing with Flickr, which is like no one knows about Flickr anymore, right? But Flickr began as some sort of flash video game and then it turned into image sharing. It was the Instagram before Instagram. There you go. I think it's one of the purest ways to discover something, right? If you solve the need for yourself without some grand idea of making it into a company, but it ends up being that useful and people really want it. It's quite pure. Yeah. It kind of leans to the iteration process too, right? Like even innovation requires iteration.

Totally. Right. You can't get to a problem or even a solution without having a problem. And sometimes you have to sort of go on a journey, which might be the wrong tool or the wrong thing. And you sort of discover from your exhaust of iteration that you've got this diamond in the rough if you just put things to work. And there you go. Iteration is one of the things we value a ton at this company. I'll say that for sure. We've had a lot of talks about that.

I think that what's also to add to that, it's that you get that iteration before you get users, when you build it as an internal tool, or you are your own users, maybe to say that a different way, where when we first started offering Graphite Te everyone back in august of last year at that point this thing had been around for about eight months right so it wasn't just we we built it our earliest version was still somewhat still had quite a bit of like logic and functionality baked into it which i think our users appreciate and called out but it was still rough then too oh yeah there's something with patience though that comes

with iteration i think that's why i'm harping on this because we could be so fast to get to the thing right especially with your journey like through school you're like you know what we're done with school we're done with whatever let's just get to a city and do our thing and let's just get to this mission and be successful but there's a patience and a process to the iteration i think that's something i want to instill into the listeners of this show and other shows we do. If you're not patient with the process of finding the problem, the right solution to that problem, you might just be chasing the wrong dog. It's a bad situation if you don't be patient. We found this book named The Mom Test

as we were going through this startup. This thing was arguably the most useful thing we read and tried to follow throughout the seed stage and iterating and finding the right idea. And it just, it harped on this idea of being very scrutinizing of positive feedback, being very scrutinizing of compliments and really look and search for stuff that's truly valuable to people and that they're, they're willing to use, they're willing to invest their time in, they're willing to refer to their friends beyond any one compliment. And I think our earlier ideas weren't fully passing that bar and we were lying to ourselves a little bit. Graphite ended up being night and day in comparison to Adelaide.

So when you're first getting started and you're building this main product, which is like iOS deployment tooling and you're a small business,, which is like iOS deployment tooling, and you're a small business, right? You're probably a handful of people, maybe just the three of you at the time. How do you justify just amongst yourselves, like, well, we're also going to build this code review thing for ourselves. Is it the classic procrastinate coding?

Like, well, you're not, don't feel like working on the main thing you're going to, or is it so compelling? Like, where did you guys, why'd you guys build this when you're supposed to be building something else? Totally. I honestly think it comes from like a debate Tomas and I had where I came from Airbnb and I was used to standard GitHub, standard pull requests. And Tomas had come from Facebook and he had seen their internal code review tooling, fabricator versions of Mercurial where they don't create branches and pull requests, they create diffs and they stack them.

And we had talked and Tomas, as we're setting up the company, we're picking the infrastructure. Tomas was like, oh, we should really go with Fabricator. It's going to enable this workflow. It's fantastic. I was like, you know, workflow sounds interesting, sounds fine, but I really don't want to move our code hosting off of the industry standard here. We might open source parts of it. There's huge benefits to having our main organization repos in GitHub. With Fabricator, we'd have to host an old PHP app, run it within our Amazon cluster, maintain it, upgrade it, have all of our code hosted on it.

I was like, this thing is probably going to be deprecated soon. And it was that tension where Tomas... No faith. It was just a little... I tried. I spun it up. It just wasn't quite there. And I think it was this tension of like, okay, we know this workflow would be fantastic, but we also have this

constraint of sticking to GitHub. So all that early tooling was bringing back that workflow, but allowing it to be 100% on top of GitHub and not disrupting your co workers. You know, it's funny. So we had this debate, this is we started this company 2020, put it down at that time, I was like, fine, I'm going to use GitHub, I'm gonna learn how to do this. I think what was interesting was so Nick, my old teammate joins us. And I remember, I think it was his second first second month, he comes to me he's like tom's like how are you doing good review like compared to what we have i feel like a caveman i think the quote was something to that effect and i was like i want you to take exactly that and just

go tell that to greg just like i i i haven't let go of this conversation go tell that to him fight my battle for me yeah exactly that was i mean that's where it came is it was like hey if people want to write scripts on top of this if they want to stack their pull requests and and everything like be my guest you know we were able to do it in a manner and nick and tamas were able to start building this out in a manner that wasn't disruptive to other people who weren't yet using kind of a stacked workflow but i'm sitting there and i'm watching them starting starting to put up stacks of 10 you 10 recursively branched pull requests. And it honestly started looking quite impressive internally. Even then,

I still hadn't hopped on the train, but it was at that point, I'm like, okay, fantastic. One, my teammates can use this and I can still review them and I can work with them and it doesn't disrupt me. And two, this is actually starting to look impressive. I actually am starting to see what it looks like when a peer puts up 10 small interdependent pull requests and so jared to answer your question like how do we make time for it i think at first nick and i started trying to do this manually so if you've ever tried to make a pull request off a pull request if you're a listener or if you've done this you know the pain that comes along with it there's a lot of rebasing which if you're familiar with git it's. It's still painful. I think at no point are you like,

oh yeah, this will be great. The first version we built was just trying to automate some of that nastiness away from us. And the argument there was like, well, we're spending our time doing this anyway. If one of us were to just bang out a script maybe in a day that does this for us, we'd probably save a lot of time. I think that was the thing that seeded it. And I think once you have a tool seeded in an engineering company that people like, engineers will keep building on top of it.

We've seen this with Graphite even today where we use Graphite for code review exclusively. And every so often there'll be a feature which someone will be like, why doesn't it do this? And everyone else will be like, well, why don't just go make it do that? Like, this isn't that hard, right?

Go add that feature. And so it snowballs from there. Yeah. I think this speaks to what Adam brought up with iteration. It's not as if you set out to build some big tool on the side. It's like you're just kind of like trying to grease the skids of your collaborative process. And just like all engineers do,

you start with a simple little script. And then if it's helpful, more a simple little script and then if it's helpful more people use it and then if it's helpful it could always be more helpful and so you start to build an ad and at what point did you know holy cow we got a product here we have a business potentially that might be better than this business that we have been building like how long did it take and what were the signals that told you guys it's time for a pivot? Yeah, so I think for so we started building this every so often someone would ask for it, we'd have old colleagues or friends would be like, Hey, I know you've talked about this workflow. I haven't heard you complain about it

so much. Did you solve it? Do you have something I can use? And we'd always be like, yeah, we like built a small internal thing. Don't worry about it. much. Did you solve it? Do you have something I can use? And we'd always be like, yeah, we like built a small internal thing. Don't worry about it. Or maybe someone would see our tool sort of in like the background when we were screen sharing. And they'd be like, hold on, what's that? And we're like, don't worry about that. Like focus on the real product, which is what we're here to talk about. I'm trying to talk to you about the thing here.

Yeah, right. Exactly. Distracted by my other cool thing. Honestly, actually. Literally, that's what was happening and it was summer of last year where uh fabricator which is this tool that had spun out of facebook in 2012 it was what they had for code review back then they've definitely iterated past that but it's a good jumping off point that company decides that they're shutting down and so what we saw

was we're in some facebook alumni groups. A lot of people were like, my company uses Fabricator. Fabricator is end of life this year. What am I moving to? Please don't let it be GitHub, right? And we saw a lot of that happening to the point where we were like, okay, maybe there's something we should do. And so I remember we started out being like,

let's first figure out how many people would be interested. And so we put out this survey being like, hey, if we were to, we weren't even sure what we wanted to do. We were like, maybe we open source it. Maybe we like just give it to you. Maybe we let you onto our internal platform.

Because at this point, this is a thing that, I'm not exaggerating when I say it, had like our repo names and our branch names and our usernames hard-coded into it. Like this was built for us. This was not meant to be a product. This was our script and uh we said okay if if we could magically make this available like who are there like 20 people who would be excited so we really want to get 20 to try and

experiment and we ended up with 40 people that were like i need to be in this beta like i i will die if i'm not in this beta and we we were like, okay. So that was August. We got a lot of good usage from them. We got a lot of good usage from them. And it was a lot of, there were people at very well-known companies who we were like, okay, this is interesting. We should go from there.

That was August. September, we decided to pivot to this full-time and say like, let's build towards like getting a proper wait list out there, which isn't just us putting a poll in some alumni groups, but see who else we can get. That's November, November.

So November 17th, we post our waitlist to hacker news, expecting about 500 signups. We get 3,500 in that first week. And we're like, okay, this is what we're looking for. It seems like there's some appetite here for better code review tooling.

Yeah. That's a good spot to be in. Honestly. I mean, like to, here for better code review tooling. Yeah. That's a good spot to be in, honestly. I mean, like to have low expectations and get a higher than expected list built, it's like, wow, okay, clearly there's something here that we were not thinking of. And Greg, you mentioned it, like you called it, like fabricated with end of life. So your initial apprehension was true and then validated. And then there's this vacuum.

And so the vacuum that's left there was evident, clearly. Yeah, it really does feel like the right time for this tool to be built in the sense that Fabricator's been end of life. So you have people shifting to GitHub, but wishing they had a different workflow. On top of that, it's one of the first times where GitHub's APIs have been mature enough that you can build a platform on top of it offering code review, but it's still 100% synced back to GitHub. If you go back a few years, that level of API access hasn't been available. It kind of felt like the perfect time for this to come into existence. You have other products too, like Google offers an open source version of Garrett, but similar to Fabricator, it's not at all modern.

I think it's only being used really for Chrome and Android these days. Most companies don't run it internally. There's kind of been a hunger that we realize talking to people for any alternative to standard GitHub code review. You know, it's funny. So building this out, we then put ourselves out there and see, okay, who's interested in this? And we, at first, we knew the Fabricator users would be interested.

What was interesting was the Jarrett users were certainly interested. I think Google has sort of put Jarrett in a backseat since they've started using Critique internally, which is their new exciting, shiny code review tool. We saw the same enthusiasm from GitHub and GitLab users who I think really were like, yeah, I know that there can be better.

I haven't seen it here, but I'm interested in it. And then I think Bitbucket's end of life this year as well. And so there was this perfect combination we talk about of things that just created space for us to exist. Yeah. We tried to set a high bar too. You know, we were very, like I said, when we were thinking about like the mom test book

and other learnings, we wanted to be very skeptical of any new idea, make sure we're not just getting excited about something shiny. Because of course we have our natural biases. And that's when we're talking to these people, we said, hey, we're going to give this to you, but you know, can you hop on a 30 minute call

every week for 10 weeks while you're using this? And people were like, yeah, no problem. And we, you know, you know if you want to, you want to join this wait list, can you refer like five people you work with? And people, people would do it and people say, no problem. We tried to set up differing bars to really understand, like, are people just interested or are they actually finding meaningful value? Even in the early days, even when you kind of have to walk on glass to use this, even if our documentation is terrible and the thing still has bugs in it. And when we saw people doing that and they would go through these steps and they would say,

no, I still love this. It broke on me. I'm actually annoyed it broke on me, but please fix it because I want to keep using it. It was very affirming. I think that was the magic moment for our designer was we had built out this thing in the dashboard. It was fairly new. We were excited about it. And I think some of our users were like, yeah, I wish it behaved this other way. And one of them went so far as to actually just mock up the site as they thought it should be and just send it and be like, no, no, no, this is what I need. Just build this.

And it wasn't people just turning. It wasn't people walking away. It was people being like, this needs to exist. And I don't care if you're doing it wrong. We will help you get there. But we need someone to do it for us. And that was cool. That's what's interesting to me is that there's this thing that's like, you get this demand.

And I'm not trying to be negative towards what you've built. They're not necessarily coming because you built the coolest and best thing. It's because there's such a need, which is almost even more invigorating as to be in your position because there's such a need for it, despite maybe your thing not being the best version of it yet. There's a need for a better flow or a better workflow. And the incumbents, massive, by the way, $15 billion opening daily IPO list, you know, in the stock market, GitHub massively acquired by Microsoft. These are massive organizations that have not gotten it right.

And there's a significant need with a massive adoption possibility. So your total addressable market is just massive already and going to grow infinitely as developers keep coming to Devland, which they will. Yeah. You know, Adam, there's something you said, which I think is actually really interesting, because we wondered for a long time, like, why haven't GitHub or GitLab done this? They're big companies, we have a lot of respect for them, they clearly have the resources for it. And I think the answer that we came up with for GitHub, certainly, and GitLab, which came a little after them, was this realization that what they're focused, or at least what GitHub's focused on is open source.

And open source code review and company code review look very different. So if you're in open source, you have a maintainer, maybe some contributors like me, writing like some code, committing it regularly, someone comes along, they write a pull request, I have no idea who this human is, right? Frequently, the pull request is incomplete. Perhaps it needs to test. The code isn't up to par because we just haven't worked together. All sorts of things can go wrong. And so getting that pull request merged takes quite some time. It's very rare that you find a project where people put up PRs and those PRs get merged very quickly. Flip to a team. What team code review looks like is very different, right? Like Greg and I review each other's code on 10 plus times a day. We know each other at this point quite well. We've been working together for years.

And so the kind of collaboration software that we need and the kind of collaboration software that you need when doing open source are two different types of collaboration software. Doesn't GitHub use GitHub to build GitHub? Aren't there large projects there? I know large projects like Ruby on Rails, for example, or Kubernetes. I feel like, and this is me going based off of not total data at this point, just feelings. I feel like at a certain point, they all start to build their own systems inside of the system. Or they're actually like, hey, we're using Fabricator on the side or something.

When they get real big? And so maybe I'm answering my own question. But GitLab probably uses GitLab. Aren't they like a team? Pretty big, too. I don't know. Why are they not seeing what you're seeing is the question. I think a lot of the companies, when they do reach a certain scale and they can staff an effort, because these kind of systems are not easy to staff and create internally.

But when they reach a scale where they can, I think Microsoft has done this. Google has done this. Facebook has done this. They will eventually either take fabricator, fork it and expand it internally, or they'll just create their own thing from scratch. I believe honestly, it's because they look at GitHub and they say,

this isn't the pinnacle of what code review can be. This is, it's wonderful for open source software. It's good for code hosting, but it's not the pinnacle of what code review can be. It's wonderful for open source software. It's good for code hosting, but it's not the pinnacle of where code review could be. You see so many features that companies have built on top of. We talk about stacking, but for example, another one that we heard from a Microsoft engineer

was this pattern of crash detection, where if you open a pull request that's modifying some files and a peer has an open pull request or even like a local pull request that would be modifying those same files. Why don't you notify those people up front and let them know that, hey, you might be about to have a rebase conflict. You're working on the same thing. Maybe cooperate. There's so many small incremental features that have been built out from the UI, from the code intelligence that haven't been brought into GitHub.

People aren't, you know, if you have a big enough engineering org, you say, hey, these are still valuable, we're going to build them internally. And I think then to answer your question around, so what about GitHub, though, as a company? Why haven't they built this out? So I don't have a great answer for you there. I think the best answer I have for you there is that when we've talked to engineers from GitHub, like, well, hold on, you've seen the same things we've seen. Why aren't you building some of these features? What they described to us is what they have compassionately referred to as setting cell, which is, hey, maybe you think that every company looks the same. Every company has one trunk branch that they're merging into.

Every company has CI. This is not true of our repos. And so when we're building a feature, we don't just need to think about us. We need to think about everyone. We need to think about everyone. And everyone actually looks quite different. But when we, Graphite, are thinking about us, we've made it very clear, hey, there's a very limited configuration of repo configurations that we want to support. Now, we believe that many software companies fall into this category, which is why we're okay with this assumption. But certainly not everyone does, right? We've certainly heard this case of, hold on, actually, like, in our repo land, we have

like three trunks and they merge into each other and something. And we're like, hey, that's great. Graphite's the wrong tool for you. But if you look like a more, I'm going to say canonical software development stack, right, where you have one trunk, you have feature branches off of it, you merge those feature branches back in, you need reviewers, you need approvals. That's where our tool really shines. This episode is brought to you by Square.

Millions of businesses depend on Square partners to build custom solutions using Square products and APIs. When you become a Square solutions partner, you get to leverage the entire Square platform to build robust e-commerce websites, smart payment integrations, and custom solutions for Square sellers. You don't just get access to SDKs and APIs. You get access to the exact SDKs and the exact APIs that Square uses to build the Square platform and all their applications. This is a partnership that helps you grow. Square has partner managers that help you develop your strategy, close deals, and gain customers. There are literally millions of Square sellers who need custom solutions so they can innovate for their customers

and build their businesses. You get incentives and profit sharing. You can earn a 25% SaaS revenue share, seller referrals, product bounties, and more. You get alpha access to APIs and new products. You get product, marketing, tech, and sales support. And you're also able to get Square certified. You can get training on all things Square

so you can deliver for Square sellers. The next step is to head to changelog.com slash square and click become a solutions partner. Again, changelog.com slash square. So let's talk about the workflow stacked diffs lots of smaller little prs i watch your demo video we'll link that up in the show notes that your co-founder did interesting stuff that seems like it's just like moving at a very quick pace like you said like you guys review each other's code 10 times a day. That's a world I've never lived in. Tell me about it. I think foundationally, it is pretty easy to get behind the idea that many small code changes are going to be better than just massive, large one-off changes from time to time.

I think there was a paper out of Google 10 or so years ago that talked about this and they did a deep internal study of the company. And they found that not only do small code changes get reviewed faster, that makes sense. Your peers aren't going to procrastinate them, but they actually get better feedback and more comments on them. Because when you hit a certain scale and you put up a 500, 1,000 line pull request, people start skimming it and start to rely more on trust. When you put up a series of 50 line code changes, people actually give it a proper look. On top of that, of course, it's easier to bisect. If there's a bug, if CI breaks, you have a smaller scope of change to act on. So I don't think it's too crazy of an idea to

get people behind this idea of just plentiful small changes over larger one-off changes? You know, I feel stack diffs, Jared, is just such a loaded term where people will hear it and have an opinion one way or another. And I'm going to just bring that back and say, I think the thing we advocate for is small changes that have to be on top of each other, because you're working on the same functionality, right? The analogy I like to make is, let's say that you're trying to build, I don't know, promo codes, you just built the checkout flow, the checkout flow is written now, it's up for review, you now need to add promo codes into it, what are you going to do? You can add it to the first PR,

but then it like becomes large, you don't like that. I can go bother my reviewer, right? And I can be like, hey, like, blocked on you, can you give me a review? And they're like, man, this checkout load thing's already 2,000 lines, I'm not just going to drop what I'm doing to work on it. Or you can go work on something else, right? And then you kind of like, I mean, we're all developers here, right? You forget the context, you're like, you come back to promo codes, you're like, alright, I remember roughly in the code where I need to add this, but now it's been a few days since I last worked on this. It took a little bit of time to get reviewed.

And so stacking is just this idea of, okay, cool, fine, just build the promo code PR, assuming that the checkout flow PR landed as is. And in truth, that's not the case, right? Maybe you'll have to edit the checkout flow PR, but the bet you're making is that the edits you're going to make to the checkout flow PR aren't super duper substantive.

Like, yes, it will still probably look somewhat similar to what you already wrote. And so just start running ahead a little bit. It makes sense to me. So I've done some code review. I've always worked in very small teams. I have been a manager. When I was doing consulting,

I would have freelancers that work for me and I would review their code. And I despised when I would get a manager. When I was doing consulting, I would have freelancers that worked for me and I would review their code. And I despised when I would get a PR in my inbox because I just don't like that part of the job. I don't even like to look at my own code. Just ship the sucker. So I'm not very disciplined. But I think the size of it was part of it, is where I'm driving at.

I would get this feature in my inbox to go code review. And it's like, this is my job. I have to make sure this is good and I'm going to do it, but I'm going to despise it because there's so much mental overhead to get into that. Like it doesn't feel like it can be quick. And so if maybe if that is the idea,

like that could have been five small PRS. I mean, it's better. I mean, it also allows the author, you know, if you're skilled to take the reviewer on a logical journey, right? Because it's not only five small PRs, but they're usually logically stacking. So you can see how the person is bringing together a larger feature. And they

maybe maybe they add a function, then maybe they add the call set to the function and then add the test to the function, then add, you know add the other system that starts depending on it. And in each pull request, they're all bite-sized. We see internally, I think, a best size of about 50 lines. It's so easy to review, think about. And what's even best is that you don't have to review all of them yourself. You could get in there, review one of them, get pulled away, go to lunch. Another peer could come along, continue reviewing the stack.

At no point are people blocked. Even the original author, they could say, great, hey, I got the first half of these reviewed. I could choose to start merging these in if I want to. I can wait. I can keep stacking on top. It really just breaks up the process and keeps everyone unblocked. One way I like to think about this, you know, we often get asked, especially as kind of an early stage startup, if we're ever going to build out collaborative, like real-time

collaborative coding, I think there's a lot of startups are kind of interested in this idea of like Google Docs style. Like where's the logical limit? Do you start getting like multiple cursors on a VS code? I think our take is probably not. You won't see a Figma or Google Docs in our opinion, because code has this interesting property where the intermediate state is constantly broken. So real-time collaboration is kind of hard because you're just constantly breaking each other's actual logical flow. The closest you can get

to real-time collaboration is just small atomic changes, which each are functionally correct in passing all your test cases, but are as small as possible otherwise. And I think that that's another kind of way to reason about this workflow is it gets closer to a real-time collaborative process because we're just really breaking down coding into the smallest change chunks that still pass tests that are still logically sound. You know, my favorite part about it is actually as an author it's the what greg was saying jared i don't know if you've ever had this you get this pull request it's like 4 000 lines maybe it's 2 000 lines you agree with the first like 1600 of them right and then there's

one bit which you're like well i don't know if this is the thing we should ship right or maybe we should do this one a little differently but as an author i i actually don't care right because if the if we can agree on like the first basic things i can actually start landing this and that means i don't need to worry about rebase conflicts i don't need to worry about continuing to think about that you don't need to read it in future versions i can just get that at the door kind of as you were saying we can just ship this sucker and then there's that last bit which we still need to talk about but it's much smaller yeah it massively decreased we see just a huge decrease in time to land the longer board request is up without merging in just the more more pain more problems everyone's going to have sure and

the more you truncate them we see a just a faster time to land so as you author are you writing a feature and then splitting it into logical stacked diffs and then opening PRs? Or are you actually building those? Are you opening those PRs as you go? And then you finally get to the end. How does it work in practice? So people do both. We generally suggest that you do it as you go.

I think many people find that a lot easier. And so the idea is in the same way that you might be making commits as you go by using gate commit or something like that right when you're actually doing uh sort of like the graphite workflow make branches there so instead of saying oh i want to make a commit just make a new branch and the reason we make a branch is because on modern code hosting platforms so github and gitlab a branch is the smallest unit that you can open a pr against so rather than making a bunch of commits that I open PRs against, you need to make a bunch of branches that you then open PRs against, and then you can run CI against those, review those independently,

and merge those independently. But to your point, you know, tooling also supports this idea of making one large change. You look at your state of your Git repository and you see 10 files are changed. You're totally free to just take two of those, create a branch, the next two stack on top, et cetera. We make it really easy with the open source CLI to sync all these changes back and forth to however many open pull requests you have at a time.

So even if you have a stack of 10, it's one command just to sync all of your local changes back up. It seems like a commit per PR makes a lot of sense. Is there a way of doing that? Like say I just go 10 commits down the road and then say, all right, here's my 10 PRs and you can just go create the 10 branches for me if I need to. I think our teammate Jacob is building that feature into the CLI as we speak. This is a requested feature and it's totally possible. Add my plus one to that one. I'm just thinking how I would probably actually use it.

And for me, that's probably the way that I would do it. Because I tend to think about my commits that way. It's like this little chunk of work is done, then this little chunk of work is done. And those seem to translate very well into an opportunity for code review. Yeah, it's a shame that, you know, the code review platforms by default don't let you review on the commit level. But, you know, it is what it is. I think we thought initially at the beginning a lot around should we mandate

single commits per branches or do we want to support multi-commits per branch? And we realized talking to folks that this is a flame war and there there are strong opinions on both sides and we said hey you know whatever we'll be agnostic uh both are totally fine by us you know you can have one commit your branch you can have money it all works exactly so what happens when you're dead wrong about one of those little prs and you think think, there's not going to be massive changes. And then you just move on and you're just building your stuff.

And you're like, all of a sudden, your reviewer is like, we're not going this direction. Then you're in more trouble than you were if you had just sandbagged it. You'd be surprised how rarely that happens. But if it does happen, I mean, you've got a couple options. Perhaps the change that's been flagged is halfway up your stack. And the first half of those changes were were actually totally valid and meaningful in which case cool you know merging what you got and consider refactoring or throwing away the rest that still might be better than if you just had one massive change and the whole thing's not going

to land uh is a step one but honestly in reality mean, perhaps this nature of the teams we work on, it's rare that you go too far off the rails in a direction. One more thing I'll say on this is that if you are breaking up your pull requests and you're putting these things up as you go, you're probably going to get that feedback that you're going in the wrong direction faster than you would

if you were working on one monolithic change. Because someone might be code reviewing the earlier parts of your stack before you've even finished the top of it. If I did it all as one big go, if I sat in a hole for a week and made a 3,000 line pull request, I might not get that feedback for a week or two, and that's going to be even more frustrating. It's about efficiency, really. You want to be able to give you were saying, Jared, before that you hate the part of code reviewing. I do.

And we've been talking from the person who's committing, so the developer, right? But as the code reviewer, you're like, I want to be able to grok it. And it's to have to like have documentation for a pull request would be like, come on. You know, you want to be able to get through some of it. You know, I think this method provides the whole, you know whole stand blocked, do it faster, efficiency for a team, rather than having to get this thousand line pull request that, sure, as a committer, as a developer, it's fine for you. Because what do you care, right? It's the code reviewer.

That's the person or the team who may be like, okay, you have to make it easier for me to help you help me help us, which is we're the team with the same jersey, right? You know, it's funny. Adam, exactly correct. I remember when we started this company. So Greg and I came from different cultures, right? He came from Airbnb. I came from Facebook. And we were talking around.

So there are a lot of conversations we had in those early days kind of figuring out like, out, okay, so what did we learn at these jobs? How do we want to build this engineering culture? I remember one of the things he told me early on was, yeah, some mornings I just take two hours to sit down and do an individual code review. And I'm like, what? Someone sent you a code review that took you two hours to do? And he was like, yeah, that's pretty normal.

And I'm like, what? No way am I going to sit down for two hours and review someone's code. I'm going to, if it's two hours long, I'm going to tell them to split it up so that it's easier for me to understand. And I think that's one of the positive things that falls out of this workflow. It becomes a lot easier to review and therefore you can keep moving forward. It's part of the whole movement. I see this broader trend. You guys probably see this too, uh, towards just a continuous workflow and continuous changes. So you,

whether it's a integration test, continuous delivery in this case, it's, I don't know, one could argue it's like continuous code changes or something. The whole thing is becoming much more stream based and much less waterfall based. And I,

in some ways I view this as like the, the code review part of that evolution. You wonder how far that can go. I guess the Google Docs Live real-time collaborative coding is kind of like the end game of that. And do we ever really want that? Greg, you think maybe not. Some people think maybe we will.

I think we'll find out if we want it, because someone's going to build it, and we're going to see if it survives in the market, right? I mean, that's what innovation is about. What do people actually want? You have to build something that we want to use and maybe we do actually want that. Maybe we're going to stop somewhat short of that.

I think from the demand that you guys are seeing and I think just from, let's just call it the mental stimulation that I'm having around these ideas, it seems like this is a step in the right direction from where we've been and kind of where some of us are today. Yeah. I mean, I think, will we ever see like a totally collaborative code editor? Maybe for pair programming. But I think the question is, is that how like all code for a company is going to be written? No, probably not. Right. I don't, I don't imagine a world where we just have like

main master trunk, trunk, whatever you call it, and you just see however many engineers you have at your company's cursors just going at it. That sounds impossible to get a wrinkle on. More like an MMORPG. Who can type faster wins the game. Delete my line of code before I write the next one. Yeah, exactly. But might we see that for more targeted collaboration possibly, right?

And one of the things that we actually do see is people will use stacking as a way to collaborate where they're like, hey, I have a feature branch, but I'm not the only person working on it. I'm going to write two commits. And then someone who's like, hey, can you land that thing so that I can start working on something? I'm just like, hey, can you just stack on top of me? And then you get these towers built by many groups of people which are collaborative, but have discrete chunks built by individuals. So what does it feel like to use Graphite?

Because when it comes to using Git, and we're coming from a thousand different directions, you've got people using GitHub Desktop, you've got people using the Git command line, you've got people who put it in their vim and they've got it in their vs code or maybe it's up in your stack blitz i don't know where people are using git these days but many different ways uh you guis etc surely graphite has show notes that's in your show notes yeah we sync our show notes with github so we're using it even when we're

just uh adding links and markdown. How do you use Graphite? What does it look like day to day? I think when we were first building out the command line interface, we wanted to make it as interoperable with Git as possible. I think the worst thing as an engineer is being forced to go whole hog on something, completely adopt some opaque black box tool, and throw away the other tooling and workflows that you fully trust. We said, okay, hey, can we build this on top of Git primitives? Any metadata that we're creating, can we store that within Git refs themselves?

Can we make the commands just be complex overlays on top of underlying Git commands? And can we make it so at any point, if you want to, you can break out and you still just have your your git branches and your pull requests like normal that was that was really our initial design goal and we achieved that i mean in a lot of ways the cli is just everything git offers you plus a bit of metadata that keeps track of the dag or the you know which branches are parents of which other branches and helps you with those rebase operations when you want to perform them. But there's nothing to stop a user at any point

from saying, no, I'm going to run Git to create my next branch, or I'm going to run a Git to create a commit. You can do it with Graphite, you can do it with Git. You can use Graphite after Git to just realign your stack, make sure everything's in order. Yeah, we started with a CLI because we figured it was where a lot of people use Git.

We want to be everywhere in the long term, right? And so one day you will find us in Vim, in VS Code, in a GUI, all of that. For us, it's a question of sequencing. And so CLI came first. GUI probably comes next to help some people who are less familiar with the command line tools, but still use Git, use Graphite as well. And then from there, I imagine we'll start to branch into VS Code,

IntelliJ, wherever you may be, but one step at a time for us. I think we're quite agnostic about the whole interface. It's helping engineers work together, adopt this workflow, move faster. But if you want to do that in a GUI, you want to do it in a CLI, that's up to you. We just want to be there to support you. Yeah, I think that makes sense. I think starting at the command line makes sense. I think when it comes time to do i think basic git at the command line is just fine once you get into the more interactive rebasing the squashing the picking you know staging line by line etc command line git for me at least becomes cumbersome and that's usually where i do reach

for a gui now i watched the demo video again we were referencing it we'll have it in the show notes people should check it out because that's a nice overview of what it feels like i think to work with graphite uh at least at the time that that demo was created by your co-founder and it has some nice uh looking stuff in there is like he was using the gt command which is that an alias or is that like what your guys's graphite gets installed as uh how do you actually like do the stacking and the rearranging from the command line are you like referencing hashes or numbers or what's that like it's really as simple as create your changes as you normally would stage them as you normally would you know get add my files would, you know, git add my files.

And then where you might otherwise just create a new commit, you can just create a branch. And you use Graphite to create the branch. And you say gt branch create. It's actually, for some of these commands, we looked at Git and we said, the nomenclature is a little bit hard

to understand for beginners. I think in Git, it's checkout dash b is how you create a new branch. We tried to just do a noun verb pattern and say branch create. That under the hood is quite simple. It just creates a new Git branch with your changes and then sets the parent metadata.

And we use that parent metadata if we're ever going to perform a rebase for you or if we're opening a pull request against GitHub and we want to set the merge base correctly, we use that metadata. But mostly under the hood, and it's all open source, you can read it, it's mostly just executing common Git operations for you underneath. So you might go along, you might call create branch a couple of times, so you have three branches locally. And then the next command that's most frequent would be stack submit. So not only can you run commands that operate on any individual branch, but we have commands that operate on the stack level.

Stack submit would open up pull requests for those three branches all in one commit. With different flags, you can specify the description. You can specify if you're opening it as a draft. But in general, it'll open up those three pull requests. It's also idempotent. You know, if you've made some changes to already existing pull requests, it'll just sync those up and keep them fresh.

And then lastly, we have one or two final commands that if you start merging those in, it will automatically clean up the branches locally and shift your stack down. So say you merge in half those pull requests, we can just in one go shift that down and keep your local stack synced. It's handled a lot of the hard parts, I suppose,

behind the scenes for the user. So it seems like a complex workflow, but Graphite simplifies a lot of it by doing a lot of the behind the scenes for them. The whole thing can be done in, I think, about four commands. Yeah. Cool. And another side of the story here is we have a web dashboard. the scenes for them whole thing could be done in i think about four commands yeah yeah cool and then the other side of the story here is we have a web dashboard so web dashboard the goal is you

know once you start stacking you end up with a few more pull requests than you might have otherwise and so keeping track of where they are what do i need to review where are they in the process becomes even more important and so our website login with g GitHub, it immediately off the bat just shows you, okay, here are the PRs which are ready to land, which you need to review, that you're waiting on someone else to review, and then other stuff that maybe you just want eyes on and are waiting for an author for. So if I requested changes on a PR that Greg put up, or maybe I approved it, I'm waiting on him to take action. And then within that, you can actually go ahead and code review in there. And so that is entirely synced to GitHub. You see all the same functionality as GitHub. on him to take action. And then within that, you can actually go ahead and code review in there. And so that is entirely synced to GitHub. You see all the same functionality as GitHub.

So you can leave comments there. You can suggest that it's there. And then we try to add, you know, a little bit of our own sort of like special features in there. And so you have everything ranging from memes and macros, things that just make code review more fun for you as both a reviewer and an author, to things like being able to leave comments outside of the lines that were just changed. memes and macros, things that just make code review more fun for you as both a reviewer and an author, to things like being able to leave comments outside of the lines that were just changed.

So in GitHub, you can only comment on changed lines. One of the features that we always got was, hey, can we comment actually on any line in the PR? Because sometimes you change a variable name and you need to actually just change where it's referenced later on in the code. You can leave that comment in Graphite, and we will just leave that back in GitHub as best we can, saying something like, hey, this comment was left using Graphite and is meant to reference this line with then like a little excerpt of the code.

Yeah, a really common workflow is we'll get one person at a company who will start using Graphite. They'll create their stacks. They'll use the web dashboard to maintain those pull requests and maybe even merge them in all at the same time. We support batch merging.

But their peers are still just using GitHub. And again, they don't have to get disrupted. They can see those pull requests like normal. Graphite puts a little comment on those pull requests, helping show with links navigation around the stack. But it still just looks like normal. It's 100% synced back to GitHub underneath the hood. And then what we often see, honestly, is teammates will look at this and they say, hey, well, same thing I did. My teammates actually putting up a lot of good code changes. This makes sense.

Let me give this a try. And it seems to naturally spread. We put very little effort into marketing or sharing this thing out. It seems to have a natural virality to it, which we appreciate. This episode is brought to you by Sentry. Build better software faster, diagnose, fix, and optimize the performance of your code. More than a million developers in 68,000 organizations already use Sentry, and that includes us.

Here's the easiest way to try Sentry. Head to Sentry.io slash demo slash sandbox. That is a fully functional version of Sentry that you can poke at. And best of all, our listeners get the team plan for free for three months. Head to Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog. And by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. Atlas provides an integrated suite of data services centered around a cloud database

designed for scale, speed, and simplicity. You can ditch the columns and the rows once and for all and switch to a database loved by millions for its flexible schema and query API. Thank you. Azure and Google Cloud. Yes, you heard that right. Distribute your data across multiple cloud providers at the same time. The next step is to try Atlas Free today. They have a free forever tier. Prove yourself and your team that the platform has everything you need. Head to mongodb.com slash changelog. Again, mongodb.com slash changelog. One of the challenges with beginning anything or building something that you just pray that gets adopted is like,

if it's a team tool like this is, will the whole team have to use it to use the tool? And I think that's the beauty of Graphite, at least from this vantage point, is that Jared can use it and I don't have to use it. And there's some virality to it where while he's using it, I can see he's efficient. Like you said, there's comments on the pull request. It's still normal GitHub workflow, et cetera, et cetera. You can even buckle down to just straight up Git if you want to. So there's not a lot of like you have to be all in or nothing,

which I think is super important for a tool. Is that just by happenstance or was that literally by design in how it worked out? I think it was one of the things our users first asked us for, right? So when you're an early dev tool, right? And you're trying to convince developers, hey, I think I have the workflow you want.

You just got to try us out. The first question we got was like, well, hold on. Like, what if I don't like it? Like, am I locked in? Right. And then our answer was actually the same.

It's now, which is, hey, listen, we store all of the metadata in Git, so nothing's locked into us. So we actually store all the branch parents all in Git. And then you can always drop into Git if you need to. And we sync everything to GitHub. So between those two, your data's your own, you understand what's going on.

Yes, we do a lot of magic in terms of like rebasing automation but more than happy to explain that to you you can read about how we do it online and so we wanted to make this thing really accessible and understandable for people to be able to sort of go and understand part of the reason the cli is open source is so that people can see like oh cool this is what it's doing. I mean, we're developers too, right? We have all these same concerns when we're using new tools, when we're using the tool that we're building ourselves. Sometimes there's a bug in it and we want to make sure there's escape hatches.

We don't want to be blocked by this tool that we're building out quickly. I think there's a whole level of empathy of dogfooding that we try to really practice. And we have, again, I think I mentioned before, but we have this Slack community full of developers who are using this, giving feedback. And everyone's just so honest with each other, whether or not it's a bug report, it's feedback. It's us saying, hey, we're so sorry. We had a bug in the last version. We messed up. If you're curious, here's exactly what went wrong and how we fixed it. Thank you for bearing with us.

There's a human element to the whole thing that is very nice it's nice to build for other developers yeah i think some of it is by design right so when we first first built this nick and i were like cool we want this different workflow and greg was like i want nothing to do with that like make sure i don't see it make sure i can still do the thing i i want to do and so when we first built it it it was like, cool. Like we need to. Kudos to you guys for not just kicking him off the team, by the way. I mean, you could have offed him right then, but you let him stick around. That was wise.

Just change my key, change the lock on the door. Anyway, cool. We solved the problem through different means. But so we need to figure out how to work with that. And so I think that led us down this route of, okay, how do we make it interoperable? But like, really? Yeah.

How does that lead it to, let's say, the business side of things? So there's obvious growth here. You announced your Series A, I believe. Was it Seed or Series A? I don't even... Series A, 20 million. Series A, 20 million. I knew the number, but I wasn't sure if it was Series A or Seed.

So congrats on that, by the way, which means that you're at least on your way to the right direction. I can imagine that's got to be helpful with adoption, too. I think you kind of begin enterprise first rather than smaller teams, it seems, based upon the logos on your website and whatnot. But talk to us about how that led into just adoption. Does that make it easier? Obviously, it does. But, you know, is it harder?

What's the process to gain new teams, gain new trust? There's obviously Fabricator out there and Merit and all these different routes. There was this demand, but how do people know about this workflow that's beautiful that isn't GitHub or GitLab? And then how does this model, this non-locking, this DX and empathy-focused developer pattern you know work into adoption you know so when we raised our run we were looking for something very specific which is we did not want to be forced to how do i say this become like a businessy business super quickly

we were our belief was hey we think we're building workflow. We think that there's a lot of value behind code review, but we think we need to first like get the world to understand it, get the world to at least try it out and use this. And so we were incredibly excited by Andreessen because the partner who joined us, Peter Levine, he's the one who led GitHub's A actually. And so when he met first met us, he was like, I get it. This is, this is GitHub. This is what it looked like. Because when GitHub came out, Git wasn't a surefire thing. It was this new technology that some people were like, well, maybe this is right. Maybe this isn't right.

And so I think to him and to some of our early users, the belief is like, no, this is the way the world is going. We all believe, much like back then, we believed in collaboration. We still all believe in collaboration. We believe smaller changes are the way to do it. And so what we were looking for was a partner who was going to support us in saying, okay, how do we introduce the world to that concept? How do we introduce the world to smaller changes, to team-centric code review, not open-source-centric code review as we describe it?

And who's going to have the expertise to help us carry through. And so we are very grateful. Not only did Andreessen join us, a lot of the angels we brought on were former and current executives actually from GitHub, and GitLab, who came on and were like, yep, we know what we need to do here. We first need to sort of start to teach this workflow. We need to focus on actually building familiarity with this and doing right by the community, because that is why we exist, right? It's this community of 3000 developers in Slack who care about us, who help each other out, who write edits on post-it notes and send it to our designer that give us sort of the right to be a company. And how do we grow that to not just the 3000,000 people who have taken early bets on us,

but what we want to be the developer community at large, right? The tens of millions of developers that are out there. It's awesome. I imagine it's nice for companies who are starting to go, honestly, all in on graphite. Some companies, it's had this bottoms-up spread so far that most all of their engineers are using it. And I hope it's nice for them to see us raising that round too,

because it means we have plenty of runway. It means we don't have to worry about, you know, will we have enough money to keep paying our team? Will we have to like pressure into enterprise sales really quickly? Hopefully it gives them a little bit of peace of mind there. Maybe this has been confirmed somewhat by internal conversations with people at GitHub, but what do you do whenever they feature this thing? Whenever they code spaces you or co-pilot you, there's Gitpod out there, code spaces

is obviously in that space too, agnostic to all the places, tab nines out there in terms of AI-assisted development, co-pilot. Is this like Dropbox to Apple one day? Is this just a feature, as Steve Jobs once said? Or is this something that, I mean, I guess quote Mr. Wonderful, can they crush you like the cockroaches you might be? What will they do?

Yeah, I mean, I think it goes back to what we said of I think their audience is fundamentally different. I think when we think about the audience that GitHub primarily actually is beholden to, it's that open source audience. And I think because of that, there is a slew of settings and features that they need to support that we just don't, that will continue to be our strategic advantage. I think they're passionate about being a platform. You know, when we talk to some of the GitHub folks these days, they don't want to get into the game of having companies built on top of them and then just trying to cut them down. They're trying to be a friendly platform.

I also think, I mean, this is more subjective, but I think they're trying to focus on finding ways to sell Azure compute. And when you talk about some of these projects like Codespaces and Copilot, I think in some ways they're funneled, as well as GitHub Actions, they're funneling users towards buying Microsoft Compute. And that actually makes a lot of sense as a business. But it does mean that code review for the time being is perhaps less interesting to them. And they might be more supportive of just companies building on top of them. If their true passion is compute and it's code hosting,

I think there is room for companies to be built on top. One more thing I'll say on this is there's a benefit to us existing in this space and in the long run, us being agnostic to where the code is hosted. So we currently support GitHub, but there's no reason we don't support or we can't support GitLab. We can't support, honestly, private code hosting, you name it. The same way Terraform is nice in a world of Amazon CloudFormation, for example. There are sometimes benefits for a company to adopt the tool that is more agnostic to the backend and less coupled.

So Graphite exists today as a command line tool that layers onto Git as well as a web-based dashboard. Are those two things decoupled can i just use the command line tool as a regular user and just hop on graphite's ideas and not necessarily become a graphite you know account and a customer or is it all kind of like you got to buy into the graphite business to use our command line tool. Yeah, I mean, as long as you're not doing network-based operations, so things that would require GitHub-level authentication, the command line tool works fine. So as Tomas said, you can create stacked branches,

you can reorder them, fix them up, split them out, and all that is doing is modifying metadata within your git repository itself i think the only command we have that will require you to set up some account with us would be submit and that's because it's doing work on the server to open up and number of pull requests against github and then link them together yeah because there's a github app involved exactly but yeah we've we've tried to again it's somewhat community-centric, right? If we don't need you to go through our server, you don't have to.

And we definitely do have users who will set up the web account, hook it up with the CLI, and then predominantly just use the CLI. And that's totally fine as well. We end up just needing the web account as a way to call into the GitHub API. So tell us, I don't think we touched very much on that web dashboard and what it looks like today and maybe there's a future of pro accounts or team you know i figure that when you start to think about monetizing which you very well said that you're trying to defer those kind of decisions until you have critical mass fair enough that's what vc is for but surely in the back of your mind, you're thinking, well, this could maybe be a monetization thing. Maybe this could be a monetization. It seems like the webby stuff,

the collaborative stuff, also licensing for teams, et cetera, could also be a good route. But what's the web dashboard do today? And maybe do you have plans for that being more awesome down the road? Well, maybe I'll say what it currently does and Tomas can talk about the incoming features. One other thing I'll underscore is, like you said, you can use the CLI without using the web dashboard. You can also use the web dashboard

without using the CLI. You don't even have to buy this whole idea of stacking your code changes. You can just use this and say that, hey, if I work within a large company and I'm doing pull requests against 20 repositories, lots of different people, you might say that there's not an easy way to see at a glance, kind of like a Gmail inbox of like, okay, what are

the three things I need to review? What are the three things I need to merge? We provide that to you. That's the first page within the Graphite Web Dashboard is customizable sections, almost like an email inbox of actionable pull requests. The second main view we have is if you click into any of those, we, similar to Fabricator, we show you a single page with all the comments, with the description of the pull request,

the code itself, all keyed out with shortcuts, modern looking interface, file tree, you name it. And people tend to enjoy this interface a little bit more, honestly, for code review and merging because it's a little bit snappier. It's a little bit more responsive. It's a little bit more modern of an experience. It has GIFs, you know, it has keyboard navigation, has a couple of features on top of GitHub.

That's where the web stands currently. Tomas, you want to talk about what's coming? Yeah, I mean, so what's coming? The biggest thing that's coming is we have a bunch of UI improvements coming out, which are aimed to make that PR page even simpler, easier to understand, easier to just get involved. I think one of the funny things to us is when you look at most pull request page of like,

okay, where's the information I need to collect? It's scattered throughout a bunch of tabs and it requires a very careful read of timelines and things like that. We want to make this even easier because as jared you said many developers do not love this part of their job and are just trying to get in and out of code review as fast as possible and we want to facilitate that and so that's our goal is those ui updates i think what happens after that then is some of those uh that gui that we talked about earlier, features that are aimed at making Git sort of more accessible and easier to understand for people who are newer to the experience. And I think what happens even after that is probably some of those team collaboration features.

And so things, the magic that really happens when you and I are both Graphite users, what can we start to do because we're both on Graphite and because we have that new interface? I guess if you're listening to this and you think this is interesting but you wish that code review had some random feature let us know. We're super receptive. We went so far as one of the primary views in the website is just an upvoting feature list and any user can go on there and just, hey, I wish my code review had this feature. Upvote existing suggestions and a big part of our roadmap is actually just picking those top

community asks and implementing them. So one thing we think is really exciting is we got this amazing, loving community, and they get to say what they want the feature of code review to look like, and we'll probably help build those. Yeah. So you have the command line interface. You have the pull request inbox, which obviously is super helpful. And then you have a separate tab, I'm assuming, in the web view of this, which is code review where you're digging into, you're looking at different things. Assuming that the code host is GitHub, if you adopt or a team adopts Graphite, if they're in this world, do they ever have to actually go to github.com slash their repo or whatever to even do anything?

Or do they sort of eject? If they buy in and they see value, do they sort of eject from all GitHub workflows, basically? Aside from code host and maybe discussions or something else that might be on GitHub, obviously. Workflow related, pull request inbox, code review. Is that sort of like away from GitHub.com essentially? Yeah, Merrill, our co-founder, had a good way of thinking about this when we first built it out.

Because we dog food this thing too. And the idea was, can we as a team get to the point where we have no reason to go back to GitHub? Beyond maybe changing some extreme admin setting or something. We got ourselves to that point. And I think a lot of the teams who use us feel the same thing. There are, there's a long tail of fringe features and settings that one might go to GitHub to configure, but for common workflows, correct me Tomas, but I don't, I don't think there's a reason to go back.

You know, I think it's funny, actually. I think that there is, I think what we did to actually fully round out the conversation, what we were saying, it started as this tool of just how do we get ourselves into this better platform? And to that snowball effect that you were talking about, as we build it out, as we see opportunities to improve various parts, we've just been adding to it. And so for ourselves, any place where we find ourselves going back to GitHub, we tend to code around it and say like, okay, cool, this might be an area for us to add. I still think there's a ton to do.

And so I still end up going back to GitHub for various things, like what's the timeline of commits? Code search is something I frequently need. But in general, in the pull request flow, that's the thing I now keep entirely on Graphite. But even on our PR page, there's just a link back to

github and to view it on github so again at no point is there any lock-in and if you need to access a different feature you just click in i'm thinking about this from a different angle the reason why i ask this question is one what's the actual user experience but then two the pull requests and you know those kinds of things on gith GitHub.com are valuable to GitHub.com because they bring the user back to GitHub.com. You could totally ship and do all your work inside, you know, terminal and never touch GitHub.com unless you're reviewing code and doing different things. Like, you can eject from, you know, in quotes, their brand, basically. I think as you become more popular and you gain more inroads, you may be more threatening to them than you realize today

from a brand perspective. You know what I mean? Because if they can eject from GitHub.com their workflows and sure, you're valuable and they're friendly now. I'm just thinking at some point you may be threatening to them

because of that. So be careful out there. Yeah, I think there's probably a lot of roads before then i think before then we they'd probably talk to us i think we'd probably have a conversation yeah i think there's a lot that they want to own that we have no intention or desire to in terms of projects code spaces co-pilot right uh actions sure I think that as we grow there, I'm sure there are conversations that will happen. Yeah. I think what Adam's saying, DeMoss, is you've got to look over your shoulder in case someone's following you in the night. No, I don't quite mean it like that threatening, but I think there is going to be a day when

you may not play nice or a table conversation may need to be had because you may gain that much power in this space where you know they're power users like these are enterprises that you're these are large customers for them and if they can for the most part eject from the github.com workflows then and they're not users of code spaces or maybe they're not using other tooling you know it can be it can be an issue for them long-term potentially. I'm just thinking that outside the box. I could be totally wrong. Totally.

And we'll have those conversations when the time comes. I think the thing that keeps us on the right track is focusing on the developers and saying, hey, we will build what is best for them, what's going to be most helpful, including ourselves too, because we're dogfooding this. So I think if we just keep our eye on the community and, what's going to be most helpful, including ourselves too, because we're dogfooding this. So I think if we just keep our eye on the community and on what's actually useful for the world, that'll pull us in positive directions.

And if there needs to be corporate competitive conversations, we'll have them. Sure. Well, so that's a good way to put it for sure. I like that approach and I like that sentiment too. That gives me faith in the direction you may go. So we've asked you lots of questions. We've talked deeply about your workflow, your tooling, some of your business model to some degree. You mentioned your large round of funding.

You're sort of punting on some of the business direction you might can go now because you want to make sure that you get critical mass and are actually valuable and useful. You've got a Slack community people are involved in. You got a lot of, you know, a lot of growing respect, a lot of demand happening out there. You're still currently in waitlist. You mentioned 3,500 earlier. What is your waitlist size now? Like if someone's listening to the show today and they're like, okay, I've got to have this tool.

I want to buy it now. They can't buy it now. So they join a waitlist. What is the process? What's the next step for would be, should be, could be users from this point? It's must. What is the process what's the next step for would be should be could be users from this point it's what's the what's the promo code yeah i mean i think the short version is if dm at with graphite on twitter and i'll let you through tiny listener of the show more than happy to okay part of the reason we have a waitlist is uh honestly to make sure we're growing at the right pace there are There are times where we get an announcement

or some article, or maybe this podcast, where a wave of a couple thousand users try and sign up. And part of it is us respecting our servers from some new wave of load. And also to make sure that as users come aboard, they're having positive experiences and that we're able to respond if they have a problem or a bug or a feature request. And so I think we use the waitlist purely as kind of a smoothing function

a buffer yeah yeah i think we use it it's one the smoothing function and then two it's still early days for us and so every so often we'll see a bunch of people sign up and we're like well today's the day we were planning the database migration so like hold on to them for a hot second. Let's get through that first. And then we let them on. We haven't, we generally let most people through. I think actually we've let almost everyone through at this point. So you don't have a massive waiting list sitting there.

It's sort of like trickling. You get somebody on there, they're maybe on there a few days or a week at most, and they're through. Yeah. Okay. We also, and if anyone's like particularly motivated, email us, tweet us, whatever you need. More than happy to let people through. That is not the goal. The goal is more for our side, for capacity planning. And so I guess on the flip side of that, we've asked you lots of questions, as I mentioned.

What have we not asked you? What have we not asked you to talk about? Or what's particularly interesting that we just haven't covered that needs to be covered before we close? I mean, Tomas, if you're someone who loves working on dev tools and modern code review in New York, is there a way you can get involved? Yeah, I mean, also definitely reach out. I'll say that for sure. Nice plug for hiring.

You are hiring, is that what you're trying to say? Yeah, we are hiring. Actually, I'll take it two regards. One is we for hiring. You are hiring. Is that what you're trying to say? Yeah, we are hiring. Actually, I'll take it two regards. One is we are hiring. Two, we have plenty of users who like to contribute to us anyway. So our CLI is open source. We do accept open source contributions. Actually, our Windows and Linux installations are entirely community-led.

More than happy to help support people, ramp them up in that regard. Yeah, it's a community both inside the company and outside. Yeah, and other than that, if you're just interested in checking out the tool, I think the thing I'd say is like, join the Slack. See, like, I think the Slack is this really wonderful place

where you see people joking around, you see them helping each other, you see them asking us questions, you see us asking them questions. It's a really great way to get to know sort of like the company and the tool. And so definitely check that out as well. I'll just underscore again, you know know if you're listening to this and you

have ever wanted more from your code review this is the best time to tell us about it and we will help make sure it happens okay get your feature requests in now while they're still small exactly yeah exactly one more point i want to mention there. So Greg, you mentioned hiring, you mentioned New York. So are you not a remote company? Are you open to anywhere? What's the state of like how you hire and how your team works? Yeah, we're currently, I think bucking the trend a little bit. And we are a full in-person team in New York, about seven people total. We have an office here in Williamsburg. I'm sure we'll move it back to Manhattan as we scale. One day we might open the doors and go supporting hybrid or full remote. But for the time being, while we've been small, you know, I say seven people, we've benefited massively from

that internal communication, that culture building, just the positive experience of all working together every day, literally shoulder to shoulder, sharing lunches, dinners. You know, I could believe there is a limit to how that scales. I could also believe that the future is unknown about how COVID and other work patterns evolve. But yeah, currently we are one of the few full in-person tech startups. Cool. Well, if you're NYC-based or desire to be NYC-based, give them a shout.

Greg Tomas, thank you so much for, you know, iteration, patience, you know, listening to the community, caring about the community, open sourcing the parts you can, obviously, and just caring about better workflows. We all need better workflows. All efficiencies are welcome here. So thank you for your time today. And thank you for, I guess, the hope in a modern code review process. Thank you. Well, hey, thank you for having us. Yeah, no, exciting

to be here. That's it. This show's done. Thank you for tuning in. What do you think about Graphite? What do you think about this modern approach to pull requests and the workflow involved in helping teams be more efficient with merging changes. Let us know in the comments. Links are in the show notes. To our loyal Plus Plus subscribers, there is a bonus after the show, so stay tuned. If you haven't joined Plus Plus yet, now's the time. Check it out at changelog.com slash plus plus.

Big thanks again to Greg and to Moss for the work they're doing at Graphite and sharing their wisdom here on the show today. Of course, a tremendous thanks to our friends and partners at Fastly. Our pods are fast globally because Fastly is fast globally. Check them out at Fastly.com. Breakmaster Cylinder is, of course, our beats master in residence. Those beats are banging. We love them.

Thank you, BMC. And of course, last but not least thank you to you for listening to the show all the way to the very end if you haven't yet subscribed head to changelog.fm for all the ways to subscribe that's it this show's done we'll see you next week Thank you. Game on.