Finding the Right People to Learn From: Why Your Network is Your Net Worth

I spent my first year as a developer learning from the wrong people.

Not bad people. Just the wrong people for where I was and where I wanted to go.

My learning sources:

• YouTube tutorials from people who’d been coding for 6 months
• Reddit advice from anonymous strangers
• A bootcamp instructor who’d switched careers 18 months prior
• Other junior developers at my skill level

What I learned: How to copy-paste solutions. How to feel productive while making minimal progress. How to stay stuck in tutorial hell.

What I didn’t learn: How to think like an engineer. How to solve novel problems. How to actually get better.

Then I met David.

David had 20 years of experience. He’d built systems that served millions of users. He’d failed, recovered, and built better systems.

I cold-emailed him after reading one of his blog posts.

Me: “Can I buy you coffee and ask about your career?”

Him: “Sure. Thursday at 3?”

That one hour changed everything.

Not because he gave me some secret trick or magic framework.

But because he asked better questions than I’d ever heard.

When I showed him my code, he didn’t say “This is wrong, do it this way.”

He said:

• “What happens to this service if the database goes down?”
• “How would you test this without hitting the real API?”
• “What would this look like at 100x scale?”

I couldn’t answer any of them.

But now I knew what questions to ask myself.

That’s the difference between learning from the right person and the wrong person.

The wrong person gives you answers.

The right person rewires how you think.

The Mentor Selection Matrix

Not all teachers are created equal. And the “best” teacher isn’t always the right one for you, right now.

Here’s how to think about it:

The sweet spot: 2-3 levels ahead.

Why?

Too close (peers): They don’t know much more than you. You’re learning from shared ignorance.

Too far (idols): They’ve forgotten what it’s like to be you. Their advice assumes knowledge you don’t have.

Just right (2-3 levels ahead): They remember your struggles. They’ve recently solved the problems you’re facing. They can translate expert knowledge into language you understand.

Story: The Three Mentors

Let me tell you about three people who tried to teach me React.

Mentor 1: Jake (6 months ahead of me)

Jake’s advice: “Just use useState for everything. It’s the easiest.”

What I learned: How to write bad React code that works.

The problem: Jake was teaching me his current understanding, which was itself flawed. I copied his bad habits.

Result: I wrote terrible React apps for 6 months before realizing useState isn’t always the answer.

Mentor 2: Sarah (Senior engineer, 8 years experience)

Sarah’s advice: “Think in terms of data flow. Where does state live? How does it flow down? How do events bubble up?”

What I learned: How to architect React applications properly.

The key difference: Sarah taught me principles, not just patterns.

Result: I could apply those principles to new problems I’d never seen.

Mentor 3: Dan Abramov (React core team)

Dan’s content: Deep dives into React internals, fiber architecture, concurrent mode.

What I learned: Fascinating stuff. Way over my head.

The problem: The gap was too big. I didn’t have the foundation to understand what he was talking about.

Result: Interesting to watch, but didn’t change how I coded day-to-day.

The lesson:

Jake was too close. Dan was too far. Sarah was exactly right.

Find your Sarah.

The Five Types of People You Need

You don’t need one mentor. You need a constellation of different people who serve different purposes.

1. The Guide (2-3 levels ahead)

Role: Direct mentorship, tactical advice, code reviews.

What they give you:

• “Here’s how I’d solve this specific problem”
• “This is the mistake I made when I was at your level”
• “Try this approach, here’s why”

How to find them:

• Senior engineers at your company
• People active in communities you’re part of
• Authors of blog posts that resonate with you
• Open source maintainers of tools you use

How to approach them:

Bad: “Can you be my mentor?” (vague, high commitment)

Good: “I read your post on API design. I’m working on a similar problem. Could I show you what I’ve built and get your feedback?” (specific, low commitment, shows you’ve done work)

2. The Model (5+ levels ahead)

Role: Inspiration, vision, showing you what’s possible.

What they give you:

• Proof that the path exists
• Standards to aspire to
• Long-term perspective

Examples:

• Industry leaders you follow on Twitter
• Conference speakers
• Authors of books that changed how you think

How to learn from them:

• Read everything they write
• Watch their talks
• Study their work
• Note the questions they ask, not just the answers they give

Important: Don’t expect them to mentor you directly. Learn from their public work.

3. The Peer (same level as you)

Role: Accountability, shared struggle, motivation.

What they give you:

• “I’m struggling with this too”
• “Let’s learn together”
• Someone to pair program with
• Shared accountability

How to find them:

• Study groups
• Bootcamp cohorts
• Online learning communities
• Local meetups

Why they matter:

Learning alone is hard. Learning with someone at your level makes it sustainable.

You motivate each other. You hold each other accountable. You celebrate small wins together.

4. The Beginner (behind you)

Role: Teaching reinforces your learning.

The Feynman Technique: You don’t really understand something until you can explain it simply.

What teaching gives you:

• Forces you to clarify your understanding
• Reveals gaps in your knowledge
• Builds communication skills
• Feels good (helping others is rewarding)

How to do this:

• Answer questions on Stack Overflow
• Write beginner-friendly tutorials
• Mentor someone one level behind you
• Explain concepts to non-technical friends

5. The Adjacent Expert (different domain)

Role: Cross-pollination of ideas.

The insight: The best ideas come from applying patterns from one domain to another.

Examples:

• You’re a backend engineer? Learn from frontend engineers.
• You’re a developer? Learn from designers, product managers, data scientists.
• You write code? Learn from writers, architects, chefs.

Why this matters:

Everyone in your field has the same blind spots.

Someone from a different field has different blind spots.

Learning from them reveals patterns you’d never see otherwise.

Story: How I Found My First Real Mentor

I tried the traditional advice: “Find a mentor at your company.”

The problem: My company was a startup. Five engineers. Nobody had time for formal mentoring.

So I went unconventional.

I made a list of 20 engineers whose blog posts I loved.

My approach:

1. Read everything they’d written
2. Pick one specific post that resonated
3. Build something inspired by it
4. Email them: “I read your post on X. It inspired me to build Y. Here’s what I learned. I have one question about Z.”

Response rate: 40% replied. 8 out of 20.

Of those 8:

• 3 answered my question
• 2 asked follow-up questions
• 3 turned into ongoing conversations

One of those three became a mentor for the next two years.

Key lessons:

1. Demonstrate that you’ve done the work. Don’t ask for general advice. Ask specific questions about something you’ve already tried.

2. Show that you value their time. One specific question, not “Can you teach me everything?”

3. Make it easy to say yes. Low commitment, high specificity.

4. Provide value back. Even as a beginner, you can:

• Share interesting articles you find
• Introduce them to someone in your network
• Write a blog post expanding on their ideas (with credit)
• Contribute to their open source projects

Mentorship isn’t transactional, but it should be reciprocal.

The Red Flags: Wrong People to Learn From

Not all teachers are good for you. Here’s who to avoid:

Red Flag 1: The Confidence Without Competence

The pattern: They speak with absolute certainty. No nuance. No “it depends.”

Example: “Never use X. Always use Y. Anyone who does Z is an idiot.”

Why it’s bad: Real expertise comes with nuance. Blanket statements reveal shallow understanding.

What to look for instead: “X works well for A, but if you’re dealing with B, consider Y.”

Red Flag 2: The Status Player

The pattern: They care more about looking smart than helping you learn.

Signs:

• They make you feel stupid for asking questions
• They use jargon unnecessarily
• They dismiss your ideas without explanation
• They’re more interested in proving their intelligence than transferring knowledge

What to look for instead: Someone who makes complex things simple, not simple things complex.

Red Flag 3: The Outdated Expert

The pattern: They achieved expertise 10 years ago and stopped learning.

Example: The developer who insists on patterns from 2010 that no longer apply.

Why it’s bad: Tech changes fast. Yesterday’s best practices are today’s anti-patterns.

What to look for instead: Someone who’s actively learning and updating their mental models.

Red Flag 4: The One True Way Evangelist

The pattern: They believe their approach is the only correct approach.

Example:

• “TDD is the only way to write quality code.”
• “If you’re not using microservices, you’re doing it wrong.”
• “Functional programming is superior to OOP in every way.”

Why it’s bad: Software is all about tradeoffs. Anyone who doesn’t acknowledge tradeoffs doesn’t understand the domain deeply.

What to look for instead: “Here’s when I use X, here’s when I use Y, and here’s how I decide.”

Red Flag 5: The Bitter Expert

The pattern: They’re burned out, cynical, and will drain your enthusiasm.

Example: “Everything in this industry is terrible. All code is bad. Everyone is incompetent.”

Why it’s bad: Their negativity is contagious. Learning requires optimism and energy.

What to look for instead: Someone who’s realistic but still excited about the craft.

Practical Strategies for Finding the Right People

Strategy 1: The Coffee Chat Campaign

The method:

1. Identify 10 people 2-3 levels ahead of you
2. Research them (blog, Twitter, GitHub)
3. Find one specific thing they’ve done that resonates
4. Send a personalized email:

Template:

Subject: Quick question about [specific thing]

Hi [Name],

I read your post on [specific topic]. The part about [specific insight]
really clicked for me.

I'm working on [specific project] and I'm trying to figure out [specific
problem]. I tried [what you've tried], but [obstacle you hit].

Would you have 15 minutes for a coffee chat (virtual or in-person) to
discuss this? I'd love to hear how you'd approach it.

Either way, thanks for writing that post. It was helpful.

[Your name]

Why this works:

• Specific, not generic
• Shows you’ve done work
• Low time commitment
• Easy to say yes

Success rate: About 30-40% will say yes.

Strategy 2: The Public Learning Strategy

The method:

1. Learn something
2. Write about it publicly (blog, Twitter, LinkedIn)
3. Tag or mention people whose work influenced you
4. Ask for feedback

Why this works:

People love seeing their ideas spread. They’re likely to engage with you.

Plus: You’re building your own audience, which creates reciprocal value.

Strategy 3: The Open Source Contribution Path

The method:

1. Find an open source project you use and respect
2. Start with tiny contributions (docs, bug reports, small fixes)
3. Engage thoughtfully in issues and PRs
4. Build relationship with maintainers over time

Why this works:

You’re providing value (contributions) while learning from experts (maintainers).

Bonus: You get code review from experienced engineers, which is incredibly valuable.

Strategy 4: The Community Engagement Approach

The method:

1. Join communities where experts hang out (Discord, Slack, forums)
2. Don’t lurk. Participate.
3. Answer questions you know
4. Ask good questions (specific, showing work you’ve done)
5. Build reputation over time

Why this works:

You’re demonstrating competence and curiosity. Experts notice and engage.

Strategy 5: The Reverse Mentoring Offer

The method:

Find someone senior in one domain but junior in another.

Offer to teach them something you know in exchange for learning from their expertise.

Example:

You: Backend engineer who knows Docker well

Them: Senior frontend engineer who wants to learn DevOps

The exchange: You teach them Docker and deployment. They teach you frontend architecture.

Why this works:

It’s reciprocal from day one. Neither person feels like they’re “asking for a favor.”

The Mentor Relationship Lifecycle

Mentorship isn’t forever. Here’s how it typically evolves:

Phase 1: Initial Contact (Months 1-2)

Low commitment. One-off conversations. Feeling each other out.

Phase 2: Regular Check-ins (Months 3-6)

Monthly coffee chats. You bring specific problems. They provide perspective.

Phase 3: Active Mentorship (Months 6-18)

More frequent interaction. Code reviews. Career advice. Strategic thinking.

Phase 4: Peer Transition (Months 18-24)

You’ve learned a ton. The gap has closed. The dynamic shifts.

Phase 5: Ongoing Friendship

You’re now peers in different areas. You learn from each other.

The key insight: Good mentorship has a natural end date.

If you’ve learned well, you eventually outgrow your mentor in some areas.

This isn’t failure. This is success.

And now you find new mentors for your new level.

Story: The Mentor I Outgrew

Remember David, from the beginning of this post?

For 18 months, he was the perfect mentor.

He taught me:

• How to think about system design
• How to debug production issues
• How to communicate with non-technical stakeholders
• How to make career decisions

But around month 20, something shifted.

I was working on distributed systems problems. David’s expertise was in monoliths.

His advice was still valuable, but less directly applicable.

I needed a new mentor for this new phase.

This felt awkward at first. Was I abandoning him? Being ungrateful?

No. This was the natural evolution.

David and I stayed friends. We still grab coffee quarterly.

But I found a new mentor (Elena) who specialized in distributed systems.

And David found a new mentee who was at the level where he could be most helpful.

Everyone wins.

Maintaining Mentor Relationships

Once you’ve found the right people, don’t let the relationship fade through neglect.

Tactic 1: The Regular Update

Send periodic updates (monthly or quarterly) even when you don’t need anything.

Template:

Quick update on what I've been working on:

1. Shipped [project] - used the approach you suggested for [problem]
2. Started learning [new skill] - inspired by our conversation about [topic]
3. Hit a wall on [challenge] - still thinking through it

Thanks again for your guidance. Hope you're well!

Why this works: Keeps you on their radar without asking for anything.

Tactic 2: The Share and Credit

When you learn something useful from someone else, share it with your mentor.

“I read this article on X and immediately thought of our conversation about Y.”

Why this works: You’re providing value. You’re showing you’re learning. You’re keeping the relationship active.

Tactic 3: The Gratitude Loop

When their advice leads to success, tell them.

“Remember when you suggested I try X? It worked. Here’s what happened.”

Why this works: Positive feedback is rewarding. They’re more likely to continue investing in you.

Tactic 4: The Introduction Offer

If you can connect them to someone valuable, do it.

“I met someone working on X, which I know you’re interested in. Want an intro?”

Why this works: You’re not just taking. You’re contributing to their network.

When You Become the Right Person

At some point, you become the person someone else should be learning from.

This is a responsibility.

How to Be a Good Mentor

1. Remember what it was like to not know.

Don’t skip steps. Don’t assume knowledge. Explain like you’re talking to past-you.

2. Ask questions, don’t just give answers.

Bad: “You should use Redis for caching.”

Good: “What caching options have you considered? What are the tradeoffs?”

3. Make them think, not just copy.

Bad: “Here’s the code, paste it in.”

Good: “Here’s the approach I’d take and why. Try implementing it and show me what you come up with.”

4. Be honest about your limitations.

“I don’t know” is a complete sentence.

“I don’t know, but here’s how I’d figure it out” is even better.

5. Give them space to fail.

Don’t solve every problem for them. Let them struggle (productively).

The struggle is where the learning happens.

Final Thoughts

I wasted a year learning from the wrong people.

Not because they were bad teachers.

Because they were the wrong teachers for me, at that time.

Jake (6 months ahead) couldn’t teach me what he didn’t know.

Dan Abramov (expert level) was too far ahead to be directly helpful.

Sarah (2-3 levels ahead) was exactly right.

And that changed everything.

Now, three years later, I have:

• 2 active mentors (for distributed systems and career growth)
• 5 peers I learn with regularly
• 3 people I’m mentoring
• 10+ “models” I learn from publicly

I didn’t find these people by accident.

I sought them out deliberately.

I provided value before asking for it.

I maintained the relationships intentionally.

Your growth is limited by who you learn from.

Choose wisely.

Seek people 2-3 levels ahead.

Build relationships, not transactions.

Provide value, not just asks.

And when you become the right person for someone else, pay it forward.

The quality of your teachers determines the quality of your learning.

So go find your Sarah.

Who’s someone 2-3 levels ahead of you that you’d love to learn from? What’s stopping you from reaching out? What’s one specific question you could ask them?