Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)

Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help find bugs, but the primary purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).

I'd love to get HN's take on this :)

Agree that shared understanding is the hard part. Bugbots find bugs. Review is how the team stays aligned on the change. Visuals help a lot for that first pass.

Another cause of burnout for us was noisy bot comments on top of diffs that already look AI-written. We only want findings we would actually act on.

I checked your skill and looks really good, however I find it to be very complex already, we do many PRs and maybe visualizing graphs for every one is too much. I think ideally could filter the complexity of PRs and adapt the visualizer depending on that, being just two sentences on some and complete graphics on some.

I myself created Revix AI and we internally created some rules that we found that served educational purpose as well, we started linking that rules to the PR comments that Revix did so the devs could access that information if they wanted. Following what I said, it's always better to keep it simple and only expand if the human wants to get deeper or if the pull request requires it.

Yeah that's definitely true, a future direction would be to filter PRs as Chore/Operational/Feature/etc and only create visualisations for Feature Requests - maybe Jev can help here ;)

I checked out your website and found it quite abstract, I understand enforcing team standards on each PR but I don't see more meat beyond that for reviews. Would be keen to see what y'all do in the review space!

Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)

Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help but not really because the purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).

I'd love to get HN's take on this :)

Overkill but clever :) reminds me of https://www.pinterest.com/pin/we-are-looking-for-graphic-des...

sweet, will use this the next time :)

Yeah I just used off the shelf base material and didn't have the eight equipment to make rounded corners, hence the current diamond shape :(

Ah yeah, I should have mentioned that in the post somewhere, but reflective would definitely be a nice next step. I have seen TheSignGuy use reflective material in his videos, I'll have to find the equivalent on the Cricut store.

Do you have sample images of what this would look like? I imagine the texture and finish won't be as smooth as vinyl but curious nevertheless.

Grafana Tempo also switched from Protobuf storage format to Apache Parquet last year. It's fully open source, and the proposal (from April 2022) is here: https://github.com/grafana/tempo/blob/main/docs/design-propo...

The relevant code for parquet storage backend can be found here: https://github.com/grafana/tempo/tree/main/tempodb/encoding

disclosure: I work for Grafana!

Cool thanks for sharing. Can you say something about how it's worked out? Has it reduced bandwidth or CPU usage?

The Parquet backend helped unlock traces search for large clusters (>400MB/s data ingestion) and over longer periods of time (>24h). It also helped unlock TraceQL (a query language for traces similar to PromQL/LogQL). There's more details in this blog post: https://grafana.com/blog/2023/02/01/new-in-grafana-tempo-2.0...

I don't have the exact CPU/bandwidth numbers on me right now but CPU usage has went up by about ~50% on our "Ingester" and "Compactor" components (you can read up about the architecture here - https://grafana.com/docs/tempo/latest/operations/architectur...). But this is optimising for read performance which improved significantly.

This is really interesting, thanks for sharing. What's also cool was the low effort needed for this setup (Java autoinstrumentation + Clickhouse exporter + Grafana Clickhouse Plugin).

Since Tempo is a k/v store that can retrieve traces given a traceID, we need either a metric system that can store traceIDs in exemplars OR any logging framework to log traceIDs that can be copied over to the Tempo Query UI.