The Full Spectrum of Collaboration
February 28th, 2024
In this third conversation (read the previous one here) with Zed's three co-founders Nathan, Max, and Antonio, I wanted to ask them about their views on collaboration. Collaboration in software teams in general and specifically the mode of collaboration offered by Zed — now and in the future. What is the ideal mode of collaboration? What do you think about async vs. sync work? If we follow the Zed vision of collaboration to its conclusion, will we still have git, commits, and pull requests?
This conversation was much more mellow than the previous two. Not only because it was late for Antonio and I here in Europe, but also, I think now, because what we talked about — how people work together and how we want to work together — is abstract, and personal, and maybe even more nuanced than the technical conversations we had. But while maybe more subdued, this was still a very interesting conversation that I've thought back to every day since last week when we recorded it.
What follows is an editorialized transcript of an hour long conversation. I tried to preserve intent and meaning as much as possible, while getting rid of the uhms, the likes, the you-knows, and the pauses and course-corrections that make up an in-depth conversation.
(You can watch the full conversation on our YouTube channel.)
Thorsten: Collaboration is a big part of the Zed vision. You built it from the ground up with the idea to have CRDTs and collaborative text editing in Zed. So my question is: what's missing from the tooling that we have today that makes you want to go and improve collaboration?
Max: What comes to mind with that question is a workflow that I've always envisioned and that's more fluid than what we have today: pull requests and Slack and screen sharing — the trifecta of today's collaboration tools.
To give a narrative: I'd like to be in a coffee shop, coding solo by myself, focused on something, and then realize that I need help from you. I'm not sure if you're around right now and without leaving my editor I want to leave a comment that sort of explains what question I have for you, Thorsten. "Can you explain this piece of code right here?" I don't have to go find the git blob corresponding to that code on GitHub. There's not that jump. And then I can resume what I'm doing. And then if you're in, say you're in a coffee shop at the same time, and you want to respond with text, you can just jump in and say, "oh, we changed this API. Now you need to do this." And you're coding with me for a second and you type that in chat. It's a lightweight thing.
And then I realize, "wait a minute, I have a deeper question about this. I need to talk to you." I say, "hey, can you talk?" and then, beep boop, you're in my editor, we're talking, we're pairing. You'll say "okay, we change this here, this is here, this is why this is here." I take you on a tour, we do some intense collaboration and then we part ways.
You're not looking at my screen, obviously. It's a fluid experience for you and me. And then in the future, someone comes along and sees that this changed and says, "huh, what's going on with this code?" And they see that Max and Thorsten had a conversation here. And they can sort of see that textual interaction, trace that back to how the code looked at the time they had that conversation.
That's what I want. I feel we've built a really important part of that right now, but not the asynchronous piece.
Thorsten: I could argue and say all of this is already possible with what you mentioned — Slack, Zoom, GitHub, and all of this. But the fluidity that you mentioned seems to be an important part, that you don't have to go to GitHub and leave a comment and check your emails for replies. Instead you're still in your code. It's all in one thing.
Max: Yeah, let's rewind that story and talk about the things that are possible but painful today. Today, at that initial moment when I realized I had a question for you, I then thought, okay, how do I link to this code in order to be able to refer to it and talk to Thorsten about it? I'm in the code right now. My branch has changed. I have stuff that's not pushed up. I have a decision to make. Either I push up a work-in-progress commit so that there's something on GitHub I can link you to, or I rewind and find where that code exists on a different branch and use GitHub's code browsing interface to find that code and link to it. And then I switch to Slack and say, here's the link.
So maybe by that time I've already decided: eh, nevermind, I'm not going to do that. I'll muscle through this pain a little bit longer before I decide it's even worth doing that.
So that's one moment, the very, the very beginning. And then, say that you just got my message that says I need help. Today, what you would get is a link to GitHub. And again, it may be a link to some code that's not exactly what I'm working on, just because I didn't have a way to tell you about the code that I was exactly working on. So you have this friction of, "ok, I'm in my code editor. I'm working on the same project in all likelihood. But I'm going to jump over to GitHub to look at this code, because that's what you sent me a link to. And I have to use GitHub's code navigation or Sourcegraph's code navigation or something other than my editor to look at this code. So maybe at that point in time, you go: "I'm not gonna investigate my answer that I give too deeply, because it's painful to do so." That's moment two.
And kind of the biggest of all is if I decide, "okay, this text back and forth is a little inefficient, I'd like to talk to you right now." Today with the tools that exist prior to Zed, you'd usually reach for something like a Slack huddle. And Slack huddles are fine, but the code piece of it, the sharing your screen, that's the the biggest part. You're now looking at my screen and you're feeling like, "oh, how can I get off this screen share? I'm having to look at this pixelated screen that's not my theme. I can't do anything. Let's wrap this up." So maybe at that point in time, you bounce off. It's not worth doing this.
And then finally, the people who want to find out about this conversation later because they hit the same piece of code. That's, I would say, maybe the worst piece. Say Antonio comes along looking at this code later, hits some similar issues that I discovered. I mean, if it were me today, what I would do is like, do a git blame on the file, but then the conversation's not in git, it's on GitHub. Take the SHA from the git blame, paste that into the web browser, see if this this part of a pull request? Where's the conversation here? Maybe I can find out, go to the pull request and there's no conversation. Oh, there's a ref to another issue.
The reality is I probably gave up and I decided to just reason through it myself because it's not worth finding that. Or I search for keywords in Slack. But both are painful. So for me, it's all those moments in time where you could exchange the information with today's tools, but there's a lot of points where it wouldn't be worth it today. How hard of a problem it would have to be to be worth doing that is too great.
And I think what we would like to do is make it always worth doing it, by having tools that don't hold you back.
Thorsten: Who wants to add something here? Because I have a ton of follow up questions, but I want to hear from others too.
Nathan: For me, a shared environment is where I want to be. A shared environment that encompasses the full life cycle of the process of developing the code. So with git, you have sort of a shared environment. The environment is the repository environment. But the granularity of commits, I think, really distorts our behavior around communication around code.
What is a commit? A commit is a snapshot at a point in time that's static. And right now, the only things you can really talk about are commits. But if you can only talk about something that was a snapshot at a point in time, then as time passes, the relevance of that conversation just sort of drains away, right? Because you're talking about an outdated chunk of the code.
That means we tend to only talk about new code, but there's all kinds of code that it probably makes sense to have conversations about. It's just really a pain in the neck to link to them. I could push a "WIP" commit and link to that snapshot and have a conversation. But, again, as time passes, the relevance of that conversation is just going to drain away because it's anchored to old code.
So the ability to bring conversations forward through time, actually link a conversation to a piece of code instead of a snapshot of a piece of code, actually drop an anchor to a character and as long as that character lives, being able to carry that around and see that there was a conversation tied to it — that's a big thing that's missing to me.
Antonio: On top of that, I feel like everybody has had this experience of like, I don't know, ... It's happened to me a lot of times of where I will work on something, I'll create a branch, push up a PR, and the typical workflow is that you ask for reviews and typically, the longer the PR, the worse the reviews. The longer the PR, the more chances there are that you'll get a "looks good to me, ship it", versus the smaller it is, the more probable it is that people are gonna nitpick.
And the problem of PRs today, what I really dislike about them, is that if you're good, you'll be really good at your commit messages, right? You'll describe them really perfectly and by the end of it, you'll write a summary in the PR description, right? But that summary is only your recollection of how things went. But between when you wrote the first commit and when you typed that summary, maybe a week has passed. So that's one problem.
And the other problem is that you're looking at a diff, but when you read that diff, it's in alphabetical order. That's not how I would present my diff to another human being. I would tell them, Hey, you know, these are the big pieces and ....
Nathan: Presenting a narrative to them, not just a diff.
Antonio: You know, those interactions that Max was describing, they did happen while you wrote that code, because maybe you did have that screen sharing session or you talked to your coworker, right? And just being able to capture those conversations and let them live with the code — those conversations are as important as the code.
It's almost like code is an artifact of those conversations in a way. It's an artifact of that knowledge. And right now those two things are disjoint and they're spread in several databases — GitHub, Slack, people's brains.
Just being able to unify them and capture all that knowledge seems — well, I'm really excited about that when we talk about collaboration and what Zed can do.
Nathan: There's just so many conversations about code that aren't happening that I think would happen if we had better tooling support for them. And in general, I find the vibe of a pull request to be kind of like an adversarial conversation. It's like you're trying to get it through the review and people are putting up these obstacles for you to clear and address. And there is a place for that, especially if you're all already on the same page and it's mostly a couple tweaks or whatever.
But if it's deeper than that, I prefer a more collaborative dynamic where we're just working on the thing together. I mean, that's what Zed does quite well right now. There's still improvement to be made, but it's shifting from that adversarial dynamic to a collaborative one, truly collaborative.
Thorsten: It sounds like you all share certain values in regards to collaboration. Do you think the ideal collaboration would be that we would all sit in an office next to each other and instead of sending a message, we would just point at the screen and, "hey, Nathan, come on over here. Let's look at this." Do you think this would be the ideal case and the problems we're talking about are only problems due to being remote? Or do you think that, you know, mob programming in an office with five people around one screen and everything goes on trunk, that is also not the ideal?
Nathan: No, I don't think mob programming where everything goes on trunk is reasonable. To me, it seems reasonable to be able to have separate streams of synchronized development. But I will say I spent a lot of time in an office pairing at Pivotal. And I'd much rather have my own screen and my own keyboard and my own monitor, but sit next to the person on their own screen. Because then I can navigate independently. We don't have to fight over the keyboard.
So it's less essential, I think, in an on-prem setting where we can actually look at each other and look over someone's shoulder and talk about code in a shared environment. But in a remote setting, we need a shared environment. And right now, our shared environment is GitHub, which has these constraints around you've got to take a snapshot and push it up, and there's all this friction involved in sharing that particular environment.
Or there's other tools like Slack, which aren't designed for code. Or screen sharing of various forms, which is not designed for code and so it's pixelated and only one person can do it.
So in a remote setting, I don't know how people survive as remote teams. I mean, I'm sure it happens, but I just feel like we as a team function a lot better because of the ability to actually — not 100 % of the time, but at least some of the time — work together.
Thorsten: Coming back to what Max said, that scenario where he's sitting in the coffee shop, you would send me a message and wait for an answer. If we were sitting next to each other in an office, you wouldn't just tap me on the shoulder when you have a question, you would still be mindful of not interrupting others, right?
Max: If I had to make a binary choice of sitting next to someone in the office or only ever interacting asynchronously in pull requests, I would take the former. But I think what we're trying to build is better than either.
There's still this ability to have focus time where you're only dealing with other people asynchronously, but then you can kind of jump into the synchronous interactions when you need to.
Thorsten: What I hear is that you value collaboration. Collaboration for you is not just "I need somebody to give me a checkmark on the pull request and then I get it out the door." You want to work with other people. You want to work together, you think there's importance to working as a team with others and you think the history of the software is important, how it became what it is today. Where does that come from? Is it your background working in large corporations? Is it your background working in small corporations? Or is it open source and working with lots of contributors? Or is it the three of you having worked together for 10 years and seeing how that works out?
Antonio: For me it's just more fun to write code with someone else. I'm just more stimulated intellectually. Of course, I'm excited about the product we're building, but I get as much joy building it with other people. It's part of the joy I get when I write code. And I also think it leads to better code.
I've made friends by writing code with people. At every company I've worked at. These two guys [Max & Nathan] obviously are a great example, but at other companies as well, with all the people I paired with and worked with, I established a relationship.
And I think that's so important, as human beings. And that's something that I'm really excited about. Working with other human beings, being friends with them, and building the best thing you can build together.
Nathan: And if you have a team, you're going to have to talk to these people at some point or another. It's just a question of when and how. Because yes, you could go off alone and write a bunch of software, but if you have a team, presumably the reason you have a team is because there's more software to write than one person can write by themselves. And so that means that the software in total is going to be the composition of software written by multiple people and sorry, but you're going to be communicating. So now the question is how. To me, the GitHub collaboration model has always felt like sending email. It's the asynchronous flow. And that works for certain problems. But some of these, I don't know, the problems we were working through this morning around paint order, it's just like... I'm not talking about that with others at the pace of email. I'm either sitting and thinking about it by myself all alone, or I'm in a tool that enables a finer-grained communication around that.
Thorsten: So if we go all the way with your vision, what's still left of today's tooling? Do we still have pull requests? Do we still have Git? Do we still have Git commits, branches?
Nathan: I mean, on a long enough time frame, I think it would be nice to make it more convenient to collaborate than using Git.
I mean, I do think we'll have branches. Because again, branches are a tool that facilitates working asynchronously, which is still an important way to be able to work. You've got to be able to, even if it's two groups of people that are synchronously working on two separate things, but asynchronously relative to each other. That's a fundamentally important way of being able to work.
But I think being asynchronous was a revolution when GitHub came around, because before then, branches were a pain in the neck on SVN. So I still think branches are going to exist and asynchronous workflows are going to exist. I just think it will be one point on a spectrum of potential interactions that you can have to code. And you choose that point on the spectrum, not because it's the only tool available, but because it's the approach that makes the most sense for the situation that you're in.
Thorsten: So how much of this approach to development is a cultural thing and how much of this is really the tooling? To explain where I'm coming from with this question, look at the last 15 years of DevOps: some people say, "oh, once we had the cloud and we had immutable infrastructure, that's when DevOps came to shine." And others are saying, "it's a mindset. It's how you think about developing and how you involve other teams." You three have a shared understanding of collaboration. Do you think if we built the tooling to enable it, that others will also pick it up? Or do you think it's also cultural thing, and that others have to embrace that building software as a team?
Nathan: My hope has always been that by reducing the friction involved in communicating this way massively we set people up for success in terms of moving that way with their culture.
We have all had the benefit, Max and I, pairing at Pivotal, where that was just the way it was done. Every workstation was set up for pairing. And the whole world was designed around the assumption that you're going to be pairing. And we learned how cool it was to just work with people in real time. I don't know that if I had not had that experience, if I would have powered through the hassle of screen sharing or whatever it was we did before we built Zed.
Antonio: I mean, I didn't have that experience at Pivotal, right? Prior to joining Atom, I didn't pair with anybody, right? I think the first person I really paired with intensely was Nathan. I mean, I remember those initial sessions, I was like, oh my God, this is intense. Still is. In a good way. And so, I guess Nathan and Max exposed me to the culture, you could say, but I think for me, it clicked from day one. It was intense on a technical level for me, but it was never intense on a emotional or interpersonal level. From day one it was more fun. I'm not working on this thing by myself. I'm working on it with someone else.
I feel like... — Thorsten, we've been pairing for the last, yeah, how long has it been you've joined?
Thorsten: Five, five, six, five weeks, I think.
Antonio: I feel like I could have never built a relationship with you being remote without us pairing every day. It's just not on the same level.
So, yeah, there is some culture involved, but at the same time, it's not like people are not having conversations. People do reach out to tools to have those conversations. So I think there is a need for this. And I think, yeah, having a tool that empowers you to have more conversations or just streamline the ones that you already have. Yeah, we'll be good.
Max: Yeah, I think pairing has a connotation. People view it as kind of niche or something. It's kind of associated with all these things, the two keyboards attached to the computer, the tooling associated with it, having to stop typing because someone else wants to type because the input is going to the same device.
And people say, "I don't want someone looking over my shoulder while I'm writing code." I think that's something that I've heard. But like Antonio just said, you have to have some conversations with someone unless you're just working on really easy problems. You have to have a team that you talk to. And so it's just a question of when and how.
I don't even know that we will need the term "pairing" as much anymore once it is this way [the Zed way of collaboration]. It's just another very natural means of working. It doesn't have the connotation of the two keyboards. It doesn't have the connotation of two people doing one stream of work and this inefficiency people talk about sometimes when talking about pairing.
Because we could literally both be fixing compile errors in the same buffer at the same time. So I don't know that we'll need the concept of pairing anymore. Once we're done, I think it'll just be as natural as when you're in Slack together and you're talking — we don't say that that we're pair documenting.
It'll just be the way of collaborating: you can do it in real time, you can do it separately, you can be in different buffers, you can be in the same buffer. It's just more ephemeral states. More ways of collaboration in your shared environment taking place.
Nathan: One thing I'll say, we've talked a lot about pairing or real-time collaboration, and I think it makes sense because that's the first thing we built in Zed. That's what's supported in Zed now. But the reality is, especially in my role, I just do a lot of talking. And sometimes all I want to do— It's funny, all I want to do is actually not talk to anybody and just be silent and that's where I'm excited about CRDB [the idea to store code and CRDTS in a DB, see here] for some more information] and annotations, like a text-based modality of interacting with people that is also real time, but where I don't necessarily have to talk or at least not right away, but I could just be in my code and ask a question.
The thing Max brought up early on, I'm still really excited about that mode as well. It's ironic to be one of the founders of this collaborative editor and sometimes all I want is to be quiet and have music playing or something. But it's true. And I don't think there's anything wrong with that. But I don't necessarily want to have to push a WIP commit to have a simple conversation in text either about code. So that's the next phase for us.
Thorsten: To inject myself as a non-question-asker: I do think what you said about it being on a spectrum is the most important bit, that it's not binary, a choice between sitting next to each other in office and mailing lists. And what I keep thinking of for the last 10 minutes is that when I started my first internship as a software engineer I was pairing a lot. First time I've ever done it. When I first heard about pairing, I thought this is crazy, but then I did it and the bandwidth and throughput you have and the shared understanding — it's hard to convey if you've never experienced it or never built a piece of software like this. When I then joined my next company, I was still a junior and I would often be pulled along by a senior and he would sit me down next to him and he would say, today we're going to write SQL queries, you're going to love this. And then after that, less and less pairing over the years, but I always had the knowledge that this is a mode that could be used, as in "hey, let's jump on a call or let's do this together. The next three hours, it's you and me and we do this." So I do think that knowing that the spectrum exists and that it's not a binary thing is a really powerful thing and that you can actually work together with people for five hours every day and collaborate. Um, I don't have a question, sorry. But does that mirror what you think about, that you want to make it seamless to go from one mode to the other? Sometimes collaborations means async, sometimes it means sync, sometimes I want to be left alone. But it's always within reach, without friction.
Nathan: Yeah. And the only way to do that well, and a big reason why we wanted to build Zed — not the only reason, the number one reason I wanted to build Zed is just to build the best damn code editor that exists on earth, period — but another big justification for it, at least early on, is I really think to do collaboration on software you have to put it in the tool that you're using to write the software. It's an immersive experience. So that's a controversial take. And I knew that to really sell that take, the editor had to be amazing. Right? It's not like I'm going to use some crappy editor just to collaborate. It has to be the editor I already want to use just because it's awesome. But then if I can just directly treat the code as this shared artifact, as inherent seamless part of the experience, now I'm cooking.
Thorsten: Why do you think that's controversial?
Nathan: Well, it implies that in order to use Zed as a collaboration tool, you sort of need to be all in as a team on Zed. But I think, I don't know, I think that that's fine. There'll be some people that just use Zed in a more single player mode, or maybe they use Zed more selectively, kind of with other members of the team that are using it, but maybe the whole team isn't using the editor and they still use traditional asynchronous collaboration tools in the meantime.
But I do think the pattern that exists with VS code, for example, is that one person adopted it and then gradually the whole team sort of standardizes on it. But it is a big thing, that's what made it controversial. I think of this idea as this kind of Apple approach, vertical integration. We're going to own the whole experience.
Antonio: Right. I could totally see a vision of the future where this collaborative experience is offered as... like, Zed is not the only thing that integrates with it.
One big reason for building the editor, like Nathan's saying, is that it's vertically integrated. It means that we can really produce the user experience that we want. Like we don't need to be constrained to how extensions are made in VS Code or back in Atom. We tried this once, right? In Atom, we tried building Teletype. And the big problem with Teletype, which was a package, was that the core data structures of the editor were not collaborative. And so we had this extension and it basically replicated the entire buffer. It was this parallel version of the buffer and... You could do a lot of things, but you definitely could perceive the limitations there.
So a big reason for building the editor is not having those limitations, but I could totally see a future where this collaboration kind-of-framework that we build can be interacted with from other editors. It's just not gonna be the first class experience.
Nathan: Or maybe it could be, but we wanted to build a first class experience and the only way to do that was to build it. But if somebody doesn't want to use our GPUI interface for a collaboration experience that we ended up building and we ended up standardizing and spreading out, that's fine. But that's going to be a ways from now to be real.
Thorsten: Why do you think most of the software world still runs on pull requests? In the last few years, people have been saying, "I want better code reviews, this is not it, let's use this other tool." Then people try different things, but it doesn't really take off. So why do you think that is? Have we hit a local maximum or is it the technology that was lacking or is it something else?
Nathan: I just don't think any of the other alternatives are better enough. We use pull requests. Go look at Zed's repo. Tons of pull requests, including those opened on our team. Now, a lot of those commits on there might have two authors, but we still use them. So for this modality of asynchronous, let's look at a diff, leave some comments, I mean, maybe you can sort of refine around the edges of that experience.
But the reality is that GitHub's presentation of that workflow is good enough for most people that it's not worth the additional overhead of switching to some less familiar tool or a tool where the code isn't hosted or et cetera.
But what Zed makes possible today and what it will make possible when we accomplish what we're trying to accomplish— I think I'm still in a Zed channel broadcasting this whole conversation.
Thorsten: Ha ha ha.
Antonio: Hahaha
Nathan: Okay, let me leave. Yeah.
What we're trying to accomplish just isn't possible to do with snapshots, right? We're talking about more of an operation-centric sort of CRDT or just a finer grain level of interaction. In my mind, these alternative pull request review tools or branch review tools are not really fundamentally changing the paradigm.
Antonio: And there's a lot to be said for pull requests. I think not only the presentation for snapshots is good on GitHub, there's also a lot attached to PRs, right? There's CI, right? That's also a big part of it.
Nathan: And I don't have anything against pull requests and I will continue to use them or, you know, eventually if we decide to pull that into Zed, I will continue to use asynchronous workflows. It's just, we need synchronous ones desperately, I think.
Thorsten: Nathan, you mentioned the whole software development lifecycle, which in its common definition often includes deployment, debugging, whatever, even incidents, stuff like that. But so far we only talked about the actual writing of code together.
Nathan: Right. And then what happens to that code after?
Thorsten: Yes. In your vision, would you also change the other parts too? How we debug production software, how we together look at incidents and whatnot?
Nathan: Well, I do, yeah. Not as many, not as many, but one thing Antonio and I looked at for a little bit before diving in on Zed was this idea of— GitHub used to have Hubot, which was doings ops in a Slack channel. And I thought, wouldn't it be better to have a collaborative terminal that was a shared terminal and it's a shell environment and you can chat in it, kind of like bring the chat to the shell rather than the shell to the chat. So that's one thing I would love to do, to have this collaborative situation room/ops/shared terminal type thing.
Another thought I've had around other parts of the development life cycle is just having your editor sort of be your command center into a lot of that stuff. But I haven't thought as hard about that. I mean, I've had dreams of using some of the anchoring facilities, like using the code as sort of a database almost. And so when exceptions start flowing in, you can almost write them to the code base as "an exception happened here in production" in this sort of meta layer that's floating on top of everything. And then that surfaced in the editor. And so to really start using the code base itself as like the foundation on which all this information about things that are happening in production, performance information, exceptions getting thrown, can be kind of annotated and then surfaced to the developer where you can see it. You open a file and you'd see, not in this exact version of the code, but in production, yesterday, an exception was thrown here. Isn't that interesting? So just more like integrating it together.
That's not going to ship next week by any means, but I really would love to see it.
Thorsten: Last question and I'm bringing this up because I came around on it. So, when I joined, I said, "Nathan, when do we add video calls to Zed? I need video calls in Zed." And now I'm not sure I want video calls because it changes a lot for me when I don't have to worry about how I look or what I do with my hands and face and whatever. And there's something really nice about just being on a phone call with people. Do you think this is important? Is this a kind of happy accident that you just didn't get around to video calls, but now that's how it works. Or do you think I'm overestimating the importance of audio vs. video calls?
Max: I feel the exact same way as you, Thorsten. It makes it feel more lightweight to me then when the video isn't on, at least by default. There's also something nice things about seeing all of your faces. So I haven't made a hard philosophy about it, but I kind of enjoy that I can, I don't know, be eating a burrito and like and just consult in someone's code and...
Nathan: For me, it seems fine to add. It wouldn't be that much additional complexity. So we could add it. It's just not a priority because we don't need it.
Antonio: I had a conversation with my therapist this week and we were talking about how in therapy when you go there, there's this chair and what do you call it? A sofa? Yeah. Yeah. And basically she was explaining to me how not looking at the therapist and just staring into the void kind of puts you in stream of consciousness mode.
I kind of like that about not having video, I guess. The fact that I can just stare at something and just vomit thoughts.
Nathan: But what I will say is I got a Vision Pro. I'm probably going to take it back because I think it's too heavy. I might keep it. I don't know. I'm trying to decide. But what I would like is if I could put a virtual office around me. I want a situational awareness that I don't think video really will add. I'm looking for something else.
I remember being at Pivotal and they would have wide desks and they would put like four or sometimes six desks together in like a big pod. And you'd be working together and you just feel the energy of the people around you. You kind of hear over here, like what people are talking about. And so there's something about being aware of what people are doing and where they're at.
We're trying to kind of reproduce a little bit in the channels panel where you can see faces.
And I don't think a video of Antonio's face is really that useful to me. I just need that GPtonio coding output, you know? But if I could see Max and Conrad or you and Julia ...
Antonio: ... eating burritos.
Nathan: ... sort of proximate that would be cool. But, you know, let's just try to get Following [a feature in Zed's collaboration mode] working first.