Reviewing code is a skill
Conversation activity · last 21 hours peak 3/30m
Clustered from 15 items across 3 sources. Not yet parsed — the coverage below is the raw record.
Social posts 3
Voices from the web unedited
-
And probably also to avoid unintentionally adding blame. "Why didn't you do it like this?" can sometimes feel like an accusation, depending on the tone and team dynamic.
-
Top 25 stories on lobste.rs: 🔗 Reviewing code is a skill https:// typesanitizer.com/blog/code-re view.html 🔥 Score: 0 💬 https:// lobste.rs/s/gyxkma/reviewing_c ode_is_skill 🔗 GNOME Shell Design Dreams https:// blogs.gnome.org/shell-dev/2026 /08/11/gnome-shell-design-dreams/ 🔥 Score: 0 💬 https:// lobste.rs/s/b3uky6/gnome_shell _design_dreams…
-
One of my previous posts [How should we learn from bugs?](https://typesanitizer.com/blog/bug-analysis.html) has a longer example, but the short version for why you'd want to avoid counterfactuals is: (quote from the post) > Counterfactual reasoning is dangerous when attempting to understand why things happened the way they happened, and why people…
-
I am supposing that it is because you do not want to ask leading questions or bias the junior person's answer in some way.
-
It's an example of the [socratic method](https://en.wikipedia.org/wiki/Socratic_method) It's an extremely efficient management/growth method but it is also very time/energy consuming.
-
When there is something I don't understand or potentially don't agree while performing a code review, I tend to phase it as curiosity: "I'm curious, why did [...]" OR "I'm curious, what if it were implemented this way [...] what do you think?" It shows interest without making any assumptions and allows the implementer to respond with rationale.
-
To state the obvious, pull down the code and look at the change in context then. There's absolutely nothing wrong with that! The Github (et al) review interfaces are not necessarily well set up to help you understand the diff in the wider context, but your dev setup absolutely is (or should be).
-
I was wondering about footnote 10, quoted in context here: > In the meeting, the senior person, instead of pointing out things which don’t quite make sense, or could be done differently, instead first asks the junior person for their perspective on why they did things a certain way, or what assumptions they were making.[10] > > [10]: It’s key to…
-
So much devolves to: > "How could you be so dumb?" > "You told me to do it this way!" > "I'm not dumb! Do it like this…" Neither are, there was just information and instruction omitted at some point. > "What led you to this state?" > "I acted based on prior instruction." > "We are both now wiser, as I realize I should have explained this better…
-
> but it is also very time/energy consuming. I think this is the key piece for why there is no intrinsic motivation to use this method or for why it's so difficult to avoid counterfactuals. Especially given that many of these interactions happen asynchronously which potentially adds a time delay, further increasing the time/energy required.