Knowing about all the metrics available on a Prometheus instance can sometimes feel impossible, so I'd like to share a trick I devised to making exploring those metrics easier!

During my morning planning today, I was thinking about the highest priority work task I had on my plate. Without getting too into the details, I introduced a new component into our system, and it's been failing in... interesting ways. I can issue a command to invoke that failure, but it takes about five minutes to run its course. I figured that I might be alternating several times between provoking this failure and analyzing the new findings - so, I thought to myself: what's the best way to spend that time? Here are some thoughts I had on that:

My friend Frew, as well as others, have said that our job as developers is not to write code, but rather to solve problems. I had a win in this regard relatively recently where I saved myself a good chunk of time by leveraging a Prometheus component for a purpose it may not have been designed for, but is remarkably well suited to.

Recently, I was curious about how Firefox's reader view implements its estimated reading time, so I spent a little time looking through the Firefox codebase. It turns out that it uses the readability package to extract the content of a page. Once it has that, it gets the length of that content and divides it by an estimated reading speed - and it was this part that surprised me:

As I mentioned in a previous post, I use Slack at work, and I find it to be a constant source of distraction. I have taken to shutting it off for much of the day, which has the obvious disadvantage that if people need to reach me, they can't! In that post, I admit my weakness of needing to acknowledge unread badges and proposed a sort of "narrowing" features for Slack. I wanted to follow up on that and discuss some of the solutions I thought of, as well as the one I'm currently using.