Coaching through Code: Using the CEDAR Model for Better Feedback

Giving feedback is a core engineering skill, yet many developers rely on the flawed feedback sandwich. This often obscures the actual message and feels insincere. To foster growth in junior developers, you must shift from being a critic to being a coach. Effective feedback doesn't just fix a bug; it fixes the developer's mental model, ensuring the same mistake doesn't reappear in future pull requests.

Establishing the CEDAR Framework

The CEDAR model stands out because it places the junior developer in the driver's seat. It consists of five stages: Context, Examples, Diagnosis, Actions, and Review. This structure prevents the "keyboard bashing" tension that often arises during code reviews and keeps the conversation focused on technical growth rather than personal shortcomings.

From Context to Diagnosis

First, set the Context. Create a safe environment by stating that the goal is better code, not a personal trial. Move to Examples, where you point out specific lines of code or architectural decisions without passing judgment. The magic happens during Diagnosis. Instead of saying "this is wrong," ask open-ended questions like, "Can you walk me through the logic here?" This forces the junior to realize the error themselves, which is the most powerful way to learn.

Driving Action and Retention

In the Actions phase, let the recipient suggest the fix. If you hand them the solution, they lose ownership and start "throwing things over the fence," relying on you to do the thinking. Nudge them toward patterns like the Strategy Pattern or the Law of Demeter to ground the discussion in design principles. Finally, Review the plan together to ensure total alignment.

Practical Tips for Daily Reviews

To make this stick, keep your feedback loops tight. Smaller, frequent pull requests are easier to digest than massive architectural overhauls. Limit your critiques to one or two high-impact issues per session to avoid demoralizing your team. Always criticize in private, especially for behavioral issues, to maintain the safety of your engineering culture.