zlacker

They're different mindsets. Some folks are better editors, inspectors, auditors, etc, whereas some are better builders, creators, and drafters.

So what you're saying makes sense. And I'm definitely on the other side of that fence.

>>bryant+(OP)
When you form a mental model and then write code from that, thats a very lossy transformation. You can write comments and documentation to make it less lossy, but there will be information that is lost to an reviewer, who has to spend great effort to recreate it. If it is unknown how code is supposed to behave, then it becomes physically impossible to verify it for correctness.

This is less a matter of "mindset", but more a general problem of information.

>>bluefl+C2
Whether reviewer or creator, if the start conditions / problem is known, both start with the same info.

"code base must do X with Y conditions"

The reviewer is at no disadvantage, other than the ability to walk the problem without coding.

>>bbarne+k7
This is the ideal case where the produced code is well readable and commented so its intent is obvious.

The worst case is an intern or LLM having generated some code where the intent is not obvious and them not being able to explain the intent behind it. "How is that even related to the ticket"-style code.

>>bryant+(OP)
You don't become a good editor, inspector, what have you, by having other people/machines write all the code for you. To become and, perhaps more relevant, to stay a good reviewer, you need to regularly write code from scratch to see how it works. On top of that, languages, frameworks and libraries change constantly and you need to write and execute and experiment with new code to see exactly how it behaves so that you can eventually review the code that uses these features. Good reviewers are not born good reviewers!