I ruin developers’ lives with my code reviews and I'm sorry

basically starting a rant about being a tightass about code review with a bad piece of code

What is not clear in your comment though is that that means looking at the code and making sure there's no mistake too in it too.

It may seems like it's working as expected, but maybe you'll find an edge case that was missed by the original developer.

It's possible too that the solution of the original developer was clear to him, or that it's clear knowing the context of the ticket, but once in the wild, that code may become incomprehensible (which later on can bring more error because someone misunderstood why that line was there and changed it incorrectly for example). That can be easily fixed by adding a tiny comment there.

Sure doing what it's supposed to do in an acceptable performance is great, but I think there's a bit more into a code review and ignoring theses can be quite problematic.

> "I can't read it!" - I also can't read Chinese

Doesn't this show there's an issue though in the long term? If you are the only one that can read Chinese in the company, maybe it would be a better idea to consider using English?

For example, in a recent code review I found a function where an argument was being passed in but not used, and a constant of the same type with a similar name was used in the body of the function. That obviously happened because the author got halfway through refactoring their code and didn't realise, and we were both happy to fix it.

* There is some built-in diversity of skillsets, if not demographics, by pushing team communication into a continuous meeting format where non-developers are given space.

* It forces some vulnerability into the mix, which gets you into a less inhibited state: "I don't know, but" is way more common if you literally can't run off and prepare some slick answer to every question or hide behind your ownership of the solution space.

* The I/O bottleneck of having a whole crowd at one screen moves the emphasis away from the lines of code, and towards the broader parts of problem solving and getting feedback. Everyone that's experienced always says that it's not how fast you type that matters.

* Feedback becomes less punishing. Everyone gets a chance to drive, make some minor errors, and immediately correct them, which keeps everyone on the same level and encourages a healthy attitude to learning, vs the anxious/punishing "all-seeing-eye judgment" nature of batch code reviews.

But mostly, I like the idea of a hypothetical mind-melded "superdeveloper" emerging from a mob - a coder that pumps out extremely high quality code solving exactly the right problems in a single iteration, without breaking a sweat. I do think I've seen it in bursts in the past, just not in a systematic fashion. My experiences with pair programming definitely suggest that it adds intensity to problem solving that isn't there alone, and it makes me suspect that we may just straight-up be "doing software wrong" by focusing on quantities of code edits and not the overall communication flows.