The Illusion of Mastery
I've been writing code professionally for six years now. I've built logistics platforms, real-time messengers, and enterprise systems. I've optimized performance, designed distributed architectures, and debugged impossible problems at 2 AM.
I thought I knew how to code.
Then I started mentoring junior developers, and everything changed.
The Moment of Humility
My first mentoring session was a disaster. A junior engineer asked me to review their code, and I immediately started pointing out everything wrong with it. "This is inefficient." "This isn't idiomatic." "You should do it this way instead."
I was confident. I was correct. And I was completely useless.
The junior developer nodded along, made the changes I suggested, and then came back the next day with the exact same mistakes. They hadn't understood why my suggestions were better. They had just mechanically applied my fixes.
I had failed as a mentor. And I had failed as an engineer.
What I Realized
Here's the uncomfortable truth I discovered: knowing how to do something and knowing how to explain it are completely different skills. I could write clean code instinctively, but I couldn't articulate why it was clean. I could design elegant systems, but I couldn't teach the principles behind that elegance.
That's when I realized something profound: if you can't explain something simply, you don't really understand it.
"My mathematics professors at Yogyakarta State University were the best teachers I ever had. Not because they were brilliant—but because they could take abstract concepts and make them tangible. They could strip away complexity until only the essential truth remained. That's what I needed to learn how to do."
The Humble Experiment
I decided to change my approach. Instead of just reviewing code, I started asking questions:
"Why did you choose this approach?"
"What problem are you solving here?"
"Can you walk me through your thought process?"
And I listened. Really listened.
I started explaining concepts using analogies from my math background. A queue? That's a first-in-first-out data structure, like a line at a grocery store. A hash map? That's a function that maps keys to values—just like a mathematical function. A race condition? That's the observer effect in quantum mechanics (okay, maybe that one was a stretch).
But the best part? When I explained things to others, I understood them better myself.
The Unexpected Benefits
The more I mentored, the more my own code improved. Here's what I discovered:
1. Simplicity is harder than complexity. When you have to explain your code to someone else, you naturally make it simpler. You remove clever tricks. You choose clarity over brevity. Your code becomes more maintainable because it's designed to be understood.
2. Naming matters more than you think. When you're mentoring, you realize how much time is wasted on confusing variable names and ambiguous function signatures. You start naming things with intention—because you know someone else will have to understand them.
3. Documentation is a teaching tool. I stopped writing documentation as a chore and started writing it as a lesson. I explained not just what the code does, but why it does it. I included examples. I anticipated questions. My documentation became better because I was writing it for a student, not just for compliance.
4. Testing teaches you about design. When a junior developer asks "how do I test this?" and you can't answer, you've discovered a design problem. Hard-to-test code is poorly designed code. Mentoring made me obsessive about testability.
The Ripple Effect
The most surprising outcome wasn't my own improvement—it was watching the junior developers surpass me.
One of my mentees, after just six months, proposed a complete redesign of our order processing pipeline. It was elegant, efficient, and scalable. I would never have come up with it because I had been doing things the same way for years.
That's the beauty of mentorship: it's not about making copies of yourself. It's about helping others become better than you.
"To me, that's the true measure of mastery. It's not how much you know. It's how many people you've helped learn. It's not how many problems you've solved. It's how many problem-solvers you've created."
My Advice to Every Engineer
If you've been coding for a while, mentor someone. Even if you don't feel ready. Even if you think you don't have much to offer.
Start small. Review code. Explain a concept. Share a resource. You don't need to be a senior architect to help someone who's a few steps behind you.
Be curious. Ask questions. Listen to the answers. Every junior developer has something to teach you—maybe a fresh perspective, a new tool, or just a reminder of why you love this work.
Be humble. You'll make mistakes. You'll give bad advice. You'll confuse people. That's okay. Acknowledge it, learn from it, and keep going.
Measure your success differently. Don't track how many bugs you fixed. Track how many bugs your mentees fixed on their own. Don't count the lines of code you wrote. Count the lines of code your mentees wrote confidently.
The Real Reward
Six years ago, I thought success was about knowing everything.
Now I know it's about helping others find their own answers.
Every time I see a junior developer solve a problem on their own, I feel more satisfaction than any bug fix or performance optimization ever gave me. Because that's not just code—that's confidence. That's growth. That's the next generation of engineers learning to think like problem-solvers.
And honestly, that's the best part of this job.
So if you're reading this and thinking "I should mentor someone" — stop thinking. Just do it. Find a junior developer. Offer to help. Share what you know.
Trust me. You'll learn more from them than they'll ever learn from you.