Transcript: Sentry - David Cramer
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.
Hello, Will Vincent.
And we're very pleased to have David Kramer from Sentry join us.
Welcome, David.
Hey, everybody.
Thanks for having me.
Oh, thank you for coming on.
Real honor.
It's a real honor.
So you have quite the history in the Django space.
We want to talk about Sentry, a lot of new products coming out.
maybe for those you know given our our listeners we have a couple thousand 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 yeah um you know i'm uh 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 uh 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 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 0.95-ish,
somewhere around this time frames and just kind of been growing with it ever since you know these
days i do a little bit of less but uh 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 i have this vivid memory of just
seen like a video demo of you could put the comments template tag in there uh and it just
like all of a sudden you had comments i'm like oh that's cool you know 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
compared rails versus jangle and i'm like well i have no idea how this ruby tain works so yeah
fair enough they did that yeah and i don't think anything's changed i mean um and then did you have
a formal background in computer science or how did you get into just programming in general no i feel
like i was like i don't know 18 years old when this was all going on um and so i'm self-taught
uh you know i'm uh both a high school and a college dropout which means i eventually fixed
the high school thing but then college was also uninteresting um 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
uh and i was uh a very much uh you're like typical teenager who's into video games and whatnot
and that kind of aligned well with world of warcraft which was coming out at the time and
i was just clever enough at reverse engineering uh 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 another job and then eventually made my way out to the bay area to work for uh what i would
describe as more real companies got it got it well that makes three of us who are self-taught so
you're in good company uh though carlton went all the way to a phd and i'm somewhere in between yeah
but not in computer science like i mean so i mean do you i mean do you i mean clearly you don't need
um that computer science back i mean what's your sort of thought you know people people get i mean
i still 20 years in get this sort of oh i didn't get cs sort of insecurity what
yeah i think it's valuable personally um 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 4-0 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 um 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 and they 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 um 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 or distributed systems um and just nobody has the experience or uh even academics like to
kind of know what to do and so we'll see but so i think it still has its place but i also think
if you're determined it's not super relevant i mean i've found um just my own experience you
know that read you know so i've got every algorithm book and i sort of go dip in them
and i you know i from but 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 answer and then you can go and look it up which kind of
i think you can get a lot of that through experience too but you'll still like i 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 and
i learned how like cpus work and 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 it's just getting people with this like the same
vocabulary actually massively helps but you know that i don't think a lot of cs programs are that
useful yeah okay interesting well that's a little bit like ramanujan right the indian mathematician
who like did create everything his own and kind of did a couple hundred years and then at some
point got up to the 20th century yeah that's how you should pitch it anyways yeah well 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. Yeah,
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
abstract away a little bit, which is frustrating if you want to actually do something. But from
a pure learning standpoint i do think probably makes it easier to just pick up a language though
i mean like to your point on 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 i think that's interesting how do i explain this to a 10 year old you know
just like the amount of exposure that people are getting i think there will be more minecrafts for
sure in the future but like you know i i don't know how roblox works but i know that's kind of
in a similar vein of uh there's a lot of this like creator maker or whatever you call this
these days um 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 and high school kind of age range um grade 6 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 um and to me that's the gap you just need 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 that doesn't get you actually that far into
solving problems and 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 um to really kind of get
over that barrier and i agree on like the multiple languages things 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 something simple
you know carlton look how many books do you have carlton on rust this is like your bedtime reading
just working through a new one on clis which is very good um but yeah i mean the thing with
learning a new language is unless you're using it um 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 twinkering away at it for a year or so and yeah i'm about 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 um there's a sort of
deadline there yeah i don't know absolutely this is a technical podcast so let's just jump right
into so century air handling like i don't want to have you repeat the same thing you probably
have to repeat on most podcasts century started as a as a django set i believe is that correct
like what's the what's the quick history rather than making the rest of the podcast about
what uh sentry is we want to talk about the cool details of it yeah uh quick history 2008 ish uh
django debug toolbar simple snippet use the admin hooks uh and it was a middleware and that's all it
was is it would capture exceptions thrown into admin and you'd have a dashboard for errors and
that seemed super useful and so over time through like sort of open source and community and 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 uh 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 don't have access to the right information
and and i would always build things to try to solve for those problems and um century is one
of those many things and uh it's also probably the one that's been the most successful at this
point uh clearly but uh 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 and then a sense of size like how
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
but like how do you all internally think about the growth so these days we're like 400 people
part of that's we just acquired CodeCub so there's a kind of a spike in growth but yeah I think
when I thought about building Sentry 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 going to 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 and 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 focused which means you
treat a lot of things differently and so for us i don't know what the customer count these is today
or these days is rather uh but i do know we have somewhere around 50 000 uh people who pay for our
SaaS service. And by people, I mean organizations like companies, which to me is awesome. And we
achieve that by charging a fair price and all these other decisions along the way. But it's
awesome because that is bigger than most companies in the world that try to sell enterprise software.
And I don't know. So when I think about growth and I think about goals, it's just like,
there's still a lot more to do. And that's why we do a lot more than Django these days. It's like,
how do we service and help more developers and more different kinds of software? And so I think
a lot of a lot of um things to solve within that yet but that 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 uh and optimize for becoming the most
successful thing we can be but from a mind share not just a dollars and cents point of view that's
so good because i've used sentry for years and years and years and i've always had this exact
same thing is that it's 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 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 sentries i've always
just been like no i'll just pay for it because and every client i've ever had i'm like just pay
it save like you know you're going to save that in the first week from the speed of speed of
triage or speed of you know you're just going to get more information out of it and it's not worth
the effort to run it yourself so perhaps 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 and in that balance of yeah you could
run it yourself but why on earth would you yeah and i think honestly like one of the things i've
recognized over the years is i 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 and the actual realization
of that is like century actually provides us immense value from like day one of going to
production where it 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 would 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 product's trying to give you even if if even if
that one percent is actually useful to you right and that to me was like the 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 that 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 um and you
This is not technical, so sorry, but 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 there, 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 continually drive more and more value? Not how do we charge more and more money from the exact same thing over the years, like in 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. And all of a sudden everything's
super expensive. And I don't know, I just never wanted to be in that business. It's not as
satisfying. So, well, it seems sustainable. I mean, this is one of the questions like Carlton
and I are both in our forties, like, you know, at a certain point, it's like, why, how do you
keep doing the same thing for a long time? And it sounds like, you know, 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 longevity so yeah but that's exactly the sense i have as well in the business
and you want to hang around you're not like i'll sell it off and you know yeah publicly tell us how
you feel i mean i'll be honest it's draining after a decade plus of doing this but i'm invested in
the outcomes and like i'm still very passionate about it i think the hard thing for for folks to
understand is uh 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 try 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, 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 the sort of continued momentum, uh, 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 like, you know, you know, the tech scene
and everything that's going on. Yeah. I'm like, great. Um, cause 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. Um, but that's for me, the really exciting thing right now is like, okay,
like we're going to build a public company done a very specific way. That's not been done before.
Uh, 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, that, those are like the exciting
things for me less so than the technology things these days though i i think at least more recently
we're starting to do more interesting tech uh investments which is i guess one of the the cool
things you get out of becoming a larger organization as well 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's interesting take you know we're
very kind of narrow on this podcast i uh 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 website 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 a rich UI in 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's solved 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 in JavaScript
and the backend 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 start is like broken a year from now,
or it's like really hard to rebuild um mostly because of dependencies and whatnot but is that
not because you're using javascript right like it's a sort of vicious circle it is part of it
i will say the same thing happens in python so we have this project that my co-founder and i worked
on must be a decade ago 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
text or or fix the fact that now it's on python 2 and i'm even more screwed in this but um and so
it's a similar problem javascript's just more extreme to that problem and so yeah i i've not
i mean i still know django very very well um 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 in uh quite a while
actually other than bolting on like some patches and stuff here and there okay no problem well i
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, um, like bath bombs and, and all this stuff. And
in the hallways this year, there was a lot of talk around HTMX 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 HTMX? Are you familiar with that?
I'm familiar with the, I've not used that personally. I'm familiar with the concept
and 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.
So I can't comment on the implementation, especially 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 transpilation.
Like, I have to go from one dialect to three dialects deep.
Like, I need to go from, like, some modern TypeScript-y thing to some modern JavaScript-y thing down to, like, some compressed compatible layer.
And it's, like, making that process work is never fun.
And even early day century, we had built like a middleware, like a Django.
I don't even remember what I called 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 I think it's a lot of opportunity because no matter what, you're going to be compiling some kind of thing or you're going to 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, um, manifests to help the CDNs 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, 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 air
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 or two, 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 front end, you know, in terms of error handling
and performance these days? I think it's still way too immature. And I think the problem is
people like to reinvent the wheel. I, I, I do not enjoy interactions with a lot of the JavaScript
community and 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 the 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 the 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 component stuff that's
coming i think they've got some stuff to figure out on the apis like that is also good because
that solves our our reactive ui layer but with basically one like template language kind of thing
is how i would think about it and to me 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've been working in like on the software on the back end side of things or
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 they're like no no no
we need to upgrade. I'm like, why? What's the purpose of upgrading? 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 maintainer's 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 or should.
And now the problem is in like JavaScript, like you basically have to update all the time because
the dependency graph is just like a thousand deep. Right. And like one thing's going to break
and you can't fix it because the other thing is dependent on it.
And there is no solution other than to stop doing that,
like to stop the dependency graph.
It's just not good.
I don't know.
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 re-implementation.
Yeah.
No, I mean, that rings true.
the re i used to do front end stuff you know and i i used um the way i got into django was doing
apis and django was what i used to do the apis that went with the front ends i was building and
over time i slowly moved more and more into um django world and back end world because i just
couldn't like take the constant you know burn down start again burn down start again burn that start
again it's like no like this isn't sustainable for me and i just drifted further and further
a way that's why i'm so excited by the you know the recent emergence of things like htmx and alpine
and these much more lightweight solutions that are like you know actually that that there are
single scripts that you just bring in and then you've you've got everything you need there um
yeah i mean that's that doesn't give you the reactive uis that you're talking about though
it doesn't give you that yeah i i think what we're going to see that happens is we're going to find a
way to simplify the service architecture to where front and back and just become 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 and it's like separate services right and even if you look at
technologies like next.js 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 a known like i i have to
go like convince them that they need middleware as like a concept and they're like whoa whoa that
doesn't make any sense i'm like trust me it makes sense like that's how the entire world works is
it was 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
or as i used to pick on django everybody's just building a blog and like cool you can solve the
blog case really really well or like so next for example is phenomenal like e-commerce and that's
cool but like i can't build century in next.js i can build centuries front end in next.js and so i
That might be okay, but that world is still hard because then all of a sudden, I'm probably running Docker containers or something locally.
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 where it's 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 phase.
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 Cursons from Crunchybridge about Postgres and we were,
you know, 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 the sense of just yeah there isn't one all-in-one there's like you know for a website
managed 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 going to
scale it's not going to be maintained yeah that we're just moving past that phase of the web yeah
i don't 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 for sale but we use it for like our marketing website
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 the very least that vendor has a lot of liability associated with them yeah yeah
and 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 digital ocean 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
cdns um and that's fine that's a that's a good problem like if you're just deploying like a
front end right but my back end's 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 still
a gap but it will change and you know we'll see like planet scale is like cool but i'd much prefer
planet scale just be installed in gcp than 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
they're toy projects right now like they're they're used for prototypes and startups and
even 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 you're maybe building like a media 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 e-commerce or any of 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 going to
interact with these like crazy databases and these like if you've ever used a firebase um which is
just like the most awful key value store which is like the easiest thing in the world to expose all
your it felt sketchy even like six years ago yeah oh yeah 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 could 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 social interaction in a centralized place, which is what it needs to do at the end of the day.
Nobody wants to, like, have to visit 20 of these. And so it's decentralized, but it's actually trying to be centralized.
And like the solution to problems is to, like, change the problem so you can solve it, not to overcomplicate it.
So I don't know.
We'll see.
It'd be nice if there was a, you know, sitting on top of AWS Django specific solution someone did for hosting.
We'll have to see what the new year brings.
Right.
Anyway, listen.
So I want to ask about the Sentry.
So you're talking about people wanting to deploy on infrastructure on a single cloud provider like, you know, AWS, GCP, whatever.
Is that the kind of model of people who are actually running their own Sentry because they want to keep the data all in health?
because i yeah or is it hobby so like who's running it 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 uh sometimes a javascript developer uh no it's it's probably like the weird devops
persona that's like no i can do all this why wouldn't i run it myself and they they don't
realize that it would just cost them 30 dollars and like it's way cheaper no matter what to just
pay for the sass service like there's no way you get your infrastructure cost below 30 dollars to
run it in a production app so so that's like silly but ignore that case there's that i am like
privacy conscious or security conscious and i i've convinced myself i'm better at it than 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 um 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, where a U.S. organization, we just can't do business with them.
And so, or 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 Sentry.
Like, Yandex runs Sentry, for example, in Russia.
And, like, I'm sure some of the big tech providers in China are also running their own Sentry.
And that's cool.
That's fine.
Like, for me, that still achieves our goal of market share, right?
So 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 Sentry, but like a Lockheed Martin that have like a lot of government regulation, and maybe they need air-gapped machines. We're not going to solve air-gapped servers for them, but Sentry can work air-gapped, right? And 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 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 persona, the DevOps persona, it's not just the hobbyist.
It exists at the finance organizations too.
And usually what happens is like, yeah, we can run Sentry.
this is fine. We know how databases and stuff work. And then a year later, they're like,
okay, we'll buy your cloud service. And so they eventually, they come around.
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 community contributions do you get? I mean, I imagine it's minimal, but I don't know.
Yeah. So I think, you know, I've 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 going to yell at me and I'll challenge it.
They are just wrong. But so Century's 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 Apache after three years. And so it's somewhat of our balance of like,
We need to fund the development of Sentry because nobody else contributes to it, 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 this tricky balance because it's actually not relevant that Sentry is open source, if you're honest with yourself.
Like the part that's relevant is can you self-host it 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, 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, it's a little bit more complex. Um, 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 licensed,
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 APIs,
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 RRWeb, which is what powers our new session replay product.
We've just funded for, you know, a couple years, like, 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 user product of Sentry, but it will be, like, some of it is, some of it isn't.
Some of it's like we have all this technology to symbolicate errors, 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 demonifying, basically, and converting back to TypeScript or something.
But then iOS has a completely different version.
C++ has a different version.
Rust has a different version.
Some of it's standardized.
But, like, we now have, I think, the leading solution in the open-source ecosystem to symbolicate 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 our open source to power that same behavior.
And they will contribute back sometimes.
And that's actually awesome because those cases are, that's computer science.
Like, that's actually a hard engineering problem, right?
And so we'll have stuff like that.
And then we'll have, like, pure utilities.
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 widely adopted in the open source ecosystem.
And we barely use it at Sentry.
And so as an example of like, like the different flavors we have going on of open source at 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 a thing.
We're not focused on this idea that like technology is super secret and we're protecting some IP
shenanigans so um the model is very much open source even if the the literal implementations
of each one are not like you know proper now in open source yeah okay but i mean i remember when
um redis um introduced a similar license because they were fed up of getting you know their
business taken out from under them and i have a lot of sympathy for them but the internet went mad
and was like oh it's like but for my perspective it's still open source right because what i want
to know is okay look you know can i say it can i see it can i verify that it's you know um safe to
run on my servers because it doesn't contain malware that's important to know um could i
fork it if i had to i mean not me personally but you know could it be forked if it had to be that
kind of thing's important the fact that there's a clause in the license that says amazon can't
run our business i agree and i i think like i i'm joe we might do this for what it's worth i'm
going to push the legal team. I want to relicense and just name it something obnoxious. My joke was
like, it's a business source license right now. I'm like, can we just make it the very serious
business license? And we will just like hard meme 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 I value out of Redis again, is that I can run it that like, if there's a
problem, I could 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 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 is all I can say. Um, you know, I, I want great software
to exist. Open source is great. I love it. Open source, but like, I mostly just want great
software to exist and 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, I would say is probably worse than BSL or something like BSL, which is just a
proprietary license with some protections. 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 oracle yeah i mean nobody wants to yeah you know no one yeah
you're not that's not a competitor but you know what i mean yeah uh 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 century 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 hyped
industries. We're like, no, we're just going to solve a problem and solve it really damn well.
And we're going to 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 test for me. Like, I don't care about file storage or like
syncing files or any of those things. Right. Some people probably did. Um, but you, you have your
own reasons for joining companies. And so some people, you know, like century because of the
open source thing. Like Armin Roniker 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 going to 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 pull 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 the total ecosystem of developers fair enough we had one of the highlights for me
of django con this past october was um david lord came by for the sprints and talking with him just
about things and he had you know trying to make flask maintainable just thinking of armin's web
of 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 uh 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 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 gonna you know what i'm gonna
do is interesting and the rest of it is all kind of hand wavy marketing sales stuff anyways so yeah
so what yeah and i actually think you know a lot of companies are like well-intentioned you know
there's the pr ignore the pr angle like like dropbox was 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 uh from folks that work
there right um 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 uh 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
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
hard problems, right? And you can only refactor the same UI so many times and still call it
interesting, I guess, at the end of the day. Well, can we speak of CodeCov, the acquisition?
I mean, Sentry has moved far beyond error handling. What's your quick take on those
areas and what's kind of exciting for you personally? Yeah. So, you know, I mentioned
like our goal and my goal was always like all my peers use Century and I get like kind of that like
hallway track thing. And and that's become like the business model over time is like
we have a rule, kind of a soft, hard rule internally. But if we're going to invest a
dollar, one dollar 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 of these other
functions that exist at companies and the the the reason is like if you look at things like
new relic once upon a time they were great and they serviced x persona so called software
developers and they had great like kind of um apm stuff and then they built 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 to the same customer.
And you see this with companies like Atlassian, where this is literally their business model,
right?
And so that's a business angle from the like the practical angle, it's like we want to just
make it like easier to build software and that should be everybody's job that's building tech
for tech companies basically and sentry's core is is monitoring at the end of the day and and
there's like a thesis that maybe we can bring monitoring earlier in the life cycle um 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 um and so we kind of want to do that and that's all for
developers like 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
a 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 everybody to figure out. And so
then when you bring in CodeCov, 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 with 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 optimize, 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 request 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.
When I was at Dropbox, I focused on CI 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 sort of reporting angle of it, the analytics angle of CI is just completely awful.
The infrastructure to run the tests and everything, it works fine, right?
Like, everybody just solves the infrastructure.
And everybody that tries to solve the reporting realizes it's, 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 stuff's going to go wrong.
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 CodeCov
and basically tell you 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 should be embarrassed if I just caused 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 orgs, you know, it's hard to like push for how much
time things take.
So that helps that side too.
So I would say open-ended, we don't know where we're going with the CodeCov acquisition,
but I'm bullish on investing in spaces that I think just help us build better software.
And so if I could like have like end to end, I would like, I'd be like, cool, we're going to, 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.
Okay.
Can I ask a question there then, David, that ties in?
You said you focus on software defects and, but one of the cool things you've brought in kind of recently is the performance monitoring and the profiling.
And how do you see that fitting into the century?
Because it's great and it's lovely, but it's not the same as the exception reporting that started off.
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 not even just at Sentry, in life, we have too many things to look at.
We do not have the time to look at them, right?
And what made Sentry great, literally the one thing that made Sentry great, you could take away everything else, was when there was a new error.
it emailed you, it was in your inbox and it was like that. And so you could kind of trust that
like if you broke something, you're going to know about it right away. 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 as an example of signups go to zero,
That might be a software 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 sign-up 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 the issues product, which is basically just error monitoring.
And we released, like, our first kind of POC in this, which was like, oh, we can detect N plus 1 queries.
That's literally just a software defect.
Now, it matters because when, if you've never experienced these things, when you have 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 talking to people about how to think about what these performance issues are, and I'm almost like it's like static linting but in production in a way, right?
it's not necessarily a problem 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 didn't
handle it and so when we think about apm and profiling and um 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 it
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 it 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.
We actually try to curate a lot of those rules.
And so as an example in profiling right now
with that data stream,
they're actually looking at main thread blocking IO.
Things where if you're doing hundreds of milliseconds of IO
in the main thread, 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 linting.
It may or may not be a problem for you, but 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 going
to 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 going to put these in their templates or other things
that are equivalent to like Django's template abstraction, right?
Or even just API calls.
And so I'm 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 behavior versus if something's 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 one so to talk to take one thing you do do you've got this kind of um user pain metric
which is kind of good because it helps you to identify so to talk to 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 that and then you can see did did did that metric drop after we released it oh it did well
you know there's progress so that's kind of yeah yeah and then 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 um 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 has failed at
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 Sentry 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 what Sentry v1 was. Like literally,
It was like, in Django, it was like, I think, I might have even just like straight up taken
the CSS or re-implemented, 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's Sentry is 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, we have to ask guests, so I know you're not an AI company, but if someone
wanted to not reinvent the wheel and, you know, anonymize data, like people are making
the same n plus one and other problems all the time um 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 i think like i would argue that's like what we're trying to build now i don't
think it's ai necessarily well 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
and we're like 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 in look at the
traces that come in and you could be like okay when you see this in django it's actually this
is a problem like you could recognize this problem 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 um because i actually think it's very exciting if you could build these rule sets
and they are going to be like they're going to be very domain specific which is one of our
challenges right because there's so many different domains and i i think and then you can take that
again going back to ci like centuries n plus one works fine in ci errors 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 cove 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 that helps as well with the problem with coverage because one problem with coverage is
you kind of game it oh you need high arrays 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 it still executes the code but those those that test would actually be quite
handy if you've got you know static you know this static analysis going on in the background
yeah and i actually had to explain to some of the engineers the other day because i wrote a bunch of
the we're talking about javascript testing being terrible which it is um 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 element's on the page kind of like i don't think they were selenium but close
enough right and people are like oh but this doesn't test anything i'm like no no no it tests
that the code actually runs 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 i think there's a long ways to go and sort of like test uh paradigms like how we can
evolve that conversation but i i do think coverage is just like one of these useful metrics that 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 okay we've had jeff tripler 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 a 200
test did it you know did it actually work so that when you start hacking around you oh do you know
what we took down the home page okay well that's fine yeah exactly well i think we're 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 i am sure uh our marketing team
would probably tell me i'm supposed to plug something but i don't really do that um i don't
know we'll do it we'll say you like it's 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 i would actually challenge nothing controversial about that
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 Sentry, we've done something wrong,
especially if they're using, like, an alternative to Sentry
because, like, we are just so good at the Python thing
with, like, the local debugger,
like, kind of, like, the context locals and stuff.
But, yeah, I don't know.
Nothing to shame.
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.
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 of things, but what would be the one thing?
I would find that path to making it 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 I
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 um outside of that i think jango's is it's
always been good that you could plug like what you wanted and take away uh things you didn't want
um and i see i'm not even familiar it's probably on version four or something these days and i know
it's 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 i genuinely think it's 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 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 you know when we started the podcast a couple years ago century was like we
need to have ideally you because century come on because it's part of the core toolkit of django so
thank you for taking the time lovely to meet you well we'll have links to things in the show as
ever django chat.com and we'll see everyone next time bye