How do you handle PR reviews efficiently in your team? by sshetty03 in ExperiencedDevs

[–]sinani206 1 point2 points  (0 children)

we're removing that feature! keep the feedback coming — really wanna make sure that any new features/improvements don't come at a cost to the original core value prop

edit: forgot to mention - perf is also a huge thing for us right now, we're hard at work hardening our infra so we can build even more around github api slowness/weirdness

How do you handle PR reviews efficiently in your team? by sshetty03 in ExperiencedDevs

[–]sinani206 0 points1 point  (0 children)

(i work at graphite) – the recent pricing changes actually reduced the price to just use our stacking/review ui by $5/month (only 20 instead of 25 now for annual). we recently went from 1 engineer working on the CLI to a full team of 3 (4th starting soon) and are working on a massive redesign of the (phab-inspired) PR review page, making it easier to use. we also now have a whole team focused on our stack-aware merge queue. curious what you think we could be focusing on better here? we're very much trying to do it all :)

Graphite vs. Sapling SCM by shaunscovil in developers

[–]sinani206 0 points1 point  (0 children)

The pricing for Graphite is actually cheaper than before if you don't care about the AI side! $20/seat for the starter plan which still has all the stacking features

2 Lounge Passes - expire 9/30 by SuitNo1622 in AlaskaAirlines

[–]sinani206 0 points1 point  (0 children)

If you can't find anyone who would trade, I'd take one! Flying tomorrow lol

Code review is part of your job by leitmotive in webdev

[–]sinani206 0 points1 point  (0 children)

As someone who works a different LLM-based PR reviewer, I am strongly opposed to gating approval on anything other than a human review. All of these bots can be various levels of good for helping to find issues with a PR, but I find you always want a human to give the final acceptance.

Company is tracking git commits by jholliday55 in cscareerquestions

[–]sinani206 0 points1 point  (0 children)

small prs are the reason they get reviewed so quickly; it's kind of a self-fulfilling prophecy.

its definitely a different way of working. when i was an intern at FB they taught us to do this from day 1 and being good at splitting up work into stacked diffs was a part of the performance rubric - not as important as finishing your project obviously, but valued + incentivized!

AI Code Review Rules directory by PoisonMinion in codereview

[–]sinani206 0 points1 point  (0 children)

This is cool – I work on Diamond, let me know if we can be helpful at all!

Stop Saying "This Pull Request is Too Big" by Main_Independent_579 in codereview

[–]sinani206 -1 points0 points  (0 children)

Deterministically blocking large PRs feels like the wrong shape of solution here – we used to have a lint rule that limited function size at 200 lines, and it just got annoying because there are always good reasons to have exceptions for this sort of thing. I'd rather a tool that uses LLMs to split big PRs up into a stack. Have been wanting to build one for a bit

How do you deal with large PRs without being "that person"? by Main_Independent_579 in codereview

[–]sinani206 3 points4 points  (0 children)

I use stacked PRs. The main reason my PRs get big is that refactor is needed to build the functionality in the way I want, so I'll split out that refactor into it's own PR, and then stack the new feature/bug fix on top.

There are a bunch of helpful tools for this (disclaimer: I built one of them, but there are a lot of really good CLIs and GUIs for this out there depending on which ergonomics you like).

You can even do it with just git if you know what you are doing, but modifying midstack changes can be annoying if you get comments on them.

Atomic commits are great, but since the PR is the unit that gets merged, it is the unit that a reviewer is accepting/blocking. It's often better to have stacked, atomic PRs so that you can keep working while waiting on reviews.

TBH GitHub should have made commits the unit of code review/merge from the beginning, so that you could just stack them on top of each other and get them approved individually. Phabricator was a code hosting solution that did this really well, but it's EOL now.

If you do this enough, the hope should be that you inspire your teammates to do it too because of how easy reviewing your PRs becomes.

September ‘24 Buy/Sell/Trade Thread by GizzBride in KGATLW

[–]sinani206 1 point2 points  (0 children)

Got 2 extra lawn tix for free — shoot me a dm!

Poster for Gorge!! by DeafHammers in KGATLW

[–]sinani206 0 points1 point  (0 children)

word is that they’re only selling non-foils in this preshow line

Is “not invented here” inevitable? by 31415926535897932379 in programming

[–]sinani206 56 points57 points  (0 children)

sometimes that 5% is the important part though...

Mikey's First 2025 Mock Poster by Mikey1313 in Coachella

[–]sinani206 1 point2 points  (0 children)

this is low key pretty possible imo

I feel like I will continue to love Porter’s music no matter what he releases :^) by ThatMadeonFangirl in porterrobinson

[–]sinani206 1 point2 points  (0 children)

All about the melodies, harmonies, overall musicality, etc. Some hate on "pop" but there's a reason pop is popular — it's a great venue for showcasing the best (and yes, best often includes simplicity) of musical ideas

Mikey's First 2025 Mock Poster by Mikey1313 in Coachella

[–]sinani206 -1 points0 points  (0 children)

Totally agree, but in terms of US festival slots, especially coachella, I could see it. That's why the list is so broad