Honeycomb's pricing model is excellent for small teams, though, so there's that. I'm the only person on my team who has Sentry access and it's annoying.
That said, "Sentry seats" is probably an early item on the shopping list once StoryTime like, pays for its own accounting costs.
I used to start with Honeycomb first because in theory they can handle every instrumentation need I might possibly have... but Sentry is so good at handling the specific class of problem that accounts for like 95% of what I go to telemetry for that I'v switched loyalties
Usually just those queries plus clicking into a trace on something that seems unnaturally common or unnaturally slow will produce a "haha wtf" moment and then I just go fix it
It's rare that I run any Honeycomb queries more complicated than
COUNT GROUP BY name
P99(time_in_ms) GROUP BY name
Once I have more traffic heatmaps will probably get more interesting
Where I'm at in general on application telemetry — at least for Elixir Phoenix apps
1. Sentry. Very nice, straightforward Elixir integration. Gives me information about most 500 errors — e.g. problems the app knows it's having.
2. At some point I start wanting performance information and especially wanting to see what's occasionally weirdly slow. At that point: traces into Honeycomb.
3. Eventually I add metrics to the Honeycomb integration.
I will *grudgingly* use metrics for VM statistics but I still have yet to encounter a situation where what I want is a custom metric produced by my application
After over two years of working on this application I have finally encountered a situation where I want metrics: The whole application got OOMKilled by the Kubernetes running it, so now I want to see VM memory so I can start to work out what's using the memory
(it's probably not actually *that* much memory — first thing we did was bump the container from .3 GB to 1 GB, the application itself just operating at rest uses about .15 GB)
It’s not our job to fix our employers
This broken industry is too big of a problem for software developers to solve alone with unions
Do you think you are neurodivergent?
This is not a question about diagnosis. If you think you are, the answer is yes.
As always, please boost.
It’s not our job to fix our employers
https://www.baldurbjarnason.com/2026/06-its-not-our-job-to-fix-our-employers/
This broken industry is too big of a problem for software developers to solve alone
(And a Patreon launch)
Then the first time I deployed it didn't work and I had to tweak the OTLP headers because Honeycomb requires different ones for metrics than for traces and while this is documented it took several rounds of examining the docs to notice that it's a requirement
Finally, had to update some libraries and the OTP but that was overdue anyway so it doesn't *really* count as an annoying thing I had to do for this.
In this case I had to decide whether to use the (unofficial!) `otel_metric_exporter` package, or find some other way to deal with the fact that OTel API requirements aren't compatible with the way the standard Elixir telemetry library emits metrics from the BEAM
Then, even though I'm using the library, I *still* had to write some custom code so that we only emit compatible metrics to the OtelMetricExporter through the existing Telemetry module
Every time I have to touch my OpenTelemetry configuration (this time to export metrics) in Elixir it's a fiddly nightmare
Like, I'm grateful that OpenTelemetry means an integration is available at all for a relatively obscure language (though— shoutout to Sentry for having its own Elixir SDK!) but I dread touching it because I know I'm going to get like three small details wrong on my first way and only *kind* of understand several decisions I've made
We're at the part of the Hype Cycle where MongoDB is the Future because it's Web Scale even though obviously a lot of datasets are... relational... and so should be modeled with... a relational database
I think in aggregate it's likely that what we're doing right now, as an industry, is stressing everyone TF out and spending a bunch of money without actually... getting much of anything out of it
Still, this is at the level of Hypothesis
Mostly what I'm sure about is that productivity in software development is already pretty poorly measured, so it's hard to make statements about one way or another
We've known for decades that lines of code is a bad measure but you'll still see people who should know better talking about how great their agents are in terms of LoC
But in general I don't think that AI-assisted programming helps very much with either
1) the absolute hardest problems in your software
2) the long tail of small detail issues that were already mostly "decide what it should do"
And in fact I think it's very possible that they're making both of those parts of software development worse/more expensive
You're getting the bulk of already-pretty-easy coding work faster at the cost of making the time consuming parts harder
On the other end of the spectrum, I also find it plausible that agents built on LLMs are good at building "my personal version of X" especially when you need a pretty small subset of the features of X
They're very good at copying. They're bad at fit-and-finish. There are a lot of cases where fit-and-finish just doesn't matter very much, so being bad at it is fine.
There are some interesting exceptions to this general "coding agents probably just move the work around" thesis. In particular, I find certain stories about using co-ordinated agents to do large pieces of work entirely plausible, particularly for domains where verification is highly specifiable, like "migrate data from one relational database format to another"
https://www.cockroachlabs.com/blog/experiment-running-hospital-code/
The linked PDF Is to a Harvard study that I think can be fairly summarized as follows
"Among firms that use JIRA, firms that adopted AI earlier produced more code, more PRs, and more commits, but did not increase the number of completed JIRA tickets. We considered whether this is because the JIRA tickets got larger but we don't think they did. Instead, we believe that it's mostly because any time that got saved writing code is now spent reviewing and verifying code."
fion.ac/jellyfish.pdf