"The Company Never Planned to Develop Me!" 3 Unorthodox Paths to Self-Directed Growth

Hutouchui has chatted with many friends, and people often complain that their slow growth is because no one mentors them, because they haven't met a leader like the multiplier I mentioned in my previous article.

They see others join a team with mentors, code reviews, and PPT opportunities; meanwhile, I'm like a free-range vegetable seedling, growing by the weather and by fate.

This is also an undeniable fact of the workplace: (many) companies aren't refusing to develop you; they simply have no time to manage you. Whether you can grow depends entirely on secretly fertilizing yourself.

The following 3 tricks are the self-multiplication methods I stumbled upon during those days without a mentor, without sponsorship, without being looked after. No chicken soup, all practical.

1. If no one teaches you judgment, dissect other people's judgment yourself

When I first entered the workplace, my code was always criticized by my TL, who said my thinking wasn't mature enough and wasn't object-oriented enough.

I felt wronged: you don't explain why, so how am I supposed to become mature?

Until one day I started doing a git diff between his rewritten commit and my original, studying every line to understand why he changed it (actually, back then there was no git; I'd probably get beaten up if I mentioned CSV and SVN).

• How can the Object design be more reasonable?
• Which judgment is more robust?
• Why choose the approach that better fits the current business scale?
• Which solution looks elegant but hides coupling risks?

This isn't review; this is dissecting cognitive models.

Half a year later, he posted in the group for the first time: "This solution is quite well thought out." It wasn't that he changed; it was that I had already run through several versions of the approach in advance.

▌What you can do right now:

• Find the most recently modified PR by your Leader, run git diff commit1 commit2
• For each difference, try to answer three questions: Why was it changed this way? Would I have done it this way? Are there other ways to write it?

2. If no one gives you projects, bite into the scraps and create impact

For a while, I was only assigned a scheduled task module. Others were building platforms and doing recommendations; I was fixing log errors.

But I didn't want to lie flat.

I started analyzing which steps this task often failed at and how inefficient the retry logic was. I spent two weeks rewriting it into a parallel task chain, reducing the runtime from 9 minutes to 3 minutes and the failure rate by 80%.

My Leader said, "I never had time to look at this module; I didn't expect you to handle it."

We don't necessarily have to be the protagonist, but we can first play the role of the behind-the-scenes core tool person well.

▌What you can do right now:

• Find a neglected small module, list the failure records from the past month, and see if it can be reused or optimized
• Even just adding a meaningful log field to make online troubleshooting faster is impact

3. If no one gives you exposure, create visibility scenarios yourself

When I first started, I barely spoke in meetings, afraid of saying something wrong. Until I shared my experience troubleshooting a small bug once, and my Leader suddenly said, "I hadn't thought of it from that angle."

It turned out I wasn't unrecognized; it was that no one knew what I was doing or how I was thinking.

Later I developed a few small habits:

• Write detailed descriptions and reasoning in PRs
• During tech sharing, proactively say I recently encountered a pitfall and share how to avoid it
• Help answer questions in the group more often, without rushing to answer, only sharing experiences I've had

Gradually, everyone assumed: "For the module you're responsible for, ask you first if there's a problem." After all, if no one knows what you've done, it's equivalent to doing nothing.

▌What you can do right now:

• Before each weekly sharing, write down 2 key actions from this week + 1 small reflection
• Write a troubleshooting FAQ for the module you're responsible for and post it to the team wiki
• Find the most easily overlooked item in your PR and add logic explanations and performance metric comparisons

Epilogue: Don't wait for others to give you a map; learn to build a compass first

Three years later at a class reunion, someone was still complaining that their leader never taught them and they could never get core projects. Meanwhile, I was already leading people.

Growth is never arranged; it is forced out by yourself.

We can say the company has no culture, but we can't not grow our own brains.

We can be without a mentor, but we cannot be without cognitive leverage.