David is co-founder and CTO of Sentry, an open-source application monitoring and error tracking tool. We discuss building the early versions in Django, being self-taught, the advantages of middleware, next-generation hosting platforms, and general tips to avoid reinventing the wheel constantly in technology.
This podcast does not have any ads or sponsors. To support the show, please consider purchasing a book, signing up for Button, or reading the Django News newsletter.
Will Vincent 0:05
Hi, welcome to another episode of Django Chat, a podcast on the Django web framework. I'm Will Vincent joined by Carlton Gibson. Hi, Carlton.
Carlton Gibson 0:11
Hello, Will Vincent.
Will Vincent 0:12
And we're very pleased to have David Kramer from Sentry join us. Welcome, David.
David Cramer 0:16
Hey everybody. Thanks for having me.
Carlton Gibson 0:17
Oh, thanks for coming on real honor.
Will Vincent 0:18
It's a real honor. So you have quite the history in the Django space. We want to talk about century a lot of new products coming out maybe for those, you know, given our, our listeners, we have a couple of 1000. And some of those I think, are well familiar with you. But for those who aren't. What's the quick story of how you got into programming and Django and then we'll go from there?
David Cramer 0:37
Yeah. You know, I'm, I guess, old these days old enough. So I've been around for a long time. So I got my start with PHP, like a lot of folks. And I don't know exactly what the trigger was. But at some point, I was interested in doing other things, like learning more things, or learning, I guess, how to level up something along those lines. And Rails was hot at the time, and Django seemed kind of interesting. And, and I had actually briefly looked at Python before that. And I'm just like, what do you do with this? Without the web framework, it did not seem overly useful back in the day. But it was easy to learn, which is one of the big things in my career. Yeah, so I got started in Django, like point nine, five ish, somewhere around this time frames, and just kind of been grown with it ever since I remember, a little bit less. But I think honestly, I was just looking. I'm like, oh, we should build, like, we should use a new tech, like a better technology versus this random hodgepodge of PHP. And I was exploring rails, and I'm like, Okay, what else and I, I have this vivid memory of just seeing, like a video demo of you could put the comments template tag in there. And it just like, all of a sudden, you had comments, I'm like, Oh, that's cool. And that was like, that was like a revolutionary idea. I feel like at the time these days, it's kind of silly. But you know, at the time that like, just made the idea of many different things a lot easier. And you know, then I can peg rails versus Django. And I'm like, Well, I've no idea how this Ruby thing works. So your photo
Carlton Gibson 2:05
did that.
Will Vincent 2:06
Yeah, I don't think anything's changed. I mean. And then did you have a formal background in computer science? Or how did you get into just programming in general?
David Cramer 2:16
Well, I felt like I was like, I don't know, 18 years old, when this was all going on. And so I'm self taught. You know, I'm both a high school and college dropout, which means I eventually fixed the high school thing, but then college was also an interesting. And I guess I got lucky along the way, where, you know, my passion sort of aligned with something that pays fairly well, these days. And I was very much a, you're like, typical teenager who's into video games and whatnot. And that kind of aligned well with World Warcraft, which is coming out at the time. And I was just clever enough at reverse engineering, the data structures in the games and so like, the early part of my career started with like, reverse engineer video game, create, like web database out of it. And then, you know, one thing led to another that led to like, you know, one job and in another job, and then eventually made my way out to the bay area to work for what I would describe as more real companies
Will Vincent 3:10
got it. Got it. Well, that makes three of us who are self taught. So you're in good company, though, Carlton went all the way to a PhD. And I'm somewhere in between? Yeah. But
Carlton Gibson 3:19
not in computer science. Like, I mean, so I have indeed, I mean, deep. I mean, clearly, you don't need that computer science pack. I mean, what's your sort of thought, you know, people, people get, I mean, I still 20 years in and get this sort of all I didn't get so yes. Sort of insecurity?
David Cramer 3:39
Yeah, I think it's valuable. Personally, I, I don't know, I felt a certain way a certain for a certain period of time in life, where I'm like, yeah, it doesn't really matter at all. And then I spent a couple years at Dropbox, and they're all like Foro MIT grads, it's like a lot of super smart people doesn't nearly doesn't necessarily mean like, everybody's more effective. But when there's actual, like, what you might call engineering work to be done. They've got a lot more knowledge to solve the problems. And what I mean by that is, I was trying to solve some like, graph traversal problem. And I'm like, I have no idea how to just pull out. And all of a sudden, like, I've got 20 People who just know, like, an optimized path through it. And it was like night and day in terms of performance. And so I valued it in those things. And I don't think it matters all the time. Like if you're just building like a login form, who cares? But when it does matter, it helps a lot. And I think, you know, I have a personal take on this. But I do think there's a gap in the industry now, because there's been so much like everybody wants to get into tech, but then nobody can do like the actual engineering work only, like the simple web stuff, which, you know, suffice to say creates a lot of challenges when, you know, there's a lot of like, infrastructure kinds of problems or systems are distributed systems, and just nobody has the experience or even academics like to kind of know what to do. And so let's see, but so I think it still has its place, but I also think if you're determined but it's not super relevant.
Carlton Gibson 5:02
I mean, I've found just my own experience I, you know, that read, you know, I've got every algorithm book and I sort of go a dip in them. And I, you know, I'm not an expert in that at all. But it is helpful to go Oh, actually, I remember seeing that there's a, this, this answering, then you can go and look it up, which kind of,
David Cramer 5:21
I think you can get a lot of that through experience too. But you'll still like, I would always joke, I have no idea what to call anything. I'll just like, I'll be able to come up with like a solution to a problem. But I there's like, certainly like a formal name around it or something. And I would never know what it is. Actually, like, kind of embarrassingly, I spent less than six months in college. And in that time, is when I actually finally learned what binary actually was, and what hex actually was, before that, I just like, I think I just guessed, or I don't even know what it was, but I couldn't quite grasp what was going on. And I'm like, Oh, this was useful when I learned how like CPUs working, I'm like, oh, that's kind of useful knowledge to understand, because all of a sudden, okay, I took that. And now I understand what a pipeline is, like, from a from a terminology point of view. And so I think just getting people with this same vocabulary actually, massively helps. But you know, that I don't think a lot of CS programs that useful.
Carlton Gibson 6:15
Okay, interesting.
Will Vincent 6:17
Well, that's a little bit like raw Minuchin, right, the Indian mathematician who like create everything a zone and kind of did a couple 100 years, and then at some point got up to the 20th century. Yeah. That's how you should pitch it. Anyways, yeah. I'm just thinking back to my startup experience when I was in San Francisco, 10 years ago, and everyone was MIT, Stanford. And it was exactly that they may not know how to build a static site, but they all off the shelf algorithm stuff. And I certainly think there's nothing wrong with it. You I think you also, you get this sense of programming outside of a particular language, when you're self taught a lot of times you go a couple years in one language, and then it's harder to make that shift. But most CS programs, you know, you're touching a bunch of languages. So you abstract away a little bit, which is frustrating if you won't actually do something, but from a pure learning standpoint, I do think probably makes it easier to just pick up language, though. I mean, like, to your point of video games, I mean, I have little kids and these days, you know, Minecraft and kids, like, I'm gonna learn Java, I'm like Java, it's like, oh, Minecraft, it's like, oh, man, like, I wish there was a Python. Minecraft, you know, because kids are like, Why would I learn Python? I want to build Minecraft. Yeah, yeah, I think that's it.
How do I explain this to a 10 year old, you know, just like, the amount
David Cramer 7:27
of exposure that people are getting, like, there will be more Minecraft for sure in the future. But like, you know, I don't know how Roblox works. But I know that's kind of in a similar vein of, there's a lot of it's like creator maker, or whatever you call this these days. But with the technical approach, which I think is super interesting for the next generation, because otherwise, like, you've got to learn this somewhere, right? And yeah, you'll learn theory and stuff, and in college programs, but like, the practical application of things, doesn't really exist. And like, we always bias around Co Op universities like Waterloo and whatnot, just because those programs where it's like constant internships, combined with sort of that CS theory, that's like the best of both worlds. And I just think that, like, you need the practical application, like in middle school in high school, kind of age range, grades six through 12. And you get that and then you combine it with some theory, you're, you're great. Like, you can solve a lot of problems at that point. And to me, that's, again, you just mean you need that diversity of skill, versus, you know, there was like this trend of boot camps and, and it's like, they don't actually teach you that much. It's like, cool, you can build an HTML form. But like, that doesn't get you actually that far into solving problems. So you can be determined and go from there. But I think the gap is you still have to be determined and have to, like spend a lot of time like self learning to really kind of get over that barrier. And I agree on like, the multiple languages seems like one of my biggest struggles is like, whenever I try to pick up something similar to rust, where it's like, here's all the academia thrown at you all at once. And I'm like, This is hell. Just like bring back some, you know, Carlton,
Will Vincent 8:53
look, how many books do you have Carlton unrest? This is like your bed. Yeah.
Carlton Gibson 8:57
Just working through a new one on CLI, which is very good. Yeah, I mean, the thing with learning a new language is unless you're using it on a particular project, it's kind of slow. It's like, a kind of back burner, you know, okay, a little bit here a little bit there a little bit there. And, you know, I've been tinkering away at it for a year or so. And yeah, I'm about at the point where I'm like, Yeah, I'm comfortable here. I can just but it's taken that long, because I'm not thrown into the you've got to get this program working. And, you know, there's a sort of deadline. Yeah,
Will Vincent 9:30
absolutely. This is a technical podcast so let's just jump right into so sentry air handling like, I don't want to have you repeat the same thing you probably have to repeat on most podcasts. Sentry started as a as a Django site, I believe, is that correct? Like, what's the what's the quick history rather than making the rest of the podcast about what century is? Do you want to talk about the cool details of it?
David Cramer 9:50
Yeah, quick history. 2008 ish, Django debug toolbar, simple snippet, use the admin hooks, and it was a middleware and that's all it was is it would come After exceptions thrown into admin, and you'd have a dashboard fares, and that seemed super useful. And so over time through like, sort of open source and community, all this, like I expanded that further to be sort of abstract of Django, like breaking it out and going from there. And it was always just like, how do I make my job easier and more satisfying, like, it's not fun when you're sitting here trying to like reproduce a bug, and you've just got no details. And so there's just lots of times in life where I just didn't have access to the right information. And, and I would always build things to try to solve for those problems. And sentry is one of those many things. And it's also probably the one that's the most successful at this point, clearly, but But yeah, and these days, we do a lot more, but mostly focused on those developer kind of, how do I debug production code problems?
Will Vincent 10:49
And then a sense of size? Like, how many employees do you have? Like, is what's what sort of number do you reach for in terms of, you know, showing up into the right growth? Because I just think of centuries everywhere? Yeah, like, how do you all internally think about the growth?
David Cramer 11:03
So these days were like, 400 people, part of that we just acquired code cups. So there's a kind of a spike in growth. But yeah, I think, when I thought about building century, I mean, I just like building software. So it's like, cool, successful, that's awesome. But like, for me, it was like, I just like doing this thing. So if I have to build a business around this thing, I'm gonna do it the way I want. And so the the key thing out of that was, I wanted all of my peers to use the thing I built, because it makes it much more satisfying, then you can get feedback and like, like, the hallway tracks at conferences are always fun to talk shop, you know, right? I want to be able to talk shop all the time in life and not feel guilty. That's basically what I optimize for. And so that's in our company values, we actually have this written in that it's like, we're not an enterprise company, we're very market share focus, which means you treat a lot of things differently. And so, for us, I don't know what the customer counties is today, or these days is rather, but I do know, we have somewhere around 50,000 people who pay for our service, and by people, I mean organizations, like companies, which to me is like awesome. And and we achieve that by charging, like a fair price and all these other decisions along the way. But it's awesome, because like, that is like bigger than most companies in the world that try to sell like enterprise software. And I don't know. So when I think about growth, and I think about goals that just like, there's still a lot more to do. And that's why we do a lot more of the Django these days. It's like how do we like kind of service and help more developers and more like different kinds of of software. And so I think a lot of a lot of things to solve within it yet. But that's the main way we focus on where we're going. So it's not your typical like business, what are our goals, or what's our growth, you know, kind of thing, it's just like, build it as it makes sense and optimized for becoming the most successful thing we can be. But from a mindshare, not just a dollars and cents point of view.
Carlton Gibson 12:51
That's so good. Because I've used sentry for years and using it, and I've always had this exact same thing is that it's open source, right? So I could download it, I could put it on my server, I could run it myself. And I've never once done that, because the pricing is just so fair. And you know, it's you don't a lot of things you feel gouged by, I've never felt gouged by surgeries, I've always just been like that, I'll just pay for it. Because every client I've ever had, I'm like, just pay it, it's like, you know, you got to save that in the first week, from the speed of speed or triage or speed of, you know, you're just gonna get more information out of it. And it's not worth the effort to run it yourself. So actually, you talk to that, because I just think you've out of all the companies I can think of, you've pitched it just perfectly in that balance of Yeah, you could run it yourself. But why on earth, would you
David Cramer 13:42
Yeah, and I think honestly, like, one of the things I've recognized over the years is, I build a new hobby project or some kind of internal service, which is basically all I can do these days. And I install sentry right away, because I feel like I'm handicapped without it now, like I actually, like, I just don't even pay attention to like QA, I just assume that if something's broken, that I've missed, it will like show up. And so and the actual realization of that is like sentry actually provides this immense value from like day one of going to production, we're actually over time, it saves you a lot of money, because you don't need to bring in like a bunch of expensive vendors, you can actually get away without like logging for a long period of time, like a very, very long period of time. And logging is very expensive, or like the traditional APM stuff, you'd have to buy like a New Relic or something. And they're also very, very expensive. And you don't use 99% of whatever that products trying to give you even if even if that 1% is actually useful to you, right. And that to me was like the great realization over time. And so we've tried to keep that in, kind of in check as we grow and try to expand and especially as we expand the business side, it's like remember, like, the goal is like that, we will expand the market and we will have many, many customers and so it's okay to not try to over rotate on the cost per customer. And so when I remember I went through this exercise, and you know, this is not technical, so sorry, but, uh, with our VC early on, and it's like, how do you build $100 million in revenue? And I'm like, I don't know We get lots of customers. And then we just like did the math. And it's like, okay, we need every customer to pay us like $2,500 a year. And if you know anything about a lot of these successful companies, they're that see, that's ACV, their ACV is 10,000. Plus it's not 2500. And so we're actually approaching the business from a very different model. And it's like, how do we just continue to drive more and more value? Not? How do we charge more and more money from the exact same thing over the years like, and like, I don't know, enterprise or whatever, because you find a lot of companies, they just grow. And all they do is like, they give up on what got them started, like they start, stop offering a free plan or stop offering a cheap plan, all of a sudden, everything's super expensive, and I just never wanted to be in a business. It's not as satisfying. So
Will Vincent 15:40
Well, it seems sustainable. I mean, this is one of the questions like Carla and I are both in our 40s. Like, you know, at a certain point, it's like, why, why do you keep doing the same thing for a long time? And it sounds like you're leading with values? Which makes sense, right? Whereas it doesn't necessarily matter. You had a certain growth target, though. I mean, for investors, it's like you're serving a mission. So that makes sense that that can be, yeah, let me see. So yeah, but that's exactly the sense I have invested
Carlton Gibson 16:06
in the business and you want to hang around, you're not like, sell it often, you know,
Will Vincent 16:11
publicly tell us how you feel.
David Cramer 16:13
I mean, I'll be honest, it's draining after a decade plus of doing this, but I'm invested in the outcomes, and I'm still very passionate about it, I think the hard thing for for folks to understand is this concept of control, like, you lose a lot of ability to get, the way I describe this is like, if you're a builder, like you just like building software, which is who I am. At some point, very quickly, the company gets to the point where all you can do is describe what you want your like sort of painting to look like, you're like, I want to like a horse or something. And maybe you tried to give details, but you can't paint it somebody else has to and you have to tolerate that, like the horse is going to look wildly different than you want it to look. And that's actually like a very challenging gap for me, because I still want to be in the weeds and build things. And these days, I'm just not hardly at all. But I still do drive a lot of technology and architecture and sort of Product Strategy, which I think is what keeps it interesting. And I think the the challenges and sort of continued momentum. You know, kind of keep me going to some degree like as as an analogy, like, I very much want to see this through to a public company, which is kind of the trajectory we're on. And I'm just like, Thanks world. I don't know when this is going to happen now because it's, you know, another day vaccine and everything that's going on. Yeah, I'm like, great. Because for me, that's like the big milestone. Yeah. And I'm like, I don't know, maybe there's a milestone after that. That keeps me going. I'm not sure. But that's for me, the really exciting thing right now is like, okay, like we're gonna build a public company done a very specific way that's not been done before. And a lot of that's with like our open source thesis in mind and how we've approached customers and like the large market share and things like that. So that those are like, the exciting things for me less so than the technology things these days. No, I think at least more recently, we're starting to do more interesting tech investments, which is, I guess, one of the cool time to get out of becoming a larger organization as well.
Will Vincent 18:02
So I'm sorry, you said you didn't want to talk about technology. But I'm curious, since you're somewhat removed from Django itself, how do you see the web framework landscape these days, because I always find it interesting take, you know, we're very kind of narrow and this podcast,
David Cramer 18:16
I, I worry that Python is dying for anything. That's not data science. And I worry because like, at the end of the day, there is a shift towards sort of this service architecture, which is abstracting the front end away from sort of the API web side of things. And Django certainly makes it easy to build like a small project, but I never use Django anymore. I'm always like, Okay, I want to build like a rich UI. And building rich UI. Django is actually like, quite difficult, because it doesn't have a way built in to make it easy to bundle, say, like a React application or something like that. And I don't think anybody saw this for what it's worth yet. But almost every time I build a new project, I'm reaching for a new JavaScript based approach. And my My dream would be cool, let me write the front end and JavaScript in the back end and like Python, or something, but I don't want to have to run multiple services or set up like this complicated dev environment, right? Because like, my goal is like, how do I just build the thing, and like, not build the dev environment, like, I don't want to spend all my time just getting off the ground, which I do, it'll take me like three days to bootstrap a new project, which I hate these days. And I could eliminate that by like using something like Django or rails or something that's like, more traditional, but then you just lose all of this sort of innovation that's going on with the UI frameworks and those components. So I think Django is still good. And I especially think the ORM is still one of the best solutions out there. But I do worry that there's not a clear decision these days of what is the best and what is going to survive the next three years because almost every project I started is like broken a year from now or it's like really hard to rebuild, mostly because of dependencies and
Carlton Gibson 19:46
whatnot. But is that not because you're using JavaScript? Like
David Cramer 19:53
it is part of it. I will say the same thing happens in Python. So we had this project that my co founder and I worked on, must be a decade ago and And every year, I'll be reminded of something, I'll try to boot it up again, and it doesn't work. And so every year I'll spend like an hour trying to fix it or fix my requirements at tax or, or fix the fact that now it's on Python two, and I'm even more screwed in this. But um, and so it's a similar problem JavaScript just more extreme to that problem. And so yeah, I have not, I mean, I still know Django very, very well. And I still have strong opinions about what works and what doesn't work in it. But I've not actually written anything in Django and quite a while, other than bolting on like, some patches and stuff here and there.
Will Vincent 20:32
Okay. Well, I remember I think it was, was it 2018 or 2019, sent at Django con us in San Diego century had a big presence. There was like the Fight Club, like bath bombs and, and all this stuff. And in the hallways this year, there was a lot of talk around htm X was probably the main takeaway as to your point, you know, how do we still do Django but not get caught up in JavaScript things? Do you have a hot take on HTML? Are you familiar with with that?
David Cramer 20:56
I'm familiar with the I've not used that. Personally, I'm familiar with the concept and the the implementations, I think it's a good idea. I think the challenge is like, you need reactive interfaces, right? Because we don't want to go back to jQuery land where we're doing all this awful, like HTML manipulation. And I think at the end of the day, like, I don't want to write well, to be honest, I've never been a fan of Django templates. But I definitely don't want to write Django templates, I want to write just my actual reactive interface. And I want basically context to be stuffed into that somehow. And so I can't comment on the implementation, especially on on the Django side, but like, that is not technically hard to pull off. I think the challenge most days, honestly, with JavaScript is the the translation like, like, I have to go from one dialect to three dialects deep, like I need to go from like, like some modern TypeScript II thing to some modern JavaScript D thing down to like some compressed compatible layer. And it's like, making that process work is never fun. And even early days century, we had built like a middleware like a Django, I don't even remember what I call the project, but like a Django extension that would do the compilation for you. And it would call out to like, Webpack, or whatever else. Webpack was, at the time, there was probably something else. And it was a nightmare to maintain it just like it was so complicated. And that, to me, is the gap with basically any framework these days, and I actually think it's a lot of opportunity. Because no matter what, you're going to be compiling some kind of thing, or you're gonna be doing some kind of asset manipulation, right, you need like that build pipeline. And it's honestly, it's just like, it's way too customized. And it doesn't need to be everybody does the same thing. Like we all like, we want to like, like change the JavaScript from one thing to another, we probably want to minimize like image asset size, we, we probably need to like write a bunch of like, manifests to help the CDN or something. They're all like exactly the same, there's no reason to have like, 50 different flavors of the same problem. Like nobody cares about the syntax of the manifest, just use one and call it a day. Like,
Will Vincent 22:45
I mean, I don't want to argue with you. But I would say outside of JavaScript, I feel like most languages have, like a behemoth or two that most of the energy goes into. But I mean, but maybe that's a lead into I know, what century a lot of what you're doing with error handling performance is actually switching to the front end. Right. Is that correct? Right, which is still some, you know, when people say, How do you test the front end? It changes every year to and there isn't a great answer. Yeah. So I guess do you have what's what's your what's what do you make of the the front end, you know, in terms of error handling and performance these days,
David Cramer 23:20
I think it's still way too immature. And I think the problem is people like to reinvent the wheel, I do not enjoy interactions with a lot of the JavaScript community, going back to the conversation about CS, a lot of them could benefit from going and taking some CS classes, like because everybody just wants to like completely reinvent everything come up with new like vocabulary for already known problems. And it actually just creates a lot of churn. Like, if you look at like that, just the amount of time wasted on reinvention where we make basically no progress. It's like, what are we doing? And maybe this is a little bit of like a tech bubble. But there's just way too much of that. And there are some good things happening. To be fair, I think, like React is a phenomenal technology, take away all the other NPM ecosystem stuff. But react itself is a great technology. And I think if you think about like the server components, stuff that's coming, I think they've got some stuff to figure out on the API's. Like that is also good, because that solves our reactive UI layer. But with basically one like template language kind of thing is how I would think about it. And to be that's exciting. But I think all the other stuff is like why are we just reinventing the wheel over and over and over and not maintaining it? And I think that's the risk these days is you like invest in like a technology, you have to upgrade it all the time. Like, like if you been working in like on the software or the backend side of things, right? The infrastructure side of it. The rule is don't upgrade don't ever upgrade, like even Django like we were on an old version of Django until like, I hired a bunch of people and like, no, no, we need upgrade. I'm like, why? What's the purpose of upgrade? I don't need LTS support, we can patch it ourselves. There are no security flaws, because we don't use any of that stuff. Or it doesn't exist in our version of Django. Like we can maintain that right. And that's a that's like a maintainers philosophy of, of software systems, right? Like software doesn't go old. Like, yeah, there's some things that are problems, but like it works kind of forever, where it should. And now the problem is and like jobs can buck up So you have to update all the time because the dependency graph is just like 1000 deep, right? And like one thing is gonna break and you can't fix it. Because the other thing is dependent on it. And it's, there is no solution other than to stop doing that like to stop the dependency graph. Like, it's not good. So I don't know, it's like, that's my mini rant. But I think it's like, there are good ideas, there's good execution, and we have to evolve it a little bit. But a lot of the stuff we're doing is actually not evolving the conversation. It's just like, you know, reimplementation,
Carlton Gibson 25:28
you know, I mean, I, that rings true. I used to do front end stuff, you know, and I used, the way I got into Django was doing API's, and Django was what I used to do the API's that went with the front ends I was building and over time, I slowly moved more and more into Django, world and back, and well, because I just couldn't, like take the constant, you know, burn down, start again, burn down, start again, burnout start again, it's like, no, like, this isn't sustainable for me, and I just drifted further and further away. It's why I'm so excited by the, you know, the recent emergence of things like HDX, and alpine and these much more lightweight solutions that are like, actually, that there are single scripts that you just bring in, and then you've got everything you need. Yeah, I mean, that's reactive UI is that you're talking about, it doesn't give you that,
David Cramer 26:19
I think what we're gonna see that happens is we're going to find a way to simplify the service architecture, to where front end back end just becomes separate. And that's fine. We've accepted that, because the only way most of this tech actually works today is if you actually separate the front and back end is like separate services, right. And even if you look at technologies, like next Jas and remix, which have both server and client, the server is not a real server. Like, as an example, good luck using middleware, which is like unknown, like, I have to go, like, convince them that they need middleware as like a concept. And they're like, Whoa, that doesn't make any sense. I'm like, trust me, it makes sense. Like, that's how the entire world works is like we inject middleware, and that solves problems. And they just, again, it's like reinventing the wheel. And like, a lot of this is like, they don't have real world experience of systems engineering that know that these things are like necessary to deploy to real production scenarios. For as I used to pick on Django, everybody's just building a block. And like, cool, you can solve the blog case really, really well, like so next, for example, is phenomenal, like E commerce. And that's cool. But like, I can't build century index. Jas, I can build centuries front end index js. And so I that might be okay, but that world is so hard, because then all sudden, I probably run the Docker containers or something locally, I've got like, I've got to spin up two different environments, because it's not one ecosystem, two different package managers. And it's just like, you go down that rabbit hole, right. But I think that's where the world is going is some version of that service architecture with front end and back end, where you don't need to solve every problem in one. But we've at least simplified it. So something like Django or some abstraction can easily manage Django and whatever UI layer I want to use, just like, you know, whatever CSS layer I want to use for that, that face.
Will Vincent 27:53
It's almost like as, as the web and things get more complex, you need more specific focus. Like I'm thinking, we talked to Craig Carson's from crunchy bridge about Postgres, and we're saying, Why doesn't, you know, the new generation of hosting platforms have managed databases? And he was like, I don't think they're going to, just because it's, it's just so much more work. And so this sense of just, yeah, there isn't one all in one, there's like, you know, for website, Manage Database, because dedicated front end dedicated back end, sort of makes sense. As things get more complicated. I mean, it would be nice to have everything all in one, but it's not gonna scale. It's not gonna be maintained. Yeah. We're just moving past that phase of the web.
David Cramer 28:34
Yeah, no, I would push back on like, I think if we look at these new generation of hosting platforms, they're just very early in their lifetime. Like, they're not deploying real applications. They're deploying, like as an example, like, we use resell, but we use it for like our marketing website. And it's great for that. We don't use it for anything else, because it can't talk to our database. And I'm not going to like talk to a database that's exposed to the world, because why would I? Like why would I add more security risk in what is like the scariest time for security in all of history? Right, like, and I think this is the gap people are not realizing is like you can't, Cloud is not some magic, you connect all the like random vendors together. Nobody wants to do that. Like I want to buy stuff that's run on GCP, I want to buy stuff that's run on AWS, because I can trust that vendor, or at the very least, that vendor has a lot of liability associated with them. Yeah. So I think there's still a gap there. But like, what I see, they're not all the same, like fly is different. And DigitalOcean, of course, is different, but like a lot of them are just at the end of the day. They're almost like somebody's gonna get mad at me when I say this, but they're like glorified CD ends. And that's fine. That's, that's a good problem. Like if you're just deploying like a front end, right. But my back end is not going there because I need access to sensitive services. And those are going to be like, as firewalled off as I can possibly get them. So So I think that's so gap, but it will change. And you know, what we'll see like planet scale is like, cool, but I'd much prefer a planet scale just be installed in GCP, then some third party service that's going to hold all my sensitive data, again, which is why I think a lot of these are like their toy projects. Right now, like they're used for prototypes in startups, and this is Heroku, even at the end of the day, for the longest time is like, you're not building a technology company on top of these platforms, you're might be building like immediate thing or a prototype. But at the end of the day, like every real business that is technology to be clear, and that's different than say, ecommerce or any these other businesses, is running infrastructure on cloud provider. And that's where everything is going to live. So, so I don't know what that evolves to. But I just don't think a lot of this this view of like, Yeah, we're gonna interact with these like crazy databases and these, like, if you've ever used Firebase, which is just like, the most awful key value store, which is like, the easiest thing in the world to expose all your
Will Vincent 30:42
sketching, even like, six years ago? Yeah,
David Cramer 30:45
yeah, it's awful. It's not it's not by design, it's bad. And you can't fix bad design, like, you know, we can talk about like the Twitter thing, right, like Macedon, I don't think it's ever going to take off because the design is so technically unachievable to do what it wants to basically reimplement, Twitter at scale, right to collect that degree of, of social interaction in a centralized place, which is what it needs to do at the end of the day, and nobody wants to like have to visit 20 of these. And so it's, it's decentralized, but it's actually trying to be centralized. And like, the solution of problems is to like change the problems, you can solve it not to overcomplicate it. So I don't know, we'll see. It'd
Will Vincent 31:21
be nice if there was a you know, sitting on top of AWS Django specific solutions, someone
Carlton Gibson 31:27
would love to see what the new year brings. All right, anyway, listen. So I want to ask about the century itself. So you're talking about people wanting to deploy on infrastructure on a single cloud provider? Like, you know, AWS or GCP, or whatever it is, is that the kind of model that people have people who are actually running their own century, because they want to keep the data rolling in health? Because I yeah, what was it hobby? So like, who's
David Cramer 31:54
there's a few, so sometimes it's a hobbyist that has convinced themselves this is a better idea. Never is okay. But whatever, you're gonna do you some JavaScript developer? No, it's probably like the weird DevOps persona that's like, No, I can do all this. Why don't I run it myself, and they, they don't realize that it would just cost them $30. And like, it's way cheaper, no matter what to just pay for the SAS service. Like, there's no way you get your infrastructure costs below $30 to run it in a production app. So So that's like silly, but ignore that case. There's the I am like, privacy conscious or security conscious, and I, I've convinced myself, I'm better at it. And century, okay, the security thing is BS, the privacy thing, maybe maybe it depends on where you live, like, for example, we don't have servers in Germany. And Germany's got like a much more strict approach to GDPR. So that's a little complicated. So we get a little bit of that. So a lot of like big enterprises in Germany, might prefer to host it themselves. You also get things like sanctions, like it doesn't matter what your politics are, like, governments are both right and wrong at all times. It doesn't matter which government you pick. And so some countries, for example, we're a US organization, we just can't do business with them. And so we just refuse to operate there. Like as an example, like China, like we're not going to operate in China. But people, companies in China can run century, like Yandex run century, for example, in Russia, and like, I'm sure some of the big tech providers in China are also running their own century. And that's cool. That's fine. Like, for me, that still achieves our goal of market share, right? That's like the case that I can get behind. There's also companies and I don't know if they do or don't use century, but like a Lockheed Martin that had like a lot of government regulation. And maybe they need air gapped machines, we're not gonna solve air gap servers for them, essentially can work air gapped, right. And so, so those kinds of cases are like real world. No question like, yes. Makes sense, right. But I think a majority of it is like this kind of, it's not maybe not the majority, but it's like split between those. It's like, yes, this totally makes sense. You should run it yourself. And then it's like, why have you convinced yourself, this is a good idea, you're wasting your time. And our solution is just like, don't worry about it, like people are going to be people, they're going to do their thing. And it's kind of all over the map. And to be fair, that that persona, the DevOps persona, it's not just the hobbyist, it exists at the finance organizations, too. And usually what happens is they're like, yeah, we can run century this is fine. We know how databases and stuff work. And then a year later, they're like, Okay, well, by your cloud service. They eventually they come around.
Carlton Gibson 34:17
And so the second follow up there, it's open source, but what kind of contributions you get back from, like, non century contributions, like, does that make sense? Like, how many Yeah, can be community contributions you get? I mean, I imagine it's minimal, but I don't know.
David Cramer 34:33
Yeah. So I think, you know, I had to explain this to many investors over the years that open source is not a generic thing. And I think people often get confused. So first off, if I say it's open source, a bunch of people on the internet are gonna yell at me and I'll challenge that they are just wrong. But so essentially, is BSL license which is proprietary which basically says AWS and GitLab. You cannot sell century, which is the intent of that license specifically that intent right. But it becomes a patchy after Three years. And so it's somewhat of our balance of like, we need to fund the development of sentry, because nobody else can contribute to it and to get to your question. But we also want to give back to the open source community. And we also believe in sort of the knowledge transfer of open source, like to not reinvent the wheel over time. And so for us, it's actually like, it's tricky balance, because it's actually not relevant this century is open source, if you're honest with yourself, like the the part that's relevant is can you self hosted for free, that's all people actually care about. They're not actually using the code, like we have a company that took our open source version and thought they were going to spin up a competing service, they probably have, like 20 customers, you know, they've gotten nowhere, like it doesn't make sense, just build your own, if you're going to try to like compete, it just it's silly to think you can leverage open source, when it's like a product, you know, if it's like Elastic Search, or something that's a little bit more complex. But from the community angle century, kind of has like a bunch of different aspects, we have our instrumentation side, which is liberally open source, and people can reuse. Now they're conforming to the century API, which we're not going to develop an open standard around, but like we have these SDKs, that you could technically build a competitor on, I think GitLab is for example. Again, high risk, but you can do that. And so those are liberally license, which there's a lot of value, the ecosystem can get off of that because instrumentation is a complicated thing, right? It usually is internals, not well documented API's random edge cases. And so that's actually a useful case of knowledge transfer and open source, people will actually contribute to that. And more importantly, we basically employ every contractor who wants employed, that helps us with our SDKs. And so we've done that for years, we just try to like fund the development through anybody that actually is genuinely interested. And we'll do that for other libraries, too. For what it's worth, like our our web, which is what powers our new session replay product, we've just funded for, you know, a couple years like the the main developer on and that's kind of been one of our approaches, like how do we better evolve that open source ecosystem. But then we have the other side, which is pure, like utility stuff, it's not necessarily connected to the end end user product of century, but it will be like, some of it is some of it isn't some of its like we have all this technology to symbolically there. So basically, to take the machine readable errors and make them human readable, which, you know, JavaScript has a version, which is like source maps, and it's just like D minifying, basically, and converting back to TypeScript or something. But then iOS has a completely different version C, C++ has a different version. Ross has a different version, some of its standardized, but like we now have, I think, the leading solution in the open source ecosystem, to symbolically code to the point where I think like folks, like Mozilla actually leverage our open source. And I think some of our competitors also leverage open source to power that same behavior. And they will contribute back sometimes, like, like, and that's actually awesome, because those cases are, that's, that's computer science. Like, that's actually a hard engineering problem, right. So we'll have stuff like that. And then we'll have like pure utilities, like, like I wrote, like, a test harness for requests a long time ago called responses, which literally somebody at our company just maintains now. And like maybe there's open source, but it's like, it's widely adopted in the open source ecosystem. And we barely use it a century. And so as an example of like, like, different flavors we have going on of open source that our company, but the main thing is, like, everything we do basically has like a, a don't ask for permission, open source model behind like, it's like, if it's a server, you follow this licensing schema, if it's not do one of these other approved things, we don't care. Just like build the thing. We're not focused on this idea that like, technology is super secret, and we're protecting some IP shenanigans. So the model is very much open source, even if the literal implementations of each one are not like, you know, proper now and open source. Yeah, okay.
Carlton Gibson 38:29
But I mean, I remember when Redis introduced a similar license, because they were fed up of getting, you know, the business taken out from under them. And I have a lot of sympathy for them. But the internet went mad, and it's I but from my perspective, it's still open source, right? Because what I want to know is okay, look, you know, can I say, Can I see it? Can I verify that it's, you know, safe to run on my servers, because doesn't contain malware? That's important to know. Could I forget if I had to, I mean, not me personally, but you know, could it be fought if it had to be that kind of things important? The fact that there's a clause in the license that says Amazon can't run our business?
David Cramer 39:11
I agree. And I think like, if we might do this, for what it's worth, I'm gonna push the legal team, I want to relicense and just name it something obnoxious. My business source license right now I'm like, can we just make it the very serious business license, and we will just like hard mean this on the internet, because the whole idea that you should not have some protection is just like, it's silly. It's like immature, like, right. Like, what what I value out of Redis, again, is that I can run it that like, if there's a problem, I can fix it. I can maintain it if I need to. I can hire people to maintain it. I don't need to commercialize it, like the business I'm in is not commercializing somebody else's infrastructure providing like software, right, that's not everybody, right, like AWS, that is their business, so it's understandable. And for us, like when we relicensed we didn't have to ask permission of anybody, because like the entire contributor graph works for our company. And so There's this like, abstract idea that like, oh, you should be mad even though you have no claim over the software, which is just, it's, it's irrational as all I can say, you know, I want great software to exist. Open source is great, I love it open source, but like I mostly just want great software did exist in us to not reinvent the wheel most of the time. And so that in a lot of shapes is achieved through open source licenses. And it doesn't matter if it's free, you know, open core, which I would say is probably worse than BSL or something like BSL, which is just a proprietary license with some protections.
Will Vincent 40:33
So how does that factor into hiring? I would imagine it helps to have this attitude. I mean, versus other, you know, I don't know, another company that's more proprietary. Oracle, let's pick on. Yeah, I mean, nobody wants, you know, no idea. You're not, that's another competitor. But you know, I mean, yeah,
David Cramer 40:49
I think it helps not everybody cares, to be fair. And I think there's a lot of different things people think about when they're joining companies like sentry is not an interesting thing to work on. Like, we're not doing crypto shenanigans, we're not like aI air quotes, you know, we're not, we're not any of these, like hype industries, we're like, No, we're just going to solve a problem and solve it really damn well. And we're gonna keep doing that. And so you join a company for personal reasons, right? Like, when I joined Dropbox, I'm like, I want to write Python. And I want to work something that has like, serious scale. And it's, it's awesome if my mom has any clue what that is, right? What the product is, like, those were kind of like the tests for me, like, I don't care about file storage, or like syncing files, or any of those things, right? Some people probably did. But you have your own reasons for joining companies. And so some people, you know, like sentry, because of the open source thing like Arman Ronica joined early on, and like, we didn't even know what the company was going to be in that stage. And it was like, cool, we're gonna do open source stuff, you know, we can just do whatever we want kind of thing. And it's just like something we were passionate about. And like a number of people are similar in that century. But surprisingly, it is not a big source of poll in like Silicon Valley, like, Yeah, some people care. But I actually think if you look like that, that subset of people that care is actually pretty small relative to the total ecosystem of developers.
Will Vincent 42:01
Fair enough. We had one of the highlights for me of Django con this past October was David Lord came by for the Sprint's and talking with him just about things. And he had, you know, trying to make flask maintainable, just thinking of Arman's Web. Yeah, software. But yeah, you're right. I mean, I guess we're all biased, right towards open source. But the reality is, I mean, I remember being shocked that when I was on Silicon Valley, a lot of engineers didn't care what the product was at all. They just wanted a hard challenge. At first, it didn't know made no sense to me. But as I get older, I'm kind of like, well, at the end of the day, like, I kind of see it, like, as long as it's not totally evil. It's like, am I going to, you know, what I'm going to do is interesting, and the rest of it is all kind of hand wavy. marketing sales stuff anyways, so yeah, so what
David Cramer 42:45
Yeah, and I actually think, you know, a lot of companies are like, well intentioned, you know, there's the PR, ignore the PR and go like, like Dropbox is, I mean, Dropbox, I don't think has negative PR, but like it was well intentioned, I think uninteresting over a period of time, like centuries, very well intentioned. I actually even believe, like, people love to hate on Facebook, I genuinely believe Facebook is well intentioned from everything I hear from folks that work there, right. And they also get to solve a lot of cool technology problems. And they also actually contribute. Like, I'd say Facebook's actually one of the Facebook and Microsoft are probably two of the most significant contributors to open source in the last like few years, if we're honest with ourselves, like, and you've got to look at some of those things to be like, Huh, you know, that that's like, actually an important thing that sometimes we forget. And I think generally speaking, great. People want to be around great people, and they want to be challenged and continually solve like hard problems, right. And you can only, you know, refactor the same UI so many times and still call it interesting, I guess, at the end of the day, so
Will Vincent 43:41
Well, can we speak of Code Club that acquisition? I mean, century has moved far beyond error handling? What's your quick take on on those areas? And what's kind of exciting for you personally?
David Cramer 43:51
Yeah. So you know, I mentioned like, our goal, and my goal was always like, all my peers use century and I get I kind of that, like, hallway track thing. And, and that's become like, the business model over time is like, we have a rule thing, kind of a soft, hard rule internally. But um, if we're going to invest $1 $1 goes towards developers. And what I mean by that is, it's not going towards management, or VPS, or product managers, or customer support, or marketing, or any these other functions that exist at companies. And the reason is, like, if you look at things like New Relic, once upon a time, they were great. And they service X persona. So software developers, and they had great like, kind of APM stuff. And then they build a bunch of tools for other people in the company. And I'm like, well, that's uninteresting. And that's also why New Relic is basically failing over time as a business or at the very least, a lot of people are kind of like taking their business away. And so part of the business thesis is like one, we should just service the same customer because it's the easiest way to build a more sustainable business because you can just sell more products are the same customer. And you see this with companies like Atlassian, where this is literally their business model, right? And so that's the business angle from the like the practical angle. It's like, we want to just make it like that. easier to build software. And that should be everybody's job that's building tech for tech companies basically. And century's core is monitoring at the end of the day. And, and there's like a thesis that maybe we can bring monitoring earlier in the lifecycle. Because all it is, is it's just instrumentation for errors, and latency and all these other things, right, which, technically, you could get in CI, no problem. And so we kind of want to do that. And that's all for developers, like you'll you'll find, we don't do any kind of like analytics, or any kind of like product usability kind of things. It's only software defects is what we focus on, right. And that's very specific focus. And it's because we just think we have to, like do that thing and continue to do it well. And that's just such an easy concept for me to figure out. And so then when you bring in a code curve, there's a lot of reasons that like I was excited about them joining the company. One is because it clarifies our position more, we're not just building like, we're not going to give you, you know, system monitoring or infrastructure, monitoring a bunch of graphs and widgets and stuff that frankly, I just don't think is useful. We're going to focus on like, I want to ship the software and get back to shipping the software. And I was always bullish personally, like, I think code coverage is actually such a useful metric. Because what I would do, like, code review is a pain in the ass for everybody, like people just sit in code review forever. And so I always optimized like just rubber stamp this, I'm accountable for if it works or not, like, if you want to review the logic, have I tested it well enough, like, start there? Like, is the test coverage actually testing real world use cases, right? And the simple metric of like, how many lines of this pull requests are covered by tests? Is like that alone? Like, just that simple indicator tells you so much. And it's such an easy binary yes, no on should this actually be greenlit. And so I think that alone is useful, but also like just building more on like, the CI side has always been a desire for me. It's what I when I was at Dropbox, I focused on CI and, and CD kind of problems. And I just think it's such an area that like, nobody really builds like, everybody just builds infrastructure, like you have actions, like the the sort of reporting angle of it, the analytics angle of CI is just completely awful. The infrastructure to run the tests, and everything works fine, right? Like, everybody just solves the infrastructure, and everybody that tries to solve the reporting realizes is like a very hard problem. It's like a very hard distributed systems problem, basically. And so I personally am excited to see what we can do pre production, basically. And basically bridging production and pre production, where our kind of point of view is always like, we just want to be able to enable fast decision making like stuffs gonna go wrong, can we make can we minimize the consequence of things going wrong? And like, as an example, I'm hoping in January, we're going to ship a feature in sentry that will overlay code coverage, and basically tell you this, this error, for example, was it tested at all like, is the issue you just didn't write test, because like, people don't like blame, but blame is such a useful accountability structure at the end of the day, like, I want to know, like, I shouldn't be embarrassed if I just cause like a serious bug. And it's all because I didn't write the test, right? Like, if nothing else, that gives me validation for like, I should spend the time on tests. And if that means I need to, like some more things, you know, it's hard to like push for how much time things take. So that helps that that's it. So I would say open ended, we don't know where we're going with the code of acquisition. But I'm bullish on investing in spaces that I think just help us build better software. And so if I could, like, had like, and when I was like, I'd be like, cool, we're gonna, we're going to take you all the way from pre production to production. And we're also going to like, ship the code for you. But I don't know that we'll ever do that. So we'll see.
Carlton Gibson 48:27
Okay, can I ask a question there? Then David Tyson, you said you focus on software defects. And that one of the cool things you bring aboard in kind of recently as the performance monitoring and the profiling and how do you see that fitting into the century? Because it's great, it's lovely, but it's not the same as the exception reporting that started off.
David Cramer 48:47
Yeah. So this has been the interesting test, we kind of pivoted our product roadmap recently, because we've been building a lot of these, what I would describe as dashboards. And now internally, I'm notorious for saying we don't need any more fucking dashboards. Because just a century in life, we have too many things to look at, we do not have the time to look at them, right. And what made century great, literally the one thing that made sense your gut, you could take away everything else was when there was a new air, it emailed us in your inbox, and it was like that. And so you can kind of trust that, like, if you broke something you're going to know about it right away. It's it was proactive in that regard. Now, it might send you a lot of those emails. And there's, you know, it's not a perfect model. But that idea is very important. And so as we did APM, or performance monitoring, which, for context, if folks don't know, performance means two things. For us. It's latency. Is it fast or slow? And is the throughput high or low? Because it's an example of signups go to zero, that might be a software defect defect, that's not an error. And it's not a latency issue, right? It's just, I don't know, maybe you deleted the signup page, right? And so when we think about it from that angle, we're like, okay, what are the problems we can identify? And that's been the change in our roadmap of like, we have two issues product which is basically just air monitoring. And we released like our first kind of POC in this winter was like, Oh, we can detect n plus one queries. That's literally just a software defect. Now, it matters. Because when when, if you've never experienced these things when you have a like a query in a loop, and this is like a common thing you would do in Django templates, for example. Most days, it's fine. But then all of a sudden, you get a high load day, and the database is overloaded. And that query in a loop is actually like hammering the database, and then everything falls down. And so it's almost I've been, I've been talking to people about how to think about what these performance issues are. And I'm almost like, it's like, it's like static linting. But in production in a way, right? It's not necessarily a prom, it's almost like a, this is a bad thing to do. It might be okay for you, it might not be okay for you, it's up to you if you should fix it or not, which arguably is the same as errors, right? Like, maybe this error is fine. Maybe you don't care, right? You just can't handle it. And so when we think about APM, and profiling and things like that, it's like it has to be one of two things, it has to help you debug a problem better than you could before. So basically depth. So profiling is kind of depth to some degree, because it's like function level versus tracing is kind of like network level. And then breadth, which is should help you identify new problems, and ideally, help you identify as not you go look at dashboards and wire up a bunch of custom things. Like we actually try to curate a lot of those rules. And so as an example, I'm profiling right now with that data stream. They're actually looking at like main thread blocking IO, like things where like, if you're doing like, hundreds of milliseconds of IO, and the main thread, like your app is hung, right? And that's like, oh, yeah, makes sense. But that's such an easy thing, you could mess up. Again, it's almost like static Lintian, it may or may not be a problem for you. But we can, we can certainly identify those and call those out. And so, you know, I think a lot of stuff we're doing is in that vein, and I think it's gonna be exciting. But I will tell you, we have no idea, kind of what we're doing in the sense of like, n plus one straightforward. Like, that was me saying, Hey, this is a real problem. Trust me, lots of Django developers are gonna put these in their templates or other things that are equivalent to like Django template abstraction, right? Or even just API calls. And so like, known quantity thing, ship it, see what happens. A lot of the others are like, Okay, now what, what, what else is like an obvious kind of root cause, or like, key problem that is black and white? Because as soon as it becomes subjective, it's kind of complicated, like, an N plus one is subjective if it matters or not. But it's not subjective. If it's actually like that. Yeah. Versus if something is fast or slow. Well, should it be fast? Should it be slow? Is there actually something wrong with it being slow that you can fix? What's the something that's wrong? Can we even identify that? And so we'll see where this goes, we don't quite know yet. So you'll see a lot of experimentation from us as we try to figure it out. But I will say I think it's a much better model of how monitoring should work at the end of the day
Carlton Gibson 52:39
one, so to talk, to take one thing you do, you've got this kind of user pain metric, which is kind of good, because it helps you to identify, to talk to it, it does not, it doesn't help you debug, particularly what's going on. But it does help you identify all that you know what that page is causing user pain? Let's let's go and spend some time looking at that page. And we can fix it. And then you can see did did that metric drop after we released it? Oh, it did? Well, there's progress. So that's kind of
David Cramer 53:04
Yeah, yeah. And that's one of the things it's always like, there were always like these keys, is it fast? Can we tell you about it quickly? Can we help you understand if you should care or not? Which is kind of that user pain is one of those many ways you can think about that, right? And then can we can you reproduce it without having to go like actually take more steps, right? Like, if you have to ask a customer for more details. Sentry is failed it like its job in this regard, right, which is very different than, again, a lot of monitoring a lot of monitoring is maybe you have the logs, you have a metric on a graph somewhere, and you have no idea what the actual problem is, or you don't have the right details to reproduce it. And all of that all of century has always been modeled off of like the Django debug page, because I'm like, Huh, what if you just put this in production? And that's, that's what century v1 was like, literally, it was like in Django is like, I think I might have even just like, straight up taking the CSS, or reimplemented, I don't know. But it looked like the debug page. And it was just in the admin. And that was like your Issue Details page. And today, century's a little bit different, but it's the same thing. It's just like, let's get as much information as we can for you in production. So increasingly,
Will Vincent 54:06
we have to ask us, so I know you're not an AI company. But if someone wanted to not reinvent the wheel, and, you know, anonymized data, like people are making the same n plus one and other problems all the time. Is there any conceptual way in which there could be something helpful that would just go through your code, right, and just say, you know, here's n plus ones, or here's, here's all these known things that we see time and time again, and all these Django sites, all these other sites? Can you see that would potentially work? Or is that just not feasible in any way?
David Cramer 54:36
I think like, I would argue that's like what we're trying to build. Now. I don't think it's aI necessarily, right. Yeah. That's kind of what I'm getting. Yeah. And so like, I very much believe, like we're actually talking about could we expose? So we have this detection layer, right? Could we just expose this to the user and imagine you could build a set of rules that look at Django instrumentation, basically look at the errors that come and look at the traces that come in, and you can be like, okay, when you see this in Django, it's actually the This is a problem, like you could recognize this prop and then create an issue out of that. So we're actually trying to, like make it so we can expose that and like almost like a JavaScript kind of language. Because I actually think it's very exciting if you could build these rule sets, and they are gonna be like, they're gonna be very domain specific, which is one of our challenges, right? Because there's so many different domains. And I think and then you can take that again, going back to Ci, like centuries, n plus one works fine. And CI, eras work fine in CI latency, okay, you need like real kind of load to show latency. But like those other things, like you could actually run in CI and identify problems before they hit production, right? Now, you still need the tests to run. So maybe that's where code code comes in line like that you're actually testing the code. But there's a very real world where we will bridge that CI gap with production monitoring, and then all of a sudden, you have like, like an interesting conversation about what could Canary be? What could production level QA actually look like if we if we change the story a little bit,
Carlton Gibson 55:52
that helps us deal with the problem with coverage, because one problem coverage is you kind of game it or you need high res coverage. So you write a test that sort of just tests loads of stuff all at once. It's not a very good test, per se, but it does execute a lot of code. But that actually is still execute the code, right? But those those, that test would actually be quite handy if you've got, you know, static, static analysis going on in the back.
David Cramer 56:15
Yeah, and I actually had to explain to some of the engineers the other day, because I wrote a bunch of the, we were talking about JavaScript testing being terrible, which it is. I wrote a bunch of tests, because it was so hard to actually like, test the behavior that just like load the endpoint and check if like a simple elements on the page, kind of like, I don't think there was selenium, but close enough, right. And people were like, oh, but this doesn't test anything. I'm like, no, no, it tested the code actually work like that it executes. And that is like actually such a big deal. Because a lot of times you just break stuff, because you didn't even run the code. And you'll catch so many bugs by literally just running over the code and not even validating the logic, right. And so, you know, I think there's a long ways to go and sort of like, test paradigms, like how we can evolve that conversation. But I do think coverage is just like one of these useful metrics is like, it actually adds a lot of value. You just, you know, it's flaky historically, which is one of the challenges we got to get past. So
Carlton Gibson 57:06
I've got we've had Jeff Triplett, come on a few times, and talk about testing. And one thing he always talks about is pretty much every endpoint, you know, set up for 200 tests did it you know, did it actually work so that when you start hacking around, you are Oh, do you know what we took down the homepage? Okay, well, that's fine.
Will Vincent 57:20
Yeah, exactly. Well, I think we're coming up on time, are there things we haven't asked you that we should or things you want to mention to people, people listening about sentry and Django in particular?
David Cramer 57:32
I am sure. Our marketing team would probably tell me I'm supposed to plug something, but I don't really do that. I don't know. I
Will Vincent 57:39
will do it. Well say you like it's not controversial. Say you're doing Django, you should use sentry, like everyone's doing it. That's true price price point is reasonable, like, and there's new features coming out. So I would actually challenge the controversial about that.
David Cramer 57:53
If you are using Django and not using sentry, I am super confused. And you should send me an email and explain yourself. Because like, I have no idea why that would be the case. And I tell this often to like the go to market teams, I'm like, you should know if every single Django production app is not running Central, we've done something wrong, especially if they're using like an alternative to Century because like, we're just so good at the Python thing with like the local debugger, like kind of like the context locals and stuff. But I don't I don't know nothing, nothing to show him. Check it out. If you're not using it. You know, we're always open to feedback. You know, we're on GitHub, so find us there. Yeah.
Will Vincent 58:27
Well, let me let me end with one quick one. If you could, if you could wave a wand and change one thing about Django? What would you change? I mean, you've sort of talked about a couple things, but what will be the one thing I would find that
David Cramer 58:37
path to making. So react can work with Django, like that's the only thing that needs to exist, because it's not about like changing a thing. It's about maintaining relevancy. And actually, the least favorite thing for me these days is going to like a Python conference, because I know what inevitably is going to happen is the majority of people are going to work in data science, which is totally fine. And I have nothing to talk to them about. Right. And so I think we need to, like rebuild that relevance of like traditional web frameworks. And the only way you're going to do that is by satisfying some of this JavaScript demand. Outside of that, I think jegos is it's always been good that you could plug like what you wanted, and take away things you didn't want. And honestly, I'm not even familiar, it's probably on version four or something these days. And I know it's accelerated the majors a lot more. But I'm not familiar with a lot of the new models, a lot of my complaints are probably from from older Django. But I genuinely think it's been a great framework for a very, very long period of time and has solved sort of the core needs since you know, probably like one two, or somewhere around that version. So Well, thank
Will Vincent 59:34
you very much for taking the time. I know you've a lot of things you could be doing appreciate taking the time to come on here. This is what you know, when we started the podcast a couple years ago, sentry was like we need to have ideally you cuz century Come on, because it's part of the core toolkit of Django. So thank you for taking the time. We will have links to things in the show as ever, Djangochat.com And we'll see everyone next time.Bye bye.