Episode 15: Peter Pezaris, CEO of Codestream


If you notice any errors in this transcript, you can propose changes to the source.

Beyang Liu: All right, I'm here with Peter Pezaris, the founder and CEO of CodeStream, a company that's changing the way that programmers communicate over code. Peter, thanks for being on the show.

Peter Pezaris: Thanks very much for having me.

Beyang: Awesome. So before we dive into CodeStream and what it is, and how it's changing the way that we can have discussions over code, I would like to kick things off by asking people, "How did you first get into programming?"

Peter: It feels like a million years ago. I guess I first became interested in programming because my brother, I have an older brother, he's six years older and he had a couple of computers. And I pestered my parents to buy me an Atari 800. And back then, storing programs was kind of a challenge and it was expensive. So, I would write programs, but as soon as I turned the computer off, I would lose my programs, so I asked for my birthday for a hard drive or the floppy drive rather. And I remember it because I had worked so hard on writing this program, it was like a Zork-like Dungeons and Dragons type thing. And so we brought the disk drive home and back, then Plug and Play didn't exist, so I couldn't save my program because in order to plug in the floppy drive, I had to turn off the computer.

Peter: So, that was my first intro and that was back in the early days of my high school and I remember when I applied to college, actually, my college essay was titled, I'm Not Sure Exactly What I'm Going To Be, But I Know I'm Not Going To Be A Computer Scientist, because I was actually applying as a Physics Major, but then two years into college, I was like, "You know what? I love programming," and I've been a software engineer ever since.

Beyang: Awesome. And I guess the journey from there to CodeStream, you've founded a couple of software companies along the way. Care to share kind of a brief overview of that journey?

Peter: Sure, sure. Well, I went to CMU, Carnegie Mellon and while I was there, I made a whole bunch of friends and the three of them in particular, we ended up working on Wall Street at different firms after graduating. And one night over beers, we decided, we were at this bar talking about how much money Bill Gates had. And we decided that maybe instead of talking about his wealth, maybe we should talk about how we could create our own wealth. And so, that night, we decided to start a company, that was in 1995, and I've had the really good fortune of working with those same three guys ever since. CodeStream is our fourth startup. The first one was Fantasy Sports Online, so kind of embarrassingly, we're in the Fantasy Sports Hall Of Fame.

Beyang: That's awesome.

Peter: Yeah. Well, it's kind of funny, because I think it was ESPN that ran a commercial about they've made a statue to like some dude, who was like in the Fantasy Sports Hall of Fame, and it's this like really skinny, geeky-looking guy. And I'm like, "Hey, that's me." So that was the first business. And we sold it to CBS Sports and that was awesome, because those were the early days of the internet. And we had a great opportunity. We actually built one of the first versions of majorleaguebaseball.com. We built the first version of nfl.com. And so we had the chance to be really at the forefront of the initial deployment of the web, and using it as an information pathway where people would get all kinds of sports news and information.

Peter: And then the bubble burst, right? And we all sort of experienced that. And media company stopped investing online, so we had to sort of reinvent ourselves, so we started our second company that was a social media company called Multiply, that we sort of did a soft pivot into social commerce. And we had a great exit with that company selling it to Naspers, which is a massive global media company. And our third company was Glip, so we sold that to RingCentral Glip, launched the same month as Slack with an almost identical product. And although we didn't enjoy the sort of rocket ship success that Slack did, we found a great partner in RingCentral, and now, our technology is powering all of RingCentral's messaging services.

Beyang: Awesome.

Peter: And that led us, so we've started three companies, we've sold all three successfully, and now CodeStream is our fourth. And I can't say how fortunate I feel to be working with the same bunch of guys, they're all my best friends, and we've had a lot of success and a lot of fun along the way.

Beyang: It sounds awesome. It sounds like the Dream Team. And I guess a lot of developers I talked to, they kind of have this arc in their career where they work on a bunch of things where they're applying software to various domains and then at the end, they come back to developer tools, which is kind of advancing the state of their own craft. It seems like the three of you have kind of followed that arc as well.

Peter: Yeah, yeah, for sure. And for us, it's definitely that story, but also a very targeted version of that story because if you think about the three businesses that we created, the first one is Fantasy Sports Online, which at its core is moving your love for sports online and making it more fun and more social. And then our second business was social media, which on its face, everybody understands that that's moving your social life online and making it more fun and more social.

Beyang: I see, so it's all about communication and socializing with... got it, got it.

Peter: And our third business, which was competitor to Slack, that's essentially the same set of challenges, only in a different context. Now, we're making business communication online more fun and more social. And so, we finally realized, the one audience that we think is really underserved when it comes to modernizing communication flows is developers. And so, a large part of the inspiration behind CodeStream was having built these systems for so many other audiences that we're like, "Okay, let's scratch our own itch here."

Beyang: Makes sense. So, when I think about developer communication, I think of maybe a couple of different places that developers regularly communicate, I think of code reviews and pull requests, I think of chat, I think of maybe pair programming. I think of just like pinging someone. Well, I guess that's, I already said chat or talking to the person next to you, although that's increasingly hard, I guess, in kind of the post-COVID remote world. I understand that CodeStream is none of those things. It's kind of a new way of interacting and discussing code and sharing knowledge. So I guess, for the benefit of our listeners, most of whom I would imagine have not yet heard of CodeStream or are not too familiar with it, what is it?

Peter: Okay. Well, the easiest way to describe CodeStream is where we started. And it's with a very simple premise, which is that if you're looking at code and you're an editor, and you have a question about it, how do you ask that question? And I'm old enough to remember that, let's put coding aside for a second and let's talk about Office documents like word processor. So, if I'm in Microsoft Word, and I have a question about a sentence that I'm looking at, I'm old enough to remember what I used to have to do. And what I used to have to do is I would turn on track changes, I'd add a comment, I'd save the file, and then I'd email it to my teammate, who would then unpack the attachment, see what my comment was, and then email me back.

Peter: And if you think about it, at its core, that's essentially what developers are doing today, because we have an editor that we view code in and if you have a question about that code, what engineering teams tell us today is that if they want to get an answer to a question about a block of code, they select the code and they copy it, paste it into Slack, and in doing so, you lose all of the context. You have to recreate that, so you have to say, "In this repository, in this file, which is in this directory, I have a question. I'm on this branch. And I'm looking at this code and tell me why function foo is returning null for me."

Peter: And then the person who asked that question, has to stop what they're doing switch over to Slack, get distracted by a whole bunch of things, eventually, they'll get back to you, and you know. So, that level of deep context switching was something that we wanted to solve by embedding collaboration right into the document authoring tool in the same way that Google Docs now is so much better than track changes and the old versions of Microsoft Word. So, building that simple communication tool right into your programmer's editor seems like such a no brainer that when we first came up with the idea, we're like, "Somebody's definitely done this before, right? Somebody must have."

Peter: And yet in all our research, we found that really nobody had attempted it or at least not, we couldn't find any evidence of somebody having attempted it and once we got into it and tried to develop our prototype, we started to understand why. And there's basically two main reasons. The first reason is that the way that typical development is done is that everybody has a copy of the source tree, so I'll have my copy of the repo and you'll have your copy of the repo. And when I make changes, you don't immediately see those changes. So, Google Docs takes advantage of the fact that we're both looking at the same document and so, that makes it easy for me to select a sentence and then ask question about it, because we're both looking at the same thing. Well, that's not true for programmers, so that's the first hurdle we had to overcome.

Peter: And then the second hurdle we had to overcome was that, well, chances are, if you're on a team of any decent size, I'll be using one editor, and some of my teammates will be using a different editor, so we don't really have control of the authoring tool itself. And we knew we didn't want to build our own editor and try to convince everybody to just switch over because that's a pretty big competitive landscape. There's a lot of engineering effort that's going into building programmers, editors, and we didn't want to be the 51st editor list that tried to gain that market share.

Peter: So, what we decided was we would build CodeStream as a plugin for all the popular editors to provide a very simple capability, which is, if you see some code and you don't understand it, you just select the code. And you type your question works just like Google Docs, commenting does. And we've tried to hide all that complexity to make it really, really easy.

Beyang: Got it. I think that immediately prompts the number of questions in my mind, so like the vision that you're going towards is Google Docs is like experience, but in your own editor without kind of any extra mental overhead, right?

Peter: Mm-hmm (affirmative).

Beyang: But I guess like how do you get around that issue that you mentioned earlier of everyone having a different view of the source tree? Are you just kind of like pushing things up when someone makes a comment and then when another person wants to view that comment, they like pull that branch or how does that all work?

Peter: So, what were the original and this is back to the sort of the idea behind CodeStream. The idea is we want to make it easy to answer a question about code that you're looking at. So, you first select the code that you want to talk about, right? And then you add your comment and similar to how Google Docs does it, right? So, you select the sentence or you select the code block. So when you do that, we capture all the context that we need in order to present that code block to the other people on your team in a relevant way.

Peter: So, for example, if you're on branch A, and your team is on branch B, well, if the code is the same between branch A and branch B, then we don't really have to do anything different, right? We can just sort of present that to the other person on the other side the same way. If you've made some local changes, well, then we show them, we give them the opportunity, like this is the code that Peter commented on and this is the code that you have and here's the diff. And so, you can write within the message body of my question, you have little tabs, so you can see all three things.

Peter: And so it's really presented in a way, one way to think about it is that Slack or other communication tools all have what they're really, really good at, like iMessage is really good at sharing photos and talking about photos. Well, CodeStream is kind of like a messaging service that's built for talking about code. And so, we've made a code block sort of the first class object in the conversation stream and so, we've given developers the tools to be able to understand the context of all the code that's being shared.

Beyang: Got it? And so, is it more for would you say asynchronous or synchronous communication? Is it like I have a question in some code, I make a comment, and my colleague immediately gets a ping or a notification in their editor or is it more I have a question, I ask it and then sometime later, someone who will get like a batched notification or maybe an email alert, and then they'll click into that and answer my question later?

Peter: The way that we'd like to think about it is that a lot of teams use Slack and Zoom for internal communication. Those are sort of the two big exact, they're competitors in each category. We're a lot more like Slack where you can ask asynchronous questions, you can ask a group of people, you can ask the whole development team, "Hey, does anybody know how this works?" In which case, maybe it's not an immediate response, but somebody will get back to you eventually, hopefully.

Beyang: Got it.

Peter: But you can also @mention people in which case, they will get a little toast notification in their editor, "Hey, Peter needs your help with this thing," but importantly, we don't provide that sort of Zoom-like capability where it's more like pair programming. We think there are a lot of great tools for pair programming. We're not trying to compete in that space, but more of the synchronous and asynchronous, but text-based communication.

Beyang: Got it. That makes sense. So, if I'm using CodeStream, I have something like a feed perhaps of various comments that get added and then if someone @mentions me or if there's some other trigger that sets off, like, "Hey, I want to get alerted on this type of comment right away," that will immediately show up and I can go and respond to that.

Peter: That's exactly right. And it's probably worth mentioning that we do also have very robust integrations with Slack, Microsoft Teams, and just regular old email. So, in addition to having that notification come through just the CodeStream interface or come right into your editor, if you prefer or at your choice, you can have these things ping your teammates through existing channels on Slack or through @mentions or you can even just DM one of your teammates a question right from your editor.

Peter: And the key is, it's using your existing communication tools and yet, you don't have to do that context switch, because CodeStream captures the context for you. So, when you ask a question about that code, your teammates will know exactly what you're talking about because when we share that question via Slack, we'll know what repo you're in, what branch you're on, what file you've selected the code block. And we even provide a handy one click on the other side, so when you ask the question, your teammate just has to click a button, and it opens up their favorite editor right to the file that you're asking about, scroll to the right positions, they can look and see in their editor, exactly the code block that you're asking a question about.

Beyang: Yeah, it makes sense. It seems like this mode of communication, it's closest to the kind of turn around and ask your colleagues sitting next to you or paying someone on chat, that kind of mode of communication. I'm curious, though, if users of CodeStream also find it changing or affecting other modes of developer of communication. So concretely, code review is something that most teams do every single day. And, does the ability to ask better questions and get answers more quickly take some of the burden off the code review process, in your experience or do you think these are pretty like distinct modes of communication that code review is pretty separate from what you're trying to tackle?

Peter: So, that's a really interesting question and one in which like I'd like to dive in and talk about it a little bit. When we originally started CodeStream, we understood that there really wasn't any tool like it, there was no tool that made it easy to just ask question about code without having to first make a change, and then save your change and then committing the code and then pushing it and then creating a PR and have somebody pull it down and like request them as a reviewer, and then they're doing a code review, there's so many steps to that process, that we wanted to take all the friction out of it and just make it super easy, "Hey, why is this returning null for me," right?

Peter: It's because there's so many that our thesis was based around if we can reduce the amount of friction, increase the frequency of developer communication, then yes, we could make code review easier at the end of your sprint. What we found was that the customers when we first launched, the customers that were using CodeStream the most experienced that. And so, we surveyed them and of our active customers, they told us, on average, it reduced their code review time by 50% and that was awesome.

Beyang: Interesting.

Peter: That was really great.

Beyang: Is that because they were like answering questions before they got the code review or were they using it like in the context of a code review, like "I'm reviewing this diff and I'm going to hop into CodeStream to make it faster?"

Peter: A little bit. And that was the really surprising thing, it was a little bit of both. And our most active customers, when we talk to them about how they were using CodeStream, they were actually using CodeStream as a sort of ad hoc code review tool.

Beyang: Interesting.

Peter: To do code reviews before sort of the end of the sprint or instead of using a GitHub.com interface on a PR GitLab or a Bitbucket interface. And when we saw the lengths to which they had to sort of jump to use our in-editor commenting tool to perform a code review, we said, "Well, why don't we try to make their lives a little bit easier?" And so, we built a code review tool right into CodeStream. And this was the start of 2020. Our big initiative was a CodeStream code review, which we call a Feedback Request.

Peter: And the idea behind CodeStream's FRs is that it's a much lighter weight process than having to go through all the steps of creating a PR. And importantly, one of the things that we realized we could do, because we're in your editor, first of all, like creating the FR is like, super simple, it's two clicks, right? And you're done and you sent off the request. But we've also developed the capability for you to request code, request feedback on code that's not committed yet and that's not pushed yet, because we're in your editor, we see what your diffs are and at any point, you can just with two clicks of the mouse, you can just say, "Hey, how does this look so far?"

Peter: And you can share your current working changes, including all this stuff in your working tree and we package that up as a diff set, and ship it along with the feedback request object. And so, your teammate can then visualize that in their editor and provide you line by line comments or comment however they like. And then that allows you to get sort of checkpoint reviews as you're developing the code before you're ready to merge again.

Peter: Because what we hear from development teams a lot of times is that developers on the team wait too long to ask for help or wait too long to get a second pair of eyes on something. And that's incredibly demotivating, especially if you're mentoring, like a junior developer. If they've had their heads down for a whole week implementing some solution and finally, it's Friday, and they're ready for their code review and they've been like off base all week long, then it's something that happens too often. And it's a really tough thing for managers to have to deal with where you have to tell them to go redo the whole thing, which is incredibly demotivating or you have to now accept all this technical debt into your codebase.

Peter: And I think it's something that we all deal with, at some level, all the time. And anything we can do to try to reduce that and get feedback earlier in the process is really important, and fundamentally, the most important thing we can do to improve developer practices. And that's why companies like Google, they rather famously, their code reviews are an average of 26 lines, whatever it is, and they merge things in within four hours. And so, they've solved the problem a different way, which is to have these sort of micro PRs, although they comp change this, whatever. And some people are able to do that, but we interview development teams all the time, who still struggle with having big PRs that have big reviews at the end, and we're trying to develop the tools that can help them avoid that.

Beyang: Yeah, totally, I always find it's challenging, there is a definite trade-off between small and big PRs, I think the conventional wisdom has settled on like, "Okay, small PRs are better," because if it's any larger than a couple of hundred lines, it's going to be very difficult to review. But at the same time if you think about like the amount of, the quality of the change that you can get across in a couple of hundred lines versus a couple of thousand lines, right? It's very different.

Beyang: And so, it almost feels like in a lot of cases, by limiting yourself to smaller PRs, you're kind of implicitly constraining your engineering team to make these incremental evolutionary changes whereas a lot of times, a lot of value can be added by one person saying, like, "Hey, I've been thinking about this area of the code to this problem for a long time, I want to make this big sweeping change and I'm just going to go do it." But then you get this problem like this giant PR that no one else in the team feels they can review and then that's the point at which the knowledge, the shared knowledge begins to be siloed and in the mind of the one engineer.

Beyang: And then of course, like the challenge is like, "How do you spread that knowledge out to the rest of your team?" So, it sounds like how would CodeStream kind of fit into that situation? Would I as the engineer behind that big PR, would I be just be like constantly getting feedback earlier on, on that PR would I be answering questions about it kind of after the fact, as people dive into that code?

Peter: There are three ways we can help in that situation. The first way which we covered is that the code discussions can be easier. While you're sort of digging in, you can get incremental feedback by these feedback requests, so importantly, feedback requests can be disconnected from commit cadence. And that's something that we think is critically important because when you discuss code, I think putting artificial barriers of like, "I have to commit and push in order to talk about this," is incredibly limiting. Like, "Why not let people talk about code at any point in time?" We think that's like foundational to better communication. So that's the first way we can help.

Peter: The second way we can help, you talked about information sharing and knowledge sharing. Well, one of the things that the CodeStream does that we haven't touched upon yet and it's kind of cool is that we realized that in developing this algorithm that allows us to communicate about any part of the code at any time, even across branches, well, we built an algorithm that will determine for any given version of a file, for any commit SHA for a given range within that file. Where does that range end up in a future version of the file? And we had to do that in order for this commenting to work. It's a pretty sophisticated algorithm.

Beyang: That's a tricky problem.

Peter: It really is, but what it allows us to do is then save that common thread with that sort of logical location, even in future versions. And so, we can keep a linkage between the conversation and the location even after merges, after the code changes six months later, we still leave behind these annotation markers in the codebase letting a conversation took place here. So we think that that, and because we develop the algorithm, we even can do that at your option with merged PR comments. Now, some people find that really useful, some people find that less useful, but we can sort of resurface all of your merged PR comments, the comments on specific code blocks, and allow you to see them and visualize them in your editor.

Beyang: So, if I'm looking at a file, and like, "Why the heck is it written that way?" I can click a button and go spelunking into the discussion history behind that file. Is that what you were saying?

Peter: That's exactly right. And, in fact if that file contains any comments from any prior PRs or any comments from any code discussions or like from our FRs or feedback requests or any just ad hoc questions of, "Your teammate Lisa asked your teammate Joe, 'Hey, how does this work?'" And Joe explains it to him. So, all of those conversations are available for you to visualize in your editor, wherever you're looking at the code.

Peter: And so it, it can give you a much deeper history and more information about how the codebase has evolved over time. And we give you the tools to manage that sort of... basically, what we're doing is we're capturing the exhaust fumes of the conversations that are already happening about your codebase, and then we give you the tools to manage that and organize it, so it can become a form of documentation about the history of the file or the component or the whole source tree. So that's the second way that we help in, in this sort of giant PR situation.

Peter: And then the third way we can help, which actually, the newest thing we built is for GitHub specifically, but GitLab and Bitbucket are coming soon, we've built an all new PR interface, right within your editor that we believe is... well, it's just a sensational experience, because you get a nearly pixel perfect reimplementation of the GitHub.com UI for PRs, but it's inside your ID. And what this allows you to do is basically anything you can do with a PR, now you can do in the context of your editor. So you can see a list of all your PRs, we allow you to do like custom queries.

Peter: So, you can have multiple custom queries showing you exactly the PRs that you're interested in, the ones that are assigned to you, the ones that you authored, the ones that you've been requested as a reviewer. And then when you load that PR in your editor, we allow you to visualize the diffs not only using and everybody is sort of familiar with that one big long list of defuncts that GitHub provides you, right? So, you can do that, because it's a-

Beyang: Yeah. It doesn't scale well beyond a couple of files because-

Peter: It doesn't. It doesn't. And you have that view if you want it, but you also have sort of what you might be more accustomed to within editor, which is your editor's built in diff tool. So, you can visualize the changes like in a side by side and that gives you access to all your editors, you know bells and whistles like jump to definition and find file and the key bindings that you like and code intelligence and integrate it with all the PR commenting system, so you can perform your PR code reviews within your editor.

Peter: And so, the reason that this helps is that you can make those incremental changes knowing that it's less of a burden, it's less friction to get your teammates to interact with your PR, because as soon as you request them as a reviewer, they're going to get that in-editor toast notification. "Hey, Peter wants your feedback on this latest commit." They can do it right within their editor, just by clicking on that toast notification, send you the feedback back. And all this still publishes through to GitHub.com so you still have your single source of truth for that but it's a really pleasant way of working with PRs now.

Beyang: Got it? That sounds really cool. I know that GitHub has an integration into... Well, maybe not every editor but VS code. Have you tried that out at all and do you know how this would compare to that experience?

Peter: So their experience is kind of like... What's the best analogy? Like it's functional, it does the basics, but it's really limited to the basics.

Beyang: Got it.

Peter: And it also looks completely different than GitHub.com. So if what you want is sort of a different screen-

Beyang: It looks like you're in your editor and you're just viewing a diff in your editor and making a comment in line.

Peter: Right, right. So PRs actually can get quite complicated. I think there are some like 86 different event types that can happen in a PR timeline and we support nearly all of them. The editor extension that you're talking about supports, I believe, five out of the 80 plus. So it's a really limited experience that allows you to do some of the basics, and I'm sure they'll improve it over time. But our goal with CodeStream's PR interface was, first of all, to make it cross editor. We support 14 different IDEs and the experience is identical across all of them. And the second is to be 100% of what you can do on GitHub.com.

Peter: And, in fact, we'd like to describe it as 120% because we've taken everything that you can do on GitHub.com. We've re-implemented it and then we've added on top of it. For example, one of the things you can't do on GitHub.com and you can't do in their extension is you can't comment on anything that's not a part of a diff hunk, which I always found to be incredibly limiting. Like, if there's a part-

Beyang: I's very limiting, yeah.

Peter: Right? If there's a part of the PR that like you want to point somebody to some other part of the file or some other file in the codebase, you literally can't do it. So we build that right in because we have pretty advanced commenting functionality that we've built up over the versions of coaching that we developed so we make it really easy.

Peter: If you want to comment on any part of the codebase, you just select the code, you type your comment, and we'll add it to the PR.

Beyang: Yeah, that makes a lot of sense. How do you ensure a uniformity of experience across all those? What'd you say? It was like 13 different editors?

Peter: Yeah, 14.

Beyang: Fourteen.

Peter: Yeah, so that was a pretty heavy lift.

Beyang: The naive way, I guess, would be just have a web view that gets embedded into each of those. Is it like that? Or is it you built out separate native implementation for each editor?

Peter: It's a mix. It's a mix of both. Our client code is a three-tiered architecture. The front end is a web view written in React in TypeScript. Then there's a sort of agent process, kind of like a daemon that runs that handles communications, networking, it's got a local cache, that type of stuff, lots of business logic in there. And that's also written in TypeScript. And so those two layers are the same across every editor.

Peter: And then there's a middle layer that speaks directly to the editor with the editor's API language. And that's the real challenge, because I'm sure... Back in the days in the late '90s, we had the browser wars where there was MSIE versus Netscape Navigator and then Opera and then Safari came along. And as a web developer, you had a challenge because each one of them implemented their standards a little bit differently. And then Microsoft would introduce some new tag and it wouldn't be supported on the other so you had websites that said, "This requires IE 6" or whatever.

Peter: And it was kind of a nightmare but at least they were all trying to implement the same standard. They were all using HTML, and JavaScript, and CSS. Well, in the editor world, there's no such promise. Each editor has its own extension language, its own set of APIs, its own everything. And so that was a really heavylift to build those adapters that, at least for our purposes, is a layer on top of the editor that gives us a consistent API to develop it to, things like open this file, what's the current selection, what repo do you have open, all of those things, all those API calls that we have now implemented across those editors. But what's nice about that is that it allows us when we build new functionality, we can build it once and it's available across all 14 IDEs.

Beyang: Got it? What are the 14 IDEs? Do you know offhand?

Peter: Fourteen makes it sound like a little bit better than it is because it's really four or five. Yeah, maybe a little bit more than that. I'll describe them. So there's VS Code. That's the easy one. Visual Studio, also pretty easy. Although, let's take a second to congratulate Microsoft on yet another brilliant decision on marketing and branding because none of our customers understand that there's a difference between those editors and the two totally different things, but...

Beyang: Yep, yep.

Peter: Okay. So there's those two, then there's Atom, which is, unfortunately, while we're talking about editors, it's a shame that Atom hasn't stayed more relevant. I think VS Code is really taking a lot of the wind out of their sails. And I know a lot of people that really love Atom and it's a shame that it's not getting the love that it maybe deserves. So those are the first three, and then the rest are the JetBrains family of editors.

Beyang: Got it.

Peter: And the reason it's a little bit more complicated is that JetBrains has 11. Between PhpStorm, CLion, all WebStorm idea, they also have Android Studio, but that's a different maintenance track. It has different APIs so that's really kind of different. And then there's also-

Beyang: It's got different APIs.

Peter: Some, yeah. And there are subtle differences between the different JetBrains that we have to constantly work around.

Beyang: I see.

Peter: There's also two major versions of all of those editors, one using... because they switched how they do web views. And so we maintain five or six different versions of CodeStream for all the different JetBrains editors.

Beyang: Got it. Is there any roadmap for support for Emacs or vim or Xcode?

Peter: We actually have somebody helping us out with an Emacs implementation. It's worth noting that CodeStream is an open source project. We offer the client and the source code for the server as well, if you want to run your own backend. Although we do have a commercial version, CodeStream for business and CodeStream enterprise that provides all the typical things that open core companies do.

Peter: So people are encouraged if your favorite editor isn't supported yet to contact us and help us build out support for that editor. We actually find that that middle layer to connect to the editor isn't really the heavy lift once you figure out what APIs you need. And we do have that all documented, sort of a list of things that you need to implement. A lot of it is just can you get the editor to display a web view. That's a big part of it. So for an editor like Emacs, I'm not sure how satisfactory we'll be able to do that.

Beyang: Makes sense. Makes sense. So the kind of vision that you're describing for developer communication... Well, I guess, like someone once told me there's two kinds of startups or new products. There's better, faster, stronger, and brave new world. Better, faster, stronger being you take something existing and you just made a better version of it, it's clearly better but it's also clearly comparable to something that already exists.

Beyang: This strikes me as more brave new world where it's kind of this new mode of communicating and thinking. And my guess is that when you go out and you're looking for potential users and customers, you get a lot of blank stares, because there's no thing that's immediately comparable that people can say like, "Ah, it's like this but better in these ways."

Beyang: And at least in our early days, we basically had to segment. Anyone we talked to, we had to bucket either into like this person "gets it" or this person doesn't. And for the people who didn't get it, we said, "We'll get to them later. Let's focus on the people who really get it right now." Then we developed almost this kind of machine learning algorithm but human learning for detecting who is going to get it.

Beyang: We had a couple features that were like, "Oh, this person used to work at Google, they'll get it." I'm wondering if you've gone through the same process. Do you have a profile of a developer that immediately gets what you're trying to do and just says like, "Hey, I want to use that"?

Peter: We definitely have that experience as well. And I agree it's a brave new world type of product because it's a new mode of communication. What we have found is that the biggest challenge isn't so much that whether people get it immediately or not, because CodeStream, if I have the chance to demo CodeStream to somebody, I can almost guarantee that they'll be on the edge of their seat. They'll be chomping for and they'll ask, " When can I get this? I want to install it right now." Because it's such a basic, well understood thing. Communication is so fundamental and foundational and it's also the case that most developers know that the tools are limited today. They know they can't chat about code as easily as they want to and that there are...

Peter: We have this slide in one of our presentation decks where it shows, okay, this is how to ask a question about code over Slack. And believe it or not, there's like 17 different steps between copying the code, alt tabbing to Slack, finding the right channel, pasting the code, describing where it came from, going to your terminal, doing a git blame to find out who wrote the code to go back to Slack to mention every person.

Peter: So on the left hand column, there's the Slack interface, which is 17 steps. And in CodeStream, it's two steps. Select the code, type your question, right. And we automatically mention the author of the code. So people get it, right? Right away, they get it. What our challenge in our brave new world is because of some of the limitations in current editors, we can't provide exactly the user interface that we want to so we're not able to surface CodeStream functionality always at the moment that you want to do it.

Peter: And so what we find is that the customers for us that really get it are the ones that not only understand that they want to use it, but they understand when to use it. Because when you're in a source code, software engineers, by default, our natural inclination is to try to solve the problem and try to figure it out. We spent half of our time looking at code and trying to figure out what it does, right? It's our job, right?

Beyang: Yep.

Peter: And you have to accept that, "Hey, I could just ask and I'll probably get an answer that's faster than me trying to figure out or I'll get a deeper understanding." But that's kind of antithetical to the whole development culture, which is that I'm supposed to figure it out. I'm a professional developer, I'm supposed to understand code. And by admitting that I don't understand it, not only is that admitting to my teammates that I'm a weaker developer than they thought, but it's also going to bother them.

Peter: So we all have to break out of that mindset, I think, and realize that if the team were to share knowledge with each other, it's better for everybody. And if we can all just put our egos aside and say, "Hey, listen," it's going to be quicker for all of us if we all just ask a lot more questions. That's how teams become more efficient. And we've seen it time after time with customers that adapt CodeStream, they're able able to adapt that mindset. And then their productivity just goes through the roof.

Beyang: I think what you're saying makes a lot of sense. Definitely knowledge sharing and communication in development teams is one of the hardest problems to solve, especially in the modern engineering environment where you're working inside large organizations and there's a lot of contexts that can't fit inside one person's head. But let me just play devil's advocate here for a moment. Because as you mentioned, there are a lot of developers. I think it's part of our culture as developers to want to figure things out for ourselves.

Beyang: It's also a bit of our culture to want to cut out what we perceive as distractions, right. When you say that CodeStream is going to bring communication into my editor, that I'm going to receive push notifications when my colleagues have questions inside my editor. I can see for a lot of developers, that might strike them as like... the editor is my last refuge from the noise of all the different...

Beyang: I got Slack pinging me. I got Twitter, social media, all these sources of distraction. And when I sit down to code, when I open up my editor, what I really want to do is focus on writing code and I don't want to get pinged. I don't want a push notification, I don't want to talk to anyone, I just want to sit in my room and think what. Would you say to that person?

Peter: Absolutely, you have a great reason to be concerned. That being in the zone is hugely important for developers, maker's time as they call it. You need two hours of uninterrupted, I'm deeply thinking about this problem, I'm writing code, I'm not distracted. And that's one of the real benefits of having a communication tool specifically built for writing code. Because what we've found, and this is not only our own feeling using CodeStream ourselves, but in talking to customers, is that if you're in the zone and you're writing code and you get a question about code, that's not going to break your flow, that's not going to break your focus, you're still in the zone.

Peter: What breaks your flow is when you get a Slack notification that's about happy hour or a cat video, or you have to go to GitHub.com because somebody requested your review on a PR and clicking into your web browser shows you that you have 17 other tabs open. And now you see a YouTube video and then you're gone, you're lost, and then your calendar event pops up and, "Oh shoot, I have a meeting in 30 minutes."

Peter: These are the things that are really distracting and break your flow. But when you're talking about code, one of the things that... it's the ultimate signal to noise ratio in that everything that CodeStream will feed you is somehow related to your codebase. And that is a great way to keep all the other stuff out of your development flow, because what's the alternative?

Peter: I mean, you still are going to have questions. And today, if you're going to ask those via Slack, well, every time you mention somebody in Slack, you're pulling that developer out of their editor, sucking them into Slack where they're going to get lost in their Slack notifications for the next 15 minutes. Isn't it better to hit that developer about a coding question in their code editor, so they can answer you and get back to coding? And so that's really the philosophy behind it. And we find that it absolutely works that way.

Beyang: So what you're saying is, I'm already getting distracted by Slack because people need to communicate with me and I need to answer the questions. And this is strictly better than slack for code-related questions.

Peter: Yeah, because it's only going to show you the code-related stuff. Nobody is using CodeStream to share cat videos or anything else. Then there's no capability to do that, by the way. You have to select code to comment on it so unless you're really creative.

Beyang: You can't paste an animated GIF into the cloud box.

Peter: No, there's none of that stuff.

Beyang: There's no memes in CodeStream.

Peter: Right, no memes. It's all serious business only built for developers. And by the way, of course, you have control over your notifications as well. So if you don't want to get pinged in your ID, you don't have to. You can just turn that off. But in practice, we find that it's better to get pinged there about coding issues than it is to get pinged over Slack or via email, because then you're sucked out of your zone.

Beyang: You mentioned a bit about the constraints of working with the existing IDEs today within what their APIs and their GUI frameworks can provide from a user experience point of view. How do you see that evolving in the future? Is there a vision of CodeStream that you're working towards in the future that you hope to realize, but you can't today, given those present constraints? If so, what do you think is the path forward? Is it just the IDEs will improve their APIs or do you think you might get back around to creating your own IDE someday or perhaps some other application where more of that experience can live?

Peter: That's a good question. I think that most of the issues that we've had have actually been resolved. And what's fantastic is that five years from now, a product like CodeStream couldn't have even existed, because the editors weren't extensible enough from a UI perspective. And Atom really deserves credit as being the pioneer in this area, that they made it trivial to create a web view. And so extension authors, people who build extensions for IDEs, had all kinds of incredible creativity around giving you user experiences that were very robust within your editor.

Peter: And VS Code then took that mantle and ran with it and made it efficient enough that developers love their implementation. And that gives us most of what we want. Where VS Code is still a little bit tight is, for example, it wasn't until the most recent version of VS Code that we were allowed to have a web view in the sidebar, and the sidebar is where all the extensions live. So the only place you could have a web view is in a, what they call, a preview panel, which is an editor tab.

Peter: And so that's where CodeStream used to live until version 1.5 a couple weeks ago for VS Code. And because of that, it was difficult that CodeStream would fall out of you because it would get hidden behind some other tab and people wouldn't know how to find it or why does this work differently than all my other extensions. And so thankfully, the VS Code team implemented web view on the sidebar, which is awesome for us.

Peter: So now CodeStream has a home. It's got an icon on the activity bar so you can always know where to click to get to CodeStream. But weirdly, although there are badges on many of your other activity items there that show you how many things there are there that need your attention, you're not allowed to have a badge on your own activity. As a third party extension author, you can't put a badger.

Beyang: Interesting.

Peter: So, of course, as a communication tool, you need a badge. You need to know how many unread message, how many times have I been mentioned, how many things do I have to look at that are new? So we'd love to have a badge there but they don't allow yet. Is that going to make or break the company? I don't think so but we'd love and of course, we've opened up an issue and thankfully, Microsoft's been awesome to work with. They're an open source tool themselves so we can even submit a PR.

Peter: But I think the limitations are now becoming less and less and less. And I think that these modern editors, like Atom and like VS Code, have now set the standard so high that extension authors are creating such rich and wonderful experiences that I couldn't imagine somebody else trying to come to market today with an editor that doesn't have a web view extensibility capability.

Peter: So I think editors are going to have to make a choice. Do I want to be completely locked down like Apple? And if I can take two seconds to just rant about Apple and please open up your editor. Xcode, there's a lot of people using it but a lot of extension authors want to make it better. So you'll have to choose either to be closed, be basically text only, like VI or Emacs or Sublime or you're going to have to be an extensible editor like VS. Code, JetBrains and others. And I think that's the direction the world is heading.

Beyang: So we've talked a bit about putting web views inside of IDEs. But there's also another trend, which is bringing IDEs to the web in the form of cloud IDEs, things like code spaces and I think there's a long-

Peter: Coder.com, yeah.

Beyang: Coder.com, exactly. What are your thoughts on that trend? And will CodeStream integrate with those as well? And if so, does the way that people use CodeStream change at all in a cloud IDE versus a desktop native IDE?

Peter: It may not immediately be obvious why but I love the trend. I think it's awesome. I think for a lot of people, especially those who manage development environments, it's just so fantastic to be able to with one click duplicate an environment and say, "You hire a new developer on the team" and boom, they've got something to code against. So that's great.

Peter: I'm not sure how. Is it going to be 5% of the market or 50% of the market? I think it's a little too early to say whether people will just all move to developing in a cloud in the web browser or not. I'm intrigued. But whether they do or not, all the same problems exist. You still need collaboration. Just because it's in a web browser doesn't mean that all the problems that we had to solve for CodeStream have been solved. You still have to be able to communicate across branches. You still need to understand the context of what you're commenting on. You still need some sort of capability in the editor.

Peter: So just by having it in the web doesn't mean those issues are solved. So I think there is, if anything, more opportunity for CodeStream in that environment, because people will expect that type of collaboration and yet, it doesn't exist. So we can still provide it when you're using, for example, VS Code in a web browser.

Beyang: What does the next year of product feature releases for CodeStream look like?

Peter: Well, we've gotten fantastic feedback from our GitHub integration. We've just launched that recently and we're looking to improve it to maybe take that 120% to 130% or something. But we're also getting a lot of customer feedback from people who aren't using GitHub. So those who love GitLab and Bitbucket, we want to give them some love. And we know that it'll take us a few months to implement things to our standards to have a really full pull request and merge request experience right within your IDE for those services across all 14 of our IDEs.

Peter: So we're excited to do that. And one of the things that's great about collaboration solutions, and especially ones that are, as you said, breaking new ground is that there's no shortage of ideas and directions. And so our roadmap has never been longer. We've got this incredibly long list of things that we want to build and it's just limited by developer bandwidth. So that's one of the reasons that we went open source to try to open up our development process and to the extent that there are contributors out there that want to help us with our mission of building and delivering better communication to software teams around the world.

Peter: We'd love some help but there's only so many hours in the day and our team has been awesome, especially over the last several months, especially considering COVID of just delivering tons of new functionality with every new release. And I couldn't be more excited about where we are right now.

Beyang: Awesome. If someone's listening to this and they really want to try out CodeStream, what should they do?

Peter: Well, we're team CodeStream on GitHub. So just our repos are public and just contact us about how to contribute.

Beyang: My guest today has been Peter Pezaris. Peter, thanks for being on the show.

Peter: Thanks very much. It was a pleasure. It was an awesome conversation, I really appreciate it. Thank you.

Beyang: The Sourcegraph Podcast is a production of Sourcegraph, the universal code search engine, which gives you fast and expressive search over the world of code you care about. Sourcegraph also provides code navigation abilities, like jump to def and references and code review, and integrate seamlessly with your code host whether you're working in open source or on a big hairy enterprise codebase. To learn more, visit sourcegraph.com. See you next time.