How to Provide Constructive Feedback to New Developers

New developers improve at the speed of the feedback they get. I have led backend teams in Bahrain and Dubai, most of them developers early in their careers, and nothing I did for them mattered more than how their work was reviewed. These are the rules I try to hold myself to.

Make It Safe First

Trust comes before correction. A new developer who is afraid of you will hide problems, and hidden problems come back bigger. Be the person they can bring a broken build to. Say early and often that mistakes are how this trade is learned, and mean it, because they will quietly test whether you meant it.

Say Something They Can Act On

Telling someone their code is inefficient is a verdict, not feedback. Pointing at the query running inside a loop, explaining what it costs, and showing a better way is feedback. Anchor every comment to a specific piece of work, and give the developer a concrete next step. If there is no action they could take, ask yourself why you are saying it at all.

Balance matters as much as precision. Lead with what genuinely works before you reach what does not, and do it honestly. If praise only ever arrives as packaging for criticism, people notice within a week, and after that the praise means nothing. The old sandwich structure, something good, then the hard part, then encouragement about where they are heading, still earns its keep for exactly this reason. It only fails when the bread is fake.

Timing is part of the message too. Feedback about last month is history, not coaching. Say it while the work is still fresh, and keep a regular slot so feedback becomes a rhythm instead of an event. When it only ever arrives unscheduled, it only ever arrives when something is wrong, and people learn to dread the sight of you.

Teach Them to See It Themselves

The end goal is a developer who no longer needs me. Before giving my view of a piece of work, I ask for theirs. Usually they already know where the weak parts are, and saying it themselves costs less pride than hearing it from me. The conversation that follows a self-assessment is worth three of my monologues.

And be patient. Every learning curve is different, and where someone sits on it today says little about where they finish. Mark progress out loud as it happens. Small wins, named at the time, are what carry a new developer through the long middle stretch where everything is still hard.

None of this is really about fixing code. It is about growing the person who writes it, until the feedback loop lives inside their own head.