Learn From Those Who Came Before

As steel sharpens steel, so one person sharpens another. The veterans have wisdom. Don't reinvent the wheel.

The Wheel Has Been Invented

That problem you're wrestling with? Someone solved it twenty years ago. They wrote a book about it. The book is still in print because the solution still works.

That pattern you're discovering? It has a name. Knowing the name lets you talk about it, search for it, recognize it in the wild.

That mistake you're about to make? Someone made it before you. They wrote a post-mortem. They gave a conference talk. They're trying to save you the pain.

Your job isn't to be original. Your job is to solve the problem. If the solution already exists, use it. Save your creativity for the problems that actually need it.

Finding Mentors

Mentors aren't assigned. They're cultivated.

What makes someone a mentor:

• They've done what you're trying to do
• They're willing to share what they learned
• You respect their judgment
• They'll tell you when you're wrong

How to find them:

• Look at who you already know. The senior engineer on your team. The architect who always asks good questions. The person whose code you actually enjoy reading.
• Ask questions. Real questions, not "can you teach me everything." Specific questions about specific problems.
• Listen to the answers. Actually listen. Don't argue. Don't defend. Take notes.
• Come back with what you tried. Show you did the work.

How to keep them:

• Respect their time. Come prepared.
• Don't ask questions you could answer with a search.
• Report back on outcomes. "You suggested X, I tried it, here's what happened."
• Thank them. Specifically. "That thing you said about Y changed how I think about Z."

Mentorship is a relationship, not a transaction. Invest in it.

Being Mentored

Some people are bad at being mentored. Don't be one of them.

Bad mentee behaviors:

• Asking for advice, then arguing with it
• Asking the same question repeatedly
• Not doing the work between conversations
• Treating every suggestion as optional
• Expecting the mentor to solve your problems for you

Good mentee behaviors:

• Showing up prepared with specific questions
• Taking notes
• Trying things before asking for help
• Reporting back on what you tried
• Being honest about what you don't understand
• Doing the reading

The deal: They give you their time and experience. You give them your effort and attention. If you're not holding up your end, don't waste their time.

The Canon

There's a body of knowledge that transcends languages, frameworks, and trends. The fundamentals. The books that are still relevant decades after publication.

You should know them.

Not because someone will quiz you. Because the ideas are load-bearing. They show up everywhere. Understanding them once means recognizing them forever.

Start here:

• Practical Object-Oriented Design in Ruby by Sandi Metz (design principles that transfer)
• Test Driven Development: By Example by Kent Beck (the discipline)
• Refactoring by Martin Fowler (the moves)
• A Philosophy of Software Design by John Ousterhout (complexity as the enemy)

Then:

• Growing Object-Oriented Software, Guided by Tests by Freeman & Pryce (outside-in TDD)
• Working Effectively with Legacy Code by Michael Feathers (the real world)
• Designing Data-Intensive Applications by Martin Kleppmann (systems)

Read one. Apply it. Read the next. Don't rush. The goal isn't to finish the list. The goal is to internalize the ideas.

See the full Canon in the appendices.

Recognizing Solved Problems

Half the job is recognizing that you've seen this before.

Signs you're looking at a solved problem:

• It feels fundamental (authentication, caching, queuing, search)
• Other companies have the same problem at scale
• There are multiple competing solutions
• The solutions have been stable for years

What to do:

1. Name the problem. "This is a pub/sub problem." "This is a rate limiting problem."
2. Research existing solutions. Libraries. Services. Patterns.
3. Understand the tradeoffs. Why are there multiple solutions? What does each optimize for?
4. Choose. Don't build unless you have a compelling reason.

When to build your own:

• The existing solutions don't fit your constraints (rare)
• The problem is core to your business (rare)
• You're learning (fine, but know that's the goal)

Building from scratch feels productive. It usually isn't. You're trading known solutions for unknown bugs.

Standing on Shoulders

Every line of code you write sits on top of millions of lines written by others.^[1] Languages. Compilers. Operating systems. Networks. Protocols. Libraries.

You didn't invent any of it. You don't have to.

This is a gift. Accept it. Use it. Build on top of it.

Your contribution is the next layer. The thing only you can build because only you understand this problem in this context for these users. That's where your originality matters.

Everything else? Let the giants carry you.

The Obligation

You received. Now you give.

The veterans who wrote the books, gave the talks, answered the questions on Stack Overflow, and reviewed your first PR did not have to. They did it because someone did it for them.

The chain continues through you.

Ways to give back:

• Answer questions. Even basic ones. Especially basic ones.
• Write things down. Blog posts. Internal docs. Comments in code.
• Review thoroughly. Not just "LGTM." Actually review.
• Share what you learned. The hard-won lessons.
• Be patient with beginners. You were one.

You don't have to be an expert to teach. You just have to be one step ahead. The thing you learned last month is exactly what someone needs to learn today.

Steel sharpens steel. Be the steel.

The veterans have wisdom. The books have answers. Your job is to find them, learn them, and pass them on.