What's it like building a startup with Python and going through a tech accelerator? Well, you're about to find out. On this episode, you'll meet Alyssa Shevinsky from Faster Than Light. They're building a static code analysis as a service business for Python and other code bases. We touch on a bunch of fun topics, including static code analysis, entrepreneurship, and tech accelerators. This is Talk Python To Me, episode 228, recorded August 7th, 2019.
Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python. This episode is brought to you by the podcast Command Line Heroes from Red Hat
and Linode. Please check out what they're offering during their segments. It really helps support the show. Alyssa, welcome to Talk Python To Me. It's great to be here. It's really great to have you here. I'm excited to talk about all the stuff that you're doing. There's so many different angles and
aspects of what you got going on. I think it's going to be interesting for everyone. We're talking about going through a tech accelerator, starting a software business, building on top of open source, starting working with Python as a core way to build a business, things like this, and some others as well. So a lot we have to talk about together. These are some of my favorite topics. So hopefully, it'll be a good conversation. I'm sure that it will. So let's start it off by just getting your
background. How'd you get into programming in Python? How'd you get here? I got into programming basically like my first day of college. I took an introduction to the web. It was like computer science 105. This was 1997. So just to set the perspective for people, right? Like the web came out in like 93 as a proper browser, right? Like it was really that's like years, a couple years into it, right? Oh, yeah. I don't want to say nobody, but it was extremely unusual to be doing the kind of tech
stuff that I was doing. And I loved it. But I didn't become a programmer at that point in my life. I just, I got introduced to it. I thought it was cool. I had this, like really warm and wonderful computer science professor and these friends who are computer programmers, and just kind of had this mental note that if I ever wanted to go into programming, like they would have me and it was geeky and it was fun.
And over the next few years, I just kept being friends with all these developers. And then I got this job. And I wasn't thinking too hard about it. Just my friends are at this startup called Everyday Health. And I joined and for the first year, I worked with the founders to set up the customer service infrastructure. And then I wanted to go back home to New York. And I got promoted to the tech team, kind of like as an accident. There's this moment where they needed someone to do QA.
And I was just around. It was like for New Year's Eve and like Christmas when no one wanted to work. And I was good at it. Then they like threw me on the tech team. And there I was suddenly, you know, shipping new software every three months. And I just fell in love with it. It was just, I'm still in love with it. Like there's a short list of things that I love. And making software is really like one of the, I can think of very few things I love more. And I got into Python specifically
once I started doing talks. And I just looked around and pretty much applied to any open call for papers. And I fell into PyCon Canada. And it was like, whoa, these people, they're warm and wonderful. And this conference is like really deep and interesting and covers a lot of ground. And that just became my home in all of these ways. And I went and I did like every Python conference that would have me.
And I had this talk on the history of women and computer science that also included like all the contributions that women and non-binary people made in Python. And like all these events really wanted that talk. So I kind of went on this worldwide tour going to Australia and London and all over giving this talk on Python community.
That sounds so fun to be able to dive into that. And I totally know what you're saying. I had the same feeling with PyCon and the community and just like, wow, this place is special, you know? It really, really is. I mean, I could go on and on about how and why I love Python and the Python community, which I guess is appropriate for this show. But Python is a really good learning language.
Like there's so much that's great about Python. And I saw myself as someone who was still in some ways, like a beginner as a developer, you know, and like very sophisticated in some of these other aspects. Like I have all this deep security knowledge and I know a lot about the process of shipping software. But I like that I could go to a Python event and kind of follow along with the talks there and like make
a really meaningful contribution. And I still like that Python, that it's a good first language for people. I like being part of a community where you can tell beginners, oh, come here first. Yeah. You know, what's really interesting? And I do agree with that for sure. I met so many people who were hesitant to go to events like that. And then they're like, well, I'm not really a developer enough to come to that. I'm not like a super pro. I've only been doing this for a few years or it's
not my main thing. I'm mostly a doctor or whatever. And they're all just, you know, this is amazing. I'm so glad I decided to get over that and come. I think that's really wonderful. But, you know, also there are a bunch of people who it's not just a beginning language for them, right? It's like a professional language they've been working with for a long time. And what I think is special about Python is you can be effective with Python with only a partial understanding of it, right? Like you,
if you don't know what a class is, right? If you don't know what a class is, a generator, a meta class, a database, you can still write scripts. You don't even know what a function is in terms of creating them and you could still use it. But at the same time, you can grow all the way into building Instagram or YouTube or, you know, you name it, right? And so I think that that's really special about it. Yeah. It's a very powerful language. We are using Python at our company at Faster Than Light.
and our CTO is, you know, a very senior Python developer, but it gives me a little bit of a lens into what you could do if you were junior. And we certainly see a lot of projects where people, you know, like it's a high impact language across the board for lots of people. I think it's definitely special. There's a lot of languages that are great for building pro apps. There's a lot of good beginner languages, but there's not many that do
both. And I think that's a lot of, a lot of what makes that special and why it makes sense for beginners to come and yet still have like this full rich ecosystem that we do, which is, which is great. So let's talk about what you do day to day. You're doing some pretty exciting stuff right now. Yeah. I think what I do is a mix of these like really, really dull, not glamorous things. Like
I'll sit and I'll do taxes and accounting and like build a leads list. So like I'm in an Excel spreadsheet, just like putting in names and emails and LinkedIn because for whatever reason, I want to connect with, with those folks for the business. And then just the most glamorous stuff. So we're part of the Techstars London accelerator now, and I meet the most remarkable people, you know, so I have introductions pending to like the chief executive officers at, you know, really large, like banks
and corporates. We just met the CTO from Ikea. I guess for me, that's glamorous, right? Glamorous is like, I met this really cool developer. It's geek glamorous and geek famous, which I think is pretty awesome. Yeah. I've also traveled all over the world, which I think meets a lot of people's definitions of
glamour. It's interesting because how many people think of, I'm going to go learn software development, which is often from the outside perceived as like, those are the people that kind of go into the dark room and no one talks to them. And they're kind of, you know, it's kind of a solitary thing. And the result is like all this glamorous travel and all these experiences that a lot of people who thought they
had a glamorous job maybe are not actually getting out of it, right? Like, I think there's a lot of interesting stuff. I had similar stuff. I, you know, traveled all over the world teaching classes and, you know, got to hang out in amazing places. And I'm like, wow, how did, you know, writing code get me here? But it does. And it's great. Yeah, I think that says a lot about just how powerful it is to be able to make software these days, because
you can take it in either direction. And so if you really want to just stay home and work on interesting projects on your own terms, writing Python code is a really good way to do that. And when I think about a lot of developers, I know, that's exactly what they do. And if I wanted to do that, I could. And then there's also this other side of it where if you want to travel the world, software development,
and specifically Python, like, is a great avenue for that. I just think it's so exciting. It's a very good time to be a nerd. Yeah, that's definitely a true statement. So you said that you do some very incredible stuff that's traveling around, but also all a lot of boring things. Being CEO of Faster Than Light, like, you know, I can definitely relate to some of the stuff you're talking about, you know,
running Talk Python and the training business, and all that. There's a lot of meetings with business partners, I definitely do a lot of accounting and taxes. And the one of the things I think that stands out really big, that I think a lot of people are not initially prepared for is marketing. And that kind of stuff, you know, like, how do you go from working in QA to understanding what you need to do
around marketing? Because to me, like, building a software business, it, it's interesting, technically, it's challenging, technically, but those are kind of table stakes. And then you've got to get users and break through the noise and get people to care. So how did you get those skills? Because yeah, they're not really taught in any computer area. that happened over a very long period of time. So like 2004, I'm a QA analyst. And then 2008,
I tried to do some just like digital marketing consulting. And I started to learn a few things there. And I did okay. I had some like small businesses, a guy who was selling sneakers on the internet, and I like, managed his AdWords and social media. So you know, I started small and worked my way up. And really, I've just been hustling so hard, like learning new skills and leveling up over the last 10 years, where in 2011, I tried to do my first startup. And that didn't really go because
people didn't have a lot of confidence in me. And I there was a lot I still had to learn. Back to like 2013 2014, I'm starting to learn a little bit more. And I've gotten some press attention. There's this process where I learned, like how you talk to the press and how you get noticed. Yeah, where initially, I've never been able to figure that out. That's very tricky. Oh, I'm happy to talk about that. It's probably out of scope for this. Yeah, probably. Maybe.
That was one of the first things I learned. So want to like, you have to do or be something interesting, and then figure out how to tell the story to the press in a way that reflects the message you want to share. And then the big thing I learned was that in order to really break out, you either need a big audience, or you need someone with a big audience sharing things. I had all this envy from the founders who I saw who got traction and things went viral. And I just
studied that a little bit obsessively to figure out like, how do I become or do that? Because I loved making software, but you it's not enough to make the software people have to use it. And then I kind of figured out how to be the person who has an audience. I'm not the person with the biggest audience. But you know, 13,000 people on Twitter, I can get attention in the press,
there's different things that I learned how to do. But that was, I guess, the TLDR there is that was over 10 years of like, really studying it and trying things and eventually, like building up credibility and building up an audience up to the moment where people come to me now. And they're like, hey, I've got a job posting. Like, oh, cool. Like, I can be helpful there. Like that. That's not to remind myself of like what it used to be like, when I didn't have that. So I appreciate where we are.
Yeah, absolutely agree that that's a huge part of the hidden success story of a lot of these types of things is there's that initial audience that care to this initial group. Obviously, that is part of my story with the podcast and whatnot I'm doing there. But you know, more mainstream examples would be like 37 Signals and Basecamp, right? Oh, I love them. Yeah, I do too. And even like, almost Ruby on Rails, like, as a thing itself, right?
Those guys did a ton of writing. They had a huge blog following. And I feel like their products are really good. But there's a ton of, you know, project management products. I think that their writing and their blogs and their philosophy actually was a big secret to their success. I don't know. I'm happy to hear that. I think about that all the time. So I've been going through what they call mentor madness at Techstars London. That's a process where from nine o'clock until around one o'clock,
we meet with all these mentors from Techstars. And it's like pretty wonderful. And they're all there to be helpful. But they also all ask questions about the businesses. They're trying to figure out which startups they want to work with the most. And it's good for us to practice or learn how to have good answers for that. And one of the things I get asked all the time is like, what's your moat,
right? Like technology moat only lasts for so long. And I think like the only really good answer that we have, other than just like continually trying to stay on top of product innovation, is that kind of brand moat, right? So like, I have to go out there and evangelize code quality. And when you think of code quality, like you'll think of me and our team. And I'm excited about that,
because I think it's really important. Like I'm happy to think about going and spending the next several years, kind of convincing and sharing and getting people really excited about shipping better code. But I also think like, what will make us different from other companies? It's like, well, if you think of us as the experts for that. So I think about that idea a lot. And I'm kind of happy about it.
Yeah. On the one hand, there's something kind of crappy or like not great about the idea that the best products don't win, like, feels like in a fair or just world, like the best products will just win by default. Yeah, that's a harsh lesson. And I agree that that is not true, even though it should be. So I grew up in Queens, like with a single mom, and just in this environment where I felt like,
I'm not making the rules. You know, like, I don't make the rules, but I have to figure out the rules, and kind of accept them, if I'm going to move ahead and achieve things. And so I think that's part of just like me being a sane person in this whole startup ecosystem. But I also think it's like part of me to the extent that I'm successful in the things that I set out to do. Because I just I'm just like, okay, like, these are the rules. This is what it is, right? It's like, we can build
the best product that's never going to be enough. It's like, we just have to accept that and then figure out, okay, if we have this thing, we want people to play with it and try it. What does that mean? Yeah. Yeah. Well, yeah, you definitely have to be able to legitimately see all the ways that things are working all the rules. And then you can try to break them or try to be different. But you got to understand the playing field first, and then then you can start to get out there.
This portion of Talk Python To Me is brought to you by Command Line Heroes. For the Free Software Foundation, making a free, as in speech, version of the Born Shell was critical for their operating system. Enter Brian Fox. Command Line Heroes, an original podcast from Red Hat, is all about the people who transform tech from the command line up. Episode 6 dives into the origins and evolution
of the Born Again Shell, aka Bash. Bell Labs' Born Shell was the default for Unix. The Free Software Foundation, however, needed to create their own version for their not Unix operating system without using any of the Born source code. Get the story and subscribe to Command Line Heroes wherever you get your podcasts, or just visit talkpython.fm/heroes. So one of the really interesting things that I think you're doing is going through this tech
accelerator, the startup accelerator, Techstars. How do you decide to come and do that? There's a lot of ways to start your business, right? You could just bootstrap it from the ground up. You could try to just go around and pitch VCs. You could do one of these accelerators. There's a bunch of options. What led you down this path? That's such a good question, actually, because it's so personal, and I feel like there's no right or wrong answer. And there's even a company inside our accelerator
that doesn't really want to raise money and they want to bootstrap. Good for them. I think they're going to be very successful there. But for me, I thought it would be good for us to raise money you know, and like, just hire people to do the things that aren't our strength. You know, when I talk about like, I'm doing all this back office stuff, like, I have this fantasy where Sunday, someone else does that. And I have the same fantasy. Yes. I know. Right. So, you know,
it's like, what is it? What's your dream? I love the idea of us getting big enough where I can really go around the world and just like evangelize code quality in our brand and like hire great people and have someone else who's doing like a lot of the operational stuff, which, you know, as companies get bigger, the CEO job does become more like representing and holding the vision and hiring and fundraising. Like, that's what I really want to do. But because we're a
three person company, I'm going to do everything. So I had this fantasy that we became a bigger company and we could just do the things where we're really strong and hire other people to do the other stuff. That means you have to become a big enough company. You have to raise money. It's actually really hard to raise money without like other people vouching for you. And some of that is just the dynamic of how, I don't know how people work. It's such a big difference. If I go up to someone,
I'm like, Hey, I have a company and I would like you to write me a check. And then they're like a little on edge. Like, who is this strange person? Like, that's not a normal way to approach a person,
like a VC, like it's just not normal. And it's not how things are done in Silicon Valley versus now Eamon, who is the managing director at Techstars London will like tell VCs he thinks are a fit that like, there's this amazing company and, and you have to meet them and they have a round, but it's going to close soon because you know, like it's going to close soon. So you have to talk to them fast. And
then they come in and they meet me. They've had experience with you too, right? The folks at Techstars and they can say, you know, actually, no, they're not crazy. I've been working with them for a couple months. It seems like they've got a solid plan. Like it rather than, you know, this one, the reason
I brought up the marketing side of things is it's so much easier. I'm not gonna say easy, but easy or much easier compared to 10 years, 15 years ago to create software companies and to get them out to the world. But that means there are so many other, there's so much noise and so many other people trying to vie for the same attention. I think it's, in some ways it's harder to run a software business,
but it's easier to create software, which is interesting. So I think any of these times that you can have just a little recommendation or something is really important. I think about that also because my CTO, Brett Thomas previously built and sold Vendicia. And when he started Vendicia, it was about 16 years ago. And that was a point in time when it was just, everything was slower and there was less competition, but he had to build everything from
scratch. And so he's coming on now and like building all this stuff and we're like, chat with us on the Slack or a Zoom call. It'll be like, it's so cool. Like, you know, there's some new technology, whatever it is that does this thing that he used to have to build from scratch. And so we're really thinking about that day to day because he's learning all these new things and implementing them. And it's like, it's really cool to see. And it reminds me of how the ecosystem has changed.
But the hard part is it's really hard to stand out. I think it's very hard to build a successful business these days. And everyone thinks that they can and lots of people try. And it's actually like really hard and sad to build a business and fail. That was another reason I wanted to do the accelerator is like the downside is they take a little equity, but the upside is like we have
customer introductions and just all these people on our team now, right? Like the whole tech stars network, which is just this very powerful worldwide network that has the motto give first, which is very nice. And they seem to really mean it. Like it's warm and wonderful. And in fact, one of the co CEO of tech stars came into our office this morning in tech stars London, like I met him, I was really fanish. And for me, that's like a life changing thing to show up and you have all of
these people backing you because entrepreneurship is just actually very lonely. We'll get together about once a week, all the CEOs in this batch. And some of them are not technical at all. And so you have like Banjo is this company and they send like letters to children about this cat that's traveling
the world. And so it's not like everyone is also coding in Python or thinking about Python, but we all there's this camaraderie where we're all thinking about the same like entrepreneurship challenges. And that's been really nice. Yeah. It looks a little bit different than say like Y Combinator or something like that, where at least from the outside, I get the feeling that a lot of that is like super tech focused, right? They're trying to create Airbnb or Uber or something to that effect.
Yeah. I think YC has like what they're looking for. And in some ways, like I got into this because of YC. I mean, I've been in startups since 1999, but I came to Silicon Valley and I met Paul Graham in 2011. And I waited in line as he talked to nine people before me. And he told all of them that they should not do whatever they were doing. And I was like, Oh, and then I got there and I was like, I'm
gonna do a Jewish dating site. And here's how I'm gonna do it. And here's my plan. He was like, you should go do that. And I was like, Oh, my goodness, Paul Graham said I should go do my startup. And then I went and I tried to do it. And I felt really motivated by that support. Yeah. So, you know, I always have to be a little bit grateful to Paul Graham. But I also feel like just I'm like not really aligned with a lot of YC stuff.
Like they're really, they really want you to be in San Francisco. And like, I think I'm really excited about this idea that you can be anywhere in the world. And I think that speaks to some of what we talked about before, right? Like being a software developer, some of that should be this freedom of all we need is a Wi Fi connection and like a zoom link. And like, yeah, communication is hard and people
are hard. But I think it's worth it to try to make that work. Yeah, I definitely appreciate the thinking about let people be where they want to be. And I think a lot of opportunities to hire interesting people get lost because somebody in a small town doesn't get the opportunities to meet the people and make the connections. There's probably some opportunity to connect people who are not right
in the center of these tech hubs. Although London is a pretty good place to be as well. I love that town. And it's got a lot of interesting tech going on there. It's nice for me. I'm like on a new adventure. And I think you and I spoke earlier about being, you know, 40 and over and still starting a company. And I'm a good example of being older and still being an entrepreneur, but also like still being on my adventures, right? Yes, absolutely.
I want to go to London. And I wanted to go to London for personal reasons. But it's also a really good decision for the company. And so the two things work together. There's a lot of reasons why I mean, just London is like a huge business hub. Like actually, Shoreditch is this really cool tech hub. And it's been really interesting to be here. Yeah, for sure. I've definitely spent some time in that part of London. And I know what you're talking
about. It's great. I want to talk about this idea of being over 40 and starting a company. Because I also hear this around the context of just becoming a programmer at all. A lot of people feel like you're over 40. You've missed your chance, right? Like, for me, and it sounds like you pretty much as well, right? Like if, if you wanted to start a business, you should have done it in 1998. Right? The dot com
when we were, you know, in our 20s, or that would have been great, probably. But I don't know that even that's necessarily a good idea. I think you get a lot of experience working in the industry. And then you have something meaningful to contribute other than just lots of energy and some ideas, right? Like, if we look at what you're doing with Faster Than Light, and Bug Catcher, you told me your story about how you started in QA,
right? And that was kind of your launch into this whole tech world way back when, and you've been doing it for so long. And now you're starting this company in this and you've had all this experience, right? If the first year you got into it, and you started this company, like how, how much experience do you really have? And I think there's actually a lot of opportunities for people who are 40 and older.
Yeah, 100%. I have so much to say on that. The first thing is we run a security company. And the whole premise is that we've seen a lot, we've done a lot, we know what we're doing, and we'll be around for a while, and you can trust us. So there are certain types of businesses that are hard to start when you're 21. So you can take advantage and leverage, you know, whatever experiences you have. And then I see some younger entrepreneurs really struggle. So for example, they'll get maybe like
10 different pieces of advice from advisors or investors or mentors. And then they're like, Oh, what should I do? It's like, I'm 40. I know what we should do. And if I don't know, I'll sit down with the team and we'll talk it out and we'll figure it out. And there's this confidence kind of easiness that can come with being older and having a sense of who you are and what your values are. And that helps a lot in entrepreneurship. When you look at the businesses that have been really
successful, a lot of them were started by older people. I think about my own life, right? So I did get started early in tech startups and in companies. But I also did a lot of meandering. Like I was a journalist and a yoga teacher. And then, you know, I went on this tremendous spiritual quest. I spent a year in like the Jewish equivalent of a monastery, like a yeshiva for women in Jerusalem. Like I did all
this stuff that helped me really grow as a person. And then at 31, I did my first like C Corp startup, trying to get VC funding. And I came into that with the self-awareness and like all these qualities and character traits that I didn't have at 21. And that I also, I don't think other people have if they just kind of followed doing some consulting job or not really pushing their boundaries of who they are. So I feel like the adventures and the challenges I had in my 20s, I brought them into my
30s. And that's one reason why I came up so fast as an entrepreneur. Because I came to Silicon Valley in 2011. And two years later, three years later, three years later, I was on the cover of the New York Times Sunday business. Wow, that is fat. That is incredible. That's awesome. That's fast. So how did that happen so fast? Because at 31, I had like a good 10 years of really getting to know myself, and really just figuring out like how to show up, like really show up.
Yeah. It's really interesting your story. And I totally agree with it, right? Like, let me do some quick math. I guess I was around 42 when I started my business now. And it's, I don't look back and say, I wish I started earlier for most, most of the time. I wish I had started earlier only and starting earlier in the trend of what I'm doing, right? Like if I had started 10 years earlier, it'd be easier to create like online video training, because fewer people were
doing it, right? But that's not me as sort of my age. That's just opportunity timing, you know? Well, and now is the right opportunity for something that 20 years from now will feel really mainstream. And so I think there's this challenge of just looking at the moment you're in and trying to make the most of that. That's hard. But I think as you get older, those things get easier.
Well, and then you have that, you have the perspective that you've been around for a while, you've seen the trends, you see how stuff plays out, you can make better bets on that. This portion of Talk Python To Me is brought to you by Linode. Are you looking for hosting that's fast, simple, and incredibly affordable? Well, look past that bookstore and check out Linode at talkpython.fm/Linode. That's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server
with a gig of RAM. They have 10 data centers across the globe. So no matter where you are or where your users are, there's a data center for you. Whether you want to run a Python web app, host a private Git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly support, even on holidays, and a seven-day money-back guarantee. Need a little help with your infrastructure? They even offer professional services to help you with
architecture, migrations, and more. Do you want a dedicated server for free for the next four months? Just visit talkpython.fm/Linode. There's another aspect, too, on the development side, which is I really like working with senior programmers. So I like working with junior people, too, but in a different capacity. I have two interns right now, and they know that they're interns, and they do intern-level work. And so they're learning,
and they're growing, and I'm mentoring. And I think that's really, really important, actually. And I get a lot out of those relationships where they help me a lot by expanding just how much I can do in a day and kind of being cheerful and supportive and all of that. But for architecting software and getting it shipped on time and on deadline and without bugs, like, Brett and Reuben are both over 40. They have
both been doing this for over 20 years. And I have so much confidence if there is a problem relating to back-end engineering, like, Brett will just fix it. If it's a really hard problem, it will take longer than if it's not a hard problem. But he will solve it. And if there is any CSS problem or, like, JavaScript, React, front-end, like, Reuben will figure it out, and he will do it. And I have hired people who were more junior in their careers, and they just didn't have that. So
junior people are wonderful. We have to mentor them. We have to support them. We have to bring them into our organizations. But we also have to appreciate that senior people have a capability that comes from that, you know, all that experience. I totally agree. So let's talk a little bit about your business that you're building and this whole side of security, basically finding security problems in software, right? So let's start. There are so many. Yes. It's not hard.
I'm sure it's not. So let's start with just the overall idea and the name of what you're building. Yeah, we are Faster Than Light. And that is our goal. Our goal is to be faster than light at static analysis and other security tools. Yeah, awesome. So primarily what you're doing is you're trying to democratize and speed up static analysis of code, right? So I've got some software, and I've written it, I put it on the internet. But who knows how long it's going to stay safe up there.
That's a mistake. Don't do that. Take it, undo it. Revert, un-pull. So I can run my software, whether it's Flask or Django or whatever, through your tool, the source code through your workflow, and it'll tell me things that are potentially wrong with it, right? Like, for example, if I'm running Flask in debug mode, and then I just put it on the internet. Don't do that either.
You know, there's the VexoEg debugger that you can just open up and see what's happening and issue commands, all sorts of craziness may just be on the internet for people to find, right? And there's literally tools that go around and look for that kind of stuff and have a catalog, right? Like Shodan and some of these tools will just like, show me all the, you know, sites that have this open and I can just talk to it. So you want to know about that?
Yeah, I think we're seeing a lot of that. I think the Capital One hack that happened recently is a good example where they had something misconfigured and the hacker got in. Like this sort of thing is very, very common. It can happen to anyone. Part of my mission, what I'm trying to do here with the whole team at Faster Than Light is just make it easier and faster and simpler for people to test and ship more secure code. And I like static analysis as a way to get into that because it's really
accessible to anyone. It's something that an individual developer can do. So on the one hand, it's something that like big corporates do and like, that's good because it means like we have a business model and know like we can eventually kind of stay in business. But for individual developers, like I think that's where my heart is because it's a way for you to level up as a developer and just ship higher quality code. Well, there might be some kind of problem with the software that
you've written. Maybe you don't have someone doing the code review, you wouldn't know anything about it. But if you put it through some sort of static analysis like this, it'll say, oh, did you know that you are sending commands to the shell and you're not sanitizing user input? You're like, wait, I needed, is that a thing I should worry about? I didn't even know I needed to worry about that. Right. So it can help you learn a lot about these things just by discovering like a problem that you
didn't even realize was a problem. That actually can be a way for someone to like come into security for the first time, like scan your code, see what issues come up and then learn about those issues and how to fix them. Right. So I would love to eventually create like content and stuff on our website and videos about how to fix these issues. So hopefully that'll be coming down the pipe soon. But in the meantime, there's a lot of information available. And if there is a pretty serious
security issue, you know, you should fix it. The tools are helpful for that. We're building on top of open source tooling, which I'm actually really happy about because these existing open source tools are actually really, really good. It's just that they're a little bit of work to set up and to use. And for me, I'm kind of impatient about doing that kind of configuration. And I think for people inside companies, like you just have so much to do, right? Like you have too much to do in a day.
So we built a tool that saves you the trouble of the configuration. And it's free. We certainly we have a free tier. At some point, we'll put a paywall up, but we're always going to keep a free tier for developers. So for us, we think that what's useful for developers is just making it like a super, super fast to test your code. So what we've done in terms of interface is we have a command line tool
coming next week. And we have right now a website interface where you just upload your code. We run bandit against it. And then we give you a PDF with the results. And then we hope you'll go and you'll fix things. Yeah, that's cool. I guess you can message me or grab. Yeah, yeah, for sure. So the command line tool sounds really nice and pretty obvious for the upload. Do you like zip a folder and upload the folder
or something like that? Or how does it? Yeah, how's that work? You can just drop a folder in. And that's part of what like we flatten the dependencies and we make it kind of easy for you to just like drop all the code in. Right now we can run tests against give or take like a thousand files, which is actually like a lot. Yeah, for Python code, that's a lot actually. It is a lot. That's well, that's part of what we want to do. I'm very impatient. I was like,
it should just all be like instantaneous and make it as easy as possible. Like everyone should just test their code and not have to wait for the scans to run. And I think I'm a little bit unreasonable in what I'm hoping to do here. And that's some of that is like Brett has set the bar really high because there's a lot that he's capable of getting done. So we are building this parallelization tech,
which is exciting. And it's going to run the scans in parallel. I'm very excited about that. That'll make things very, very, very fast. And that should be live in a few weeks. But in the meantime, the site works, you can go to bugcatcher.fasterthanlight.dev and upload your Python code and test it. And if you have questions about the things that come up, like you don't know what the errors are, how to fix them,
my DMs are open on Twitter and we can figure out like, what's the best way to get in touch. But I just, I want everyone, please test your code. And if I can help you test your code, let me know. Yeah, that's, it's a great service that you're providing. I mean, people can go and set up the tooling, but to be able to just drop it in there and get an answer and not have to think about
learning how to set up something like Bandit or something like that. It's, it's really nice. I'm sure there's a lot of folks who go, we should probably test this for security, but I haven't. done it right. But if it's a matter of just dropping it in, one thing that comes to mind for me that really interesting is some form of like GitHub integration. Yeah. That's on the roadmap.
Yeah. Yeah. So like if I'm going to accept a PR, it would be great. I have capabilities and GitHub to plug it into continuous integration, build pipelines or flake eight or something like that. But just like one more like, Oh, and you know, faster than light gives it the green check. So from a security perspective, nothing super obviously broken. Yeah. I can see the usefulness of that because we run into a lot of issues, right? Like just accepting
pull requests or kind of accepting things that are upstream. And it's been actually really cool to see like you've got a sneak here in London is doing stuff for testing like upstream things in open source. And there's a lot of awareness around that. But pull requests and for sure, just your own code, like the biggest, how do they say, you know, like the dangers in the house, like the biggest risk is the code that you're writing yourself. You're the biggest risk.
The call is coming from inside the house. That's right. That's right. That's right. The bug is coming from inside your basement. Yeah. Interesting. So this is analyzing your code. Do you all do anything around dependencies? Right. So I write some code. It depends on package X package X depends on three more. Do you do anything
around tracking or analyzing that kind of stuff? I mean, you probably don't download and analyze it, but do you have any warnings for issues that are like downstream or upstream, I guess, rather? No, right now, sneak is probably the first company that comes to mind for that. And there might be others. What we do is like, we'll analyze whatever you throw at us. Yeah, sure. And we're increasing the
capabilities and also our speed. And so, you know, you could just once we have a little more speed up and running in terms of the parallelization that we could offer, like you could just dump all of that into faster than light. And we will run, you know, find bugs and bandit. And like, we're going to be including, you know, JavaScript scanners and like all these different things. And so, you know, coming down the pipeline, just like drop it all in and we'll scan it. But you'd have to go and like
grab all of it and give it to us. Yeah. Well, one of the problems with these kinds of tools, I think, is sometimes it'll tell you you shouldn't do something like, but in this case, it's okay. I know actually what's happening means this value will never come from user input. It's only going to come from what we type in the CMS, for example, or whatever. Right. And you're still going to get that warning that, you know, you're not escaping this and like HTML encoding. You're like, that's
because I don't want to, you know what I mean? Right. And I see if you would add that to like all the dependencies, you would just get a huge number of false positives as well. And it could just be like overwhelming. You know, I talked to a lot of people who say that they would do static analysis, and they need it to be faster. Like, okay, good. We can do that. But they also just want to see the top 20 bugs or they don't want to see the noise. So we're able to show you just the top bugs because
we have this interface. And so it's pretty easy for us to give you settings where you choose that. In terms of saying you don't want to see certain errors anymore, like banded and a lot of the open source tools already have like pretty good features for that. And then of course, like we can do that too. And I think that's part of the challenge with static analysis is like, right now, you always need a human to do the review. And part of what makes static analysis
so frustrating is it's just it's like a spell checker. And there's like all these things are just like, I just none of these are relevant. But then there's the two things that it catches that like you really needed to catch those things. And so it's still not optional. But I think a lot about like, how do we reduce all of that noise? We have an annotation feature, which we're pretty excited about. We don't talk about it much. It's like it's not deep tech. It's just like the ability to write
notes. But if you are sharing your reports with other people, it can be kind of neat. Like, just make a little note like, okay, it says that there's like an API key there. It says that like, there's this problem, but actually, it's fine. It's safe. Like we're aware of it. And like, please don't not buy us for like, please don't yell at us about this. Because that's one of the big
problems, right? It looks like there's bugs sometimes when everything is just fine, because the code is written safely. That's another interesting thing. If you might be licensing your source code or your software, or you're actually being acquired, or something like this, a lot of times, those situations will require that your code go through a whole bunch of different auditing and security checks, right?
And so it would be great if you as you built your software, you already mostly removed all those things and kept track of them, right? Yeah, it'd be good to not be surprised in those moments. And actually, acquisitions can be really difficult. And that's like the type of thing where the acquisitions take a lot longer than people expect. Yeah. I don't think a lot of your listeners are in that situation. But if you are, I guess like good for you. Yeah, these are good problems to have for sure.
But I guess maybe another way to look at it is if you take finished software that's been around for a long time, that's pretty big and complicated, and you throw it at static analysis, it can be kind of overwhelming. If you use it from the start, it's a couple issues here and there, and you address them as they go. But if 10 people have been working for a couple years, whose job is it to go back and fix all those problems? And that can be really overwhelming. Yeah, I was just talking about that
with my friend Alex, an ECO at StepSize, and they deal with tech debt. And part of their thesis is you want to handle the tech debt a little bit at a time. Yeah. So it's manageable. And he was saying, you know, static analysis is maybe the same thing, like, just keep doing it regularly. And then it doesn't become overwhelming. But yeah, I think if you were gonna scan like a million lines of code,
and I'm talking to a pen tester right now, he has a million lines of code that he has to scan. It's like, that company is going to be sad. That's just a lot. Yeah. So I think we're security people. And part of the message from security people is like, please do this all the time. I don't know how to not be annoying about that. I want to make it fun. And I guess, wish me luck.
Yeah, good luck for sure. Well, I do think minimum friction is part of it. That's why I was thinking of like, in automatic integration with GitHub, when you check in and stuff, because then, oh, yeah, you don't have to even ask anyone to do it. It just happens automatically, they get a little like check marker or warning or whatever. And you can ignore it or not. But it's like, right, it's just happening right there all the time. And I think that would actually help a lot.
Yeah, I think that's right. That's on our roadmap for September. But it's always it's always nice when something that we think is important, you know, someone like you also thinks is important. And I we've been thinking about it as like, when you check in your code, you'll get that feedback. But I love the idea of integrating it. So you can scan the pull requests as they come in. Because that's like, you don't want to bring in, you know, bad pull requests.
Yeah, for sure. And then there's so many of the tools that happen kind of automatically, if you had to go then check out the pull requests, and then you'll run it locally, or then upload it somewhere like it just just had that integration, like that friction, it would be gone be great. So let's talk about some of the issues that you would find running through your system. Now, you already said this basically runs on top of bandit for Python,
Python and find bugs for Java. So yes, most importantly, your service is making this easy, giving you the reports to share it, making it fast, all those kinds of things. So understanding what you could find is pretty much at the moment looking at what say bandit can find, right? Right. Although I think we're going to bring in other tools. Of course. And that's exciting. But like bandit is really comprehensive. And you look at, you know, what are the range of
things you should be worried about in Python? And people say, Oh, like Python is a safe language. It's not like C. But actually, you know, okay, fine. Like it's not like C, but you can still get possible SQL injection vector through string based query construction. All right, right. Exactly. Little Bobby tables would work in Python just as well. A flask app appears to be run with debug equals true and allows the execution of arbitrary code.
There are a lot of these bugs. And if you don't run the analyzer, like it's very easy to write bugs. Actually, some of the well, what I was thinking about when I talked about the junior developer not knowing they're doing something wrong when they are is probably the first thing that comes to mind is SQL injection, right? Where you just construct SQL strings out of static SQL strings plus variables
where the values of the query filter bits go and like that's always really bad. So you would find that, of course, the flask debug true, obviously bad. It's very easy to tell if, you know, app.run has debug equals true in it. So that should never be there. But then there's other stuff that's more subtle, like auto escape, for example, in Jinja and flask. I am going to let you talk for a minute while I go plug my laptop in. I am at 4%.
Oh yeah, no worries. No worries. So like, I didn't know that Jinja did not auto escape the inputs. The reason is because I usually work with Chameleon. I don't work with Jinja that much as often. And I don't use it in that context. But it turns out that if I've got some structured HTML, and I just convert to a string, you know, double curly bracket, it will come back out as whatever I put in,
which is super bad if that is user input, right? If I'm in a forum, and I type in curly bracket script, do this bad thing, then when that gets viewed by or rendered by Jinja, it's basically some form of injection attack, which is not good. So checking for things like auto escape equals false. And it even shows you how to turn it on. I think these are all really interesting. Let's see what else. What else do we got there? That's, that's pretty interesting. There's stuff about sending commands
to the shell. There's all sorts of things that I think are really worth, you know, flipping through that list and definitely running that against your code. Yeah. And one of the things that we do is just prioritize, you know, the highest priority bugs show up at the top. I think Banda probably does that as well, if you just run the tool and get the output. Yeah. And so you can just find like, one of the things that static analysis is it can give you
suggestions for like formatting errors, like maybe you don't care about that so much. But you'll see like the highest priority errors are security related. And I think I'm actually really excited for junior developers to take those as a way to like go and learn some security things. And for senior developers, we run our own code against our tool after we built it and we found stuff and we fixed it. And so like bugs, it can happen to you.
Yeah, that's pretty awesome. It's I love these sort of meta experiences where like your tool analyzes your tool or, you know, your language writes your language, the compiler and runtime for your language or something like this, right? It's, it's always fun to see that in the tech space. The first code that we ran was ours. Nice. That's really cool. So let's talk really quickly about the business model for what you're
building here. I think, you know, some folks that are thinking about software business, you'll probably find your thinking on that interesting. So you said there's going to be a free tier for individual developers to do some level of analysis, but then also, yeah, maybe something bigger for like enterprises or just give us your thoughts on how that comes together.
Yeah, it feels really important to me and not just me. I think there's a lot of conventional wisdom around this that if you have a developer tool, like you have to make it accessible to developers. And in our case, it just makes a lot of sense to have at least, we have to figure out exactly what does it look like, but like some kind of free tool so devs can use it and play with it. And because like, we actually really want people to write
and ship better code. Our parallelization deck is really expensive. So we're not going to give that away. But like, you don't really need that if you're one developer uploading, like a reasonable number of files, you don't need to have it go and like super speed. And there's this concept of like, just build it and give it away, like for free with no business model and just lots of VC funding. And that just feels really a little bit dishonest to me. Like if people figure out how to
make that work, I think that's cool. Like cockroach labs just raised a bunch of money and they seem to be doing like a really good job of balancing, like having started off as a free open source tool and then figuring out an enterprise model. Yeah, that's interesting. Yeah. Just so people know, cockroach labs, they create a thing called cockroach DB, which I haven't had a lot of experience with it, but it's supposed to be like a globally
distributed, redundant database server. That's about all I know about it. But yeah, they're definitely I saw this raised a big round as well. Yeah. And I think they seem to be doing a really good job. And I've met with some folks from cockroach labs and I like them a lot. But for us, like for me and Brett and Reuben, we looked at like who we were
and who we wanted to be. And we're like, we just think there's something really honest and really sincere about just making software and charging for it. I think that is so undervalued because so often, you know, the get a bunch of money, get a bunch of users and we're going to figure out how to make money from them. It sets up a lot of bad incentives to not put users first. Yeah. Well, and it runs counter to like security industry thinking. You know, I think a lot of
security people are very aware of like being the product and not like the user. Like you look at all these ad driven businesses. It's like, okay, like does Twitter think I'm the user or do they think I'm something else? Like, I don't know. Like you don't know always it's confusing. And so we wanted to have this simplicity where like you pay us and you know, you're the user. And if it's a free tier, then it's like, we just want developers to like love it and say nice things and give us feedback.
And I think there's a certain honesty in that too, where it's like, okay, like not everyone has a ton of money and, but you should still be able to try it. Like you shouldn't have to pay money just to try it. And we are really excited to give some things away for open source. So we have to figure out like, what's the scope of that. But if you have an open source project, like we really want you using the tool. So like as much as you need for like who you are and we don't want to charge you for
that. So we've talked about that a bit internally and we want to charge enterprises like a ton of money. Like, so that's also, and I feel just fine about that. Like enterprises have a lot of money and they are wasteful about it. And we just want to help them to like be secure and actually like use services that work and that are efficient. So I like that model. Yeah.
Well, around the enterprises, you know, I, a couple of thoughts. One, I feel like so many companies, I don't know what the percentage is, but it's gotta be in the, you know, 99% plus they take so much benefit from open source. They build so incredibly much on open source and they give back almost zero. Like that's such a problem, right? Like a bank that makes a hundred billion dollars a year. Could they
donate a million a year to open source? Sure. They could do they, maybe they employ a core developer, which is great, but they could do a lot more and it would be in their interest to do so. And the other is the consequence of failure at that level is really high. You mentioned Capital One, you can look at Equifax. You can, if there are these security problems, right, it's really bad. So it's also worth their money. Yeah, yeah, exactly. So it's, it seems like totally reasonable to me.
Yeah. And I think what we'll want to figure out as a company is how do we give back to the open source tools that we build on top of. And while we're a three person team, like that's a little tricky. We had an intern who was going to come in and like give back and like contribute and do pull requests
to bandit and find bugs. And then the intern had to drop out. But that was like one idea I had. I was like, okay, we'll bring in people and their whole job will just be to give back to these tools that we're on top of. Yeah. That seems really good. Yeah. So we're really early in that. But I think like we're thinking about it and we care about it. That's a good start. And as we find bugs, like as we use these tools and we find issues in the
documentation or like actual bugs, we can do pull requests. But also now like larger enterprises or even just smaller businesses can use those open source tools a little more easily. And I feel pretty good about that. I actually, I love all the business model stuff. And I'm, I'm actually really happy with our business model. I like the idea. Like we are like, we make stuff and you buy it, we hope, and we appreciate it. And that helps us stay in business. And even if we do take funding,
like that funding is to grow. It's not confusing us about like our business model isn't that VCs pay us. That's definitely a short term one. Yeah. So I think that's a really genuine model. And I think that's nice. Thanks for sharing that. So we're about out of time, but I do want to give you a chance before we call it a show. So you just give a quick shout out to your book, Lean Out. Oh, yeah. Thank you.
Yeah, you bet. So the title is Lean Out the Struggle for Gender Equity in Tech and Startup Culture. And you talked a little bit about that earlier. Do you want to just tell people quickly about your book? Yeah, Lean Out is stories from over a dozen different people, women, genderqueer people in
tech and startup culture, just sharing, you know, what it's like for them. And one commonality that came out in these stories is that making things is easy, or at least relatively easy, and fitting in is hard. And that's a lesson and a moral that I think speaks to all kinds of people and can be, I think, a bit of comfort for people as they navigate startup life or corporate life, whatever it is. I think a lot of us
have that in common. And if you're feeling that, if you're feeling like, culturally, it's a bit of a challenge, like Lean Out can be like a really warm read for you. Yeah, for sure. Yeah, it's interesting that it's essays from a bunch of different folks sharing their stories. So I'll definitely put a link people can check it out. And if they're interested in the show notes. All right. Well, before I let you out of here, though, I got to ask you the two questions
I always ask, please. Yeah. So if you're going to write some Python code, what editor do you use? Ah, that's a good question. I'm not writing any code right now. That's, I'm going to disappoint everyone. I used to be a fan of sublime. This was a while ago. And then Visual Studio. Yeah. All right. Very cool. Yeah. I feel like VS Code has definitely seemed to capture the sublime crowd pretty heavily these days. So definitely cool. And then...
Yeah. Oh, just on that, on that, I think a lot about like what IDE will integrate into first. Again, this is like coming from, you know, I'm like, so in the like product mindset, as opposed to the like, I'm coding mindset. And so I think it's probably Visual Studio with the hope that Microsoft would give us some help there. Yeah, that would be certainly cool. And it definitely like ties back a little bit into the
enterprise side of things, right? It's pretty popular with that crowd. So cool, cool. All right. And then do you have a notable PyPI package or Python library you want to give a shout out to? Oh, just we love Bandit. I love Bandit. That's just any shout out has to be to Bandit. Awesome. Very cool. All right. Final call to action. People are interested in static code analysis, maybe even joining something like Techstars. Like what can you leave them with?
Please try out Bugcatcher and let us know what you think. That would be great. That is bugcatcher.fasterthanlight.dev. And if you are interested in Techstars, just I'd love to chat with you about it. And there is Techstars London will be opening up soon. All kinds of Techstars around the world. I'd be happy to introduce you. It seems like it's a good fit. Super. All right. Well, it's been really interesting to chat with
you about what you're up to. Thanks for sharing your story. Yeah. Thank you. You bet. Bye. Bye. This has been another episode of Talk Python To Me. Our guest on this episode was Alyssa Shevinsky, and it's been brought to you by Command Line Heroes and Linode. Command Line Heroes is a podcast telling the story of developers. This season is all about programming languages and starts off with Python. Of course. Subscribe at talkpython.fm/heroes. Linode is your go-to hosting for whatever
you're building with Python. Get four months free at talkpython.fm/Linode. That's L-I-N-O-D-E. Want to level up your Python? If you're just getting started, try my Python Jumpstart by Building 10 Apps course. Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python. And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle. It's like a
subscription that never expires. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.
Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. you Thank you. Thank you. Thank you.