[pshc]

Sometimes a problem is a weird combination of hairy/obscure/tedious where I simply don’t have the activation energy to get started. Like, I could do it with a gun to my head.

But if someone else were to do it for me I would gratefully review the merge request.

[strogonoff]

Reviewing a merge request should require at least the same activation energy as writing the solution yourself, as in order to adequately evaluate a solution you first need to acquire a reference point in mind as to what the right solution should be in the first place.

For me personally, the activation energy is higher when reviewing: it’s fun to come up with the solution that ends up being used, not so fun to come up with a solution that just serves as a reference point for evaluation and then gets immediately thrown away. Plus, I know in advance that a lot of cycles will be wasted on trying to understand how someone else’s vision maps onto my solution, especially when that vision is muddy.

[solaire_oa]

The submitter should also have thoroughly reviewed their own MR/PR. Even before LLMs, coders not having reviewed their own code would be completely discourteous and disrespectful to the reviewer. It's an embarrassing faux pas that makes the submitter and the team all look and feel bad when there are obvious problems that need to be called out and fixed.

Submitting LLM barf for review and not reviewing it should be grounds for termination. The only way I can envision LLM barf being sustainable, or plausible, is if you removed code review altogether.

[strogonoff]

> The submitter should also have thoroughly reviewed their own MR/PR

What does it mean to have to review your own code as a separate activity? Do many people contribute code that they wrote but… never read?

> Submitting LLM barf

Oh right…

[solaire_oa]

Writing/reading code and reviewing code are distinct and separate activities. It's completely common to contribute code which is not production ready.

If you need an example, it's easy to add a debugging/logging statement like `console.log`, but if the coder committed and submitted the log statement, then they clearly didn't review the code at all, and there are probably much bigger code issues at stake. This is a problem even without LLMs.

[strogonoff]

Just call it “committing bad code”. LLM autocomplete aside, I don’t see how reviewing own code can happen without either a split personality, or putting enough time that you completely forgot what exactly you were doing and have fresh eyes and mind.

If person A committed code that looks bad to person B, it just means person A commits bad code by the standard of person B, not that person A “does not review own code”.

Maybe it’s a subjective difference, same as you could call someone “rude” or you could say the same person “didn’t think before saying”.

[solaire_oa]

Person A as can commit atrocious code all day, that's fine, but they still need to proofread their MR/PR and fix the outstanding issues. The only way to see outstanding issues is by reviewing the MR/PR. Good writers proofread their documents.

[blub]

I always review the local diff before pushing. Can sometimes catch typos, or unclear comments or naming issues.

The concept and design were by that point iterated on, so it doesn’t happen that I need to rewrite a significant amount of code.

[strogonoff]

My preferred workflow requires me to go through every changed chunk and stage them one by one. It’s very easy with vim-fugitive. To keep commits focused, it requires reading every chunk, which I guess is an implicit review of sorts.