Brendan: Welcome to PodRocket. I'm Brendan I'm on the engineering team here at LogRocket, and joining me today are Tomas Reimers and Greg Foster co-founders of Graphite. These two joined us last year to talk about Screenplay, a tool to make deploying and rolling back iOS applications, as simple as it is for web applications, but their current project is Graphite, which is an open source CLI and dashboard tool, trying to make the entire code review process better for engineering teams of all sizes. Tomas, Greg, welcome back to PodRocket. How's it going? Greg: Thanks. Yeah, it's wonderful to be here. Tomas: Yeah. Thank you. Exciting to be back. I think that we're the first ones to have two slots on your podcast. It's our favorite dev tools podcast. Brendan: We love repeat victims here at PodRocket. So before we dive into to talking about Graphite in some more detail, can you maybe reintroduce yourselves to our audience for anyone who didn't catch the first episode and then start by catching us up on what's happened over the past year or so? Tomas: Absolutely so happy to start. My name's Tomas, one of three co-founders here. Before this, I was at Facebook. I was at Facebook for about three years. I worked on mobile infrastructure there, helping product teams develop product faster, left to start Screenplay with Greg and Merrill two close friends from college and yeah, the rest is history. And we'll talk about it, I'm sure. Greg: Yeah. And I'm Greg, as Tomas alluded to, I've been friends with him, the other, co-founders not on this podcast Merrill all the way back since college. Tomas and I, we used to be roommates out in San Francisco every summer doing internships. We were project partners on nearly every CS class, staying up very late into the evenings. I was a morning person. He was an evening person, so he'd go to sleep and I'd wake up and we just kind of keep coding the problem sets. But it turns out that you can make friends with people in college, maintain lifelong friendships, and then turn those into companies, and for me at least, it's just a dream come true that we now are all assembled in New York. We're working the stuff we love and we're building out a cool company. Last thing I'll call. I used to do work at Airbnb as well. I was on their back-end engineering team, but working with friends and having excuse to move from San Francisco to New York was too tempting. Brendan: Gotcha. Yeah. So as we've alluded to, you guys have kind of shifted focus over the past year. So I'd love to hear sort of what's changed and maybe where the idea for Graphite came from and how you started working on it. Tomas: Totally. So when we last talked, we were working on Screenplay. Screenplay was a tool to roll back mobile iOS apps in the same way you can roll back web apps. The idea came from this insight of what we really want to do is we want to speed up the software development process and we want to do so while maintaining a high quality bar and releasing good software, right? And we believe that a lot of that was improving the development and deployment cycle of mobile apps. It was in building that process. We were fortunate enough that I actually get to work with a few of my old coworkers who have joined the team since. In building that we realized that one of the things we missed so much from our old workflows at Facebook was our code review tooling. Code review tooling, for those of you who are not familiar with the breadth of tooling that exists, or who maybe just used GitHub, actually varies a lot from company to company in the sense that many of the largest companies, Microsoft, Google, Facebook have all built their own tooling. Tomas: So CodeFlow, Gerrit and Phabricator, and then many slightly smaller companies, but still large companies. So I think like Uber, Pinterest, et cetera, those ones all use one of those tooling. So I believe both of those use Phabricator, and many teams below that size actually start to customize it. And so early on, I think one of the things that we realized was, wow, we really missed some of the code review features that we saw in Phabricator at Facebook. We, for a long time talked about spinning up Phabricator here. Greg, I think has a funny story where he was like... Greg: Well mean I came from Airbnb, which was a straight GitHub shop, and I worked on the deployments team and we were constantly trying to optimize. Okay, can we get people to ship small changes very frequently. We know from a deployment standpoint that helps things run smoothly, but it was just straight GitHub. You do these large poll requests, you get them merged in eventually. And when we came to work together, and work on a startup, we said, 'Okay, hey, we're going to cohost on GitHub. We have a little bit of open source. It's quite De Facto'. Greg: Tomas and our other teammates from Facebook, they said, "Hey, what about this opensource thing named Phabricator. It's got this other workflow." And it sounds good on paper it's a good idea of a workflow, but I really don't want to run the 10 year old PHP app that was sort of being end of lifed in the opensource community. We'd have to put all of our code hosting on it, if we just wanted to do the code review on it. It was a little bit too big of an ask. So we considered it and we said, you know what? We're just going to stick and suffer with GitHub for the time being. Tomas: Yeah, and in suffering with GitHub, I think that one of the things that we decided to do was to build a little bit on top of it, right. So it was okay, we can stick with GitHub, but let's build some of this workflows tooling on top of it, and so Graphite was born and this was now early last year. So this would've been beginning of 2021. And so we built that out. We had it, it was interesting, continued to work on mobile releases, but... Greg: It was cool, because I was sitting internally and I'm watching my peers putting up these 20 poll requests at the same time, which are all really clean and interdependent. And I'm sitting here with my Airbnb workflow, and I'm like, wow, okay. This is looking extremely productive. Greg: They're using HomeHack scripts to make this work. But this was the first time I was being exposed from a reviewer standpoint of a faster workflow. Tomas: Yeah, and so we started to build it. I remember at the time we would have these questions every so often with other former coworkers, or perhaps even customers who just saw it on the screen being like, 'what's that?', and we'd be like, 'Oh, that's our code review tooling. Don't worry about that. Let's focus on the product that we're selling'. And they'd be like, well, 'hold on, can we use that?' And for a long time we said, 'No'. And last summer Phabricator announced that they were going to sort of close up shop. And that's what the first catalyst moment when we were like, 'Well, maybe we should consider offering this'. Brendan: Yeah. So I'm kind of curious to hear what are some of the things that are kind of missing from that? I don't know, De Facto, GitHub poll request workflow that you felt like you could bring to teams or that you needed for your own workflow to be productive, because I think, myself and probably a lot of people listening have spent most of their careers working on smaller teams then at Facebook and at Google. So what are some of the things that sort of are missing from that workflow? Greg: I can speak to at least the first point, there's a variety of features. One of which that's most at the heart of this, is this idea of stacking. I think the longer I've worked in engineering, I tell this to Tomas, the longer I've worked in engineering, the more I see every system, you eventually evolve into a dependency graph or a dag. And this is sort of the evolution of code changes into a dag. So if before you have a trunk and you create one feature off of that, and maybe it's a hundred lines, maybe it's a little bit bigger in 500 lines. So be it, you put it up, you wait for code review and you're a little bit blocked. Maybe you go work on a separate branch. Maybe if you want to keep expanding on that first branch, you just kind of keep tacking onto that larger and larger poll request. Greg: That's not ideal because you end up with something large, anything that's large is going to be reviewed slower by your peers, because they're going to procrastinate it. And it's going to get a lower quality review and debugging, we all know debugging large code changes is a total hassle because you can't bisect within any one bug. So we allow through this workflow through what we're kind of copying Phabricator, the ability to stack interdependent small changes. So what would normally be larger, maybe added API endpoint as well as the server data model, as well as the front end GUI that hits on that all within one large code change. Now, hypothetically, in that example, you could break it up into three changes or perhaps you create a library with a test on it and then you create the actual call site hitting that, you can just fragment out your code changes. Greg: Each one independently is passing continuous integration tests. It's getting code reviewed. They can be merged in either as a group, or one at a time in a kind of a zipper merge function. It doesn't matter. But you as a developer, just never blocked because you can keep branching off your branches. Now, most people, myself included, if you use Git long enough, you sometimes wonder you're like, 'Maybe I should just branch off my branch'. It doesn't stop you from doing that. But without extra tooling, it's nearly impossible, because the moment you get feedback on that first poll request in your stack and you go and make a modification. Now you have to recursively rebate very carefully, every branch stacked on top of that. And if that's 10 branches or 20 branches, that's kind of outside the realm of practicality, likewise, resubmitting those, keeping those in sync with GitHub, keeping those poll requests up to date becomes just unpractical without extra tooling. Greg: So for me, it was using that stacked workflow and literally submitting 10 poll requests at the same time and merging in 10 at the same time, that I got that very cheesy feeling of 'Wow, this is actually like 10 X better', as a developer. It felt very empowering. Tomas: No, I mean, I think something I'll add to that is this workflow. Isn't also incompatible with Git, right. What we're encouraging is that you continue to use Git, your coworkers continue to review the code the exact way they always have. You continue to revoke you their code the way they have, the way we like to envision Graphite in this workflow is it's an addition to right, and so you can use Graphite as a very fancy GitHub client to just code review other people, to create poll requests for code review by other people, in a way that meets them where they are. Greg: Fundamentally within the stacking part of the workflow. Graphite suggests keeping track of the dependencies between those Git branches, but it still Git branches. It still Git commits at any point you can break out and keep running, Git commands. Brendan: Gotcha. So as a user, if I'm sort of adopting Graphite on my team, or just sort of myself, how does it fit in with my existing tooling? Am I calling this in my command line instead of Git? It obviously has a web interface. How am I shifting my workflow or my tool chain, when I get my hands on Graphite? Tomas: Wonderful question. So I think for many users, when they start using Graphite. Graphite becomes a drop-in replacement for Git. So what you'll see is that for many people its oh cool. Instead of doing check out dash B with Git, let me start doing branch, create with Graphite. And that's sort of the first interaction which starts to get you into the workflow, and Graphite the tool, the command line tool, will guide you towards creating these stacks of branches, and these dependent poll requests. As far as the website goes, we like to think about that, as I said before, as a very fancy GitHub client. All it is a client to GitHub. You can see the same poll request you can see on GitHub. You can interact with them in the same way. Heck if you leave a pending comment on Graphite that will show up in GitHub. Tomas: We try to keep everything one to one as best as we can, but with a little bit of added functionality. So things like being able to comment on unchanged lines, having keyboard shortcuts, right. Being able to see all the information in one place. That is what Graphite is trying to do and make it just much easier to review poll requests, along with making this workflow, the stacking workflow that we've talked about first class. Greg: Yeah, I think one core principle going into this that was so important to us forged out of our own needs was one, any user could adopt as little of the workflows they want to, and they'd be fine. They could just use one command from the CLI and still keep using GitHub. They could just use the web client and not the CLI as little as you want, and you can expand your usage, but there's no all or nothing approach. That was one of the things that turned us off a Phabricator originally. And second principle is that your teammates should not have to be bothered by the fact that you're trying out, or using this workflow. For them, they could still see your changes on GitHub. They can pull them down to Git, they can keep working with you. They do not have to make any accommodations that was really important to us. Brendan: Right, and obviously for a new tool, that's a making adoption incremental is obviously a smart strategy to get people comfortable trying it out. Greg: A hundred percent. Honestly it was one of the greatest challenges we had when we were exploring Rollbacks was there wasn't really an incremental way to install a large Rollback based SDK into a mobile app. It was all or nothing, and we felt like that was really impeding adoption. Graphite's been the total opposite, people just pick it up, they use on a side project, they bring it to their team at work. We've just seen this fantastic natural spread. Tomas: Yeah. Now you were asking before, so how do you think around sort of what we add on top of GitHub, or perhaps how do we think about that difference? I think one of the things... We get asked that question all the time, and one of the ways I've come to reason about it is, I think GitHub is fantastic for open source development. So if you're committing poll request, open source, repositories, GitHub is the best tool in class. I believe everyone knows that makes a ton of sense. But when you're working within a company, poll requests actually look quite different, right. In an open source repo, I have many committers, many of whom I've never met, I have no idea what their level of competency is, or if they're here to like stick it out, and really help improve the code base, or if they're just trying to do a drive by add some code and leave. Tomas: In a company, you have a much more reasonable expectation of, oh, I know Greg, I review however many, 10 of Greg's PRS every day, right. I have an idea who he is, what he's working on, what he's trying to accomplish. And so the tools I need are less around moderation and locking a thread and saying, 'Oh, this process is we expect it to take weeks'. Instead, it's 'We expect this process to take minutes or at most an hour', how do we make the tooling that fits around that workflow, and really guides you the developer so that you can get through code review as quickly as possible. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcast, and because of that, it would really help if you could follow us on Apple Podcasts. So we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Brendan: One of the challenges that you called out with using a sort of traditional Git based workflow was stacking branches on top of each other, becomes this recursive mess. When you try to untangle them, or merge incremental changes back between any subset of them. But I would imagine if you're integrating with GitHub, you're having to interface with, or try to solve that challenge in some way. What are some of those interesting technical complexities, or sort of hard problems that you guys have had to solve as you've started building out Graphite? Tomas: Oh, I mean so many. What's interesting building a code review tool is not a simple task. So I think when we start to think around, what are the challenges we have, one of them is the data model is ultimately owned by GitHub and Git, because ultimately, we want to be able to integrate and write back to both of those. Actually for a lot of the core data. So for example, where are your stack stored? What are the dependencies? We actually store all of that in Git, because we believe that that data is yours, and we want you to own it. Now, figuring out how to do something like use Git as an arbitrary key value store is really tough. We have a whole blog about how we were like, 'Well, we know we can store data and hashes in here. How do we basically map metadata around branches into the store, such that we can keep it there'. Tomas: I think on top of that, we have all the challenges that you might find in any real time collaborative web app, right. So when we think around code review, it's fundamentally this very human process, which is two people talking to each other about the best way to write code. And that's awesome. That's super cool. But that means that all of the challenges that you find in almost a chat app, or a document app, you're going to find in Graphite. And then I think the technical challenge above that is language understanding, right? It's this idea of, if you want good diffing, your good syntax highlighting, that's hard. That's the kind of stuff that we've now started having to pull out and starting to expand as we have more users, and more languages asking us for more features, right? And so that's really cool to get to build, and that's been a lot of fun. Greg: I agree with Tomas. Over the time, there's just been so many subtleties. If we want to keep again everything in sync, but we want to extend functionality, we try to get kind of crafty. One fun example is we allow people to comment on unchanged lines within poll request. This is like an age old complaint on GitHub. If you go three lines out of what was actually changed, you can't leave the comment, silly restriction. So we can support that in our interface. But we also, again, want to save that back to GitHub. So what we do is we, when you create one of those outbound comments, we store the true location information of the comment in HTML metadata on that comment, which we then saved the GitHub, including a preview of the targeted line. So it's semi viewable in GitHub, but when we read that from the Graphite client, and we present that information, we're able to reposition the comment exactly where we wanted to be. That's a small example, but there's lots of these little challenges of how do we extend that functionality while trying to be as compatible as possible. Brendan: Yeah, and it seems obvious that GitHub is probably the place to start, right? The first place to go, if you want to integrate with, code storage. Are you planning to expand to Bitbucket, GitLab, like other tools as well, and try to be sort of a universal client for this stacking workflow? What's the world domination plan? Greg: It's a great question. Our take is that, we want to decouple the coder review from the code hosting. You as a developer, or as a team, or company shouldn't have to couple those two decisions. If you want code host on GitHub, you want to code hosts on GitLab. Maybe you want to self code hosts, whatever that may be, that should just be the same as just choosing an arbitrary database or data store for your application. That shouldn't also be coupled with all of this user experience. I think I speak with both of us, in that we'd love to just be every layer on top of that hosting. Tomas: Yeah. I mean, I think we have someone who uses GitLab reach out to us, maybe weekly being like, 'Hey, when are you going to have GitLab support? We really need this'. And if that's you, if you're listening to this podcast being like, 'I really need this, and I'm on GitLab', please reach out. We have a wait list. We do intend to be able to support more, get repositories sooner. Right now, I think what we're really focused on is how do we make the GitHub experience best in class, and then the way we've architected our system is such that when we one day need to start swapping out those back ends for wherever else, you might be storing your code. We're ready to do that as well. Brendan: And so I think that makes sense with your story also about wanting to be able to store metadata in Git itself, and make that data sort of portable with the Git repository versus the hosting service. Are there any other sort of integration points with Git itself that you've had to create, or had to work on in building out the project? Tomas: It's tough to describe without suddenly just diving real deep into it. One of the ones we've recently been working on, is this idea of revisions. So one of the features that people really want to know is, Hey, I pushed a version of my poll request, maybe then I, the author or the person I'm reviewing, they force pushed, or they amended, or they something. And they now have another revision of the poll request. Is there any way to see that original revision that I have? Now in Git, Git kind of throws that data away, right. If you actually go ahead and edit history, it becomes hard to recover it. You can, but it's difficult. What we do as a platform is that's actually where we start to say like, oh cool, there's certain imutable pieces of data in Git that we can pull out such that one year later, when you later asked the question, wait, what was I looking at before? Tomas: We can answer that for you. So that's been a fun one that we've been working on recently. Greg: Yeah. I really like it as someone who, again, didn't have this functionality, this exists at Facebook. I didn't have this at Airbnb, but when I go to a poll request, sometimes I just want to see what's changed since my last review. If I gave this person a bunch of notes, and they're asking me to re-review it, I can turn on a filter, and Graphite, and I can say, oh, okay, great, you added the three lines that I was asking for. Even if that was a force push, even if that was amend, makes a trivial from the reviewer standpoint. Tomas: Yeah. Brendan: Another thing I think that you sort of hinted at was obviously being in a position to access people's source code is a very privileged level of access as an application, and obviously something that people should take seriously. So I'm curious how you've approached the sort of security and privacy aspect story? Tomas: Oh, that is top of mind right now. We are just sort of rounding the bases on Socket Compliance, which we are so excited to be able to offer to our customers. I think for us, it started with security at the beginning, right. We are aware of how much we value our own source code. Again, this started as an internal tool, and when we started building it, we were like, okay, how do we protect our own source code? And then as we started to bring on other people, we were very lucky in that the first batch of users we brought on will represent very large companies. And we were like, okay, we need to figure out how to protect their source code as well. And so we've at every juncture made the decision of like, how do we keep this more secure, not less. Tomas: And now we've formalized that with clients, by going through various security reviews, by opening up our architecture and data flow diagrams to other people so that they can give us a third party opinion, and be like, 'Yep, that makes sense. That is what we would expect', or perhaps you could harden your systems these ways. That's all made sense to us. And then we think sort of the final leap there is going through these third party compliancies, or attestations to make sure that we share, and other people can keep us accountable to, we really are doing the most we can here. Greg: Yeah. It's a moving target. I think no system is perfectly secure, but we are constantly staffing efforts and continuously improving it. I don't think we're ever going to call it done effort. I think it's going to be a permanent effort at our company, but luckily I know I'm proud that a variety of companies, including ones, with high levels of security and compliance have trusted us with that source control access. And I think it's on us to respect that. Brendan: And is that something that you found people's sort of needs and wants around security are pretty consistent, or have you found a really wide range of what people are sort of looking for you to do, or want from you as a provider? Tomas: I think it's really interesting. So when people start to ask us around security, everyone asks roughly the same questions, which I think is a good sign of like, 'Okay, these are best practices'. Fortunately, they're all things that we all meet or exceed, and then I think what's most interesting to me has been who asks for what, and what helps get people that understanding. I think for some people it's simply looking at our customer list, and being like these people trust us. Happy to talk to you, but for many people they're like, 'Hey, actually that's enough', for some people 'It's okay, can you send over the di the like various technical diagrams that make sense?' And they're like, 'Cool, that's enough'. Some people really want to get on the phone, and talk to us. We are always happy to do that. You can email security@Graphite.dev. We would be more than happy to have a conversation with you around how we approach security, what we think about it. That's been great too. Brendan: And I guess my last sort of technical question to dive into. I'm curious, what does your stack look like as you're building Graphite? Obviously you're using Graphite for part of your workflow, but what are some of your other tools, languages that you're working with? Tomas: If I can actually touch on that, one of the funniest things I find, and many of these security reviews, I don't know... A middle question that you'll frequently get is, do you all do code review? And I always laugh at that one because I'm like, yes, certainly we do. That would be funny if we did. Greg: It is great working on a product that's so dog foodable. I use our product constantly to make our product. But yeah, no, to answer our stack. One part of our stack is Graphite itself to code review, but fundamentally with the actual architecture, it's really nothing too crazy. Honestly, it's similar to most modern web apps. We use React on the front end. It's a single page app stored an S3 bucket fronted with CloudFront. On the server end, we store everything on AWS. Greg: We route through a load balancer, hitting containers, running on Fargate compute within ECS. Those containers are running servers written in Express, which is just a standard backend Node framework. Really it's TypeScript all the way through, which is really nice. We have to reuse some of our common definitions and libraries. For monitoring, we have a bit of Datadog to keep track of errors and logs and give us alerting. For deployments, we use a combination of GitHub actions for CI, and building artifacts as well as some manual scripts to help execute those deployments and rollbacks all in a continuous fashion. Greg: For data store, we keep it with Postgres once again on Amazon with RDS, nothing too crazy there. A little bit of data lake through Redshift and for cron jobs, we run some Lambdas on a timer or on certain triggers, but using the same server image, just running through different entry points. The nice part is we've tried to keep it as monolithic as possible, both in a monorepo, but in a monolithic server image for infrastructure, that's helped us move really quickly as a small early team. I'm sometimes critical of early companies who move to SOA very quickly, because they want the abstraction. They want a way to kind of containerized logic, and sometimes that also slows people down. So we've really tried to keep it monolithic as possible. Brendan: Yeah. So really focused on the simplicity, consistency, just being able to ship fast, which again, makes sense. You guys are still obviously a very small team. Greg: It's how can we move as quickly as possible, while keeping things safe and high quality. And for us, that honestly gets back to the heart of what we truly believe in with this product is small changes shipped frequently, and continuously. Just many small changes. We facilitate it and we get to live it every day. Brendan: Yeah. Well, that's a pretty good segue, I guess, to ask. So what does the team look like today? How has it grown sort of since you started and what are your plans over the next year? What do you see in the company looking like in 2023? Greg: Sure. Well, we are proud that we just announced fundraising. Series A, backed Andreessen Horowitz. That gives us the capital and runway to grow out this team. We've kept it small up until this point, with three founders and three other team members who have joined us, but honestly, with some good usage, some excitement, many feature requests. It's up to us to expand that team, expand our bandwidth and rise to those demands. So we fully intend to be growing and currently are. Our engineering team, we're looking to hire another lead designer. We're looking to help bring on people who can help us keep nurturing and growing the user community. We have a wonderful Slack community of, I think, nearly 3000 people and growing. That's the community. We want to, both be working with, providing resources to online, maybe even having in-person events, COVID allowing within New York and other places. Greg: This all requires massive efforts to grow the team. Obviously, really the fundamental one that's going to require a lot of effort is engineering. For us what's important is, can we keep that quality bar high? Can we bring in smart kind people expand the team? If that takes time, we're willing to spend it, but I'm excited, and I think the pipeline's looking good. Tomas: Yeah. I mean, to answer the question concretely, I think by end of year, we're hoping to be at around 20 or 30 people, and we hope to only grow from there. The goal is, I think for, as Greg said, when we were first working on this, a lot of it was just, 'Hey, can we build out all the initial code necessary to prove out that this makes sense, this is the product that meets users, what they need'. Tomas: I think now we actually believe we have that proof. We see hundreds of signups every week. What we're looking for now is, 'Okay, can we take this and scale it?', right. And scaling it, I think just requires a lot of people as we start to get into the nitty gritty, both of how do we get our data synced to just be faster, to write more efficiently to GitHub, possibly be swapped out with something else one day, for example, GitLab. And then the other question is how do we work on those realtime collaborative social features, right? So when we think around like, oh, your code reviewing with someone else, how do we make that faster? How do we make that sing, both on a product level, but also on a technical architecture level. Brendan: Yeah. You mentioned you're hiring a designer and that made me kind of curious, how that sort of design and UX consideration fits into your workflow, and your vision for the product, because on the one hand, I think there's this idea of something that's really dogfoodable. You kind of know intuitively a lot of what you want, but at the same time, you don't want to fall in the trap of assuming you know everything your users want. So how do you envision sort of, design and UX playing a role in such a developer centric tool? Tomas: We've been very fortunate in that since the start, I think design has been important to us. We hired our lead designer Xiulung very early on into this process before we even pivoted. I think that as a developer, it's really easy to fall into the trap of, yes, I know exactly what I want, and I think as a developer, you understand your needs well, but you don't necessarily understand the best way to satisfy them or how well representative they are of the community. I am incredibly at fault for this ill regularly be like I have this use case and therefore, every other engineer has this use case that is frequently not true. Frequently I have this use case fullstop. And so having a designer who both can understand the technical, or at least is willing to learn the technical, but also can take a critical eye towards what does our user community need. Tomas: What's the best way to satisfy it. Look beyond the ask, right. So frequently it's, Hey, I say, I need this. And it's like, okay, but why? What are you actually looking for, right, because it's not always what you say you're looking for. Greg: Yeah. Xiulung on our team, he's on 10 plus user interviews a week, speaking to users and doing it in a way that we as engineers are completely inexperienced. How do you not ask leading questions, how do you actually listen correctly, and hear the true needs, and then synthesizing that into a beautiful user interface. I mean, we take a lot of respect around some other topnotch tools, things like Linear, which they took Asana as a task manager, which was powerful, but rough on the edges, and made it also a delightful, productive experience. We look at those kind of companies we say, can we do something similar with code review? Can we keep it powerful, but can we also say this tool that you, as an engineer spend 30 minutes an hour a day in, can we make that delightful, high quality, a perfect user experience too? Now our background as engineers is not enough. We need help from expert designers. Brendan: I also don't want to leave without talking a little bit more about the fundraise. One, congratulations. That's sort of an amazing step forward. Anything more that you can, or want to say about that process? Like what was raising money? What were some of the things that maybe did, or didn't resonate with the investors that you talked to, that were going to be surprising to you? Tomas: Yeah. So if you haven't seen the news, we just raised 20 million from Andreessen Horowitz, specifically the partner who will be joining our board is Peter Levine. Peter was one of the first investors in GitHub. We're very fortunate to have him. I think that for us, what was most important going into the fundraise, was finding a partner who we believe shared our vision on code review can be better, and code review isn't just this workflows that engineers do. It's a fundamentally social experience, right. You work with other people to get your code review. It's not you and a machine. And so with that, we were very excited to see a16z come to us and say, we share your vision. We understand it. We've seen this play out before, and we want to support you throughout this journey. And so we're very excited about it. Tomas: We were very excited to talk to a lot of people. I think some investors certainly saw that vision and they're like, yes, we'd love to partner with you. Some of them, I think, wanted to push us more into the enterprise enterprise market, which is what we're not trying to do. I think what we hope is with this fundraise, this name and number shows our users like, "Hey, we're really here for you. We want to make the best tool for you. We have a lot of runway to do that." And so now it's just about executing the net. Brendan: And I guess we always sort of like to come with close with some variation of this question, which is, what is the future of developer collaboration and code review. What's going to be different five years from now than what I'm doing today in GitHub? Tomas: I'll give my broad thoughts. I think when we look at things like document or design editing, we've moved towards this realtime collaborative. I think code is slightly different, because there are these mid broken states that we don't necessarily share. But I think that what the future might hold for us is something like a branching model where you and I collaborate on code isn't painful. And me waiting for code review from you. Doesn't block me. And that's what Graphite's setting out to build. Greg: Yeah. I think Tomas said it well. I'll just say it in a different way, which is just smaller, more frequent code changes. I think that the average size of PRS, if you were to somehow measure that across companies today versus five years, it's going to decrease. We started this with continuous delivery. The continuation of that is going to be these large stacks of ever emerging poll requests, creating constant flow, each one independently passing CI, and independently passing review. I think it leads to a net faster experience and higher quality product shipping. Brendan: Really exciting. Guys, thank you so much for joining us. It was great to have you on. Is there anything else besides Graphite, obviously that you would like to point our listeners to? Tomas: Well, so we actually have a blog post coming out, I think next week on the LogRocket blogs. So definitely keep an eye out for that, and other than that, Graphite.dev. Greg: And I think, beyond Graphite. I mean, you're hearing on this podcast, I was talking about independent poll request, stack changes, but this is not a concept we invented. There's actually a lot of cool material online. If you just Google for stack changes or stack diffs, I think there's a lot of interesting writing that exists talking about these different types of workflow, independent of anyone tooling. I encourage any ambitious developer to read up on that. I had never heard about that before a few years ago. And now I see the truth. Brendan: Thanks for coming on the pod and we'll see you online. Greg: Cool. Thanks for having us. Tomas: Thank you. Emily: Thanks for listening to PodRocket. You can find us at PodRocket pod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.