Lifting as We Climb, Why Mentoring Associate Developers Matters More Than Ever

I trace my career back to a single moment: a senior engineer took a chance on someone who didn't yet have all the answers.

Early on, I had mentors who demanded discipline, checked my logic with real rigor, and passed down technical craft the hard way. They didn't just hand me answers. They taught me how to think, how to debug under pressure, and how to take personal accountability for every line of code I pushed into production.

That experience shaped how I think about this industry: we rise by lifting others.

Today, as a player-coach who still writes production code and builds engineering teams, I've watched how much has changed in how we build software. AI tools have changed how fast we ship. When I took ClearSignal from concept to production in twelve months, AI helped us move faster. But velocity isn't the same as judgment. Code generation isn't the same as architecture.

As the industry leans harder into AI tooling, mentorship isn't becoming obsolete. It's turning into the advantage that's hardest to copy.

Why LLMs can't replace human experience

AI writes syntax fast. It generates boilerplate, suggests refactors, and scaffolds endpoints in seconds.

Yet it can't mentor.

An LLM doesn't know what it feels like to carry the pager at 3am when a financial ledger goes down in production. It doesn't feel the weight of regulatory compliance in fintech or credit, where a mistake carries real legal and financial consequences. And it definitely can't sit across from a nervous stakeholder and translate business risk into technical architecture.

Lean only on generated code without building human capability, and you end up with plenty of syntax and not much judgment to maintain it. That's why senior engineers need to stay hands-on with developing juniors. Someone has to teach the context and judgment a model can't.

The syntax trap

Junior developers today face a trap that didn't really exist before: they can ship complex features before they understand the systems underneath them.

Ask an LLM to write a database migration or an authentication flow and the result can look right on the surface. Without the underlying training, it's easy to miss what isn't visible in the code:

• Edge cases in distributed transactions.
• Race conditions under high concurrent load.
• Security vulnerabilities hidden inside generated abstractions.

This is where my early mentors shaped my discipline, and it's where I put my energy today. I ask our teams to understand the why behind every system, not just the what.

When I mentor associate developers, I hold to three rules:

1. Understand the baseline. Know how to trace a request manually through the stack before you ask an AI tool to optimize it.
2. Interrogate the output. Treat AI-generated code with healthy skepticism. If you can't explain every line and its failure modes, it doesn't get merged.
3. Study failure. Learn how systems break in production, not just how they pass unit tests locally.

Bridging strategy and craft

Technical mentorship isn't an HR checkbox. It affects the business directly.

Companies in regulated industries don't hire engineering leaders just to write code. They hire us to connect business strategy to technical execution, and to build platforms that survive audits, data privacy rules, and the reliability bar enterprise customers expect.

Junior developers who get real mentorship grow into senior engineers who understand why the business cares. They learn that software exists to solve commercial problems and meet regulatory requirements, not to chase vanity metrics or clever abstractions nobody asked for.

I write more about this in my other essays on architecture and delivery, but the short version is: push for speed and reliability at the same time, not one at the expense of the other. I want every engineer on the team to see how their technical decisions show up on the bottom line.

Paying it forward

Being a hands-on technical leader means staying out of the ivory tower. Plans that never touch the codebase go nowhere. Code without a plan behind it doesn't go anywhere useful either.

Leadership works the same way. Authority without mentorship just calcifies.

The way I see it, I owe my own mentors a debt, and the only way to repay it is forward: take a chance on someone who shows promise, hand them real architectural problems instead of just bug fixes, and coach them through the mistakes honestly.

• Design real challenges. Give juniors scoped architectural tasks, not just bug fixes.
• Turn code review into teaching. Use pull requests to explain trade-offs and design decisions, not just flag mistakes.
• Model accountability. Own your failures in front of the team, fix them, and talk about what you learned.

The long game

AI makes individual engineers faster. It doesn't make a platform resilient on its own. People do that.

Mentoring junior developers isn't about teaching syntax. It's about passing on the judgment and discipline that keeps software running when it actually matters: when a ledger can't be wrong, when an outage costs real money.

We lift as we climb. The best way to repay the mentors who took a chance on us is to do the same for whoever's next.

If you need engineering leadership that's still hands-on with the code and serious about building the team behind it, let's talk.