codeapprove

Shameless plug but if you dislike GitHub's code review UI you could try my product, CodeApprove (https://codeapprove.com).

There are actually dozens of great code review tools out there: https://medium.com/codeapprove/the-best-modern-code-review-t...

Im my opinion very few professional dev teams should settle for GitHub's default UI!

I generally think of code review like static typing: many people think they don't need it but pretty much every serious large codebase uses it and needs it.

And just like coding with types: code review does not have to be a chore! With good processes and good tools it can be a superpower and a key element of developer productivity.

Oh wow something must have been in the air! I have been working on a very similar project lately, I think a lot of companies need this and your feature set looks great.

So it's safe to say I think this is a great idea and I wish you success with it! (And when you see the Show HN for "GitGuard" please don't think I ripped you off)

I’m obviously biased but you might like https://codeapprove.com, it’s a GitHub-compatible code review UI for power users.

There are actually a lot of good options in the space these days (Reviewable, Graphite, etc) so there’s no much reason to stick with what GitHub gives you!

Even at Google, most people find Gerrit to be pretty intimidating. It’s mostly only used for Chrome, Go, and Android and it’s far behind Google’s flagship review tool (Critique).

Gerrit is not a bad tool but it is somewhat hard to get used to if you have the more common GitHub-flavored git experience that most software engineers have these days.

I expect if the goal is to get the most vibrant contributor community possible the best thing would be to move to a GitHub-first workflow where Gerrit is supported as a backup. But there’s too much inertia for that to ever happen.

GitHub definitely does support (1)! You just comment and click “add to review” as you go and then submit them all together at the end. It’s been the default for a while now.

For (2) you definitely want Gerrit. For major improvements on (1), (3), and (4) you might like https://codeapprove.com which sits on top of GitHub and attempts to solve your pain points. Obviously I am biased!

Wow this looks great. I really like the additions of presence and the stats about review times. It seems seamlessly integrated.

As you might be able to tell from my username, I’m the founder of CodeApprove (codeapprove.com) which is meant to fix a lot of the same problems you’re going through with Visibly. I’m also passionate about code review and code review tools in general so I’d love to chat sometime, feel free to use the email in my profile.

Looking good Fahrzin! It's a nice update on the landing page without a total overhaul of the Reviewable look/brand.

I was actually in charge of a large open-source effort at Google (75 repositories, dozens of internal devs, hundreds of contributors) so I had a very unique position of being able to watch Googlers attempt to use Google engineering practices on GitHub.

For the most part they loved the open-source work (a lot more flexibility than internal systems) but they all complained about the code review! It just didn't give them the same rapid drive to consensus they got with Google's internal tools. And I think they were right.

So after I left Google I was very inspired to work on a better code review system for developers on GitHub. And that's how CodeApprove was born!

There are a lot of great tools in the space right now, I firmly believe that teams should not just accept what GitHub gives them. After all, we don't use Notepad as our main editor just because it ships with the machine.

I started CodeApprove (https://codeapprove.com) because I saw from the inside how big tech companies (Google, Meta, etc) optimize PR review. Rather than try to automate, replace, or artificially speed up the process, instead they've made great interfaces that allow reviewers and authors to always know whose "turn" it is in a code review and quickly find what they need to address. The goal is to get to resolution (or in other words, consensus) in as few rounds as possible and to make code review painless to the rounds themselves are short. A good tool goes a long way here.

Last year I also wrote a quick survey of other tools which I've seen in the space and think are promising: https://medium.com/codeapprove/the-best-modern-code-review-t...

That list is already a bit out of date, I can think of some newcomers (Planar, Pullpo) which would also be on the list if I was writing it today.

I've helped a bunch of teams make their code review process better (tools aside) and if you're looking for free advice on how to help your team review better I'm always happy to talk to people about this. Email is in my bio.

Looks really nice! Also I love the level of personality on the marketing page, it's nice to see a product not taking itself too seriously.

Just curious, this seems to have a lot of overlap with Axolo (https://axolo.co/), are you aware of that tool and if so how does yours compare?

Also I should mention that I am the founder of CodeApprove (https://codeapprove.com) and I always love chatting to new people in this space. Email in my bio if you want to say hi!

All great points, and I appreciate them because I think CodeApprove's marketing materials should address them more head on.

The first two (trust with repos and GitHub API rate limits) don't really apply to CodeApprove in the same way they do to Reviewable. Because we're using GitHub's newer "apps" system and not OAuth, we only have very limited scopes (can't write code, etc.) and API rate limits go up as we get more users.

Your points about stacked diffs and PR adoption stand!

(shameless plug alert)

If you're looking for a drop-in improvement to GitHub's code review experience, you may be interested in CodeApprove (https://codeapprove.com).

It's got a lot of the things that make Gerrit appealing, but with less of a drastic workflow shift (still branch-based PRs) and a much nicer UI.

Wow this looks really nice! The AI-grouped (and described) file changes is something I have never seen before, and I thought I'd seen everything in code review.

A lot of what you're doing is similar to what I've been trying to achieve with CodeApprove (https://codeapprove.com) which brings Google's code review workflow (Critique) to everyone using GitHub. It's not doing any of the AI stuff, just focusing on conversation resolution, managing assignment, and giving a much more "power user" UX to the whole thing.

If you ever want to chat about code review, just shoot me an email.

CodeApprove: https://codeapprove.com

Basically CodeApprove is a code review UI for power users to layer on top of GitHub. I find that it really resonates with people who have worked at Google/Facebook/etc before and find Github's code review tools really lacking. You get conversation resolution tracking, auto-assignment of reviewers between 'turns', a personalized inbox, and a dense/fast UI with keyboard shortcuts for almost everything.

(Note: I do have some users, but I just got out of alpha mode haven't yet charged any of them. I will get my first $ at the end of this month)

I am biased here since I am the creator of an async code review tool (codeapprove.com) but I think that many teams don't take the time to invest in their code review process and tools enough. For something that most of us do every day (often multiple times per day) there's surprisingly little focus on how to do it well.

When I joined my last team they had a bad code review process. Basically once a day or so the CTO and one or two other senior people would look at all the ready-to-merge PRs and give them a thumbs up or thumbs down. I pushed for a much more rigorous but inclusive process. Everyone would do code reviews, every PR would have two approvers, we'd talk about how to do review well and we'd invest in some more automations to solve common pain points. Not only did we get faster as a team (contrary to popular belief, more reviews != slower) but we also got much more thorough feedback AND we were able to consciously propagate the right patterns throughout our codebase in an organic way.

It's no exaggeration to say that good code review turned leveled the team more than any other engineering process change we made. More than testing or sprint improvements, more than our management changes, etc. It's highly underrated!

I agree that the tooling is very underrated! It’s strange that programmers spend so much effort choosing their code writing environment (IDE, etc) but just take what they’re given when it comes to code reviewing (mostly GitHub PRs)

If you’re missing Critique, allow me to shamelessly plug CodeApprove: https://codeapprove.com

Just like Critique, it’s a code review tool for power users that really lets you focus on resolving every discussion.

As someone who is a big proponent of "squash and merge" I am susprised to see myself labeled an extreme clean freak! I don't have very extreme git uses or opinions.

I want a few things in my team's workflow:

* A commit history that a human can mostly understand

* Effective code reviews where I can easily see what changed between rounds

* The ability to revert a whole Pull Request easily and cleanly

* A local workflow that does not get in my way and allows me to be messy when I need to be

For our team that means we commit whatever we want to our local branch and then squash and merge the whole thing at the end. The result is a single commit saying "Adds feature foo". I don't feel like I lost anything in the squash ... am I missing something? I really don't want to have "fix lint, address review comments" in the shared commit history.

Thanks for the link to Basecamp's policies! I think that's exactly what I was looking for.

Thanks fir the link to Termsfeed! At least it has one-time pricing and self-hosting, that's great.

Termly in particular seems to go out of their way to present the terms as an HTML/CSS/JS combination that is surprisingly hard to put into your own site.

Interesting stuff! I feel somewhat validated to see that there's not an empirical relationship between change size and time to merge because I've always disliked the "small PRs police".

I'd personally argue that the most important metric is "time to consensus". There are sometimes good reasons to hold off on merging an approved PR (external effects) but that should not reflect poorly on how your team does code review. I define consensus as when the author and the reviewer have resolved all blocking conversations.

That's the model I've used on CodeApprove (https://codeapprove.com) which focuses somewhat obsessively on unresolved conversations as the key element of a code review.

That’s what we’re trying to do at CodeApprove: build a code review tool for power users. UX is a huge part of it.

If you’re interested, check out https://codeapprove.com

Shameless plug but at CodeApprove we’re pretty obsessive about giving the GitHub PR review experience “more love”. Check out https://codeapprove.com if you’re interested

The key to these types of interactions is to make them impersonal. In the case of coding standards (which don't have to do with logic/implementation) try to get all of them enforced by either an automated linter/formatter or a written style guide. Then you're not saying "I think you should ..." it's either a CI error or a link from you to the style guide. There shouldn't be any argument on these points.

Another thing to do is to make sure the person you're reviewing understands how much you care about each comment. I like to prefix things I don't care about with "nit:" or "optional:" to signal that I noticed something and wanted to share my thoughts but I don't think it's a blocking issue.

Finally make sure you're being humble and friendly. If you're worried that a certain block of code might confuse a future reader, say that it confused you! There's a huge emotional difference between "this is confusing, please refactor" vs. "This was hard for me to understand at first, could you consider refactoring or adding a comment to make this easier for future readers?". By showing your own struggles, you can bring more empathy into the conversation.

----

While I'm here ... I should plug that I am the creator of https://codeapprove.com which is a tool designed to help you review code like a pro. Code review is all about reaching distributed consensus, and CodeApprove helps you get there faster.

CodeApprove founder here! If you want to chat, my email is in my HN profile.

One obvious benefit of the internal tools at Google is that they're all integrated with each other. So any Googler can quickly:

1. Search another team's code

2. Quickly jump into a Cloud IDE to make a change

3. Build and test the code, because everyone uses one build system

4. Send that code off for review and have the review tool automatically select the right reviewers and run the right tests

For a simple change (let's say a typo fix) all of the above can happen in a single browser tab in under 5 minutes even if you've never been in that part of the code before.

----

While I'm here a shameless but relevant plug: if you're looking for a Google-like code review experience on GitHub check out https://codeapprove.com

Graphite is excellent!

Shameless plug but anyone interested in a code review tool on top of GitHub may also want to check out CodeApprove (https://codeapprove.com). It's got a lot of the things that people from FAANG companies, especially Xooglers, miss about the excellent internal code review tools those companies have.

Everything in the article rings true. We as authors/reviewers can do a lot more to prove that the code works and much of that doesn't actually involve reading diffs.

However I think people often underrate how bad their basic code review tools are how much that might be holding them back! GitHub's default tooling is just not that great and you can easily miss a lot of the most important code or discussions.

So ... shameless plug. That's why I built CodeApprove (https://codeapprove.com). If you're reviewing code on GitHub, CodeApprove will make your job easier. Your reviews will be faster and more direct. If you layer the tips in this blog post on top of a good tool like CodeApprove you'll definitely notice a difference.

If you view code reviews as expressing a lack of trust, you're probably doing them wrong. Code reviews should be a conversation among people who trust each other. You're saying "hey I'd like to know your thoughts about this, and I'd also like you to learn a bit about what I am doing"

When done right code reviews spread knowledge and build trust among team members. Of course there are certainly situations which call for a push without a code review, but those should be exceptions not the rule.

While a lot of the issues around code review are cultural, I also think there's a lack of good tooling. That's why I'm building CodeApprove which makes reviewing code on GitHub faster and more enjoyable: https://codeapprove.com/

This is a really cool and thorough approach. I've always thought that it's strange how programmers are extremely picky when it comes to tools for wiring code but they seem to accept whatever they're given for reviewing code.

Shameless plug: that's why I made CodeApprove (https://CodeApprove.com). I think we can do a lot better than what GitHub offers by default.