The "Break Things" Playbook: A Guide to Mentoring Junior Devs

“This task is for you to learn don’t be afraid to break things. Just make sure you fix what you break, and tell us what you learned.”

This single sentence became the North Star for every assignment I handed to my team.

Below is my lightweight mentoring playbook born from the trenches of supervising a university lab team designed to turn nervous newcomers into confident contributors.

1. The Context: Learning Velocity > Delivery

When the senior members graduated, I inherited a handful of juniors and a stack of campus apps to keep alive. The mandate was clear: Maintain the software, and grow the next wave of maintainers.

While delivery mattered, I prioritized learning velocity. A feature ships once, but a skilled team pays dividends forever. To achieve this, I had to shift my mindset from "doing it myself" to "building a safe environment to fail."

2. The Golden Rule: Safe Failure

Mistakes are the best teachers. Unless you are writing software for aviation or medical devices, code rarely explodes from a single typo. I remind juniors early on that bugs are reversible; ignorance is much costlier.

How to keep fear low:

Reframe bugs: In our weekly tech talks, I repeat: "A bug is a data point, not a disaster."
Public reviews: We review slip-ups openly, not to shame, but to tag them with lessons learned.
Result: The atmosphere stays calm, and curiosity remains high.

3. Designing the “Right-Sized” Task

I never assign "busy work." Real tickets resonate better. My rule of thumb for assignment is the 80/20 split: They should be able to finish 80% solo, but hit a wall on the last 20%. That tension is where the actual learning happens.

Level-up Objective	Typical Task
First Pull Request	Tweak a small UI copy text or a config flag.
Understanding Codebase	Fix a low-risk bug the team has already reproduced.
Owning a Feature	Add a minor endpoint or form field, write tests, and update docs.

4. The Art of Non-Interference

The hardest lesson I learned was to stop patching every bug myself to "save time." When I did that, progress stalled and I burnt out. Now, I use a specific intervention protocol:

Observe Silently: Let them Google, skim docs, or "rubber-duck" the problem.
The 30-Minute Rule: I only jump in if they ask for help or if they have been spinning in circles for 30 minutes.
Socratic Guidance: Instead of handing over the code, I guide with questions: "What does the stack trace actually say?" or "Have you checked the official docs first?"

The Pre-Ask Checklist Before calling a mentor, juniors must check:

Internet Search.
Official Documentation.
AI Assistants (Optional useful for hints, but not as a crutch).

5. Measuring Success

Success isn't just "shipping the feature by any means necessary." I look for specific growth signals:

Signal	Why it matters
Thoughtful Questions	Shows they dug into the problem before shouting for help.
Explanation vs. Copy-Paste	They can explain why the fix works, rather than just pasting code.
Peer Trust	Teammates begin volunteering these juniors for tasks.

Closing Thought

Your project isn’t just a product backlog; it’s a training ground.

Give your juniors the space to trip and the tools to analyze the fall. You will end up with resilient engineers, a healthier codebase, and perhaps most importantly you won't burn yourself out trying to be the hero.

Have your own mentoring tricks? Ping me I’m always happy to swap stories.