And then there it was, staring me in the face: “We do it this way because…” The simple, stark truth. For two decades, I’ve watched Silicon Valley churn out shiny new paradigms and management fads, each promising to revolutionize how we build software and, by extension, how we mold the next generation of coders.
But often, it’s the bedrock principles, the unglamorous, human elements, that actually move the needle. This recent dive into what truly works for mentoring junior developers isn’t about some AI-driven personalized learning path or a gamified onboarding experience. It’s about the old-school, tried-and-true methods that build actual competence, not just tick boxes.
The ‘Why’ That Sticks
Look, the buzzwords can pile up faster than unaddressed tech debt. We’re told to “use synergies,” “optimize workflows,” and “foster a culture of continuous improvement.” Frankly, it’s exhausting. What’s not exhausting, however, is explaining why a certain decision was made. The piece hits this nail squarely on the head: “We do it this way because…” sticks better than “just do it like this.”
It’s not rocket science. When you hand a junior dev a piece of code or a technical concept, simply telling them what to do is a shallow victory. They might mimic it, sure, but do they understand it? Can they apply it elsewhere? Unlikely. But by providing that one sentence of context—the reasoning, the constraint, the historical baggage—you’re giving them a tool to generalize. You’re empowering them to think, not just to follow orders.
This is the antithesis of the “just trust me” mentality that festers in too many tech teams. It’s about building understanding, not blind obedience. And who is making money off this? Ultimately, the company that ends up with more competent, self-sufficient engineers who make fewer costly mistakes because they grasp the underlying principles.
PRs as Teaching Moments, Not Just Corrections
Pull requests. The digital equivalent of a communal whiteboard, where ideas are debated and code is polished. But too often, they devolve into a dry exchange of demands: “Change this,” “Fix that.”
This isn’t mentoring; it’s just quality control with a bad attitude.
As Saad Mehmood, the author of the original piece, points out, feedback needs to be imbued with purpose. “Instead of only ‘change this,’ add ‘because…’ or ‘an alternative is X, which is better when Y.’ Point them to a doc or example when you have one.” This transforms a critique into a lesson. It’s about teaching them to fish, not just giving them a fish that you happened to catch.
The magic happens over time. As juniors see these well-reasoned explanations, they start to internalize the thought process. They begin to anticipate common pitfalls, understand architectural nuances, and their PRs — and their understanding — become cleaner. This isn’t a revolutionary idea; it’s just good, honest craftsmanship.
“One sentence of why can save a lot of repeated corrections.”
The Power of Pairing (When Done Right)
Ah, pair programming. The Silicon Valley darling that can either be a productivity booster or a passive-aggressive staring contest, depending on execution.
Mehmood’s advice here is sound: short, focused pairing sessions. Thirty to sixty minutes. Share screens, talk through the problem, debug together. The key phrase: “Don’t take over; guide so they drive.” This isn’t about the senior developer swooping in to save the day. It’s about observation. You see precisely where the junior’s mental model breaks down. You can then tailor documentation, future explanations, or even the onboarding process itself based on these real-time insights. It’s invaluable intelligence disguised as collaborative debugging.
Ownership: The Ultimate Test
Giving a junior developer ownership of a small feature, a module, or a specific bug area is arguably the most potent learning experience. It forces them to engage with the entire lifecycle: design, implementation, testing, and even maintenance.
They will stumble. They will ask a million questions. And that’s precisely the point. This is where the real growth happens. The senior’s role isn’t to do the work for them, but to be a safety net and a sounding board. Available for review, yes. Available for unblocking, absolutely. But the reins are firmly in the junior’s hands.
This fosters accountability and a deeper understanding of the system. It’s a microcosm of real-world development, stripped of the paralyzing fear that can come with massive, ill-defined projects.
Normalizing Not Knowing
Here’s a subtle, yet critical
