Flip side of this, you can tackle both of their issues with better tooling and not throw the baby out with the bathwater.
Time lag: Stacking (https://graphite.dev/stacking) is a powerful technique that allows developers to keep developing even while others read through their code.
Context gap: you encounter the same issue in an IDE when exploring a new part of a codebase, and there are tools to help you there (click to see function def, open relevant tests, AI summarize what its doing - we've been trialing the last one internally and it's so cool). Your CR tool should offer all of that, and at many large companies (Google, FB, MSFT, even Jane street) it does. GitHub is just deficient here.
I agree with the other comments in this thread that the main problem is that what should have been an architecture / prototype / etc review happens in CR, and I agree with that. But I think moving away from CR worsens that problem not improves on it.
"Context gap: you encounter the same issue in an IDE when exploring a new part of a codebase"
Yes, that's one of my major arguments for async reviews, especially in large organizations: Future readers of the code will have ca. the same context as the async reviewer. (Contrary to a pair programmer, who has much more context.)
"there are tools to help you there"
That sounds very interesting. Can you elaborate on that? Which tools do you use when getting familiar with a new part of a codebase?
Function def and relevant tests are very useful indeed.
AI summary what it's doing. That sounds intriguing. Which tools do you use for that?
How do you get the broader context?
E.g. how do you decide which other parts of the codebase are closely related (and should be included in your exploration)?
I was intrigued by your post but unfortunately after visiting the site I see no indication of pricing. Since an account is required to submit a stack, I did not proceed without a clear idea of potential cost.
Comments
(I am biased: I am one of the founders of https://graphite.dev )
Flip side of this, you can tackle both of their issues with better tooling and not throw the baby out with the bathwater.
Time lag: Stacking (https://graphite.dev/stacking) is a powerful technique that allows developers to keep developing even while others read through their code.
Context gap: you encounter the same issue in an IDE when exploring a new part of a codebase, and there are tools to help you there (click to see function def, open relevant tests, AI summarize what its doing - we've been trialing the last one internally and it's so cool). Your CR tool should offer all of that, and at many large companies (Google, FB, MSFT, even Jane street) it does. GitHub is just deficient here.
I agree with the other comments in this thread that the main problem is that what should have been an architecture / prototype / etc review happens in CR, and I agree with that. But I think moving away from CR worsens that problem not improves on it.
"Context gap: you encounter the same issue in an IDE when exploring a new part of a codebase"
Yes, that's one of my major arguments for async reviews, especially in large organizations: Future readers of the code will have ca. the same context as the async reviewer. (Contrary to a pair programmer, who has much more context.)
"there are tools to help you there" That sounds very interesting. Can you elaborate on that? Which tools do you use when getting familiar with a new part of a codebase?
Function def and relevant tests are very useful indeed. AI summary what it's doing. That sounds intriguing. Which tools do you use for that?
How do you get the broader context? E.g. how do you decide which other parts of the codebase are closely related (and should be included in your exploration)?
I was intrigued by your post but unfortunately after visiting the site I see no indication of pricing. Since an account is required to submit a stack, I did not proceed without a clear idea of potential cost.