<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Writing on Jim's Notes</title><link>https://shizhi3620.github.io/en/posts/</link><description>Recent content in Writing on Jim's Notes</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shizhi3620.github.io/en/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Lessons from Vibe Coding</title><link>https://shizhi3620.github.io/en/posts/vibe-coding-notes/</link><pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/vibe-coding-notes/</guid><description>&lt;h2 id="the-short-version"&gt;The short version&lt;/h2&gt;&#10;&lt;p&gt;After two or three weeks of practicing Vibe Coding, I reached a broad conclusion: large language models have dramatically lowered the barrier to programming. Anyone with basic computer literacy can now use AI to write programs and implement useful features.&lt;/p&gt;&#10;&lt;p&gt;However, those features often run only on a local computer or remain personal tools. Turning them into a service that runs on a server, serves customers, and can be continuously improved requires much stronger engineering thinking.&lt;/p&gt;&#10;&lt;p&gt;If the goal is to build independently with AI and make money through an OPC (One Person Company) model, technical implementation is only one part of the problem. The overall business model, cost structure, user needs, and competition also need to be considered.&lt;/p&gt;</description></item><item><title>A Starting Point for Bilingual Writing</title><link>https://shizhi3620.github.io/en/posts/bilingual-publishing/</link><pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/bilingual-publishing/</guid><description>&lt;p&gt;Chinese is the factual source. A translation must retain the original dates, links, and verifiable conclusions.&lt;/p&gt;</description></item><item><title>Job-Search Notes: Making the Work Visible</title><link>https://shizhi3620.github.io/en/posts/job-search-notes-on-making-the-work-visible/</link><pubDate>Tue, 08 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/job-search-notes-on-making-the-work-visible/</guid><description>&lt;p&gt;Job-search preparation often begins with a resume, but a harder question remains beyond it: how can someone understand how I work without reducing complex experience to a few vague verbs?&lt;/p&gt;&#10;&lt;p&gt;I prefer to begin with a specific problem. Describe the constraints at the time, the role I held, the actions taken, and which parts of the result can be verified. Where there is no data or public material to support a claim, preserving uncertainty matters more than adding an attractive story. It respects the facts and makes the conversation more efficient.&lt;/p&gt;&#10;&lt;p&gt;Public work, short retrospectives, and ongoing learning notes can extend the limited space of a resume. But being public is not the same as revealing everything. Information about former employers, clients, colleagues, or internal systems should be de-identified, and sometimes omitted entirely. The point of professional communication is the approach to solving a problem, not details that are not mine to share.&lt;/p&gt;</description></item><item><title>A Public Project Retrospective Starts with Verifiable Records</title><link>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</link><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</guid><description>&lt;p&gt;A retrospective for a public project can easily collapse into outcomes: what shipped, what feedback arrived, and what might come next. The more useful part is whether people can understand and revisit the trade-offs made along the way.&lt;/p&gt;&#10;&lt;p&gt;I separate a retrospective into three layers. The first is verifiable fact, such as public commits, documentation, issue records, and release notes. The second is the judgment at the time: why one problem came first and another option was postponed. Only the third is personal feeling. It can clarify context, but it cannot stand in for evidence.&lt;/p&gt;&#10;&lt;p&gt;This approach helps in two ways. Collaborators get a project history rather than a collection of disconnected links. I get a record of the conditions behind a choice when facing similar constraints again, instead of relying on a vague memory of success or failure.&lt;/p&gt;</description></item><item><title>Why I Started This Blog</title><link>https://shizhi3620.github.io/en/posts/why-this-blog-exists/</link><pubDate>Sun, 06 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/why-this-blog-exists/</guid><description>&lt;p&gt;I wanted a place that moves more slowly than a chat thread: somewhere to keep ideas worth considering again, whether they come from a change in how I work, an uncertainty during a job search, or a judgment that gradually takes shape in daily life.&lt;/p&gt;&#10;&lt;p&gt;This is not an attempt to present a complete personal brand or turn every conclusion into advice. Most posts are working notes from a particular moment: what I noticed, what supports it, and what may need to change later. Publishing them asks me to separate facts, feelings, and guesses before I write, and gives my future self a way to revisit the decisions behind them.&lt;/p&gt;&#10;&lt;p&gt;Chinese is the source language here. English posts are translated with AI assistance and reviewed by the author before publication; both versions should describe the same facts. When a translation is not ready, the Chinese post may still be published and the unavailable language is shown clearly.&lt;/p&gt;</description></item></channel></rss>