work in progress
The mindset 2 min Principle Scope: adapt to your own remit

Your code is not your baby

The reflex

Someone criticises a function, a mockup or a message you prepared. You start explaining your constraints before you have understood their objection.

The builder’s reflex

“What makes you think it doesn’t meet the need? Let’s look at the case together.”

Why

You can care about your work and still examine what deserves to change in it. A defensive reaction does not cancel what you know about the context; criticism does not prove the critic is right either.

In a review, a comment about a possible error deserves to be tied to a case. A reviewer says the message sent to new sign-ups is too short. Their worry is actually about the missing address. Adding that information may be enough, without rewriting the whole message.

The reverse mechanism exists too. Whoever maintains a system may defend a choice because they remember an outage. Saying they are “attached to their code” throws that information away without examining it. Look for what the disagreement reveals before you interpret its cause.

A useful exchange lets both people state their criteria: who the work serves, what it has to make possible, and the constraints to respect. On a first project, you can ask for feedback on a single point. On experienced work, you can invite someone to examine an assumption you are less sure of.

Try this

When you ask for a review, name the question you want help on and the time available.

“Can you look at whether someone new to the subject would know what to do next?”

On a serious disagreement, say the objection back before you bring your context. Decide what you change, what you keep, and what needs an attempt. After the next use, look at whether the problem raised still shows up. A reasoned disagreement can stay open without blocking all progress.

From where you sit

To discuss

Which recent piece of feedback changed our work, and what made it useful?

Discuss this