How do you handle a team member who consistently writes poor-quality code?

Question

Accepted Answer

Poor-quality code from a teammate is a coaching problem first, not a blame problem. My approach is calm, specific, and early: diagnose the cause, give kind concrete feedback privately, set clear standards, support them in improving, and only escalate if nothing changes. The goal is growth, not a paper trail.

## How I handle it

- **Separate skill gaps from carelessness.** These need opposite responses. A skill gap calls for teaching and examples; carelessness calls for a frank conversation about standards and attention. Watch the pattern before deciding which it is.
- **Give feedback early, privately, and specifically.** Don't let it accumulate into a big confrontation. "This function is hard to test because it does three things" lands; "your code is sloppy" does not. Point at the code, not the person.
- **Set clear, shared standards.** A lot of "poor quality" is really *unstated expectations*. Code review norms, linters and formatters, and reference examples make "good" concrete and remove personal judgment from the equation.
- **Pair and mentor.** Sitting together on a real change teaches more than ten review comments and shows you're invested in their success, not just critiquing.
- **Follow up.** Acknowledge improvement when you see it; people repeat what gets noticed. If a pattern recurs, name it directly and revisit the plan.
- **Escalate only if there's no improvement.** If sustained, supported coaching doesn't move the needle, loop in their manager. By then you have specifics and a record of trying to help, which makes the conversation fair.

## Why it matters

Poor code review handled badly, public criticism, vague complaints, silently rewriting people's work, damages trust and morale far more than the code damages the system. Handled well, the same situation grows an engineer, raises the team's quality bar, and signals that feedback here is about helping people get better, not catching them out.