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.
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.