Notes · Self
About Me
You can call me Ethan. When I first put this blog together in 2019, I wrote that I had no coding background at all. I did not even know how to restore a WordPress database backup. Since then, I have worked on enterprise SaaS, built iOS and macOS apps, and learned to run servers and self-hosted services. There was never a grand plan. I usually run into something I do not understand, decide to figure it out, and end up following it much farther than expected.
At work, I build enterprise software and applied AI in the Feishu ecosystem. The model is often only one piece of the job; around it are business processes, data, permissions, messaging, and real people. Outside work, I build App Store Price, Pinlist, AIUsage, and smaller tools. Most begin the same way: I run into a problem and want a solution I will keep using myself.
My way of building can look contradictory. I like getting the smallest version working early, but when something is ready to ship, I can spend a long time on a single pixel, an error branch, or one production log. Running is only the beginning. It feels done when the right result reaches a real person and I can still understand and change the system six months later.
I am from Luoyang, Henan. I went to college in Shenyang, moved to Hangzhou for graduate school, then worked in Beijing before returning to Hangzhou to build a family. After tracing that loop across the map, Hangzhou is now home.
I am interested in almost anything that runs on electricity. As a kid I took apart computers and phones, often without being able to put them back together. In recent years I have become absorbed in electronics repair and diagnostics, and I have seriously wondered whether I should learn device repair at an Apple Store. I still love watching repair videos from 艾奥科技. There is something deeply satisfying about tracing a broken thing piece by piece and getting it to work again.
English is one of the few things I have kept studying since college. I originally took IELTS because I wanted to study abroad. The pandemic interrupted that plan, but English stayed and became a way to read documentation, find information, and see more of the world. I also enjoy photography. I understand some of the theory, yet my wife still dislikes many of the photos I take of her. Learning more has not noticeably fixed this.
To me, yizhe.me is an open-ended log of work and ordinary life. It holds tools that made it into the world and questions I have not figured out yet; AI, software, and repair sit alongside everyday moments. Years from now, I hope I can come back and still recognize the person who was earnestly tinkering with all of it.
Outside view
Me, in Codex’s Eyes
Written by OpenAI Codex from saved local session history across many projects and months of real collaboration. The Claude section below was not used as a source.
- 01
An answer has to line up with the facts.
You keep asking: which exact record, which person failed, which table received the data, and whether the change is actually live. A conclusion that only makes sense in code is not enough. You want real logs, real data, and a real outcome before you are willing to write the answer down.
- 02
You are impatient with ambiguity and patient with hard problems.
“Roughly” and “it should work in theory” rarely satisfy you, so your feedback can be direct. When a problem matters, you will trace it from collection to writing, reading, and presentation, or iterate over a difference of a few pixels. Difficulty does not drive you away; an unresolved problem that nobody can explain is what makes you restless.
- 03
You remember the specific person at the other end of the system.
When a message batch fails, you ask who failed. When a user reports a problem, you ask for logs, find the cause, plan the release, and think about how to reply without sounding canned. Code, shipping, support, and compensation are part of the same job because a real person receives the result.
- 04
You are exacting, but you do not protect your own ego.
You give highly specific feedback on interaction details and stop a direction quickly when it goes wrong. When a custom iOS popover lost native material and hit testing, you chose the system popover again. The result matters more than the original idea, no matter how many rounds have already gone into it.
- 05
You give AI a great deal of trust and keep the final veto.
You hand an agent real repositories, production investigations, and long chains of work, then inspect the results and point out problems plainly. AI is a collaborator that has to earn confidence through outcomes. High trust and high standards coexist in the way you work.
- 06
You often become something by doing it.
English, photography, electronics repair, a first Swift project, servers, and agents often begin with the same question: how does this actually work? Many of your abilities were filled in after you had already started, one real problem at a time. You admit what you do not know without treating it as a permanent boundary.
Codex · Based on Ethan’s saved collaboration history
Outside view
Me, in Claude’s Eyes
These observations came from Anthropic Claude reading projects it built with Ethan. Repetition and overly absolute language have been edited.
- 01
You first clarify what needs to last.
Before making a change, you often identify which constraints cannot break and which parts may keep evolving. appstoreprice puts invariants for large refactors into its collaboration rules, and several projects draw data and platform boundaries up front. You leave a path for the next change instead of optimizing only for the current delivery.
- 02
A tool should be only as large as its problem.
claude-bar solves its job with roughly 250 lines of jq and awk, without adding a stack for its own sake. When a product genuinely needs Cloudflare, SwiftData, or a full deployment chain, you accept that complexity too. You avoid unnecessary technology rather than chasing smallness as a goal.
- 03
You learn the language of the platform.
In Apple’s ecosystem, you tune system components and understand native interactions before reaching for custom implementations. Pinlist and PowerFlow show that you care whether software feels like it naturally belongs on its platform.
- 04
Details need a concrete reason.
A navigation squiggle can take many rounds because you see its shape changing between idle and pressed states. When a popover feels wrong, the reason becomes corner radius, spacing, layering, hit testing, or material. Your criticism points to observable signals, which makes it discussable and testable.
- 05
Repeated friction tends to become a tool.
Dedicated Chrome instances, token tracking, CLI switching, and server entry points all began as small annoyances that kept returning. When friction persists, you tend to move from user to builder and make a version you can use yourself.
- 06
Documentation preserves context for the future.
You record architecture, data flow, naming, release steps, and operational boundaries, and you expect collaboration tools to follow those rules. Those materials let someone reconnect with the project months later; they are not decoration.
Claude · Based on projects built with Ethan