Let me start with a few facts about myself. I am hairy, dark-skinned, 167 centimeters tall, and losing my hair. I chose none of these. They arrived without asking my opinion, moved in, and showed no intention of leaving. Probability explains this well enough: I was born in Southwest China to short parents, and among a crowd of short relatives I came out on the shorter side. Genetics is real, and it is not polite about it.

When I wear shorts in summer, my legs look like a forest pending inspection. When I stand against a white wall in a photo, I always come out darker than I imagined, as if the camera holds a private opinion about me. As for my hair: hair on someone else's head is called a hairstyle. Hair in my sink is called data. I say this not entirely out of self-mockery; there is some statistical literacy in it too.

All of these things once made me feel inferior, and I tried to fix every one of them. The process went roughly like this: search for solutions, order the tools, and finally discover that the problem was never under my jurisdiction. This is how people with an engineering background handle things. I admit it is not elegant, but I cannot think of a more elegant way.

People want to edit their factory settings

When I was young, I believed that with enough effort, a person could modify himself into a more acceptable version. Looking back, this belief was a bit like thinking that if you write enough code, the hardware will improve on its own.

So I researched hair removal, skin whitening, height growth, and hair loss treatment. My attitude toward my body resembled my attitude toward a malfunctioning computer: wherever something looked wrong, I wanted to open it up. Unfortunately, a body is not a computer. It cannot be reinstalled, and it cannot be restored to factory settings. Worse still, after careful analysis, the so-called factory settings turn out to be exactly where the problem is.

I did write some shabby code in my youth. As far as I know, when software breaks you can debug it; when hardware breaks you can only accept your fate. Height, skin color, and hair follicles all belong to hardware, the kind that does not accept returns.

None of these traits arrived democratically. There was no vote, no hearing; they simply took office. For a long time I refused to accept this: why can't a person choose his own appearance? Later I figured it out. I cannot even decide what time I wake up in the morning. Wanting to negotiate with follicles and bones on top of that is clearly overestimating myself.

Insecurity is a long interrogation

The frightening thing about insecurity is not that it makes you feel inadequate. It is that it keeps you ready to confess, at any moment, exactly why you are inadequate.

Other people are not looking at you, but you have already looked on their behalf. Other people are not laughing, but you have already laughed on their behalf. The elevator mirror lights up, and the interrogation begins: are the leg hairs too conspicuous, is the face too dark, am I a head shorter than the crowd, has the hairline retreated again. Anyone subjected to daily hearings like this would crack, let alone an ordinary, unusually hairy man.

The meanest part of this interrogation is that it never reaches a final verdict. I later realized that body anxiety is a petty creditor: the moment you pay off one debt, it issues a new invoice under a different name. Today it dislikes your skin; tomorrow your height. Today you have too much hair; tomorrow too little. It has no interest in solving any problem. It only needs you to stay in debt.

A person who constantly feels he owes the world a better body cannot get on with his life properly. I have known many such people, including my former self.

Trying to change taught me the boundary

Let me state clearly: I am not against change. What can be changed may of course be changed. A cleaner haircut, some exercise, sunscreen, scientific methods against hair loss—there is nothing wrong with any of these. A large part of civilization exists precisely so that people do not have to leave everything to fate.

The problem is that some changes solve problems, while others are taxes paid to shame. The two look alike but differ entirely in nature, and you can only tell them apart by trying.

I tried them all. In the end I had to admit: some things can be optimized a little, but the underlying logic cannot be rewritten. My height will not become 180 cm no matter how sincerely I search. My skin will not exchange itself for a new shade because I resent it. My hair will not report back for duty in formation because I reason with it earnestly in the shower. I reached this conclusion by induction. The sample size is sufficient; the conclusion is reliable.

Accepting this fact brought me no joy at all. Real acceptance is never graceful. It does not arrive with a sunset and a soundtrack. It is more like a man who has exhausted himself, sits down on the ground, and says: fine, this will do for now.

Acceptance does not mean liking everything

For a while, I misunderstood what it meant to make peace with myself. I thought it meant loving every hair, every inch of skin, every centimeter of height. Later I found this demand too high, and too false. There is no need to package every flaw as a gift. A gift at least comes with a ribbon. Hair loss does not.

Russell said that diversity is essential to happiness. I believe this. But believing it is one thing; having it apply to yourself is another. Knowing that diversity is good, and cheerfully accepting that you happen to sit on the "diverse" end of it, are separated by quite a few years.

Acceptance is not suddenly deciding that you are perfect. It is admitting that you are not, while refusing to spend the main energy of your life prosecuting that fact. I may dislike my body hair without hating summer. I may dislike my skin without avoiding cameras. I may admit that 167 is not tall without shrinking automatically next to taller people. I may take my hair loss seriously without entering every fallen strand into my personal history of fate.

This is not a victory. It is a ceasefire. A ceasefire is already good enough. A person has too much to do in one lifetime to fight a daily civil war against his own skin, bones, and follicles.

A person is not a medical form

The body matters, of course. No one can pretend not to have one, because hunger growls, fatigue hurts, and the hair that falls in the shower reminds you of reality in very concrete terms.

But a person cannot be just a medical form either.

If you break me down into indicators—hairy, dark, 167, prone to hair loss—I do look like an unimpressive product specification. But that is not how a person is meant to be used. A person has his own way of speaking, his habits of doing things, the things he loves, the sharp remarks he manages to swallow, and the sincere words he finally says. None of these can be measured with a ruler, so none of them appear on a medical form. What the form leaves out is not necessarily unimportant. As far as I know, the most important things are generally not on it.

These traits of mine once made me feel inferior to others. They are still here, but their jurisdiction has shrunk. They can still affect my photos, my clothes, my hairstyle, and my mood, but they no longer decide whether I deserve to live well.

The peace I can manage is roughly this: I do not sanctify what I cannot change, and I no longer humiliate it either. I am still hairy, still dark, still 167, still worried about my hair. But I no longer intend to put myself in the defendant's chair.

It is hard enough for a person to arrive in this world at all. If he must first pass an appearance review of his own making before being permitted to live at ease, that would be unreasonable. I did not figure this out early. Fortunately, I did not figure it out too late either.

When work gets busy, I often write better. The best example was a small bug in an article summary: the mobile card left a blank line, and I found the root cause in the length check. The fix was tiny, but it gave me a real post.

Busy work filters topics

The most common excuse for not creating content is not having enough time. I have used it myself.

But limited time is not always a disadvantage. It pushes away broad topics that sound useful but stay vague.

You stop writing "how to improve productivity." You start writing "how I reduced one recurring task from 30 minutes to 5 minutes this week."

The first one sounds like an opinion. The second one is experience.

Creators do not always need more time. They need more specific problems.

Urgent problems are real material

If you are busy, you are probably dealing with real tasks every day.

Those tasks create concrete friction:

• Which workflow wastes the most time
• Which tool feels awkward
• Which sentence needs to be explained three times
• Which decision keeps circling back
• Which mistake you just made and others may repeat

That friction is content material.

People with plenty of empty time often start from "what do I want to say?" Busy people start from "what did I just solve?"

The second starting point is better.

Short time forces practical writing

If you only have 30 minutes to write, you have little room for filler.

You only need to answer three questions:

• What problem did I face?
• How did I solve it?
• Why is this useful to someone else?

That is enough.

An article does not need every background detail or the full theory. If it explains one concrete problem and leaves behind one reusable method, it already has value.

Do not chase completeness

Many people fail to publish not because they lack time, but because they want every piece to feel complete.

When you are busy, completeness is the first thing to drop.

You can write one observation, one workflow, one judgment, or one failure case. A short piece is fine if the information density is high.

For example:

• Why a tool does not fit your workflow
• Why a prompt failed
• Why a project was delayed
• Why a decision turned out wrong
• Why a small change saved a lot of time

Each one can become a standalone post.

Turn work into notes

The best material is not in a topic list. It is inside your work.

Track three types of notes:

• Problems you just solved
• Mistakes you just made
• Methods you just changed

Do not wait until the weekend. Details fade quickly.

The note does not need to be complete. One sentence is enough: what happened, why it got stuck, and how you handled it.

When you write, expand that sentence.

Busy people need a fixed structure

When you are busy, do not design a new structure for every post.

Use a simple fixed format:

1. State the problem
2. Name the old misconception
3. Explain the new approach
4. Define where it applies

A fixed format reduces startup cost. You do not need to figure out the article first. You only need to put real experience into a stable container.

Writing does not have to start from zero every time.

Being busy is not the blocker

Being busy reduces writing time, but it can improve topic quality.

You are not writing imagined problems. You are writing problems that just happened. You are not giving polished advice. You are sharing methods that were just tested.

If you always feel too busy to create content, change the goal.

Do not start by chasing output volume. Start by turning real friction into useful notes.

Limited time forces specificity.
Specificity is what most content lacks.

When I choose a model now, I first ask whether it can handle my real tasks. Leaderboards come second.

Leaderboards are not enough

Model leaderboards change every day.

One model reaches the top today. Another claims to beat it tomorrow. A score tells me how a model performs on public tasks, but not whether it can match my tone, fix my code, or understand my context.

I have seen many strong models fail in daily use. They miss constraints in writing, hallucinate in research, and change the wrong boundary in coding. A model can be good at benchmarks and still fail on a vague two-sentence request.

Public leaderboards rank average ability. Your own eval ranks which model can do your work.

Your eval is also few-shot material

Building an eval set can feel heavy.

You need to collect cases, write expected outputs, and define rubrics. That can sound like unnecessary process.

But those 20 cases have a second use: they become your few-shot library.

Each case contains an input, an expected output, and a scoring standard. You are recording how you want AI to handle this type of task.

The next time you face a similar task, you can paste 2-3 cases into the prompt. Even a weaker model can do better when it sees your pattern.

Start with 20 real failures

The first version should not chase scale.

Start with 20 high-quality cases. Once you can see clear differences between models, expand the set to 100+.

The best cases come from your AI usage over the past 1-2 months:

• Failed conversations
• Tasks with the wrong tone
• Summaries that missed key details
• Code tasks with the wrong change boundary
• Research answers with hallucinations
• Tasks that only worked after repeated follow-up

Real failures are more valuable than invented questions.

You are not testing whether a model can answer a polished prompt. You are testing whether it fails in the situations you actually face.

Each case needs three parts

Each case needs three parts:

Input: the original prompt. Keep it messy if that is how the real request looked.

Expected Output: the answer you wanted. Write it yourself or edit a model draft.

Rubric: the scoring standard. Avoid vague comments like "pretty good." Split the judgment into concrete checks:

JSONL is an easy storage format. Score each answer from 1 to 10, or use Pass/Fail with a concrete reason.

Prioritize edge cases

The set needs diversity, but it should not spread effort evenly.

Include simple, intermediate, and hard tasks. Include writing, coding, summarization, search, rewriting, and analysis.

The cases that separate models are usually edge cases: wrong tone, missed constraints, misunderstood context, invented facts, or answered directly when the model should have asked a follow-up question.

These cases expose model weaknesses quickly.

Compare manually first

The lightest workflow is to feed the same case to several models and compare the answers yourself.

That already solves most model-selection problems.

If you want a more convincing result, turn the workflow into a table:

• One row per case
• One column per model output
• One column for the ground truth
• One column for score and reason

Later, you can use a judge model. Give it the input, expected output, rubric, and candidate answer. Ask it to score the answer and explain why.

Judge models can also be biased, so sample-check part of the scores.

Build your own standard

Public leaderboards are still useful, but only as a first filter.

What matters in daily work is whether a model understands your tone, codebase, business context, and follow-up habits.

Only your own eval set can answer those questions.

Start with 20 real cases. Expand to 100+ after you see clear differences. Add rubrics and a judge model when you need a stable process.

Those cases can also become few-shot examples.

That is more reliable than chasing the newest leaderboard.

The faster AI writes code, the less I want to start by reading code.

Code and plans both get long

I used to trace the files first: where the entry point is, where the state comes from, how data moves, and where the result is rendered. That worked in small projects.

Now AI may change routes, components, styles, data scripts, and config in one pass. Each file can be readable on its own, but together they become a web. After reading the code, I still may not know where the change boundary is.

Plans are not much better. They list files, steps, edge cases, and verification. For simple tasks, that is useful. For complex tasks, it becomes another long document. Code complexity turns into text complexity.

So I now look at diagrams first.

Diagrams should answer one question

I tried Mermaid, but complex diagrams get messy. More nodes create crossing arrows. More groups make the diagram wider. The diagram may render, but it is still hard to read.

Then I started using PlantUML. It is better when I split diagrams by question:

• Use a sequence diagram for call order
• Use a component diagram for module relationships
• Use a state diagram for state changes

I ask AI for diagrams first

Now I usually ask AI for this first:

First, draw a PlantUML diagram that explains how these files call each other.
If state changes are involved, draw a separate state diagram.

The diagram helps me see the entry point, data source, business logic, and side effects. After that, I decide whether I need to read the code.

docu.md handles the rendering

One more tool I recommend is docu.md.

PlantUML is easy to maintain inside Markdown, but normal previews may not render it. The docu.md browser extension can render PlantUML in Markdown. It also supports Mermaid, Graphviz, LaTeX, and code highlighting.

Now I ask AI to generate a doc.md file with the task background, key files, PlantUML diagrams, and a short explanation. I open it in the browser, read the diagrams, scan the headings, and then return to the code.

I no longer start from code details or a long plan.

I look at the diagram first.

Why is there "Mr" in my name? Nothing deep: mrlark.com was the shortest domain I could register, and "Mr" came with it.

If I could register lark.com, I would just be Lark. If I could register musk.com, I would not mind being Musk either. My online name was not invented; it was what remained.

That may sound casual, but I paid tuition twice before I learned it. In the end, a good name is plain: it should be easy to say and easy to remember.

That lesson came from two bad names I used before.

Two bad names I used

My first name was "Xiaolin's Mischief Dragon."

It was a mix of The Dragon Maid of Kobayashi's House and Water Margin: one is an anime, the other is a classic Chinese novel. When I came up with it, I thought I was being clever. It had a little anime energy and a little classical-literature energy.

Later I found three problems:

• It was too long. Seven Chinese characters are already a lot to remember.
• The reference was too obscure. People who had not watched the anime missed one half, and people who had not read Water Margin missed the other.
• It was hard to address. In Chinese, people usually use two-character names, so I still did not know whether people should call me "Xiaolin" or "Jianglong."

Later I changed it to "Yinke Jun," using "Yinke" as a sound-alike for Ink.

That name was shorter, but it still had two problems:

• The reference was still too obscure. Most people saw "Yinke" and thought of stamping or carving, not Ink.
• It was still awkward to say. "Yinke" and "Yinke Jun" both felt a little stiff.

The two names looked different, but the real problem was the same: they were names I liked, not names other people could use.

A name should be easy for readers

After those two failures, I understood something simple: the main user of a name is the reader.

Once a name is chosen, I barely use it except when I introduce myself. Readers, on the other hand, see it again and again. They see it when they read my articles, and they see it when they want to contact me.

So the standard should come from the reader. For readers, a name only needs two things: it should be easy to say, and easy to remember.

Easy to say means no hesitation when someone leaves a comment or mentions you in conversation. "Mr Lark, this was a good article" sounds normal. "Xiaolin's Mischief Dragon, this was a good article" does not.

Easy to remember means people can find you again. That is where the domain comes in.

A name should have a short domain

Why care about a domain? Because platforms are unreliable.

Today a platform may think you are worth recommending. Tomorrow it may decide you no longer fit its direction and stop showing your work.

A domain is the fixed place you control. With mrlark.com, anyone who wants to see what I am doing has somewhere stable to go. A platform can stop recommending me, but on my own site, I am still the main character.

So my rule is to reverse the usual order: check the domain first, then choose from the names that are still available. A name can fit the domain, but the domain cannot fit the name.

That is how I ended up with "Mr Lark": first mrlark.com, then "Mr."

It may not be the most striking name at first glance, but it can be spoken, it can be remembered, and I am willing to keep using it. That is enough.