How to Mentor Developers Who Think, Not Just Code
Thinking is becoming rare in our time so maybe this would help a little
Alright, let’s get into it. Nobody cares if you ship code like Amazon ships cardboard. Seriously, nobody. Because when things go wrong, and they always do, your neatly packaged syntax doesn’t matter. What counts is your ability to think.
Yeah, I said it. Think. Terrifying, isn’t it?
Junior Developers Don’t Fail Because They Miss Semicolons
Early in my career, I had a mentee named Alex (obviously not their real name, I’m sarcastic, not cruel). Alex was passionate, eager, and about as good at critical thinking as a goldfish at algebra. This person could code like the wind. Lines flew from their fingertips. But ask Alex why their solution worked, or worse, why it didn’t, and they'd stare back like a cat caught watching dog videos.
Here’s the bitter truth: Syntax errors rarely tank careers. But an inability to frame problems? That's career suicide.
"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
- Abraham Lincoln
Preparation, thinking clearly, framing the problem, that's sharpening your axe. Mentors, it's your damn job to teach them this.
Stop Coding, Start Architecting
Here’s a controversial claim: Mentorship isn't about transferring skills. It's about transferring mental models. Skills become obsolete faster than celebrity marriages. But mental models? They’re forever.
One day, Alex frantically messaged me, drowning in their IDE, buried under bugs. I told Alex, “Step away from the damn keyboard. Breathe. Stop coding. Let’s think.”
We sketched the problem on paper. We broke it down. Inputs, outputs, constraints, no magic syntax spells, just simple logic. Alex’s eyes widened, not in horror, but in revelation. They were seeing the matrix. It was glorious.
In that moment, Alex stopped being a code monkey and became an architect. The bugs practically fixed themselves. (Spoiler: They didn't. Alex fixed them, but you get the point.)
Why Thinking Beats Shipping Every Single Time
Let’s be clear: shipping matters. But shipping without thinking is just throwing problems into the future. Research backs this up. Dr. Carol Dweck’s groundbreaking work in Mindset: The New Psychology of Success explains that those with a growth mindset, people who see problems as puzzles rather than barriers, consistently outperform those who rely purely on fixed skills and rote practice.
Your junior devs aren’t failing because they suck at JavaScript. They're failing because nobody taught them how to think through a JavaScript problem like it’s a chess game. Every good chess player thinks five moves ahead. Why the hell aren't we teaching developers to do the same?
How to Teach Thinking (Yes, Really)
Here’s the deal:
Stop spoon-feeding answers. Ask questions instead.
Force them into architecture mode: diagrams, pseudocode, coffee-stained napkins, whatever works.
Encourage the why: Demand explanations. Make it awkward. It’s fun!
Celebrate clarity, not just speed: Reward thoughtful solutions, even if they take longer initially.
You’re not teaching them to code; you're teaching them how to solve problems. That's mentoring. That’s leadership.
Ok, let’s open this up:
Most mentors treat thinking like it’s optional, a “nice to have” skill that juniors will magically pick up by osmosis. Spoiler: they won’t. If you don’t deliberately teach thinking, you’re just raising fast typists with expensive salaries.
Stop spoon-feeding answers.
When a junior asks, “Why isn’t this working?”, your instinct is to jump in with the fix. It feels good. You look smart. They look grateful. But in reality, you’ve just robbed them. You stole the rep. It’s like going to the gym, spotting someone, and then bench pressing the bar for them. Sure, they “finished the set,” but they didn’t get stronger. Good mentors don’t hand out fish. They hand out fishing rods, bait, and maybe a sarcastic comment about falling in the water.
Force them into architecture mode.
Syntax is seductive. It makes you feel productive. Lines of code = progress, right? Wrong. Lines of code are like calories, too many of the wrong ones and you’re bloated, sluggish, and praying for mercy. Thinking, on the other hand, is the diet plan. Take away the IDE. Get them to diagram the flow, sketch pseudocode, draw boxes and arrows. My favorite exercise? Make them explain their design without touching a keyboard. If they can’t explain it in crayon, they don’t understand it in code.
Encourage the why.
“Why” is where the magic lives. Don’t just accept, “It works now.” Push: “Why does it work?” Watch them squirm. That discomfort is growth. Daniel Kahneman, in Thinking, Fast and Slow, calls this System 2 thinking, the slow, effortful, logical kind. Most people avoid it because it feels like work. But this is where problem-solving muscles form. If they can’t tell you why, they don’t own the solution.
Celebrate clarity, not just speed.
Anyone can hack something together with Stack Overflow or nowadays ChatGPT duct tape at 2 a.m. But speed without clarity is like sprinting blindfolded. You’ll hit a wall eventually, probably face-first. Celebrate when they pause to sharpen the axe, when they diagram, when they articulate trade-offs. That’s not wasted time. That’s investment. Slow is smooth, smooth is fast.
Teach them to zoom out.
Thinking isn’t just about solving the current bug. It’s about asking, “What problem am I really solving? And for whom?” That’s the leap from coder to engineer, from engineer to architect. Encourage juniors to see the bigger system: the user, the business, the constraints. Code is the tool, not the goal.
Embrace mistakes as case studies.
Stop fixing errors for them. Let them bomb. Then dissect the wreckage together. It’s not punishment, it’s practice. A mistake is just tuition you already paid, might as well learn the damn lesson. Make post-mortems part of mentorship, not just production outages.
Because here’s the uncomfortable truth: you’re not teaching them to code. Anyone can Google syntax. You’re teaching them to think. To frame problems. To explain trade-offs. To anticipate consequences. That’s mentoring. That’s leadership.
And if you do it right, they’ll surpass you. They’ll outgrow your guidance. They’ll start teaching you. Which is the point. The best proof of mentorship isn’t loyalty, it’s obsolescence.
TL;DR:
Shipping fast is cute. Thinking first is powerful. Great mentorship transfers mental models, not just skills.
Stop producing code monkeys. Start creating architects.
References:
Dweck, C. S. (2006). Mindset: The New Psychology of Success. Random House.
Lincoln, Abraham. (Attributed quote).