 Hi everyone, I'm David Drogenski. I'm an engineering manager on Bedrock. This is kind of a meta demo. So I'm going to be presenting about the value of dogfooding and have a group exercise for the second half. But the goal here is to really explain what dogfooding is, why it's valuable, how to do it. It may not always be a straightforward on some of the different teams here at Protocol Labs. And then how we do it on Bedrock specifically and hopefully at the end of this you'll understand the value of dogfooding and think about ways of how to apply it to your team. So with that, what is dogfooding? So dogfooding is the process of regularly using your product, otherwise known as eating your own dog food and experiencing it as a real user. And I put product here because it doesn't just have to be software. People have done this for hardware products, for physical objects, but obviously at Protocol Labs we focus on the software so we'll lean into those types of examples. So why is this valuable? Really the goal here is to build user empathy. And by that, by doing that we can actually build a better product. And you'll actually be quite surprised by the number of insights that you learn about and realize as you step into the role of a user. Taking off that developer hat, that engineering hat and just using the product, you'll start to see it in a different way. And we found that at least within Bedrock and historically like you dogfood you'll figure out, hey, this bug is really annoying. I should fix it right away. Or you'll just have a better understanding of the overall product itself. Oh, this is what this feature does. This is why it's useful. On Bedrock we have a bunch of different teams working on different areas of the tech stack. And so by having different dogfooding tasks we actually get exposure to other parts of the system and learn how that part of the codebase works. So it also gives a lot of technical knowledge sharing by just using different parts of the system. I get you more familiar with it. But ultimately it increases what I call the feedback loop of this development cycle of just iterating on using the product regularly, getting feedback regularly, you're going to improve it that much faster. How do you actually dogfood? So the ideal way is to use a piece of software on a regular basis. Now the prime example and what really got dogfooding popular was Google. They use this in almost all of their software products. And you can imagine for their search product, their biggest one, like you use search every day. If you don't come up with the result that you're looking for, you send that off to the team and they make improvements. And the key here is you have a list of users that's willing to deal with bugs and to deal with not yet production grade software so that you get that feedback regularly. Maybe my favorite example is from Apple. So when they were designing the iPhone, what they actually did the design team for their version of dogfooding, they actually carved blocks of wood and would carry it in their pocket to simulate the experience of having a device with you at all times and build a better product that way. That's maybe an extreme version of dogfooding on the design side, but it shows that you don't even have to have a fully functioning product to be actually tested out and see what it actually is like to experience that product itself. So that's the ideal. You could use a product every day. Now at PL, not all of our products, at least not yet are used every day. And so how do we simulate that experience or get that feedback sooner? So on Bedrock what we do is we actually have a team rotation. So we have three teams on Bedrock. One team for every team meeting will create a task that everyone has to complete ahead of time. And that task is time boxed to 10 minutes. And everyone on the team, it doesn't matter if you're an engineer or a product manager, will attempt to complete that task. And then at that meeting, we'll discuss how it went. We'll generate all the feedback, collect it, and the team can use that going forward to improve their product. Now the keys here are that the tasks are simple, both for creating them and also for attempting them so that anyone can do it again. It doesn't matter if you're engineer and you know how the code works or you just want to use it as a TPM, for example. It has to be easy to provide feedback. And maybe the most important thing here is that failure is okay. And what do I mean by that is like, if the user can't finish the task, that is a problem not with the user, but with the software most likely. And so like getting it that mindset, like we expect this to fail and it's okay if it fails. That's really valuable feedback for the team. That means it wasn't easy enough or the software was not good enough to perform that task from the user. And so that's actually expected. And that's I think a good mindset to have when you're dog-fooding these versions of software as we develop them live. So this is kind of like a visual map of how that works. Again, we have three teams on bedrock. We rotate them, one team will create a task. Everyone on the team spends 10 minutes sometime throughout the week. And then they try to complete that task. We talk in the meeting how it went. We provide that feedback to the team and then it rotates. So that's kind of how we do it. Okay, so we're going to try a really quick group exercise here. On the right is a template that we use on bedrock for like creating a task. So you name the task. This is actually a copy of the latest dog-fooding task we did on the team. The demo day edition. When do we want people to complete it by? Who made it? And then the task details. And you can see that these are pretty straightforward, simple details. Again, 10 minutes. But the goal here, just to run through it, we're going to use this product that we've built on bedrock, the tornado team. It's called Lassie. Its goal as a product is that you give it a CID and it gets the content. And the key distinguishing factors like it doesn't matter if it's on a Filecoin node or an IPFS node, it'll just do its best to find that content. And we're going to run the HTTP server from Lassie, so that we can test out the HTTP API there and making sure that we can get content like we would any other HTTP server. And this is actually used in the REIA project with Saturn. So that's why we dog-fooded it earlier. And then I've also listed a few CIDs here, and that we're going to try getting those specific CIDs and see how it goes. Now, because of time, I'm probably just going to run through this really quickly. But essentially, I'll go and install the latest version of Lassie. I already have it installed, so you're not going to see anything, but no new downloads, but it's there. And then we're going to just run the server. So again, I'm going to run in the top left corner here. Okay, the server is up. Awesome. It's on port 5050. And now I'm going to attempt to get a CID. So this is a template. So I'm going to copy one of the CIDs from below. And I'm going to give it a name. So it's easy. Let's call it CID1. And Lassie outputs everything in a car file format. So I'm going to run that. Now, the cool thing you could see from the HTTP server, the logs of how it requested what provider it's actually getting it from, which is pretty cool. And just because we're here, and to make it a better demo, I'm going to do the same thing for the second one. Okay, this one a little bit more interesting. It looked at a few more providers. You can read through the logs if you're interested. And it tells you the overall duration. If I look at my directory, I have two. Now, the next step in the demo, sorry, in the dog food task, it's to then view the file. So I'm going to go ahead and just view the car file. So I'm going to try CID1. Okay, that's kind of like a blob, interesting. And then I'm going to look at the second one as well. Okay, that one actually is a text file. So it's a little bit easier to parse. I don't have time right now, but the first one is actually like a PNG image on IPFS. This one is an XML feed for a blog. But that's it. So then afterwards, I could leave feedback below. This is how we do some lightweight feedback. And then ultimately, the team would then either the user or the team could file these as GitHub issues. And then we can like kind of start to prioritize them in the backlog after talking about it. And here's something that some example feedback of what I wrote previously. And you can see what the other team has wrote, like Jacob actually figured out how to open that blob more easily. And it basically requires some like car expertise, the go car library to use it. So yeah, that's kind of an example of how we dog food. Let me just I think that's about it. I think the only other thing is, again, think of how you can dog food on your team. It doesn't have to be every day. But if you can do something like a rotation, I think it'll bring a lot of value to the software you build and happy to help you do that as well. If you're stuck or you're not quite sure how to set it up, feel free to use our templates that are linked on the presentation. And we can also jump into a chat sometime and I can help out or anyone on the team as well. So thanks.