In my most recent RedMonk Conversation I talked to David Cramer, CTO and co-founder of Sentry. It was a lively conversation about developer experience and building software to make developers more productive and effective.. David is a bit of an Observability skeptic, which is not to say he doesn’t agree that we need better troubleshooting tools – in fact that’s his whole schtick – but rather he’s all about engineering and eschews stuff he sees as marketing driven.
Sentry is a very widely adopted error tracking and performance management tool. Cramer built it to solve issues he faced every day.
I’ve always focused my time on developer experience, and developer productivity. Basically it was like, how do I make my job easier? That is what Sentry is, and that is what many of my projects have been over the years. They’ve always been focused around things like CI/CD and iteration time… Get out of my way, basically. It was always just like, let me ship things to customers.
I’m one of the people that is fascinated by just building software that helps me build software rather than building the end result.
Software for building software. Sentry was dev2dev before it was a thing.
RedMonk has been spending a fair bit of time on the Developer Experience gap, where developers have all this amazing infrastructure that they can take advantage of, in a supposed golden age for devs, but then they need to get out the bailing wire and duct tape to integrate and then maintain the infrastructure they use.
Cramer argued
I think it’s a gray area because I think we have created a lot of this pain for ourselves to be quite honest with you. And so my version of the world is always how to simplify the problem, which I would say is what an engineer’s job is. At the end of the day, simplify it to its bare minimum, make it easier to solve it. Right? And I think a lot of what we’ve done with technology over the years is that we’ve tried to solve more complex problems, of course, but sometimes we ignore prior art, sometimes we just like building things. And so I do think there is an enablement factor we’ve done a good job of in the industry, but we’ve also countered that with making a lot of complex decisions, reinventing the wheel. If you look at the JavaScript ecosystem, there are a lot of solved problems in web software. Could they be solved differently?
Performance was a known quantity as an example, right? It’s like, how fast is your web server responding and rendering and all this. Now it’s like, well, how small is the amount of JavaScript you load on the website? And then how fast does it hit this arbitrary metric that you’ve decided might matter?
So what about Observability?
I will still say that I’m not 100% dialed in with whatever observability means this week. My kind of perspective on it is it is a marketing term like many things are marketing terms.
What I’ve come to understand, what observability means is people just want easier instrumentation because at the end of the day they didn’t have a lot of visibility into stuff through the traditional monitoring. A lot of the observability tools are just like, here’s a bunch of graphs, there’s a bunch of logs.
So if anything, maybe observability is about, hey, we’re tired of all these crusty tools that aren’t really solving the problems, let’s make them better. And so I think that’s probably fair.
So what is the Sentry approach? Cramer said:
All Sentry wants to do is tell the developer their team about that problem, give as much visibility to it as possible, and do it as quickly as possible. And generally speaking, that’s very coupled to the release process. So usually problems happen within minutes after new code being deployed to end users.
Anyway it’s an interesting conversation, and it’s always good to have a somewhat contrarian position to shine a light on an area. Enjoy the video. Don’t forget to like, and subscribe, comment and share.
Sentry is a client, and sponsored the video.
No Comments