Chasing the Southern Cross: How to Write a Flesh-and-Blood Engineer's Manifesto

For a while, my resume carried that all-too-familiar career objective:

"Dedicated to creating value for users through technology."

Interviewers nodded, HR didn't object, and everyone was used to it. But every time I saw that line, I wanted to roll my eyes: isn't this just the tech world's version of "world peace"? Who doesn't want to create value?

What really made me realize the problem was a project retrospective meeting. I had clearly raised several user experience pain points from user feedback, but a senior engineer on the team shot back:

"Didn't we all agree the OKR was performance optimization? You're going off track here."

At that moment, I was suddenly speechless. My words said "creating value for users," but when value conflicted with metrics, I had no idea how to choose.

I had no manifesto of my own. Only "correct nonsense."

A so-called "engineer's manifesto" is not a motto, but the anchor for your bottom line when making decisions.

It's not written for others to see, but for the future you who is being swept along by reality.

We all know technical choices require tradeoffs, system design requires decisions, and technical debt requires considering opportunity costs—but who decides which side you stand on? You must have your own manifesto, even if brief, even if rough, but it must be able to speak for you in ambiguous situations.

You're not directionless; you just can't articulate "I'm not doing this for that reason"

Often we feel lost because we try to directly define "what kind of person I am," and end up stuck in perfect narratives. The truly useful approach is actually—

Start defining yourself from the antonym.

Like the following:

I don't argue about naming for the sake of elegant code, but to reduce the cognitive cost for those who come after.
I don't aim to make the system as complex as possible, but to make it easy for newcomers to quickly get up to speed and maintain it.
I don't build a feature just because it looks cool, but to save users one extra click.

When you dare to admit "I'm not striving for that," you truly get closer to "I'm actually striving for this."

To write your "flesh-and-blood" engineer's manifesto, try these 3 exercises

Exercise 1: Use the "antonym manifesto" to dismantle correct nonsense

Write down the values you currently say most often, such as:

"Creating value for users"
"Pursuing technical excellence"
"Valuing team collaboration"

Then ask yourself three questions:

If others say the same thing, can I tell how I'm different from them?
What "opposite" behavior can I least tolerate?
Is there a way of saying "I'm not doing it for X, but for Y" that better matches my true motivation?

For example:

"Pursuing technical excellence" sounds great, but if you find yourself often compromising to reduce cognitive load, then your more authentic manifesto might be:

"I'm not writing the most complex architecture, but making sure the team spends less time explaining things in the future."

That's the flesh-and-blood version.

Exercise 2: Use the "5 Whys" to dig into your itch

This is a highly effective way to break through mental blocks.

Take a recent project you particularly wanted to be part of, and ask yourself five times in a row, "Why is this important to me?"

For example:

I volunteered to refactor the customer service system → Why?
- Because the original design often had problems, affecting user experience → Why?
  - Because I saw many users getting angry due to disconnections → Why?
    - Because I don't like users feeling ignored due to technical failures → Why?
      - Because I want users to feel "we care about their time" behind the technology → Why?
        
        Because I believe "respect" can be expressed through code.

That fifth "why" is the prototype of your true professional manifesto.

It's not a grand word, nor KPI-driven, but it will help you choose the subtle right path in many technical decisions.

Exercise 3: Write your "epitaph test"

Imagine an uncomfortable question:

If your career ended today, and your team, colleagues, and users could only describe you in one sentence—what would you want that sentence to be?

"Writes high-quality code"? "Reliable at work"? Or:

"He made me realize for the first time that technical documentation can have a human touch."

Or:

"What she built might not look flashy, but I can always get started with it immediately."

Such a sentence is not written by you; it's the crystallization of value that others feel from your long-term behavior. It's not language, it's frequency.

A warm vision doesn't need to be perfect, but it must help you make choices

Stop letting "correct nonsense" steal your time and emotions. A manifesto that truly stands firm often has these traits:

A bit "unofficial" (showing it's not copied)
Helps you pick a side in dilemmas (showing it has decision-making function)
Still supports you to continue when you fail (showing it connects to your inner values)

It's like a "bias signal"—when you face ambiguous choices, it doesn't tell you what's "right," but it tells you what's "more like me."

Final advice: Vision is not a sentence, but a trajectory you keep writing

Your "engineer's manifesto" won't be achieved overnight.

It may start with a sentence like "I'm not doing it for X, but for Y," then become a version number, then become your default behavior in projects, and finally you may not even need to write it down—others can tell what you're for just by looking at what you do.

Vision is not for persuading others, but for reminding yourself. Reminding you that beyond metrics, promotions, hot topics, and expectations, there is a judgment logic that belongs only to you.

And that judgment logic is hidden in your "slightly non-standard, but especially true" engineer's manifesto.