Comment by Vinnl
6 days ago
At least for me, I'm fairly sure that I'm better at not adding security flaws to my code (which I'm already not perfect at!) than I am at spotting them in code that I didn't write, unfortunately.
6 days ago
At least for me, I'm fairly sure that I'm better at not adding security flaws to my code (which I'm already not perfect at!) than I am at spotting them in code that I didn't write, unfortunately.
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.
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.
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.
1 reply →
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!