How to Listen in Code Review and Design Critique
Understanding precedes rebuttal — especially async.
[ essay ]
In review, understanding the concern precedes defending the diff — especially when the conversation is text.
Listening means restating the worry before you justify the change. You are worried about contrast on the dark-heart-themes token pass — yes, here is the ratio on the sidebar, and here is what fails at small size. The same move belongs in design critique: name the constraint they care about (legibility, motion, density) before you defend the mock. I have burned a thread defending a pull request I had not actually heard. The reviewer was asking about focus order. I answered about color. We were both right about different files. Restate first. Then show the evidence.
Async makes tone load-bearing. Write questions as curiosity, not indictment. Remote teams live in the sentence you typed too fast. They skip the restatement because it feels slow. It is the cheapest way to avoid a two-day argument about a comment that was never about your competence.
Close the loop. When you change based on feedback, say so. Reviewers learn their time mattered. Critique that never lands in the artifact teaches people to stop commenting. Restate. Cite the diff. Then decide.
— JV · Dark Heart Labs.