Short answer
Code quality defines the evidence that code is understandable, safe to change, and aligned with agreed engineering conventions.
About Code quality
The ability to produce and improve code that others can understand, verify, maintain, and change without avoidable risk.
Use this competency for
- Functions where people create or review production code.
- Roles accountable for keeping shared code understandable and changeable.
Do not use this competency for
- Roles that do not create, modify, or review software code.
Important distinctions
Testing strategy
Testing strategy decides what evidence tests should provide. Code quality assesses the structure and maintainability of the code itself.
Technical debt management
Technical debt management prioritizes constraints across a codebase. Code quality assesses the standard of specific code changes and reviews.
Expectations by level
IC1
Individual contributor 1
Produces well-scoped code with guidance, follows established conventions, and addresses review feedback before a change is merged.
Observable behaviors
- Uses the repository naming, structure, and error-handling patterns.
- Keeps a change focused on the stated requirement.
- Responds to review comments with a change or a documented reason.
Examples
- Refactored a repeated branch into the existing shared helper during review.
- Split an unrelated cleanup from a bug fix so each change could be reviewed separately.
IC2
Individual contributor 2
Independently improves code in a team-owned area, resolving unclear maintainability choices and reviewing peers against shared standards.
Observable behaviors
- Chooses interfaces that hide changeable implementation details.
- Reviews changes for readability, coupling, and failure handling.
- Removes duplication when evidence shows one shared abstraction fits.
Examples
- Reworked a module boundary so a new data source could be added without changing callers.
- Rejected a premature abstraction and documented when duplication should be revisited.
IC3
Individual contributor 3
Sets code quality direction across teams for complex or recurring problems and enables others to apply the standard without central review.
Observable behaviors
- Defines a code standard tied to recurring review or defect evidence.
- Guides cross-team refactors through safe intermediate states.
- Checks whether adopted quality rules reduce the problem they target.
Examples
- Introduced a shared boundary rule after the same coupling issue appeared in three services.
- Sequenced a cross-team refactor so each repository remained releasable throughout.