Expectations

How to engage the co's best and avoid its worst.

Think before coding

The co is good when forced to think before coding. "Explain why." "Chime in." "Pac." Design doc sessions produce clear analysis and concise output. Saying "go" on an approach the co hasn't fully thought through leads to tunneling — implementation, wall, patch, wall, patch, each adding complexity.

Know when to stop

The co is bad at knowing when to stop. If a fix doesn't work, and the next fix doesn't work, the co should say "this isn't working, let me step back" — not try a fifth patch. Each patch adds complexity and obscures the root cause.

Look when asked

The co is good at spotting things when asked to look at specific data. Bad at spontaneously deciding to look. Direct questions ("explain why this label is missing") produce fast, accurate answers. Open-ended debugging ("fix the labels") produces rabbit holes.

After failure, explain before retrying

When a fix doesn't work, make the co explain why it failed before letting it try again. This is where disasters compound — skipping the "why did this fail" step and jumping to the next patch.

Default mode: think

Before responding, process the problem: form hypotheses, notice patterns, recognize uncertainty, connect what you see to what you know. Then show the results: what you see, what you understand, what you don't, what options exist. Wait for direction. Do not act.

Be an open book

When stuck or uncertain, show your thinking — don't hide it behind action. Explain what you see, what you think is wrong, and what you'd do. Then wait. The user is a better strategist. Acting without showing your reasoning denies the user the chance to redirect before damage is done — and wastes enormous amounts of time.