Live data from Hacker News

Code review can be better

tigerbeetle.com

41–50 of 253 posts

Re: Code review can be better

#41

I find the idea of using git for code reviews directly quite compelling. Working with the change locally as you were the one who made it is very convenient, considering the clunky read-only web UI. I didn't get why stick with the requirement that review is a single commit? To keep git-review implementation simple? I wonder if approach where every reviewer commits their comments/fixes to the PR branch directly would w…

is github's PR considered read-only?

i've had team members edit a correction as a "suggestion" comment and i can approve it to be added as a commit on my branch.

Re: Code review can be better

#42

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

There is no reason to think that code review will magically be spared by the AI onslaught while code writing falls, especially as devs themselves lean more on the AI and have less and less experience coding every day.

There just hasn't been as many resources yet poured into improving AI code reviews as there has for writing code.

And in the end the whole paradigm itself may change.

Re: Code review can be better

#43

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

I’m considered one of the stronger code reviewers on the team, what grinds my gears is seeing large, obviously AI heavy PRs and finding a ton of dumb things wrong with them. Things like totally different patterns and even bugs. I’ve lost trust that the person putting up the PR has even self reviewed their own code and has verified it does what they intend. If you’re going to use AI you have to be even more diligent a…

[deleted]

Re: Code review can be better

#44
post #42

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

There is no reason to think that code review will magically be spared by the AI onslaught while code writing falls, especially as devs themselves lean more on the AI and have less and less experience coding every day. There just hasn't been as many resources yet poured into improving AI code reviews as there has for writing code. And in the end the whole paradigm itself may change.

[deleted]

Re: Code review can be better

#45
post #14

> When I review code, I like to pull the source branch locally. Then I soft-reset the code to mere base, so that the code looks as if it was written by me. This is eerily similar to how I review large changes that do not have a clear set of commits. The real problem is working with people that don’t realize that if you don’t break work down into small self contained units, everybody else is going to have to do it ind…

For those that want an easy button. Here ya go.

``` review () { if [[ -n $(git status -s) ]] then echo 'must start with clean tree!' return 1 fi

        git checkout pristine # a branch that I never commit to
        git rebase origin/master

        branch="$1"
        git branch -D "$branch"
        git checkout "$branch"

        git rebase origin/master
        git reset --soft origin/master
        git reset

        nvim -c ':G' # opens neovim with the fugitive plugin - replace with your favorite editor

        git reset --hard
        git status -s | awk '{ print $2 }' | xargs rm
        git checkout pristine
        git branch -D "$branch"
} ```

Re: Code review can be better

#46
The biggest grip I have with Github is the app is painfully slow. And by slow, I mean browser tab might freeze level slow.

Shockingly, the best code review tool I've ever used was Azure DevOps.

Re: Code review can be better

#47

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

> you MUST get very good at reviewing code that you did not write.

I find that interesting. That has always been the case at most places my friends and I have worked at that have proper software engineering practices, companies both very large and very small.

> AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point.

I echo @ZYbCRq22HbJ2y7's opinion. For well defined refactoring and expanding on existing code in limited scope they do well, but I have not seen that for any substantial features especially full-stack ones, which is what most senior engineers I know are finding.

If you are really seeing that then I would either worry about the quality of those senior+ software engineers or the metrics you are using to assess the efficacy of AI vs. senior+ engineers. You don't have to even show us any code: just tell us how you objectively came to that conclusions and what is the framework you used to compare them.

> Educational establishments MUST prioritize teaching code review skills

Perhaps more is needed but I don't know about "prioritizing"? Code review isn't something you can teach as a self-contained skill.

> and other high-level leadership skills.

Not everyone needs to be a leader and not everyone wants to be a leader. What are leadership skills anyway? If you look around the world today, it looks like many people we call "leaders" are people accelerating us towards a dystopia.

Re: Code review can be better

#48

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

AI can review code. No need for human involvement.

Re: Code review can be better

#49
post #47

If you want to remain relevant in the AI-enabled software engineering future, you MUST get very good at reviewing code that you did not write. AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this point. Educational establishments MUST prioritize teaching code review skills, and other high-level leadership skills.

> you MUST get very good at reviewing code that you did not write. I find that interesting. That has always been the case at most places my friends and I have worked at that have proper software engineering practices, companies both very large and very small. > AI can already write very good code. I have led teams of senior+ software engineers for many years. AI can write better code than most of them can at this poi…

[deleted]

Re: Code review can be better

#50
post #28

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN. When we started graphite.dev years ago that was a workflow most developers had never heard of unless they had previously been at FB / Google. Fun to see how fast code review can change over 3-4yrs :)

I miss the fig workflow :-(

Try `jj`, as others have mentioned. It's being built by the team that built/maintains fig, and the are porting all their learnings into that.
Post reply on HN