The Changelog: Software Development, Open Source - ANTHOLOGY - Wasm, efficient code review & the industrial metaverse (Interview)

Episode Date: December 2, 2022

This week we're back at All Things Open 2022 covering the hallway track. Up first is Shivay Lamba and he's schooling us on all things server-side WASM. It's the new hotness. After that, we talk with Yishai Beeri, CTO of LinearB about the world of code review, PR queues, AI developers, and making human developers more efficient, and happier. And last, we talk with Guy Martin from NVIDIA about what's going on in the Industrial Metaverse. He shares details about an open source project developed by Pixar called Universal Scene Description (USD) and what they're doing with NVIDIA Omniverse.

this week on the changelog we're going back to all things open this is our second installment our second anthology episode from the hallway track at all things open 2022 up first is shiva lamba schooling us on all things server-side wasm it It's the new hotness. After that, we talked with Yishai Berry, CTO of LinearB, about the world of code review, PRQs, AI developers, and making human developers more efficient and happier. And last up, we talked with Guy Martin

from NVIDIA. He shares details about an open-source project developed by Pixar called Universal Scene Description, USD, and the role it plays in NVIDIA Omniverse. Again, a massive thank you to Todd and the team at All Things Open for having us to cover the hallway track. It's so much fun.

And also a big thank you to our friends and our partners at Fastly and Fly. Our pods are fasted down low globally because, hey, Fastly is fast globally. Check them out at fastly.com and our friends at Fly. Let's just put your app and your database closer to users all over the world with no ops required. Check them out at fastly.com and our friends at Fly Let You Put Your App and your database closer users all over the world with no ops required. Check them out at fly.io. This episode is brought to you by our friends at Fly. Run your full stack apps and your databases, close your users all over the world.

No ops required. And I'm here with Brad Gessler, who is helping to build the future Rails cloud at Fly. Brad, what's got you excited about Rails on Fly? It's no secret that Rails is this really productive framework and application. We've also seen that happen. There's a bajillion different hosts that you can choose from out there that all make it really easy to deploy your Rails applications.

We've had these for years. There's nothing really magical about that anymore. It's just, this is what we'd expect. We want to type a deploy command and this thing ends up on a server somewhere. The thing that I think that sets Fly apart from all that is it scales. It has so many scaling stories. It has, again, the table stakes stuff. Oh, wow, you can add more memory to a machine. All those things you would expect from a hosting provider. Again, Fly, you can scale out. You're going to have customers that live in Singapore,

that live in Frankfurt. You need to get servers there. Fly lets you do that. Again, with just a few commands, you can provision all these servers in these different parts of the world. And then the real magic with one command, you can type in fly deploy, and you have all these servers provisioned around the world. They just work. People hit yourcompany.com, and they're hitting the Frankfurt server, and the same person in Singapore is typing

in your.com, and it just works, and they're hitting your servers in Singapore. So this thing scales out beautifully, which is really important, especially if you're starting to run turbo applications or turbo native applications where you need that really low latency. Your application needs to respond to these users in under 100 milliseconds. Otherwise, to them, it's not going to be instant. They're going to be waiting. It's important to be fast and Fly makes that possible. The reason I joined it is because of this kind of global magic that we're going to be shipping. And that's something that I want to bring to Rails developers

all around the world. That's awesome. Thanks, Brad. So the future Rails cloud is at Fly. Global magic is on its way. Try it free today at fly.io. Again, fly.io. We're here to talk about server-side web assembly, right? Yes. This is the new hotness.

Is it the new hotness? I think so. This is burgeoning, right? It's on the cusp. It's right there. So much so that I don't really understand it. So inform us, school us. First of all, why?

But then I think the how for me is also confusing. So yeah, why WebAssembly on the server? So I just kind of want to go back and explain very briefly what WebAssembly is. So WebAssembly is this bytecode and it's a compilation target for a lot of the various powerful languages like Rust, C++.

So it was started as a browser technology to kind of circumvent some of the issues that come with JavaScript. Right. And because of the performance limitations of JavaScript, you could run other programming languages directly on the browser with the help of WebAssembly because browser natively only supports JavaScript. Right. So you could compile other programming languages and functions in those languages like C++ or Rust

into these WebAssembly bytecodes. And you can run these WebAssembly bytecodes with JavaScript to be able to run some more highly performant functions. But we saw that the usage of WebAssembly was not just limited to the browser. And we saw that because of some of the benefits that come with WebAssembly, and those are primarily three of them.

The first one is the portability. So WebAssembly bytecodes are very small in nature, right? So they have a very small blueprint and very small size. Now the second one is the security sandbox model of WebAssembly. What that means is that the WebAssembly itself, like the actual bytecode cannot do anything on its own. So it's very, I mean, it's not susceptible to attacks from viruses or some third-party attacks.

You use some other technologies such as Vozzy, which is WebAssembly's system interface, to be able to make API calls or interact with, let's say, the file system. So it's a very secure sandbox model that is followed within WebAssembly. And these are primarily the biggest reasons why WebAssembly today is also being used on the server side. So one of the biggest areas where you see it being used

is with the help of containers. So if you take a look at the standard Linux containers, the Linux containers are usually very big in size, so they are large, and they also have a very large boot up time. So if you are willing to spin up a container, it will take a lot of time to spin up. But WebAssembly containers on the other hand are much more smaller and they spin up a lot more faster.

So anywhere from the range of one time, like 10x to 100x in terms of like, you know, being smaller in size and also in terms of the boot time. So if you are having a lot of applications on the edge, on the server side, that are mainly resource constant, you're able to run these applications very quickly with the help of a WebAssembly container. So these are some of the biggest reasons why we are seeing now WebAssembly, not just on the browser side,

but also picking up a lot on the server side. Okay, so what technology is underneath the WebAssembly? Do you still need like V8 or something? Or how is it running inside of the Linux operating system or whatever it's running on? Yeah, so the best part about WebAssembly is that there's no underlying technology as such. So WebAssembly itself is a dedicated technology in itself. So the idea is that the bytecode that we generate, the WebAssembly bytecode, that is

independent, right? It is portable. That means that it's not dependent on a particular system. So the same bytecode, you could technically run it on a Linux system or you could run it on the browser, right? So the bytecode itself is independent.

Now of course, because it's a target, it's a compilation target, right? So you take a particular function and you compile it. And again, it's a polyglot environment. That means you could use either, like let's say your functional languages or even your scripting languages like PHP, JavaScript, Python to basically,

like compile it into the WebAssembly bytecode. Weren't the initial implementations, though, inside of browsers? So then the browser vendors were the first ones to basically implement WebAssembly bytecode execution inside of their browsers. Yeah. So then was there an effort outside of the browsers to bring it to Linux or something, or how did that work? Yeah. So just to kind of recap on the entire history,

and I'll be very brief in that. So WebAssembly standards basically started with AssemblyJS. So there's an alliance called the Bytecode Alliance. Right. Yeah, which basically started with AssemblyJS, and this is primarily, again, focused on bringing some of the capabilities that you find with assembly language and being able to port that over to the JavaScript landscape.

But what the assembly folks or people who are working on assembly JS, they wanted to work on maintaining assembly JS but also ensure that it met with the W3C standards, with other standard web standards. So that kind of led to the growth of WebAssembly as a tool. And there's of course a funny story why it is kept, like the name was kept as Web and Assembly.

Although it's not, I mean generally, it's not just limited to web, or like WebAssembly itself format, it's not very similar to Assembly. It's like, you know, it's different. It's neither web nor assembly. Exactly, right. So, but that's the way it started. That's the web nor assembly. Exactly. Right.

But that's the way it started. That's the way it started. Yeah, that's where its roots were, but that's not where it lives anymore. That's not what it is. So as we saw that... That's why you just say a WASM, because at that point, you're not confused. Yes. Right. Exactly.

What's WASM mean? Well, it's short for WebAssembly. Yeah. Because I think that's the number one preconceived notion that people carry with WebAssembly, is that it's related to web. But of course, I mean, so I was just last week at KubeCon,

which is one of the largest developer conferences for Kubernetes and cloud-led technologies. And I would just say that WebAssembly was the central talking point in every conversation that I went. There were a number of companies that are today working on WebAssembly and specifically server-side WebAssembly.

So I also gave a couple of talks on WebAssembly at KubeCon and also over here at AllThingsOpen. Okay. And it's just there. It's growing and you're having uses of WebAssembly, server-side WebAssembly in running databases.

It's being used to run within Kubernetes. It's also running alongside Docker containers. Docker recently just announced their partnership of being able to run Docker with WebAssembly. So all of this is just showing that people are really appreciating and adopting WebAssembly in their day-to-day usage within the server-side. Okay. It's portable. It's portable. It's secure.

And it's fast. Boot time. Fast. So those are obviously huge advantages. Where would it fit in, or where would you say a use case of WebAssembly is, server-side WebAssembly, or even with Docker?

Like, what would a Docker-powered WASM thing look like? Yes, so that's a really great question. So primarily you could think of it in this way, that let's say if you are working with an IoT device, right? So the IoT device will have very limited storage and very limited compute power. Now, if you were to run a standard Docker container on that environment, again, as I mentioned,

that Docker containers will have a very long load time, and they will spin up in a very long time, right? And what you want is a small blueprint, like for your runtime to be small. So that's where you could basically use a WebAssembly container, and this WebAssembly container will be small, it will be fast to boot,

and you could do your main inference. For example, it could be machine inference or any type of inference on the actual WebAssembly container. Whereas your standard Docker containers would still be able to handle anything related to your standard input output, for example, file management or anything that you want, right? So all the network capabilities could still be managed

with the help of your Docker containers. So the architecture that we're kind of looking at is that you're not, basically, the idea is that you're not replacing your containers or your Docker containers with WebAssembly, but they are meant to basically run side by side together. Interact with each other. Yeah, where they basically help

and work well together with each other. Your fast boot times, especially for running specific functions, are being handled with WebAssembly, and your Docker containers are doing all the standard operations that you'll typically have in such kind of a system. Yeah. So we see a lot of people talking about this in the edge compute space. Yeah.

We know Vercel's talking about it. We know that Dino, for example, Ryan Dahl's written about, I can't remember what his post was, but it was basically like web containers or something. It was the same concept. So that's an obvious place where the fast boot time is very important for them. Definitely. Right, because your serverless functions have to be there,

and you don't want them to be cold starts all the time. So they're getting gains there. Yeah, and one of the examples that you mentioned was the recently announced Vercel Edge Functions, which, again, use the Vercel Edge runtime, and that's mainly powered by the V8 and WebAssembly. And again, the main idea is the small blueprint of WebAssembly. One of the other areas that we also see,

especially on the serverless function side, is that typically if you're having, let's say, a serverless function, you might use AWS Lambda, Netlify functions, or even Vercel functions. Typically, you'll have your programming languages like Python or JavaScript that you're writing your serverless functions in. But if you're writing your functions in WebAssembly, again, one of the biggest benefits that you get is the portability. That you're not dependent on a particular environment's dependencies that will make your serverless functions have to change based on the dependencies, right? Very similar to how the VMs and container concept came into the picture.

That's where web assembly serverless functions can also play a role. And of course, you get the added benefit of the web assembly security sandbox model that helps you to secure these functions. So you just create one function, and you can deploy it anywhere that you want. And that's how the Vercel edge functions also work, that you have these edge locations, and whichever is closest to your area,

automatically, I mean dynamically, those edge functions will spin up in that particular area whichever is nearest to you. And you are using the power of WebAssembly to do that compute quickly. Yeah. It's super fascinating. This technology that began in the web browser might actually be more relevant outside of

it. We're starting, like I said, this is the beginning of this phase. Huge excitement at KubeCon. So the builders are starting to build things. We'll see downstream applications here coming up. Vercel Edge Functions is a good example. WebAssembly in the browser, though, has it ever really delivered on its promises?

Figma really knocked it out of the park. Definitely. Where was the Figma-inspired followers of that technology? It seemed like Figma was kind of a standalone of like, here's a really rich, the holy grail of a Photoshop-esque thing in the browser that works really well. And they did it with WebAssembly, right? And then, like, what else was going on in the WebAssembly space in the browser?

Cool stuff? A lot. A lot of cool stuff. So, actually, one of the talks that I gave at ATO was also around TensorFlow.js, which is a machine learning library for web. And one of the great ways that you can actually use TensorFlow.js is doing the machine learning inference on the web browser. And there are a number of different backends that are supported.

And what I mean by these backends is not like your dedicated server. But what you can use is things like WebGL and WebAssembly itself. So TensorFlow.js has a WebAssembly support. So what you can use is that if you support or you use the WebAssembly backend, you could use the CPU or the GPU resources of your own system and do those machine learning inference much more quicker in the web browser.

So that's one of the, probably the biggest areas where WebAssembly on the browser side is being used. Apart from that, there are a number of different companies like Adobe, which uses it for the Photoshop on the web browser, Microsoft Flight Simulator. And then there are a number of different companies like Adobe which uses it for the Photoshop on the web browser, Microsoft Flight Simulator and then there are a bunch of video editors online video editors that use

WebAssembly for doing rendering of very quick rendering of the videos. So those are just some of the examples but one thing that I'd like to touch upon is so the CNCF which is the Cloud Native Computing Foundation they conducted a micro survey a few months back on the state of WebAssembly. And to be honest, like, the results just came

out just before KubeCon. And one, like, you could say that in terms of the percentage of the usage of WebAssembly inside the browser and outside the browser, today, more people are using WebAssembly outside the browser than outside the browser. Today, more people are using WebAssembly outside the browser than inside the browser. So I am not entirely sure of the exact metrics. Again, you can probably go and check out the CNCF WebAssembly forum, and you'll be able to find those metrics. But it's definitely true that WebAssembly

has grown a lot more than just being a web technology and now as a full stack technology probably because you see it across various spectrums, not just like front end, back end and even databases. Very cool stuff. Well, where can people go to learn more? Okay, so there are a bunch of different links

that I'd like to share. So the first one is definitely visit the WebAssembly. wasm.io. That's kind of the landing page for everything that you want to, if you want to get started with WebAssembly. Then we have the Bytecode Alliance, which is primarily the governing body

that determines and comes up with new proposals for WebAssembly. So you can join the weekly meetings that go on there. Now, specifically, if you're looking to get into the WebAssembly on the serverAssembly on the server side or on the cloud-native side,

there are a number of channels in the CNC of Slack, which is the Cloud-Native Computing Foundation Slack. So if you're more interested on the server side and on the cloud-native side, then you can definitely join those. And apart from that, there are a number of different edX courses that are free of cost that you can definitely

take a look at in order to understand what exactly is WebAssembly. And I think one of the biggest developer experience issues that people usually find is they don't understand the WebAssembly format. So again, you'll find it very similar to assembly language, but the thing is that you don't have to write the code in WebAssembly format. It's mainly served as a compilation target. So that means just know the basics

of how assembly language works, how, like, you know, internally, how operating system works, right? If you have that decent amount of knowledge about those, then you'll be able to capture the essence or how WebAssembly basically works, like, you know, a lot better. So I'll definitely recommend to have

at least basic knowledge about these concepts before getting started with WebAssembly. What's up, friends? This episode is brought to you by Sourcegraph. With the release of Sourcegraph 4.0 and the Starship event just a few weeks behind us, it is super clear that Sourcegraph is becoming not just code search, but a full-on code intelligence platform. And I'm here with Joel Kortler, product manager of Code Insights for Sourcegraph. Joel, this move from code search to code intelligence is a really big deal. How would you explain this feature, Code Insights, if you're just talking to folks in the hallway track of your favorite conference. I would really start with the technical because before I was product manager,

I used to be an engineer as well. And it's really cool and exciting just to be able to say, we're going to turn your code base into a database. And the structured language that you need to interact is just the ability to write a code search, you know, literal search, that's totally fine. Regular expression, you know, that'll give you a few more advanced options, even a structural search. But the number of long tail possibilities that unlocks, truly the journey of building this product was just saying, well, we've just unlocked, you know, an infinite number of possibilities.

We got to figure out some immediate use cases so we can start to, you know, invest in this product, build it and sell it. But we're only getting started in terms of the number of uses that we're uncovering for it. The story I told you about discovering like version tracking turned out to be a really important use case that wasn't even on our roadmap six months prior to discovering that as we were already planning to launch this product until we talked to enough folks, realized this was a problem and then found, well, oh, that's like a simple regular expression capture group that you can just plug right in because we really built this system to not limit the power of what we built. We don't want to give you like three out of the box templates

and you can only change like one character or something. It's truly like the templates are there to hold your hand and get you started. But if you can come up with anything you want to track in your code base, you can do that with Code Insights. I love it. Thank you, Joel. So right now there is a treasure trove of insights

just waiting for you. Living inside your code base, your code base is now a queryable database. Thanks to Sourcegraph. This opens up a world of possibility for your code and the intelligence you can gain from it. A good next step is to go to about.sourcegraph.com slash code dash insights. The link will be in the show notes. See how the teams are using this awesome feature again, about.sourcegraph.com slash code dash insights. Again, this link is in the show notes.

All right, we got Yashai Biri here from LinearB and Dev Interrupted. Yes. Which is your podcast. That's right. Welcome, welcome, welcome. Tell us what you're up to with LinearB. So LinearB is a startup that's focused on helping developers and dev teams improve. Basically looking at the data in your development process, your Git, your Jira,

understand what's holding the teams back, where are the bottlenecks. For executives, we show them dashboards, metrics, DORA metrics, and ways to manage improvement. And for developers, we provide a real-time alerting engine. We have a smart bot called WorkerBee that lets developers know about what they need to do right now to push forward their work. So what's like, what is the thing you found holding developers back most of the time? Like what's the big one?

The big one is the code review process. The PR or MR, depending on your gig. Merge request, pull request, code review. Yeah. So we found... Code review is pretty universal. It's universal. And we found that, you know, on average, a change

could wait for two to four to six and beyond days just to get reviewed and eventually merged. I'm talking about days. Days and weeks. Weeks. Wow. We're just talking about queues. That's a queue, right? It's both a queue, but it's also like there's a human

that's eventually going to review your stuff. It's not the only thing they're doing. They're not always aware of the queue, so they're not efficiently working the queue. So they're not efficiently working the queue. But also, today in most organizations, there's like a single queue. All PRs look the same. They all get the same treatment. Even if it's a one-liner change to your documentation or a complete refactor of a sensitive system, it's going to get the same treatment. Someone has a review for a principle or something and then the queue becomes stupid.

Right. And so one of the things that we're pushing is a system called GitStream which is about automating and providing some routing and automation for your PRs. So as a team you can decide which PRs are automatically approved. So ship it and then tell the team or show the team, maybe someone wants to take a look.

Maybe some PRs need three reviewers because they're touching sensitive areas. So it's like a rule file that you put in your repo, some GitHub actions on top of that to automate the work. And then you stop doing the reviews that you should not be doing. Right. And you have time to focus on the reviews that matter. Well, that's the question.

It's like, what's the point of a code review? There's, yeah. I obviously know what the point is. I mean, I'm not that naive. So there's a bunch of reasons. What's the point as an organization? As an organization. As a code review.

Right. Why do organizations go through the process of code review? Like, what's the ending goal of that exercise? I think you have, like, three main reasons. One is keeping the code quality up, making sure that code structure, decisions made in the, you know, architecting the code or the change, and sometimes finding bugs. That's one reason people do code reviews. The other is to make sure more people in the team understand the code base, understand and there's not like one owner or only the person who wrote the code knows what's happening.

So it's a way to spread knowledge. It's a great way to onboard new developers to the team or juniors because you can coach them through code reviews and then eventually have them review code of others as they grow into the team. So we in Liner B, we use that metric to really show how you've successfully onboarded someone. They're starting to do code reviews for others in a substantial scale that's a successfully onboarded engineer. So should every pull request or merge request require code review? You're saying no, right? Based on this rule file. Yeah, I'm saying you can be smart about it. Okay. So the principle for code reviews, yes, that the quality, get some knowledge spread, get more people to own. But not every change requires the same level of review or even a human review.

What kind of rules can you have, such as like amount of code touched, maybe specific files that are modified or what? Yeah, the file types, specific files are passed, the size of the change, the nature of the change. We have teams that default to two reviewers because they're in a regulated industry, and they're using the rules to drop down to just one reviewer in some cases. Like, okay, if it's a documentation change or a change to CSS, maybe I don't need two reviewers. Or maybe I can auto-approve and rely on my tests

and other automated systems to make sure there's no really bad thing going into my code base. So it's a combination of the complexity, the size, the types. And you can connect this to basically any test. So if you have some custom logic that will look at the code change and decide, oh, this is a change with some label, you can use that as an input to say, okay, the rule now is to do something. We have a team that's using this to, like if a developer is using a deprecated API internally in their code base, then automatically request changes. Like so the Gitstream bot will tell the developer,

hey you should change your usage to avoid the deprecated API. So that's a specialized kind of use case. Yeah. Cool stuff. Going back to the blocking or the queuing aspect of a code review, I'm curious if you've thought about or you've worked at all with stacked diffs in order for people to move on in their work while they're still waiting for code reviews of certain things. Is this something you guys have used or advocate for or have tooling around?

So we look at code reviews, there's like two types of problems. One is the queuing and waiting on humans, waiting on a process, which we solve for directly. And typically developers move on to other code, open another branch and do another feature or another bug. So they're not blocked, but their work is blocked. This PR that I just opened may need to wait for a few days. I can still move on with other stuff, but my work is now delayed. Yeah. And I'm not learning.

And there is a context switch, which is going to be expensive. If I get the review back in three days oh my mind is already elsewhere I need to reload all that so that is something we solve for directly the other kind of problem is those accumulated merge conflicts so all these solutions around stacking those like merge queues now g Now GitHub is playing in that area as well. So that's not something we solve for directly. This is more on managing the order in which things get merged and the complexity of merging multiple changes.

We're more focused on the human problem, not the technical, like, diff problem. Gotcha. So what if the human isn't there? Like? You know where I'm going with this, right? Like automated... GetUp Copilot or something like it will eventually review our code, right? It writes a lot of it, tests. I know lots of people who have all their tests written by GetUp Copilot. So what happens when the human isn't there anymore

for code review? So I think it's a good thing if you have automated even your basic reviews. We already have tests today, right? We have quality gates and linters and whatnot that are kind of a code review. Some teams still manually do style comments and requests

and changes. Double quotes. I know for every request for him, I go and take him from four spaces to two spaces. I'm just kidding. Yeah. You better. I think going from human to machine in that area is great, not just because of the efficiency, but also it takes away the sting of having to quabble about this.

Right. There's a well-defined standard, and the machine just tells you stuff so I think simple code reviews done by Copilot or similar like AI that oh I'm guessing

this needs a change right that is a good thing it frees the developers to focus their review time on more advanced things like okay what's actually going to happen

right or you forgot to make that change in the other repo because only together they would work. Right. Like dependencies and complex. I think humans are not going away. Yeah. They can move up the complexity scale and leave it alone.

It's kind of like a pre-commit hook, you know? Like before you actually open that code review request, you've already had the robots code review it for you before you had the robots code review it for you before you take the human step, right? So maybe you like go back to the cycle and write some more code because get a co-pilot or tab 9 or whoever said, hey man this code sucks, you know, fix these seven things. Bad code. So now you're just not blocking that code review but eventually you gotta get back to it. I think eventually the divide between your local code and the PR can go away. There's no real difference between a pre-commit hook and tests running on a get-up-action

once you have created a PR. It's just like I look at this as a continuum. It's about how long does the test take to run. Is it something that can run as I type in the IDE? But it has the same purpose, right? The same meaning. Right, right. I was using pre-commit hook metaphorically, meaning things I do before I actually request a code review from my boss or from whomever. So before you invoke a human-

Yeah, exactly. You got to automate stuff. Right. And you probably should not be reviewing code that does not pass the test and is, you know, failing on the early stuff. Right. Because you want to be... Get kicked to the curb for doing that.

Yeah. But once you get the humans involved... You're out of here. Once you have humans involved, there is also a lot of smart automation or semi-automation that you can do. Yeah. also a lot of smart automation or semi-automation that you can do. Like, I find you the best reviewer based on the code changes, and I assign the PR to that person. What if they're not responding quick enough?

Right. Or they're out. Maybe they're on vacation for a couple days. So today you have, as the PR owner, you have to manage and chase people. And if a system, a scheduler took that away from me and said, okay, he's not responding. I have the next one lined up. Their review queue is pretty shallow.

I can get them to respond. This person's busy. He has 10 reviews lined up. I'm not going to bother him. That kind of management is something humans suck at. Yeah. And code and automation could be really good. Automation, yeah. That's cool stuff for sure. So that kind of management is something humans suck at. And code and automation could be really good. Automation, yeah.

That's cool stuff for sure. What about when it's actually on the code reviewer's desk and they're ready to work on it? Is there anything we can do for them in their work while they're actually reviewing to help them be more efficient, more effective, get it done faster, et cetera? Yes. To help them be more efficient, more effective, get it done faster, et cetera. So the first smart thing you can do is before they start to work, give them context about those reviews in the queue. Yeah. Because one review is going to take them five minutes, and the other review is going to take them 40 minutes. Right. So we have a feature called estimated review time.

Knock out the easy ones. In the notification you get for a code review, we already tell you how long it's going to take you. Some machine learning, lots of data. So if it's a 30 minute thing, you're not going to do this between meetings. You're going to set some time. If it's a two minute

thing, you can do this. Get it done. Get it out of the office cool so context is key for making smart decisions about when to review and then for inside the review i think the like find a smart way for the issuer to leave some breadcrumbs on how you should be approaching this i'm talking about the complex reviews not the single pr. So can you record like a mini guide or leave like this is one, two, three, four, five. These are the areas.

That's the order you should be looking at the changes and maybe some small notes. I'm thinking that can... Or some sort of synopsis, some sort of summary. Like this is why I wrote the code I wrote. Yeah, so developers don't like to document. You should like the code I wrote. Yeah, so developers don't like to document. You should like the code I wrote. Yeah.

Right? So documenting is great, but it's a lot of, like, developers don't like to do that. You have PR templates, you have all that. That's great. Right. But can I maybe leave some, you know, inline comments saying number one, number two, number three,

and then get some sort of... Who's I, the coder who wrote the code? The coder, leave some, like then get some sort of... Who's I? The coder who wrote the code? The coder leaves some breadcrumbs thinking about the reviewer and at least the order and the process that they're going to go through. That could be interesting to help the reviewer get into what I'm doing and understand what I was going for. So now the code review is done. Are we done? So code review done for me means the PR can get merged. Yeah. Right?

So, yeah, when we're done with that, you're in most cases now up to your CD or deployment schedule that's either completely owned by the developers and then it's typically continuous or it's out of their hands and then it's going to be waterfall. But they can't control it. At least measure it so you know how long it takes for code that got merged to

make it to production or to make it to staging. So you have a notion of the delay and how much you're paying in delayed learning cycles. Right. Because my code has to sit for three weeks before the release is cut,

and customers can actually enjoy it. But in many cases, it's out of the developer's hands by that time. How would you summarize what you do then? Is this fair to say? Would you say, as LinearB, we help humans successfully review and merge code. I mean, we help developers, which is a type of human, mostly. Usually. Well, you said humans.

I'm back on the humans, because we were talking about robots versus humans. I guess, at the basic level... The humans. Yeah, sure, of course. Developers. Would an AI be a developer, though? Not yet. Not yet. It's about the human process.

We're getting us a bandage here, but the point is... More than the machine process. Right. And helping the team deliver, you know, deliver faster, more consistently, have, you know, less days that suck with context switches and blocks. So, it's developer experience. Feel better as a developer because developers like to produce

and like to get their code actually, you know. Out there. Out there. Of course. And so better developer experience, better efficiency and productivity as a team. That's what we do. Now, let me ask you one more potential curveball.

What happens when most of the code reviews are not done by humans anymore? Will Linear B have to pivot? No. So code reviews is just part of what we look at. We look at the whole cycle. But when more gets automated, you're left with more difficult code reviews, the complex ones, and that's still a human process thing. So you will still want to measure and you will still want to make sure you're helping your

humans do the right thing and remove context. Helping your humans. Remove the context switch costs and pain. So you're just when that future happens, we've moved the problem to the even more lucrative complex code review part. Okay. We've removed the simple ones.

Even more lucrative. The stupid ones. So you could charge more for like harder code reviews? Well, I mean, how is it more lucrative, I guess, is the better question. More lucrative is a problem itself. Okay. Right. Like that part is not going away. It's worth more, it's more valuable, so if you can solve a problem, you make more. Today, I would say the first step into getting more efficient is to get rid of the meaningless or stupid or very, very simple PRs that you don't really need to review.

That's going to free up a lot of your time to review and be more efficient about the heavy ones. Then the next step is to be smarter about your scheduling and your decision making in those code reviews. Another critical thing that can help the team is knowing when to go sync for a code review. Instead of doing async comments on the pull request, there's a time when you say, okay, now I need to pull the, it's going to be more efficient if I pull the developer and we jump on a call or grab a room

and figure this out in a sync mode. So all of this like tooling and decision support for the complex PRs, there's so much more to do there. Yeah. All right, here comes a slider. All right. What would you say if I said, cancel code review. Everything goes in. Trust your employees. We're a team here. I was almost gonna say that.

Why don't we just call it all off? Just use test and commit directly. Commit to master. Quick changes. ship it, fix it in production. Two problems. One, this works well with very strong teams. So does pair programming, right? Let's just pair program, no code reviews. If you have a consistently strong team, it can work. In reality, it's hard for all of the teams to get to that level and maintain that. The number of developers worldwide is doubling

and is still behind the needs. By definition, you're going to have a lot of juniors. That's not going away. You will have more than half of your workforce will be juniors for any foreseeable future. So code reviews and pull requests, that started as an open source thing for very, very loosely coupled distributed teams.

But it became the gold standard or the commonly accepted standard for any team doing software development, except for the very, very high end teams that are, okay, I'm good enough to work without it. So losing pull requests, that's not going to happen. They're here to stay. But starting to pull out those pull requests that can go into that mode and be ship first,

ask later. There's the ship show ask model. There's a bunch of options. And it's going to be a fraction of your PRs. Not everything. And now the smart thing is, like, how can I be intelligent about which fraction and which PR gets to go into the fast lane

and which PR gets to go to the... Which ones cause issues in production. Yep. You know what I'm saying? That's how you figure it out. Maybe, like, look at who's doing the coding. If this is a new person on the code base, give this a different treatment

than the person who wrote everything and knows in and out. Right. Maybe it's not about trust. It's about managing your resources to be most effective. Right. Right. Making developers, human developers, more efficient. I love it.

Yep. And happier. And happier. And happier. This episode is brought to you by Honeycomb. Find your most perplexing application issues. Honeycomb is a fast analysis tool that reveals the truth about every aspect of your application in production. Find out how users experience your code in complex and unpredictable environments. Find patterns and outliers across billions of rows of data and definitively solve your problems. And we use Honeycomb here at ChangeLog. That's why we welcome the opportunity to add them as one of our infrastructure partners.

In particular, we use Honeycomb to track down CDN issues recently, which we talked about at length on the Kaizen edition of the Ship It podcast. So check that out. Here's the thing. Teams who don't use Honeycomb are forced to find the needle in the haystack. They scroll through endless dashboards playing whack-a-mole. They deal with alert floods, trying to guess which one matters and they go from tool to tool to tool playing sleuth trying to figure out how all the puzzle pieces fit together it's this context switching and tool sprawl that are slowly killing teams

effectiveness and ultimately hindering their business with honeycomb you get a fast unified and clear understanding of the one thing driving your business, production. With Honeycomb, you guess less and you know more. Join the swarm and try Honeycomb free today at honeycomb.io slash changelog. Again, honeycomb.io slash changelog. I saw the GitLab person doing this, so I gotta take selfies with you guys too. Please do. Cool. I was behind the mic I think. I was hiding. The third one you guys too. Please do. Cool. I was behind the mic I think, I was hiding.

The third one you got out. I did, last one. Oh. Open scene completed for me. Open scene. Isn't that what it, OSC? No, no, no, no, Universal Scene Description. Universal Scene Description, USD.

USD. USD. United States dollar. Not United States dollar. Not United Description, USD. USD. USD. United States dollar. Not United States dollar. USD. USD. This is interesting, because this came out of Pixar, right? Yeah, it was an open source project that came out of Pixar.

It was permissively licensed. Yeah, permissively licensed, so open source project. And they built it and open sourced it because they needed a way to describe 3D worlds for visual effects, right? You need to describe a scene, the materials in it, objects, all that stuff. Yeah. And I guess about 2017, 18, NVIDIA started looking at this and said, hey, we have this thing. This was long before I joined.

I've been there eight months. And they had this thing that said, they had this need to say, hey, we have a simulation engine, right? We want to be able to define a full 3D representation of a factory, right? Or something in the real world. And USC is this great way to do this, right? So let's not reinvent the wheel. Let's go use this thing. And then since that time, you know, I've been hired, been there eight months and I'm helping them kind of understand. I have a background in open source, open standards, used to run an open standards body called Oasis Open

for a couple years, and so I was hired to kind of figure out how we understand, do a better job of understanding how to work with USD, right? We're doing a bunch of work contributing it back, but then there's conversations around what does USD look like and how do you potentially make it the HTML of the 3D web, right? Or 3D world, right?

We all know HTML. HTML makes total sense. It's a standard that everyone can agree upon. It doesn't matter what the browser is. USD can be the equivalent to that, right? And I think that from an open source and open standards perspective, there's a lot of value in beginning to understand what this looks like. So at this time, is NVIDIA the only organization using USD?

Oh no, USD is widely used. It's used in the visual effects industry. A lot of other people are looking at it and going, hey, this makes a lot of sense, and figure out how we kind of look at this and understand what this looks like. You're a user of it, right? Absolutely. NVIDIA is a user of USD. You're not in charge of it. And you mentioned one of the issues they had is that it's got such, I don't know how you describe it, like big companies, large dollar companies behind it.

They have a hard time letting contributors contribute back to it. So it's open source, right? No, I mean, they do contribute back. But you said it was challenging. It was one of the challenges. Well, I mean, it's an open source project, right? And you need to make sure you balance the needs of all the companies involved. Right.

And I think that's kind of where, from an open source perspective, we need to think about what is standardization and what is open source. How do you marry the best of open source and open standards? It's a lot of what I spent my time on at Oasis is understanding the intersection between open source and open standards. And I was telling Todd the other day, organizer Todd Lewis here, hey, we should be thinking more about this maybe for 2023 for ATO. What is the good intersection of open source and open standards? Because we've sort of, as an industry, a lot of us go into open source is great. And oh, gosh, standards. Oh, I got to go through the long process of getting something standardized. And frankly, having been involved in the standard side, I can totally see both perspectives of how open source people go, ah, standards isn't fast enough.

And standards people go, yeah, open source people, right? You have no staying power. You don't kind of understand that you've got to be in it for the long haul. You've got to be making decisions that are going to live for decades, right? So I think it's finding that balance is going to be interesting. So what is USD in its essence? Is it a language? Is it a language? Is it a specification? Is it a file format? It's not a specification now, and it's both a file format

and a runtime. So it's a way, think about, you take the visual effects perspective, right? You need to define a scene and you need to define everything that's part of that scene. All the objects in it, what all the materials are, what all the materials are what all the lighting is all of those things and the the things that nvidia has been looking at and has added is is kind of the the phys the physics part of it right i mean if you think about a visual effects shot in a movie you probably there are some cases where you want realistic physical reactions to things there's some cases you want completely unrealistic physical actions. In the Omniverse thing that NVIDIA's building, we're looking at trying to make sure we have exactly, and we have a physics engine that gives you exactly realistic physical responses. So imagine you have a factory and you've got a bunch of shelves. And I think there was a demo that we

showed of this. And somebody accidentally pushes over a shelf you want all the falling objects you want everything to react in in actual realistic physics right because you want to be able to to simulate these things so the thing that that omniverse is really built for and kind of where we think usd is extremely valuable is the ability to take any sort of digital content creation tool like autodesk Maya or Houdini or Blender and have them all work together at the same time. So anybody can be in their own digital content creation tool and you can all be working at the same time. And you can be working on a scene, everyone in their own tool,

and have it actually built and rendered in real time so you can see what's going on. The other thing we talk about with Omniverse is it kind of gives you the superpower. So if you imagine building a full factory, and we've done some work with, now since it's been BMW and others that we're working on building full factories, basically stimulating a full factory. And I mean everything from the way it looks to the way robots behave in it to the way humans behave in it. You have this ability ability if you actually get

that to work and you get IoT sensors in the robots and everything else to be able to say, okay, something happened two months ago or a day ago. You can go back in time and say, what happened? What were the conditions? What was everything that was going on? And sort of be able to do a root cause analysis. But something like Omniverse also gives you the ability to go forward in time and say, let's simulate all these different conditions that can happen.

And if you think about it, it's not just factory floors, but autonomous driving, which NVIDIA is doing work on, right? If you want to be able to simulate for autonomous driving a child running out in front of the car, obviously you don't want to do that in real life. Anything that's expensive to test. Or dangerous, right? Well, yeah, it's dangerous.

And you think about the different conditions, right? You want to be able to test for autonomous driving that is safe. You want to be able to test, okay, that child running out in front of the car in a perfect spring conditions. You want to be able to test in various lighting and various weather conditions.

And really the only way to do that. When the sun's coming up right over the horizon. Right, And really the only way to do that- When the sun's coming up right over the horizon. Right. And really the only way to do something like that is what we call synthetic data generation, right? So it's actually having the computer generate all these conditions and be able to test AIs. Yeah. And we kind of sometimes say that something like Omniverse is almost like a holodeck for

AIs, right? You want to be able to test AIs and all the conditions that potentially are going to happen. And you're not going to be able to capture all that data, realistic data. You've got to generate a large portion of it. Is that one use case of Omniverse, or is that actually Omniverse? Well, I mean, Omniverse is built to support use cases in gaming. It's built to support use cases in gaming. It's built to support use cases in autonomous driving. It's built to support basically full fidelity visualization of 3D worlds. Is that an NVIDIA product?

Yeah, Omniverse is a product that we have. Okay. Yeah. It's not just a concept. Huh? No, no, no. It's a real thing. It's a real thing.

I thought maybe it was like NVIDIA's version of the Metaverse, but they want to call it the Omniverse. Well, no, I mean, that's right. Metaverse is a hype term, right? Metaverse is a hype term. We all know this. Metaverse is like the Metaverse, but they want to call it the omniverse. Well, no, I mean, that's right. Metaverse is a hype term, right? Metaverse is a hype term. We all know this. Omniverse is like the metaverse, but you can use- What did you call it?

The universal metaverse? No, industrial. Industrial metaverse. That's right. So if GTC is our big tech show, right? And we did a bunch of stuff at GTC and also at SIGGRAPH. We did a keynote at SIGGRAPH where we talked about how the industrial metaverse, the concept of the industrial metaverse, is going to be something that is as important, some might say more important than the gaming stuff. And I love games, guys.

It's like, I love them. Which is a great thing. It's R&D for, like you said, expensive things. Like, a good example might be Event Horizon. Remember that? Not Event Horizon. That was the movie, I think it was called. Yeah, Event Horizon. That was the movie I think it was called. Yeah, Event Horizon.

That's the scary one. Never mind. Deep Blue Sea? Deep Impact. Deep Horizon, I believe. Well, whatever. It was that Louisiana oil spillage down there. To simulate what went wrong, things like that.

That would be something that you might want to do. Right. You know, Exxon Mobil. You would want them to simulate how they react to things like this. How this occurs. Physics. Right. Because that sucks for the planet, right? Right. Those are things where we probably need this basically impossible-to-replicate scenario, right?

I mean, you'd have to, like, destroy the Earth to replicate it, to test it. And you think about it, right? It's not just that one scenario. It's the multitude of scenarios that we can't even imagine. So a lot of, I think Omniverse has been used by companies that are doing wind farms, right? With the big wind... With the birds. No, no. Bird strikes or what happens when wind conditions go to some insane amount that nobody ever thought that they could. If you've simulated that ahead of building an expensive wind farm like that, you can engineer

the actual physical thing to address something that you're never going to be able to test in reality. Does this only exist in the math or is this like... No, it's an actual product, an actual technology. Oh, I understand that much. But is the product itself just running through the scenarios in some

sort of mathematical way or is it observable? Like, we say it's a holodeck for AI. I'm wondering, where do the humans fit into this? Well, the humans fit into it, if you think about it, there's support for, right now there's some support for AR glasses, but it's primarily, hey, you're all looking at a viewport, right? So a two-dimensional display, but you're looking at a viewport

that shows you everything that's happening. So if you can imagine sort of what a visual effects artist looks at today when they're building a scene, it's the same thing. You're using a viewport. I've gotten a pool design before, and they've taken me around the whole entire pool and into the pool and up around the pool and over my house. Is it like a replay of that? Yeah. Okay. Yeah, so it's what we call full fidelity visualization.

You can look at a scene from any angle. You can actually run through a set of scenarios and see what's changed. And the interesting thing is that you look at something like what Pixar needs it for, right? Again, they sometimes need unrealistic physical things to happen, but they don't have this concept of, you know, an example is you have an object and you want to throw LiDAR at it and see what the physical reaction is to that. It's not something that Pixar needs to do for visual effects, but the rest of the industry, right, that's looking at full fidelity digital twins,

you need to have a digital twin act in the virtual world as it's going to act in real life. Yeah. When do we get in this thing? Yeah. Where's the holodeck for humans and when can I sign up for it? Where's the holodeck for humans? Well, you know, the nice thing is Omniverse is free for individual users. Okay.

Right? You can go check it out. If you look at, go to NVIDIA and find, there's a search for the Omniverse page. It's available for users to play with. There's a lot of work going on to make it fully available on the cloud. We've announced a bunch of things with, like for example, Siemens, tying in with their

industrial control systems, right, and working with us in Omniverse to actually make this happen. Cool. The open source and standards part of it is the USD, right? Right. It's how do we as an industry.

How do we design the scenes? And Nvidia's done a lot of work in this and other companies have too. How do we come together to figure out how we make USD this thing that everybody is able to use, whether it's in Omniverse or in other things.

Well, Guy, thanks for joining us, Guy. Yeah, you bet. Hey, thanks, guys. Appreciate it. That's it. This show's done. done thank you for tuning in it was a blast being at all things open and an even bigger blast meeting fans new and old and everywhere in between again a big thanks to todd lewis and team for having us at all things open we appreciate the invite of course big thank you to our friends and partners at fastly and fly also to brake master cylindermaster Cylinder. Those beats are banging. All right, that's it.

The show's done. Thank you for tuning in. We will see you on Monday. Thank you. Game on.