Episode 87: Jean Yang of Akita Software on Programming Languages, APIs and the Zoom Bachelor

Brian Dawson: Hello, this is Brian Dawson with DevOps Radio. Welcome back for another episode. Today with us we have yet another exciting guest in a string of exciting guests. We have Jean Yang, founder and CEO of Akita Software. And we’ll get into it a little bit later but I’m just going to add a qualification to founder; solo founder of Akita Software. She is here. She’ll tell us more about that, the benefit the organization offers, the journey as a founder, and her overall experience in the software development and DevOps space. So, Jean, hello. 

Jean Yang: Hi there. 

Brian Dawson: How are you doing today?

Jean Yang: I’m doing pretty well. How are you?

Brian Dawson: Good, good. I’m doing well. I think as we were talking about earlier, just living that quarantine life.

Jean Yang: Yeah. Staying inside. 

Brian Dawson: Staying inside and drawing, some of the benefits we talked about earlier. Some of the unrest and stress of these times but there are some silver linings, right?

Jean Yang: Yeah, my cat and I are very close now. 

Brian Dawson: Good, good. That’s good. So, to start, can you give our listeners an overview of your current role as founder and CEO at Akita? And then I think we’re also particularly interested in your background. What was your journey here?

Jean Yang: Yeah, sure absolutely. I started Akita in mid 2018, depending on how you want to count it, give or take a couple months on either side. And what I’m doing now is I’m running a small seed stage team. What we’ve been doing is building API tools. And so, when you normally think of API tools you think of something like Postman or Insomnia or API Documentation. My background is actually in building tooling to understand what software does. And so like, what’s going on with our software. Where is data flowing around our software. If there’s a bug, like how did that happen? And what I believe is the API layer is where we need to be. 

And so, what we’ve been doing at Akita is building tools to automatically infer API specs. So, everything is based on watching API traffic. So, we watch API traffic, we infer API specs, we infer data types, data formats. We infer relationships between incoming API calls, outgoing API calls. And so, what we’re doing is we’re watching your software at the API and we’re building a model of what’s going on. And from that we’re allowing people to more easily manage changes. So, we help catch breaking changes. We give insight and visibility into what the system is doing now. We tell people about their sensitive data and all kinds of other things. And the stage we’re at is we’ve built a set of tooling that we think is super awesome around this. And we’re trying to figure out what do people want to use us for and where are we most useful. And that’s what we’ve been doing in our private beta so far. 

Brian Dawson: Interesting. All right. There’s a lot there. And I’m already going to go off track. So, forgive me for not going directly to some of the questions that we had admitted to you or committed to. 

So you are inferring API specs. 

Jean Yang: Yes.

Brian Dawson: But now to play devil’s advocate and you can help get past my density, right, I created an API. I created an API to a spec, I can generate a document and I can publish a spec for all consumers of that API, right?

Jean Yang: Mm-hmm. 

Brian Dawson: However, it sounds like some of your adopters that are in consideration as you go through this sort of product market, or pre-product market fit stage, you are targeting the people who are the creator of those APIs, is that correct?

Jean Yang: We’re targeting both the creators and the users. So, for any API traffic that we see, we can give you a spec. So that’s both for your own API and for your APIs that you’re calling. 

Brian Dawson: Okay. Okay. And yeah, that is really interesting. So, you gather or derive intelligence and make this imprint from watching payloads who unpack or unwrap payloads? Or can you just tell me a little bit more? Not ultimate detail about –

Jean Yang: Yeah, absolutely. So, we watch requests, we watch responses. And we build a model of what’s going on. And to give you just a little more background on how we happened upon this. I was doing research in programming languages. And there we were doing things like modeling things at the language level, inferring policies, properties of programs. And I had always been very worried because modern web systems and modern systems in general aren’t just one single application. They’re a bunch of applications, a bunch of runtimes. They’re this – so I like to say it’s a rainforest, it’s an entire ecosystem. 

And so, I increasingly felt, when I was a grad student, that the way we were modeling systems wasn’t scaling. And not just in a performance or a complexity of the system kind of way. But a lot of what I was doing was modeling the semantics of systems and building language features, designing language features, designing language analysis. And I just felt that things were very broken on that level because modern systems weren’t one language. And so, I had one paper that was about modeling the application and database. That led me to a series of despair. Because that paper took three years. And so then if I thought about if I have to model every pairwise interaction between every component of your system that would take me until the end of my career.

And so, I got very interested in APIs that way. And initially I had gotten interested in APIs because I was like, oh, if you tell me your API I can watch your data across it. 

That was how I realized people don’t know even what their APIs are, what their endpoints are, what their specs are, what data they have going across it, what they’re calling afterward. And so that was just a whole layer of understanding of a system that no one had. And so, people were logging, they were monitoring. You have APM tools, you have log analysis tools, you have security tools like your wide access firewalls, your runtime application security tools that sit on your edge. But there is this whole graph representing the ecosystem of your modern web application that is just implicit right now. And so that is really what we’re trying to uncover. So, we fall in the category of being an API tool, but what I’m working on is figuring out how to describe us as being so much more. I just think that software that is cross API now. And that’s what we’re trying to build tools for. 

Brian Dawson: Well there is a couple of comments I’ll feed back on that. And then we’ll move forward, dig in a little more. 

But you made me think of the story, names not to be named, of a widely adopted product of which another widely adopted product was being built on. And when the team sort of refactoring that code for this new product came in, they discovered that there were a number of API calls that were carrying, I think in some cases, up to 10-megabyte payloads. 

Jean Yang: Oh wow. Yeah this is pretty common. Our users discover way too much data flying around all the time. 

Brian Dawson: Right. And so, I think it’s brilliant, right? You get me thinking about the idea that oftentimes – look, we establish this reasonably kind of – almost from an architectural principle, right? Our API as our contract layer, as our interface layer. 

Jean Yang: Exactly. 

Brian Dawson: We strive to keep it pretty stable. But what does that mean? That means as we’re focusing changes and sort of innovation in a number of other places there is the risk that that interface goes stale. 

Jean Yang: Yep, yep exactly. 

Brian Dawson: And we lose knowledge around what it is. And so, it seems exciting. I can already see as we’re moving into a – not only from an architectural standpoint, more focus on microservices, right? But a world where we need to be fast and we need to be resilient. And I used to say years ago that at times continuous delivery is going beyond the speed of documentation. 

Jean Yang: Yep.

Brian Dawson: And I can almost say beyond the speed of understanding. 

Jean Yang: Yep, yep, yep. 

Brian Dawson: So, this resonates with what I’ve seen. 

Jean Yang: Yeah, no, that’s awesome. Yeah, because I think that like what motivates me is, I grew up programming. So, my first language was Logo with a turtle. I programmed in Basic, I programmed in Visual Basic. I’ve been on the internet since ’96. I had all these GeoCities websites. I learned JavaScript – I don’t know if it was right when it came out but very, very early. Like I was there when the popup was invented. 

And I feel like back in the early days programming was super fun because there weren’t – there wasn’t all this context you had to page in every time you wrote something. And as I started picking up jobs in programming in college, I realized that programming just wasn’t fun like it was when I was a kid.Because there was so much context, it was so easy to break stuff. And you had to do so many things whenever you wrote some fun lines of code to make sure you didn’t break anything, or to make sure you were interacting with all the context the right way. That is sort of how I decided to go into software tooling that makes programming as fun as if you’re just working with some basic few lines of code, like literally in Basic. But that was really fun to me. So, to me, the boiler plate, the context that working programmers have just accepted as part of their lives, I would like to help remove. 

Brian Dawson: I love it. And I’ll reflect back again. My dated perspective of a similar thing is I’ve always argued that I love straight C.

I love Prestige World Programing. 

Jean Yang: Yeah. 

Brian Dawson: Right? As opposed similar, the context that you bring on when you move to C++ and you bring on object-oriented programming. There’s all of this underneath, there’s all of these interdependencies and history. 

Jean Yang: Yep.

Brian Dawson: That you have to strive to understand things, break, you’re not sure why, you’ve got to diagnose. So, I’ve never heard anyone phrase it the way you have but that does relate to why straight forward C, procedural based programming was more enjoyable for me than the more modern method. 

Jean Yang: Yeah, until 2012, I made every single website by opening a blank VM file and doing like, open HTML, close HTML from scratch. 

Brian Dawson: Nice. So, before I get too excited and drilled down, we’re going to dig more into Akita, we’re going to dig more into the product and your background. But before we do, I want to do a thing that I’ve been doing with guests recently.

I have opened up your Twitter profile and for the guest that can’t see it – actually I’m going to ask about your handle. So, her Twitter handle is J-E-A-N-Q-A-S-A-U-R. And she has a profile picture wearing a mask, a veil, and sunglasses. There is so much to ask about here we’re not going to have enough time. Let me hit some real quick. So first, I get the Jean, what’s the second part? Qasaur? 

Jean Yang: So, this is a series of inside jokes. But back in, I would say, the early 2000s, chain letters were still very popular. And I learned through chain letters through some of my more Asian friends. So, I don’t know how much you know about Asian culture, it’s like West Coast Asians have a very strong West Coast Asian culture.

A very cute some of more Asian friends like to do was spell their Gs using Qs instead. 

Brian Dawson: Oh, that makes sense.

Jean Yang: So, I told one of my friends this and he thought this was just the funniest thing he ever heard. So, he just started using gratuitous Qs everywhere. 

Brian Dawson: Okay.

Jean Yang: So, instead of agh, with A-G-H, he would say A-Q-H, aqh. And then he just started – yeah, every single word he just put a Q on the end. And he gave me the nickname Jeanqasaur. It’s Jean with a gratuitous Q in there and some other things. And then other people like this nickname so much everyone started calling me this. And they also picked up the Qs everywhere. So, to this day I still have people writing to me saying, Dear JeanQ, with a Q. But it was just very infectious. 

Brian Dawson: That is funny. All right. Well, don’t be surprised if I jump on the bandwagon. All right. And you know what, there’s so much in the profile picture I’m going to move past that in the interest of time. 

But I’m going to read out your handle and as we’ve talked about, you, for want of a better word, have carefully curated your – not your handle, your profile description. So, I’ll want to dig in. So, her profile reads: Founder and CEO at Akita software. That’s fairly clear. Previously, previously @Harvard undergrad @MIT CSAIL, PhD. @SCSatCMU, Assistant professor and then the wild card, co-producer Zoom Bachelor. Now, again there’s so much I’m not even going to try to pick one. I’m going to stop and ask you to choose what you want to elaborate on, why this collection of kind of tags or callouts. And actually, more directly what is Zoom Bachelor and why that?

Jean Yang: I think for the other stuff, I think some people can be very flip about their Twitter profiles and they still get followers. I found a lot of people follow me when I just put my resume. I don’t know. I A, B tested it. This seems to be what’s most effective. People want to know I’m legit. So, I just put everything. I know it’s slightly a toolish thing to do. So, I’ll talk about Zoom Bachelor to be cooler. So, Zoom Bachelor is a Zoom version of ABCs The Bachelor. So, I don’t know if you’ve watched or heard of the show but it’s 25 women competing for the affection of one man over the course of 12 weeks. They get engaged at the end. So, what happened was at the beginning of lockdown I accidentally became a matchmaker. So, I was on a Zoom catching up with one of my friends. He said he was newly single. I had another single friend I set him up with. And they went – this was before any of the dating sites were encouraging video dating. Everyone thought the lockdown was going to be over soon, they were all holding off dating until the lockdown was going to be over. 

And I said no. Who knows how long this is going to last? You have to seize the moment, just do a Zoom date. And a sidenote is that I love the idea of not leaving my house. If I could do all of my social interaction from not leaving the house I would. So, this was an experiment to see if two people could actually meet each other from scratch, actually develop a connection over Zoom and then go from there. And so, I was very proud of myself. I Tweeted that I set up two of my friends on Zoom, everyone should do this. And then other people started texting me, hey, I want a Zoom set up too. And I was like, I’m not an endless source of Zoom matches here. And so, I had to put up a Google spreadsheet because I was like I’ve got to find some matches for my other friends. And so, I put up this form on my Facebook. And I was like hey, if you want to be set up on a Zoom date just fill out this form real quick and I’ll hook you up. 

Brian Dawson: That is hilarious. 

Jean Yang: And three days later, 80 people had signed up. And people started thinking this was a real thing I was doing. I was just kind of joking about all this stuff, I really wasn’t taking it seriously. 

I think I Tweeted to Zoom that they should make me their brand ambassador or something. But you know, I was not serious. But after 80 people signed up, I made a website, Jeandate.com. People can actually look at it now. And then my friend introduced me to her friend who was also doing Zoom matchmaking. And I was like wait a minute, this is not – I’m not taking this seriously at all. This is like not my job. I have a real job, I’m a serious person. This is not what I’m doing. Not saying matchmakers aren’t serious, but you know what I mean. 

Like, this is really just stuff I did for fun on the side. But then I met this other person and she’s like, oh yeah, I’ve been doing Zoom matchmaking. Or she’d been doing Slack and Voiceover Slack matchmaking for two weeks now. She’s like, I have hundreds of people now. This is a huge thing. Single people are really in distress. And so, this is a revelation for me. I mean it all made sense. But then I was like wow, well since there are two of us, we should do a project together. And so that’s how we decided to do Zoom Bachelorette. So, we actually weren’t sure exactly what we wanted to do. We were like maybe Zoom Love is Blind, maybe Zoom Bachelorette. But now that there’s Zoom and everyone is bored and single people are going out of their minds, we should like do something about this. 

So one thing led to another. We got our friend to agree to be the bachelorette. We decided to make it a fundraiser. We recruited 12 guys to be the bachelors. And then I think three days into our fundraiser, Alex Stamos, the former CSO of Facebook, Michael Coates, the former CSO of Twitter, and then John Oberheide, the current CTO of Duo, all gave $1,337.00 to our fundraiser, which had a $2,000.00 cap initially. So, we thought this was going to be 50 of our friends might watch, you know every single person participating brings like three friends and their mom, or something. But that was the day when Taylor Lorenz from the New York Times retweeted us. Everyone was like holy crap, what’s happening. So, the show was May 2nd. So, at this time video dating wasn’t a thing. Everyone was completely locked down. There were no sports. So, we just had the attention of all these people who had, for months, not been to any events, let alone any good video events. 

And it was really interesting. So, the show ended up being awesome. It was three hours live show, we treated it like an improv show. I think we had about 500 people watching at any time, everyone very active in the chat. Like some of the funniest parts of the show were the livestream chat. And I think over 1,000 show. It was private. Like, they had to donate money to get access to the show and still we had 1,000 viewers. 

Brian Dawson: Nice. 

Jean Yang: We got covered by CNN. There was just – people – I think it really – it hit at a time when people had lost hope about entertainment or group gatherings or any of this stuff. And it was just, like, very – it was very interesting. And the whole thing I accidentally stumbled upon. Because the whole time I was like, oh man, people donated money, now we have to put on a show. And then we were like, oh no, more people donated money, this is really serious now. The good thing was it was very time-boxxed. It all happened over the course of one week. But it was pretty nuts. 

Brian Dawson: That is, now that is phenomenal. And I’ll call out a couple of things first. So, I snuck in as we were talking and went and looked at jeandate.com. Actually, phenomenal layout on the page, by the way. But yeah, I’ve got to – you’re doing this as the CEO and founder of a company. I’ve really got to get my game up. People may wonder, I’m sure our guests – I ask myself sometimes – our guests and our listeners are like, why does he ask these questions? That story that I just uncovered is the perfect example of why I ask these random questions. Shifting. I’m going to take us back to APIs for a minute. But I also – I will ask though, as we do that, do you recognize the irony or the correlation between the fact that you are helping people leverage APIs by inferring API specs? And your jeandate.com venture is kind of a flavor of the same thing but in the real world. 

Jean Yang: Absolutely. I had a Tweet a few weeks ago actually that said, everything is a graph. Matchmaking is a graph problem. I’m trying to build the API graph for people. It’s all about graphs and connectivity, really. 

Brian Dawson: Yeah. You’re tempting me to drill down that hole, but I won’t. That is awesome. Now back to Akita. So, prior to founding Akita you worked in academia. You spent a lot of time in academia, you did your undergrad, your grad, impressive resume, by the way. 

Jean Yang: Thank you. 

Brian Dawson: Almost as impressive as what you’ve done afterwards, which is really impressive. But then you also spent time as an assistant professor at Carnegie Mellon.  Can you tell us what prompted you to, and you sort of hit us with some of this, but academia is very different? So, at some point you decided to take the leap from your role in academia to going to this wild risky world of startups. 

What work that you did in academia led you to taking that risk, or what in your background – long story short, what drove you to make that jump?

Jean Yang: Yeah, sure. That’s a great question. So, starting from college I had this goal of making developer tools better. 

So, I wanted to make programming fun, basically. So, I had grown up around computers, as I mentioned. And it wasn’t until I took programming languages, compilers, and hardware junior year that I realized that the magic I had been using was something that I could contribute to developing. And that was what got me hooked on computer science. So, I had studied computer science initially because that was the one set of classes I didn’t fall asleep doing the homework for. I’ll be very honest; I had no clue what I wanted to do. 

But I just knew I had grown up programming and I should probably – I thought I should probably explore some other things so I actually declared econ my major my first year. But I just always went back to computer science classes. I actually tried being premed for a while. Because I think people kept telling me I should explore other things, maybe because of my gender, I don’t know. But I just always went back to programming, algorithms, more programming. I just really like having a compiler there. It feels like you always have a friend to tell you if you’ve done something wrong. 

Brian Dawson: A compiler will always tell you the truth. That’s for sure.

Jean Yang: Yeah, exactly. 

Brian Dawson: There’s no gray area with a compiler. 

Jean Yang: Yeah. So, I really fell in love with the idea of being someone who would contribute to the building of these tools when I was a junior in college. That summer I interned at Google and I tried to talk to everyone at Google that I worked with about all the things I was interested in. I was like all these languages that are great, and they were programming it in C at the time, mostly. They had a backend that they had written in Java, they were actually rewriting it back to C because they didn’t have the 50 percent memory overhead to handle that at their scale at the time. 

A lot of the stuff was written in Assembly, like the real A Perf intensive stuff. So, they were like all the stuff you’re talking about programming tools, like we don’t care about and we can’t afford to care about right now. Most of the jobs in industry at the time in programming tools were performance jobs or compiler jobs. And what I was interested in is how can we help the semantics of these more complex programs be cleaner - be better. I really wanted to solve the context problem. How can you make it easier to step into a project and get started right away? How can you make it easier for someone to make a change to a complex piece of code and not have it come crashing down in 99 ways all the time? And so, for that I decided I had to go to grad school because no one was really doing that kind of stuff in industry at the time. So, I got my PhD at MIT and really the whole time I did internships in industry, I gave talks in industry. I was very interested in how can we ultimately solve this problem for developers. 

And at every step I was looking for okay, what would the path be. At some point in grad school I concluded that probably I would have to start my own company to build tools for this. Because I looked at the big companies, like Facebook, Google. I’ve done internships there. I’ve interned at Microsoft. The kinds of tooling they were building were meant to handle the scale of a Facebook of a Google, of a Microsoft. So, they were Perf things, they were type checking that’s like one extra type on top of all the code base. But if you wanted to do something that diverged from the way people did things already you would need to build a small company that helped other smaller companies. 

So that was my thinking as I went through grad school. But I also knew that the market wasn’t ready at the time for most of the time I was getting my PhD. When I finished my PhD, I also didn’t feel it was the right time. But I actually started an accelerator in 2015 with my friend, focused on security. I did programming languages applied to security in grad school. 

And what I learned was you want two factors to be in place for the company – for a tools company to really take off. One is there has to be some sort of tech need. There has to be some sort of pressing need, either there’s a new kind of regulation or there’s a new kind of language, new wave or something that causes people to want to adopt something new. And then for me specifically, I needed a technological shift to ride onto. It’s not just like consumers want this kind of thing now, I’m going to start building new tooling. And so, for me I took the assistant professor job because I was like these are the kinds of tools I want to work on, no one wants them yet. So, I’ll just keep working on them in academia. And in 2018 Cambridge Analytica hit, GDPR hit. I had been working on security stuff at the time. So, when I started Akita I thought it was going to be a security and privacy developer tools company. And from that perspective 2018 was the perfect year. 

Since then I realized that developer tools in security and privacy aren’t the best of friends. And so we have gotten much more traction dropping security and privacy from the main banner and making it just one of the use cases. But that was my initial thinking about this is the right time because of the shifts in APIs and services but also it was the year that all of the regulation was changing. 

Brian Dawson: That is so, so interesting. Now, still even with all of that, it really takes something different. I mean, I guess it takes a bit of bravery to embark on being a solely – solo founder of a company with the technological ambitions that Akita has. And as everybody can hear, you’re very shy. So how did you get up the confidence – no. But can you tell me bit more about the experience of being a solo founder? The experience of being a founder, but in particular a solo founder?

Jean Yang: Sure. Yeah, I think that I didn’t initially intend to be a solo founder. I had told myself in January 2018, when I first started thinking about this, that I would do it if I found a co-founder. And I actually trialed a couple of co-founders. But I realized that if you’re going to start a company together and embark on this pretty crazy journey, the two or three or N of you have to be so, so aligned. That it’s – someone once told me a co-founder isn’t someone you find, it’s someone you have. So, it’s a longtime collaborator that you’ve been talking about these ideas with for a very long time, or it’s a sibling who you really trust, a friend who you really trust who you guys are in the same place in life. And for me, so yeah, everybody I approached who would have been that person, they were kind of in a different place, different headspace, they had different interests, which makes sense because I had been on this ten-year journey of discovery of what I wanted to do with programming tools, kind of on my own. 

So, it wasn’t like I had been discovering this with somebody else. And the process of starting the company, I think a lot of people ask me, how did you decide? It wasn’t so much one decision as a series of irreversible small decisions, if that makes sense. So, January 2018, I start thinking about this. I say hmm, it looks like the world needs the kind of tooling that I know and want to build and that no one is doing it right now. But I was two years into a ten-year track job. I had just raised all my grant funding for my professor job. So, I don’t know how many people know about this, but professors end up doing a lot of fundraising for their group. So, it is like running a small business. I had over $4 million of funding that I had raised, or like $3 or $4 million for my research group, that I had raised, which was not easy. 

Brian Dawson: Impressive.

Jean Yang: I had three courses that I had taught all for the first time, two of which I had designed or co-designed from scratch. And so, like the first two years of being a professor are similar to the first years of being a company where you’re doing everything from scratch, you’re working all the time. 

It’s honestly pretty miserable. And you’re doing it because you expect to have payoffs from putting in all that work. So, you do not leave two years into a professor job if it’s going well, usually. It was going pretty well for me in that I had a group, I had funding, I taught my classes. You know, like I had set myself up to continue on that. But at the same time, I had been waiting for the right market opportunity to build the tools I wanted to build for way longer than I had been a professor. And so, in January I thought about it and I was like, oh man, maybe I can do this five years from now. Do you think the world will still be the same five years from now? It started with those kinds of conversations with myself, maybe five, ten years. Which I think a lot of people, when they start companies, that’s their reasoning. Like, it’s not a good time. Two years from now, five years, ten years. Like most people don’t start companies unless they’re close to tenure. CMU has a nine-year tenure clock. It would have been seven more years for me. 

Brian Dawson: Mm-hmm. 

Jean Yang: And so, I talked to my friends in industry, which moves on very different time scales. And they were like Jean, that’s insane. Seven years, the market like –

Brian Dawson: The whole market has shifted. 

Jean Yang: Yeah, the market has shifted. Winners have been declared. Like, if you want in on this space right now, this year is the year to do it. And I was like, oh man, this is terrible. I had like four papers in the pipeline. So, I was like, all right. Maybe I do like one year and then I take leave. And then again, my friends were like, you do one year, you’re doing a half-ass effort on your papers. Excuse my language. And, you’re depriving yourself the opportunity to start this company in a timely manner. 

Brian Dawson: Right. 

Jean Yang: And so, after three or four months really of thinking through this in my head, I was like already, if I’m going to actually do this company, it has to be right now. I’m basically deciding to leave academia forever unless I want to start up this whole thing again and completely start from no momentum, which, you know, is very, very painful. 

And so I was like all right, it’s the company or academia. But again, it was not a hard decision. Because I was like, all right, academia is always going to be here but the company – I have been waiting for this moment in the market for my whole career up till now. And so, it was just like, this is the biggest ship that’s going to sail. And definitely in the last years, probably the next ten years. And so, I would either have been dishonest with myself that this is what I was waiting for, or that was not actually – yeah, it would be that I was not actually what I wanted because this is what I had been waiting for. 

Brian Dawson: Yeah. And I – for a little credibility I have to add to it, listening to all your reasons, it sounds like the right reasons. I would assume that the experience you have gained in the months since you founded the company, and the experience you are likely to gain. Forget fiscal payoff, even go beyond impact but just personal experience that you’re going to gain taking this on, was a worthy tradeoff for what you would have gained in academia. 

Jean Yang: Absolutely. I’ve learned so much. And it’s been an incredible growth experience for me. And I think remaining a professor would have also been a growth experience but I do feel like I had been in academia for a while at that point. And so being a professor in many ways was more of the same. But starting Akita really forced me to throw myself into cold water, basically. I moved out to the west coast. So, here’s how the series of decisions went. So, I had been scheduled to co-teach that Fall. And I had post docs who were expecting me to continue advising them. I had students who were expecting me to continue advising them. And so, when you have that kind of responsibility, one, this is not a decision to take lightly. But two, the minute you start thinking you might take such a decision you have to tell everybody. 

So, you know, after I thought this might be a thing to do, I told my students. I told my post docs. I told my co-teacher. And so, at that point the responsible thing to do is to apply for a leave. And once you apply for a leave you have no pay. You have no guaranteed pay for the next year. So, my responsibility to keep my apartment. And so, I had so many commitments that in order to do the responsible thing with respect to all my commitments within a few short months I had no job for the Fall, no apartment for the Fall, no furniture for the Fall. And so all that was left to do was just pack up my things, ship all my things to California, which was where I had decided to start the company. And just not look back. Because I had relieved myself of all responsibilities. But it was in a way that I couldn’t just undo it very quickly. It wasn’t like I had a job that I could just easily go back to because I had been responsible for a lot of things. 

Brian Dawson: So, question to ask there. So, you have now – well first, the thing that popped up as you were talking is really where you are now with Akita, it’s been your destiny for a number of years. 

It sounds like you saw what were a ripe confluence of events, originally looking at GDPR, Cambridge and Analytica, the awareness of that, the sensitivity around data. We’ve also seen a focus on increasing software velocity, reducing cognitive load of developers. I think more so than ever in the past year or so, microservices are being emphatically embraced and gaining the attention, not only from smaller organizations developing web systems or web-based applications, but all the way up to enterprises like across a range of applications of microservices. 

So, it sounds like you found you hit a sweet spot. And you jumped in. I guess I will ask, are all of those things I listed things that you measured? And were there any other major market events that signaled to you that this was time for Akita to come in and solve a problem on the market?

Jean Yang: Yeah, no, you’re exactly accurate. So, on the one side there was the rise of APIs and microservices combined with developer velocity was a huge factor. I had thought the other side was GDPR and factors like that. We’ve since realized that’s not the case, just like APIs, microservices and developer velocity alone has been where we’ve been getting the major traction. 

Brian Dawson: Are enough. 

Jean Yang: Yeah. And we actually learned from trying to sell GDPR tools that those are often IT tools instead of developer tools. Because the whole time I was very set on I want to make development easier for developers. 

And developers aren’t always the – they’re not the first on the line for security and privacy. And for them it’s really nice to have. But what we’ve found is that developers will buy things that make them fast. And security buys things that make them more secure. 

Brian Dawson: Yeah. I think it’s been a focus on a lot of sort of work I’ve done, those distinct differences between dev and ops. So we talk about the DevOps movement, it’s extremely important. But anybody on this call that is responsible for acquiring tooling for, building tooling for, selling tooling to a range of dev and ops can probably resonate with what you state. What is priority focus for a developer, an application engineer versus an operations engineer or systems engineer or security person justifiably but maybe unfortunately, are very different today. 

Jean Yang: Mm-hmm. 

Brian Dawson: Right?

Jean Yang: Yeah, that was a big lesson I’ve learned since 2018.

Brian Dawson: Yeah. I think my – I think our eutopia is out of this DevOps movement, we not only connect people through automation and tooling those different cohorts, but we actually get to a point where their priorities actually converge more. We kind of blur the lines a little more. 

Jean Yang: Yeah, I love that because I think I see a lot of what we’re doing is bringing DevOps closer to Dev because right now what happens is if you have an incident DevOps will log monitor. They’ll say here’s what’s going on. But the developer, they developed a service. They don’t know how all the pieces fit together. So DevOps will come to the and say, this thing happened - oh no, we’ve got to stop it. And there isn’t a shared truth, always, about this is the chain of causality that led this service having this issue having this thing that a DevOps person observed. So by giving visibility to the underlying graph of these APIs we’re really hoping to shift some of the problems from DevOps into developers. 

And also, something that I’ve been really interested in is the blurred line between test and production. So, historically developers have their domain which is test. DevOps, their domain is productions. But for a lot of these microservices systems you can’t really test until you’re in production. So, what we’ve designed our tool to do is actually we run in either test or production and we just combine all of the information to piece together that visibility. And we think if you have a tool like that, that also brings Dev and DevOps closer together. 

Brian Dawson: Yeah, I’m excited. You don’t know, we didn’t share this. I’ve spent most of my career in the tools space. I’ve also spent most of my career – I’m self-taught, I’ve worked with that. So, my time in the game industry where I ran a tools and technology group, I build relationships with CMU, Berkeley, and really leveraged academia. So, there’s a real excitement about this conversation with you.

Jean Yang: Yeah, that’s awesome.

Brian Dawson: And I really do believe, and I love to hear the passion in your voice, that tools absolutely not the end all be all. We talk a lot about people, culture, tools, right? When we talk DevOps, organizational change within tech, it requires all three –

Jean Yang: Yep.

Brian Dawson: But you could facilitate and encourage some phenomenal changes with the right tooling and the right approach to tools. 

Jean Yang: Yeah, I agree completely. I think that my goal is to build tooling that facilitates the right collaborations. I think at some point we had actually viewed our tool as a collaboration tool because if people can’t have the same source of truth it’s really hard to work together.  

Brian Dawson: Yes. Yeah, single source of truth, shared source of truth, shared reality. 

Jean Yang: Yeah. 

Brian Dawson: There is a whole other episode, as I often say, of correlating that back to our times. But you recently asked your Twitter followers which of the following terms is most scary to you; breaking changes, endless code review, API explosion? What were the results and what did you learn from that? And can you also, in the process, kind of elaborate on the question choices?

Jean Yang: Yeah, sure. So, I - especially in the last two months - have started doing more Twitter polls. I don’t know if you notice but on my Twitter account, I have many kinds of polls, not just developer polls. I had a poll last night, you know, what’s the 90s song that best describes your 2020? That poll is not as popular. So, I’ll be very honest. Developer polls are the most popular polls on my Twitter. I think my other polls get maybe dozens of people. Every time I do a developer survey – I’ve realized developers just love filling out polls on my Twitter for some reason. 

And so, it’s become a really good tool to connect with like who is on my Twitter, what are the people really worried about and how can I help them. And so, a lot of my polls have this combination of me just trying to understand who is following me and paying attention to this, how are they thinking about problems and how is it related to how I’m related to problems and how can it help me better communicate with them about places where we can work together on solving their problems. Because as a tools builder, like if I can’t tell people what tools I’m building for them, that’s really bad. Yeah, if that makes sense. 

Brian Dawson: No, it does. It does. And I’m just taking note. I think that’s a fantastic way to do product research, right? Directly with the market, directly with your proposed constituents. And you can do it continuously. 

One of the things that I’ll say has really struck me in the past hour or so that we’ve been conversing is really not just your focus on and prowess in CS and technology, but more so in the understanding the user and the market is really impressive. This will actually lead me to a topic that you’ve spoken about, time management. How did I get there? Well because obviously you do a lot. And you’ve gotten a lot done. And I know that you’ve addressed the topic of time management. But not just time management. You’ve also brought forth energy management. I’m hoping you can help me – if it is what I think it is it’s very intriguing. Educate me. What are the differences between time management, energy management and how can it be applied to what us software professionals do?

Jean Yang: Yeah, I love that question. I think I’m – well you know that phrase, you have to spend money to get money sometimes?

That’s how I feel about time. Although it makes no sense for time. like, I have in my head this idea you need to spend time to get time, but with time, time is just always decreasing. So, it doesn’t make as much sense but I’ve always had the philosophy that the more disciplined you are about things like eating, sleeping, and exercising the more time you just have. I remember I had an officemate once during the last week of an internship. I was working crazy hours and I was still leaving at 4:00 or 5:00 every day to go to the gym, have dinner, and then I would come back. And he said, wow, I can’t believe you’re still going to the gym during deadline week. And I was very surprised because deadline week is the week that you want to be most going to the gym. You need to be top performance. You’ve got to eat at all the right times, sleep at all the right times, sleep enough. If I’m actually on vacation I actually don’t sleep very much because I’m just like I’ll just stay up late, watch some tv, read some books. But I think that on days you have to be on and really perform, it’s like an athlete. This is the finals. Like in the finals you don’t just like stop drinking water. 

So I think that to me there’s always been some amount of that. But I think I do take it to the next level. Where I think some people, the way they work, the more hours they work on one thing the better they get. For me, the clearer of the head I have going into something, the better I do. So, I’ve always tried to have small, stimulating side projects that I can stop really at any time that don’t take up too much of my life that really clear my head because they are sufficiently stimulating in another way. So Jeandate was that, Zoom Bachelorette was that and Zoom Bachelor was that. And I think that normally I wouldn’t have taken on such big project as Zoom Bachelorette but that, first of all that escalated out of my control, secondly, during that time what else I could have been doing was reading about Covid day in and day out. Because that’s what I knew I was doing before I started Jeandate. So I looked at it and I was like, all right –

Brian Dawson: As was I. 

Jean Yang: I’m spending one hour a day plus reading about Covid. I need some way to occupy my mind because this is draining my energy. And I need something that actually gives me energy back. So, I wasn’t really looking for a project but the minute I stumbled upon Jeandate I was like, yep, this is it. This is something that replaces all the time I was spending reading on Covid and this is very energy producing to me so I’m going to spend time on this even though it looks like a huge distraction to people who think of time as just like a quantity that is always decreasing. 

Brian Dawson: That’s interesting. To make sure I’m grabbing it, it’s really kind of looking at it as you started with trying to transfer you’ve got to spend money to make money. You said it doesn’t fully logically transfer to time but if you bring in sort of energy as another element it might work.

I think you’re really arriving at look, what you should do is return – what you want to do is get a return on investment of your time. and return on that investment maybe outcomes, successes, revenue, are a downstream return.

Jean Yang: Yep. 

Brian Dawson: But the immediate aim is to seek, to invest time in things that give you a return in terms of energy. 

Jean Yang: Yep, exactly yeah. And then, yeah. And then time and energy are sort of interchangeable here. So, I end up putting a lot more energy than a lot of people would into things that I know will give me so much more energy. It’s worth – this looks like a very luxurious energy spend. 

Brian Dawson: Yeah, and I already know this is not lost on you. But that’s a very apt view on the world for a tools developer. Right?

Jean Yang: Yeah, exactly. You always do your tools first. 

Brian Dawson: Right?

Jean Yang: Get your tools in order. Yep, it’s worth all the energy you put into it. 

Brian Dawson: Right. Where you’re looking for sustained reoccurring returns, right? That’s, yep. If I invest the right time and energy into the right tooling, it’s worth it. Anyway, awesome for our conversation. 

Jean Yang: Yeah. There is a parable my parents used to tell me as a kid about there were two carpenters who were interviewing for a job. And the one carpenter got the job done really fast and left. And the other carpenter spent all day doing the job. But he was the one who got the job. Because it turned out that he had lined up all the nails and sorted them and that’s why he spent all day. And the person doing the hiring wanted the person who was going to do the job right in the long term. Which is very extreme. 

Brian Dawson: Yeah, no, but no. It’s an awesome story. You actually know that’s somebody who can have repeatable outputs, repeatable success. So unfortunately, I know I can’t keep you forever. But there are a couple more questions I want to dig into before I let you go. The first is really what’s become a standard component of DevOps our DevOps radio interviews and that’s something we call Devooops, D-E-V-O-O-O-P-S. 

And just to qualify or explain, a DevOoops is a challenge that you’ve experienced, largely in software development, or really in your life you’ve faced across your career, your life, software development or otherwise where you made a mistake but you took a lasting lesson away from it. And with the hopes that our listeners can learn from it. So, what is your DevOoops that you have to share with us?

Jean Yang: Yeah, sure. So, this one will be from when I was a grad student developing research software for my thesis. But it was definitely my biggest oops. So, I was publishing the last paper of my thesis. It was the last year of my PhD I was working on this. And I was building a bunch of optimizations in the week leading up to the conference paper submission deadline. And so, for people who aren’t aware, how this works is how academic conference submissions work is there is one big deadline for every conference. 

For a lot of these conferences per year, so you really try hard to make that deadline because if you miss it, you’re waiting months or maybe the next year for the next deadline. So, I was like I’m finishing grad school, I don’t want to have this paper hanging over my head for a long time. But I knew I had to get these numbers better for my benchmarks to publish in the paper.  And so, I was writing the paper and I was working really hard to add optimizations to my system to make it faster and faster. And the day – like hours before the deadline I was like oh my gosh, I finally got my numbers to the place I wanted it to. And so I had done some crazy optimizations and I was like phew. Let me just finish writing this into the paper. And I submit it. And so, as you can guess, I didn’t – I hadn’t tested all the facets of that optimization because it had gotten aggressive enough that I had – I was digging into places where my test didn’t quite reach yet. And I was in such a hurry that I didn’t have time to test it. 

And after I submitted the paper, I just didn’t go back to it. And so, the paper gets accepted. I am going to the conference to give the talk on the paper. And I expect to have some extra time at the conference. So, I’m like making my talk on the way over. And I’m setting up my demo when I discover that in some cases for this optimization, it just doesn’t work. There’s a bug. And that’s why it was so fast. And so, I was like, oh no. This is really bad. I have to give a talk on these results in three days and the numbers are wrong. And this had never happened to me before. So, I hadn’t written that many papers. But I was like this is so embarrassing, do I need to withdraw a paper from the conference?So what ends up happening is I spend the next three days, during the entire day I’m debugging my system, trying to reimplement the optimization to make it faster. And then at night, because I still am not done with my talk, I’m working on my talk. So, I really don’t sleep much for the next three days. I do a little bit of socializing because I’m like I came to the conference to talk to people. 

At one point I tell people, guys this is terrible. And they’re like Jean, where have you been and I’m like my numbers are not right. There was a bug and you know, a couple other people were like this happens. If you have a long enough career it happens at some point. But I was like, this is the first time it’s happened to me and it’s so bad. So, I end up – I’m getting the numbers pretty close to what they were in the paper. I had to present a different table. Which to me was very embarrassing. I was very ashamed about this. But the big lesson I took away was, I guess first of all, bugs do happen, given how many other people were unphased by this. They’re like no, like you don’t have to withdraw your paper. This happens. Papers get a little bit wrong all the time. This wasn’t the crux of your paper. Whatever. But after that, even for very prototype, very early systems, I have really insisted to my students and my collaborators that we have to write tests as much as we can. Because that kind of thing is terrible. I think for these research systems it’s very similar to I’m in a startup when you first start your system. 

You don’t have all your tests there yet. You don’t have all your infrastructure so you are testing some stuff by hand. You’re putting extra test cases every time you add something. But that is also how we’re operating in this startup. And what that taught me is even if you’re early, even if you are moving fast, you don’t forego certain tests. 

Brian Dawson: Yeah, great lesson. And honestly, you’re bringing me flashbacks around academia and papers. But thanks for sharing that great lesson. I think it again ties back to time, energy, and tools. And where you invest. Invest in those tests. We all, as software professionals in corporate environments, are often faced with that challenge, that natural inclination just to blast through it and get it done and see the results, knowing as you’re reminding us that if you don’t take the time upfront to make sure your testing where you need to test, not even there’s a chance it’s going to come back and bite you.

Jean Yang: It’s probably going to. At some point in career. 

Brian Dawson: Come back and bite. At some point. 

Jean Yang: And it might be big, it might be small but it will happen. 

Brian Dawson: So, moving to our other kind of standard question here, resources. So, you obviously seem very well connected and well informed. So, I’m particularly interested in asking you, what is a resource. We started out with books but really any resource, a podcast, a blog, a person, that you would absolutely recommend our audience go out and buy, get, digest. 

Jean Yang: Sure, yeah. I thought about this question a bit. And most of my first answers, were to be very honest, were things any other person in tech probably would recommend at some point. But then I remembered a book I recommend to everybody is Judd Apatow’s Sick in the Head. So, Judd Apatow is a famous comedy writer, director. And Sick in the Head is a compilation of interviews he does with many famous comedians from Chris Rock to Jerry Seinfeld, Amy Schumer. 

And I have long identified with comedians. Because one, they are obsessed with their craft and they’re constantly trying to get better so they’re always putting themselves out there, iterating, trying to do better at helping other people in some way. And as a tools builder I feel there’s a very similar – something of a similar goal there. I also really like hearing from them in particular because not only are they obsesses with their craft but they’re very good story tellers. Because they’re comedians. That’s their whole job. So, to me this book was a wonderful meditation on obsessively honing your craft. On what it means to make it big and what that path is like and not getting too big for your britches. And also, it was just a master class in storytelling, which I think is important for everybody, not just for comedians. 

Brian Dawson: That was a great pick. That was a really interesting pick. Probably clear, and by far, the most unique beyond Jaqueline Salinas recommending The Alchemist. 

Jean Yang: Oh, interesting. 

Brian Dawson: And suggesting that as software engineers and developers we need to be reminded to dream. That’s a fantastic pick, thank you for that. I’m going to put that on my list and pull it down. 

Jean Yang: It’s a great book. 

Brian Dawson: So lastly, I want to ask what is next for you? What is next for Akita? 

Jean Yang: Yeah, thanks for asking. So, at Akita, we’ve put out our private beta. We’ve started publishing blog posts about what we do. We’re super excited about the tools we’re building. We’ve been co-developing a lot of features with our private beta users. And we’ve been getting the story straight, speaking of storytelling, about what it is we’re building and how we can help people right now and how we can help people down the line.  

[0:56:00] And what we’re preparing for is the plan is in November we’re going to launch on product hunt. So, by then we hope to have learned a lot by working with our private beta users and to have a really good idea of what people are finding us useful for and where we’re landing. And so, before then we would love to work with tooling enthusiasts and people who have API problems to get feedback on this is what I wasn’t to use this for, yes, this feature is working, no, this feature is not working, yes, this feature but you’ve got to change X, Y, and Z.That’s what our relationships so far have been like. And then once things land, we’d love to get more people using it just to test things out a bit more to see what a smaller number of users say is the way to go resonates with more users. 

Brian Dawson: And how should people go about getting their name in the hat to give you feedback?

Jean Yang: Yeah, so if you go to akitasoftware.com we have a way to sign up. 

And then we have a survey that we’re giving people right now that right now we’ve pretty much been letting on people who have filled out the survey already because then we know they’re really, really interested. So, I would say if people are interested, at least put your name down. If you would love to help, fill out the survey, that will increase the chances that we’ll get back to you. And we’ve just been working our way through so that we’re letting on a manageable number of people every week. And yeah, the more you say when you sign up the more, we’re likely to say this is someone who will really resonate with us and we’d love to work with you early. 

Brian Dawson: Well awesome. Jean, thank you. I’m going to look forward to watching between now and November and beyond and see what Akita does. I may actually, I can’t register for Zoom date or Jeandate but keep an eye on that. I’ll just be interested in watching what your future looks like for you. Before we let you go, real quick, any final closing thoughts that you’d like to share with the audience?

Jean Yang: Yeah, so I think something I think a lot about that I don’t know if software developers think a lot about is that programming should be fun. And it should be interesting. Because I talk to a lot of programmers and they’re like oh, it should be boring, that’s how it should be. Or there’s always just a lot of cruft. And I think as humans we’re really good at getting used to our surroundings and I think right now the surroundings of modern, especially modern web programming is there’s a ton of cruft. And the tooling isn’t there. But it doesn’t mean that it has to be that way. It means we need to start demanding more of our tools. And so yes, this is self-serving because if people start demanding more of our tools, they’ll be more accepting of what we’re building. But I also think that things could be better so people should ask for me. 

Brian Dawson: Thank you for that. Thank you for that. and I’m making a mental note based on that, if we ever talk again, we’ll talk 4GLs and we’ll talk human adaptability, the pros and cons. 

Jean Yang: Oh yeah. That sounds very relevant. Cool, well yeah, thank you. 

Brian Dawson: Well thank you much, Jean. I followed you on Twitter so you’ll probably hear from me there. I expect to talk to you more in the future. I thank you for your time, and best of luck. 

Jean Yang: Cool. Thank you.