31–40 of 193 posts
Earlier quoted context omitted.
If the code is so smart that it's not easily understandable, it's not easily fixable. My transition from junior to senior was accompanied by the realization that simpler is nearly always better.
Write me simple AI inference code that has high performance in big batches.
Found plenty of bugs by reading/doing code review.
The author is a mathematician, so when he says “it is not in general possible to find bugs by examining the code” he does not mean it is completely impossible to find bugs. He means only that it is not possible to find all bugs or even any particular bug.
Well, the code review should also be reviewing the provided test code or test plan or whatever that will prove it does not have bugs. You're not reviewing the code to confirm that the code is bug free... you're reviewing the additional code that confirms that the feature-code is bug free. Any process that has a step of "we'll get to that later" is a failure. That includes testing. Until there is some provided content…
It’s probably important to define what sort of code review you are talking about when making broad claims about it. GitHub style asynchronous pull request review with inline comments is the norm now, but it’s not the only sort of review there is. I’m old enough to remember processes that include in person reviews that were more like a dissertation defense or conference presentation. The literature around this that sh…
The best writing on this is the "agent principal-agent" problem, which correctly frames the problem of agents and code review in terms of trust. This is why the solutions for high-trust environments (small teams) and low-trust environments (big companies, open source projects) will be different. https://crawshaw.io/blog/agent-principal-agent
What if I told you that understanding what it is doing and finding bugs is actually the same problem?
So while there may be some overlap, particularly if each person has full understanding of the code's dependencies, in the general case, understanding code and finding bugs are quite different aims.
> many people misunderstand the purpose of code review Oooh, I bet including the author? Yeah, right there, he fails to make any qualifications for his statement, making it factually incorrect. There are plenty of reasons to do code review. If you force me to, I'll define it as information transfer. The point is to have a conversation about the code. To expand both people's understanding about the codebase. Everythin…
What I find to be maybe the single most important part of code review is knowledge transfer. Our entire small team thumbs up a PR before it's merged unless there's a big rush on it, and this gives everyone on the team a rough idea of the state of the codebase at any given time. There's no being blindsided like "this whole system I depend on is gone" like I had happen at far more siloed places I've worked. Beyond that…
We even find ourselves creating PRs in situations where the code is going to be merged immediately anyway, and tagging other devs, just so they have a convenient way to see what got merged and why. So people don't lose track of what is in the codebase.