You Don't Need a Mentor to Think Like a Senior
What five years of no senior dev taught me about growing on my own
I Expected Mentorship in My Early Career, But…
My first job was at a small startup. The team was around five engineers, all mid-level.
No one was clearly senior. No one had a strong grasp of best practices. We didn’t have structured code reviews, no real onboarding, and definitely no one guiding you on how to grow.
So I learned the way most people do in that situation: by breaking things 💥.
I set production DB password as 12345678 (yes, I did that :P). I shipped buggy features. Incidents occurred. We improved after that. I kept learning from those experiences and started building instincts.
Two years later, I switched companies. The team was about the same size, but the dynamic was familiar. I was the most senior engineer on the team (with two years of experience 😅). I was still running the same playbook: learn through experimentation, figure it out as I go.
And that lasted another three years. I moved, stumbled, and learned.
How I Learned Without Any Senior Dev in the Team
Most engineers I know in that situation wait. They wait for someone to assign them the right task, or tell them the right approach. I didn’t have that option, so I did the only thing left: I started experimenting 🧪.
It turns out that’s exactly what senior devs do anyway.
Plan, Execute, and Adjust with Confidence
Stop waiting for someone to teach you. Start learning from your peers, even if they’re at the same level as you. And go outside your org, because the internet has more senior engineers than any single company ever will.
What actually accelerated my growth was giving myself permission to try things without asking for approval first:
Make a plan, then run the experiment. No senior dev means no one blocking you. I would pick an idea, think through the tradeoff, and just do it.
Invite discussions after. I would share what I tried and what I found with peers. They pushed back, asked questions, and helped me think through gaps I had missed.
One concrete example: I introduced CI into our org during that period. CI tools like Jenkins and TravisCI were already the gold standard for maintainability, but most engineers around me hadn’t adopted it yet.
We implemented it, and it turned out to be a massive improvement for the release process.
But Not Everything Worked as Expected
I also introduced GitHub Issues for project management. It flopped. People migrated back to Google Spreadsheets within a few weeks.
That felt like a failure at first. But it taught me something more useful: how to identify the gap between what a tool offers and what an org actually needs. That framework became an approach I still use today.
The failed experiment gave me more than the successful one did.
If you're not sure whether you're experimenting on the right things, or moving toward a senior role, that's exactly what I help people in Your Path to Senior Engineer. You'll leave with a clearer picture of where to focus.
Having a Mentor Didn’t Go the Way I Expected
In my sixth year, I moved to a new company. For the first time, there was someone on the team who was clearly more senior than me, and willing to invest in my growth.
I Almost Lost My Senior Mindset
Honestly, I didn’t know what to do with having a mentor, even though I finally got one.
My instinct was to defer. He had more experience, more context, and more credibility in the org. So I started following his lead. When he suggested a direction, I took it.
But after a while, I noticed something was off: I found myself simply following his suggestions, but not thinking for myself.
The curiosity that drove me to introduce CI and torun experiments had almost gone. I was doing good work, but I was doing his version of good work.
I realized that in one of my managers’ feedback. Those proactivity and adventure spirit were part of my workflow, but I didn’t possess them anymore. Having a mentor should amplify what we have, but not replace it.
The Right Way to Work with a Mentor
Once I understood that, my approach changed. I stopped bringing him problems to solve. I started bringing him conclusions to challenge.
The difference looks like this:
❌ Before: “How should I approach this project?”
✅ After: “I’m thinking of doing it by X because of Y. Any feedback?”
In the first version, I was outsourcing the thinking. In the second, I was using the mentor as a validator.
The logic is straightforward: If you bring your own thinking into a discussion, you’ll walk out with a sharper version of your own.
Last Words
You don’t need permission to experiment. You don’t need a senior dev to tell you what to try.
Pick one thing in your codebase or workflow this week. Something you’ve been curious about, or something that feels slightly broken. Form a hypothesis. Try it. Reflect on what happens.
And when you do eventually get a mentor, bring your thinking to them first. Use them to validate your ideas, not to generate them.
⭐️ The senior mindset starts the moment you stop waiting for a mentor. Your growth only stagnates if you always wait for one.
If you’re not sure whether you’re building the right habits to reach the senior level, that’s exactly what I help with in Your Path to Senior Engineer, a 1:1 session where we figure out what’s actually standing between you and the senior mindset.
See you in the next post.
Adler from Tokyo Tech Lead