Chasing the Southern Cross: Can the Career Vision You Wrote Still Help You Make Choices?

That night, I opened a user complaint email:

"Your system made me lose 3 hours of work data! You engineers don't care about users at all!"

My heart skipped a beat: I had clearly written a data backup feature.

But the moment I opened the operation recording, I fell silent.

The backup button was hidden in a third-level menu;
The icon looked like a trash can;
The error message was just "Error 500".

Technically, I hadn't done anything wrong.

But the user still broke down.

That night, I looked back at the career vision I had written on the Wiki:

"Write clear code and complete requirements independently."

That was what I wrote six months after joining the company.

At that time, I thought that being able to finish a module independently without dragging the team down was the standard of an excellent engineer.

Every time I shipped without bugs, every time my PR got a thumbs-up, every time my boss praised my development speed in the weekly meeting, I would give myself a checkmark.

But now, it just feels glaring.

1. You think you have a sense of direction, but it's just a sense of task completion

Many people write their first career vision the way I did: simple, direct, even quite practical.

But the problem is, this kind of "V0.1" vision only works when you're just starting out.

No matter how clearly you write it, it can only answer one question:

"I want to get this thing done."

But it cannot answer the more critical question:

"Is this thing worth doing?"

I truly realized this difference after completing a project—

My boss praised me for "doubling the performance," but what lingered in my mind was the flowchart on the homepage that users couldn't understand at a glance.

I had done many right things, but I hadn't done "the thing I felt most needed to be done."

After that day, I decided to add a version number to my vision.

It wasn't wrong; it just wasn't enough anymore.

2. The version number system for visions: not an upgrade, but a recalibration

I started from V0.1, and later wrote V0.9, V1.3, V2.0.

I didn't always think it through clearly, and not every version had a dramatic moment—sometimes it was just a small "I can't stand it anymore" instant.

But I would regularly look back and ask myself three questions:

In the most recent choice that made me struggle, did this vision come in handy?
Has it become a mantra that I no longer believe in?
Was there a decision driven by "what the boss thinks" rather than "what I want to achieve"?

Once, I suddenly realized:

I hadn't looked at any user behavior data for two months.

During that period, I was leading a high-performance, high-concurrency refactoring project. Technically it was beautiful, and I received recognition.

But I felt increasingly empty inside.

I opened that vision document and saw the line:

"Let ordinary users accomplish what they truly want more easily and efficiently."

I realized I had drifted off course again.

That was the trigger for me to update to V2.0.

3. Why do we hesitate to upgrade our vision?

It's not that we're lazy, nor that we lack direction.

It's that we're afraid that replacing the old vision would negate the self that endured confusion and burned the midnight oil.

I also had a whole year where I couldn't bring myself to write V1.0.

At that time, I had just been promoted to technical owner and started receiving a lot of user feedback.

I realized that the code I wrote so elegantly and the processes I designed so efficiently were completely incomprehensible and unused in practice.

I wanted to rewrite my vision, but I couldn't get past that mental hurdle.

The phrase "complete requirements independently" was the anchor I clung to when I was anxious about my technical skills. I was afraid that once I let it go, it would be like denying all my efforts.

Until one day, sitting on the bus, I watched a user type the same keyword three times in our system, just because the loading animation wasn't clear enough.

I desperately wanted to rush into the meeting room and say:

"Stop arguing about how elegant the architecture is. Our users are already doubting whether they're stupid."

That night, I went home and wrote down the new vision:

"I am willing to stand in the user's shoes, so they no longer doubt themselves when operating."

4. The real purpose of a vision: not to put it in a PPT, but to help you make choices

Later, I encountered a more realistic scenario:

We had two optimization directions to choose from:

A: Improve the API response time from 500ms to 300ms, which could be written into the quarterly report;
B: Redo a configuration process that confused 80% of users, with no explicit data metrics and requiring cross-departmental coordination.

My boss suggested choosing A.

I hesitated for a long time, and in the end, I also chose A.

After launch, the boss was very satisfied.

But the message in the user group, I still haven't forgotten:

"Why does changing a setting require seven clicks? Is your system designed for ninjas?"

I saved a screenshot of that message and titled it: "Professional shame."

Three months later, I used my weekends to secretly complete the refactoring of option B.

User complaints dropped by 40%, but in my promotion report, I still wrote "optimized API performance."

5. The truth is a bit cruel, but it's even more worth writing down

The hardest part of a vision is not writing it down, but after writing it down:

No one cares;
Many people oppose it;
KPIs don't support it;
The boss thinks you're "too idealistic."

I once rejected a popular project in a review meeting, just because it was too unfriendly to the migration of old users.

I said: "We can't make our early users pay for technical upgrades."

As a result, I was marginalized and rated as "lacking strategic vision."

That project was halted six months later due to user churn, but no one remembered what I had said back then.

Perhaps it was at that moment that I understood:

The moment a vision truly takes effect is often when you stand alone, with no one echoing you, and you have to bear the consequences.

But it is also at that moment that it ceases to be a slogan.

6. A vision is not about who you want to become, but about the kind of person you don't want to turn into—someone who is "not you"

My current vision is V2.3:

"Even if no one reminds me, I am willing to proactively represent the user's perspective."

This sentence doesn't sound that cool, not as grand as "change the world with code."

But every time I read it, I feel the road under my feet is clear.

It's not a vision that makes people admire me; it's a vision that keeps me from regretting.

🌱 A question for both of us:

In a key choice you made recently, did your career vision play a role?

Or have you not opened that document for two years?

Maybe we can stop pursuing a vision that "helps you get promoted,"

and instead write one that, in our most chaotic, most anxious, most easily swept-along moments, makes us pause for a moment, look back, and think:

"Is this the direction I want to go?"

Give your vision a version number.

Even if it's just starting from V0.1, that's enough.

Let's keep writing it together.