 Live from Mountain View, California, it's theCUBE. Covering DevNet Create 2019, brought to you by Cisco. Hi, Lisa Martin for theCUBE, live at Cisco DevNet Create 2019. This is day two of our coverage here. We're excited to welcome Taylor Barnett, a speaker, tech talk speaker for this event, lead community engineer at Stoplight. Taylor, it's great to have you on theCUBE. I'm glad to be here. So first of all, before we talk about your tech talk that you gave yesterday here at DevNet Create, tell us a little bit about Stoplight. Yeah, so Stoplight is a platform to build, test, and design web APIs. Specifically, we focus right now on REST APIs, but we're really encouraging design first principles when people are building out their APIs for very much pre-production. And what we have found was so many APIs out there are not documented, they're not tested, they're not designed well, and so we wanted to build tooling to help users be able to do that. So that documentation we've heard yesterday and today is absolutely essential. Yeah, and so a lot of what we're doing is we're actually using the Open API specification, which a lot of teams at Cisco are now using, and so we can auto-generate documentation from that, but also we can auto-generate instant mock servers, do different types of testing, all from that, because it's both human and machine readable, so we're taking advantage of that. So you gave a tech talk yesterday, I liked the title, going to infinity and beyond documentation with Open API. Tell us, our audience, basically kind of an overview of what you presented and the three takeaways that your audience left with. Yeah, so historically Open API specification has been known to be an auto-generating reference documentation, so a lot of people are like, yeah, I know it for documentation, but they don't know it for all the other things, so the things that help them do design first principles, the things that help them mock and get feedback about their APIs and also how to test. And so I'd say the three takeaways that's what I focus on was how does this design first really benefit us and why is it worth spending that time, because to a lot of engineers, it kind of feels like a friction point, like you're making me do something else before I can start coding, and so helping them see those benefits, and then also being able to use the feedback through they get through mock APIs so that they don't have to code all the API and then get the feedback, they can do it before that process. So much faster. Yeah, totally, and just better testing to actually make sure that once we design the API, that we're actually implementing it to what the design says. So on the design front, you mentioned design first, and I was telling you before we went live that we've heard that a lot throughout general and I have yesterday and today, this is design first approach, and it sounds like from what you're saying for developers, it's not necessarily the first thing that they want to do, they want to get their hands on and start coding, so tell us what design first means and actually how it can really make the developer's job better. Yeah, so design first is really just being able to take a step back before that code and describe what the API is on a lower endpoint level. For us, that's doing it in a visual editor at Stoplight, we actually have a visual editor to help people do that so that it's not writing things from scratch, so even then, that makes it faster than having to write on a blank document that nobody wants to write in, and it might be a mess and decisions are hard to make around that document because it's a mess and all this stuff, and then being able to take that and then start doing the mocking and all the other things. So for developers, it's a lot about getting to see what those other benefits are to convince them that it's worth it and it's going to save them time over all versus having to wait. One great example of that is actually with being able to mock APIs. Front-end engineers could go ahead and start implementing the API before the development process of actually implementing it is even done, so that traditional waterfall development process, you just cut that out because they can start doing it in parallel, and so it can really make teams a lot more efficient. Did you, were you happy with the reaction yesterday? Because this is an event of this, the DevNet community's got 595,000 plus people. There's been about 400 here in person. What was the reaction, especially from developers who may have been around a while and are very used to that waterfall approach? Were they like, Taylor, this is amazing, or girl, this is like a whole cultural change. Yeah, I mean, we work with actually a lot of enterprise companies at Stoplight, and it is a little bit of a cultural change. You talk, there's this whole bigger idea of API transformation, even just moving to having APIs first is a bigger change. And then, you know, then the design part, but I have found that once, if you're introducing somebody to APIs first, it's easy to sneak in design. Oh, it's easy. And so then you don't have to then teach, oh, let's design the API first and do design. It's all part of the same package. So a lot of enterprises with their transformations to moving to like in a very API focused infrastructures, they then are just more receptable to the design first. That's good, especially if you're able to show them that the obvious benefits of their getting things done faster, like this is actually taking this new approach is actually going to be better for you. And do you find that developers are adjusting quickly to this new principle? Yeah, I know, I mean, there's definitely pain points. The tooling is still catching up. So the industry for REST APIs has kind of centered around open API specification, but there were others before that, Rammel for us specifically. And for anybody else, open API used to be called Swagger specification. Some people might know it by that. But a lot of it is like, yeah, the tooling is still maturing, but it's in a lot better place than it used to be. So when I was a backend API engineer about four or five years ago, I was introduced through API Blueprint, which is another specification. And it was very painful to have to document an API with it. And now it's just gotten so much better with the tooling mature. You can see massive differences alone just in the last few years. Oh yeah, totally, yeah. Just like last four years, yeah, totally. So this is your first DevNet Create and you're a speaker at your very first one. That's pretty cool, Taylor. Yeah, yeah. How long have you been involved in the DevNet community and how has it impacted what you do for Stoplight? Yeah, so I was kind of introduced through it. I knew people that worked on DevNet and like Mandy and so then I kind of got introduced to that. And now it's been really interesting to see how they've built up this community of people sharing code and things. And it's different than like a GitHub type community. And so it's kind of interesting. It was just like it's a, you know, you don't see a lot of communities that are run by companies that necessarily they're not in the code repository business, but they see the value in people sharing things and collaborating and stuff like that. And so it's kind of different of a community but also very interesting to have watched it grow. Yeah, the sharing and the collaboration. You can walk in yesterday and people are eager to do that. And in other types of conferences that we cover at theCUBE, especially if there's co-operative partners there, it's a different vibe. This has been very much one that's been refreshing. And to your point, the difference between what Cisco's built here in the last, very organically by the way, in the last five years what Susie and Mandy have done, that openness and that excitability to share things and to learn from each other, even though there's got to be developers here from competing companies, that's a very cool spirit. And something that I think they've done a very good job fostering that. They've also, I kind of wonder if it's chicken and egg, how much has DevNet and this, you know, over half a million strong community been sort of a forcing function or an accelerator of Cisco's evolution? If you look at Cisco's been around for such a long time, not on API first company, big enterprise. This is a big, all of their products this is a big change for them. It's been really awesome to see all the talks that are focused on Cisco's APIs being designed first. Like, I don't see a lot of enterprises that feel like they've really taken it to heart as much. And I've talked to some people and they say, yeah, I mean, you know, there's been some pain points, but I'm like, yeah, but there's companies that are envious of that y'all've done this. Yes. And they've really like probably improved the developer experience of their API so much because of having that design first approach. So one other thing that I think is very cool about DevNet and Create is that yesterday morning it was kicked off by two really strong female technologists, you both mentioned. We had Mandy Wheelie on yesterday. She's the senior director of developer experience. Right after you, I've got Susie Lee on the SVP and CTO. And I'm good at a lot of events. The Cube covers a lot of events every year and it's very important to us to be able to highlight women in technology because it's still an unresolved, you know, gap there. But it's also really unusual to see an event kicked off both days by females. You've been a STEM since you were a kid. How does that impact you? Do you see that as inspiring? Do you see that as, I wish it wasn't an issue? Yeah, no, yeah, I wish it wasn't an issue, but no, but it's really awesome. So like when I was trying to decide if I accept my, when they asked me to come speak, I totally looked at that. That was something when I saw their faces on them that they were going to be keynotes and stuff. You know, it gave me already like a whole different feeling of how the conference was going to be. So it was really exciting to see that, yeah. That's good. And when I first got into tech a long time ago, I was just not aware. I wasn't in a technical role, but I didn't notice. I mean, I noticed the difference and the disparity, but I didn't feel it. And so it wasn't until I started going to more and more events where I saw, wow. Yeah, sometimes you're at events where it's just the sea of people that don't look like you and it's a lot different here. Yeah, and so I imagine, I appreciated it this morning. I'm sure you did as well when Susie called on to stage the young girls from Verizon and those from Presidio that are, Cisco's clearly making a concerted effort to recognize and help this diversity in thought. I mean, imagine designing APIs with the many different perspectives and how much better products and services and companies will be if we just have more thought diversity in and of itself. Yeah, I think about it a lot with developer experience. So one of the things is there's this idea of beginner's mind failure that sometimes if you think your API is like great, but you don't approach it with a beginner's mind, you might actually be failing a lot of your users. So you're a veteran developer, you're super skilled and you don't fail in the somewhat areas that someone who's newer to development might fail. And so then you just lost a bunch of your customers. And right up front, without even them getting deeper into the API. And so being able to have more diverse perspectives around designing APIs can definitely help prevent that. That's a really important point, Taylor, that you make there, because it's like, this is really everything that's designed these days, whatever it is, an iPad, but sticker, a piece of clothing, it's all designed for a consumer to consume whatever the product or service is. And in technology, so much conversation goes around delivering an outstanding customer experience. And you're saying, we have to think about that. Probably where design thinking comes into play, right? About being designing with that sort of a diverse perspective approach that, hey, you're going to lose customers here. It actually gets to the bottom line. Yeah, versus just being like a nice benefit kind of thing. Well, Taylor, it's been so fun having you on theCUBE. Thank you so much. I know you have the flight to catch back to Austin. So thank you so much for joining me this afternoon. And congrats on being a speaker at your first event. We'll see you next year. Thanks for having me. My pleasure. I'm Lisa Martin. You're watching theCUBE live from Cisco DevNet Create 2019. Thanks for watching.