DEV Community: xundao

7 Days of Daily Writing: What I Learned

xundao — Thu, 30 Jul 2026 09:41:49 +0000

Tags: writing, beginners, discuss, career

Seven days ago I made myself a promise: publish one article every day for a week. No excuses. No "I'll just polish this one a bit more." Ship it, hit publish, move on to the next one.

This is day seven. Here's what actually happened.

The first thing I noticed: day one was easy. Day two was hard. Day three was nearly impossible. There's a reason most "daily writing challenges" die around day three. By that point, the novelty has worn off and you're staring at a blank cursor with nothing particularly novel to say. You've already used up the ideas you've been carrying around in your head. Now you have to generate new ones, on demand, under a deadline.

I almost quit on day three. I had a half-finished draft about API design patterns that was so boring I couldn't bring myself to re-read it. I deleted the whole thing and started over. The replacement article — about building in public and vulnerability — ended up being the one that resonated most with readers. If I'd forced myself to finish the boring API article out of stubbornness, I would have published something mediocre and missed the opportunity to write something that actually mattered to me.

Lesson one: kill your darlings early. If the draft isn't working, the draft isn't working. Starting over is faster than salvaging.

The second thing: I became a much faster writer. My day one article took about four hours. My day six article took ninety minutes. The mechanics didn't change — same keyboard, same markdown editor, same brain — but something about the daily rhythm forced me to stop second-guessing every sentence. When you know you have to publish by end of day, you stop treating every paragraph like a sacred text. You write it, you read it once, you fix the obvious problems, and you ship.

Here's a weird side effect I didn't anticipate: writing daily made my code better. Not in the sense that writing prose improves syntax skills — that's not really a thing. But the discipline of articulating my thoughts clearly in English (which is not my first language) bled over into how I structure my code. I started writing more comments. I started naming variables like they were headlines — clear, specific, impossible to misinterpret. The mental muscle of "how do I make this idea accessible to someone who isn't inside my head" is the same muscle, whether you're writing an article or writing a function.

The language barrier deserves its own mention. I'm a native Chinese speaker writing for a primarily English-speaking developer audience. This adds a layer of friction that native English speakers don't experience. I spend roughly 20% of my writing time just on phrasing — not because I can't express the idea, but because I'm hunting for the most natural way to say it. The upside: it forces me to simplify. I can't hide behind complex sentences or jargon, because I'm not confident enough in English to deploy them smoothly. The result is writing that's more direct than it would be if I were writing in Chinese and translating. Constraint breeds clarity.

What surprised me most about this week wasn't the writing itself. It was the responses. People actually read these things. People left comments. A few people reached out to say "I'm on the same journey" or "this helped me think differently about X." That's a strange and humbling feeling — knowing that words you typed alone in your apartment reached someone on the other side of the world and made their day slightly different.

I'm not going to keep writing daily after this. The pace is unsustainable for me alongside actual product development, and honestly I think daily publishing has diminishing returns after the initial push. But I'm going to keep the rhythm at a lower frequency — probably twice a week — because the benefits are too significant to abandon entirely. Better thinking. Better code. Better connection with other builders. All from something that costs nothing but time and courage.

If you're considering a daily writing challenge: do it for a week, not a month. A month is a marathon you haven't trained for. A week is an experiment. You'll learn whether the format works for you without burning out. And whatever you do, don't wait until you feel "ready." You won't. Nobody does.

I document this journey at xundao.xin — no newsletter spam, just honest notes from the build.

The 5 AM Club Is a Lie — What Actually Shipped Code

xundao — Tue, 28 Jul 2026 01:06:45 +0000

Tags: productivity, webdev, career, beginners

I tried the 5 AM routine for exactly eleven days. Here's what happened: I was exhausted by 2 PM, my code quality dropped off a cliff after lunch, and I spent more time staring at my ceiling at 4:30 AM convincing myself I was "meditating" than actually meditating. By day twelve I deleted my alarm and slept until I woke up naturally. That was the day I shipped the most code of the entire month.

The productivity industry has a vested interest in making you feel like a failure. If you're not waking up at 5 AM, if you're not using the Pomodoro technique with a custom Notion dashboard, if you're not tracking every minute of your day in a color-coded calendar — well, clearly you're just not trying hard enough, are you? Buy this course to learn how.

Reality check: most of the productive developers I know don't do any of this. They have messy processes. They work at weird hours. They sometimes go three days without touching code and then pull a fourteen-hour session because the ideas finally clicked. The only consistent pattern I've observed among people who actually ship is this: they've stopped optimizing for "feeling productive" and started optimizing for "producing things."

Here's what my actual shipping rhythm looks like now, six months into building solo.

I wake up sometime between 7 and 9 AM. No alarm unless I have a specific meeting. I make coffee. I read something that has nothing to do with tech for thirty minutes — fiction, usually, or a long-form essay about something random like the history of concrete. (Concrete is fascinating, by the way. The Romans had self-healing concrete and we still don't fully understand how they made it.)

Then I open my laptop. I do not check Twitter. I do not check email. I do not open Discord. I open exactly one thing: the file I was working on yesterday. I spend the first hour doing the hardest task on my list — usually something that requires genuine thinking rather than just typing. By 11 AM I've either solved it or I've made enough progress to feel momentum.

Lunch is real. I leave my desk. I don't eat at my keyboard while scrolling Hacker News. This sounds trivial but it was genuinely the single biggest change that improved my afternoon productivity. Twenty minutes of not looking at a screen, eating actual food at an actual table, resets something in my brain that coffee can't reach.

Afternoons are for the easier stuff. Code review on my own PRs. Documentation. Responding to messages. Tweaking CSS. Anything that doesn't require deep focus but still moves the project forward. If I'm in flow I'll keep going until 6 or 7 PM. If I'm not, I stop at 4 and go touch grass.

Evenings are sacred. No laptop after 8 PM. It's not a discipline thing — it's a survival thing. The first two months of this journey, I worked until midnight every night because I felt guilty about my "low" output. I was burning out in slow motion and didn't realize it until I caught myself crying at a Pixar movie trailer. (It was Elemental. I stand by my emotional response, but still.)

The real breakthrough was understanding that consistency over months beats intensity over days. I don't need to write 2,000 lines of code every day. I need to show up every day — or most days — and move the ball forward, even if it's just one commit. Over a year, that's 200-300 commits. That's a shipped product. That's documentation, tests, bug fixes, features. That's enough.

I still track output, just differently. Instead of hours worked, I track decisions made. A day where I made one good architectural decision and wrote fifty lines of code is better than a day where I wrote five hundred lines I'll just rewrite next week. The metric that matters isn't activity. It's progress.

Stop trying to optimize your morning routine. Start optimizing for actually shipping something.

I share the real rhythms of solo building — not the hustle-porn version — at xundao.xin.

AI Won't Replace You — But Another Builder Will

xundao — Mon, 27 Jul 2026 01:09:24 +0000

Tags: ai, career, productivity, discuss

Last month I met a developer at a Shenzhen tech meetup who told me he was "waiting to see where the AI thing goes" before deciding whether to learn it. He's been waiting for two years. In that same two years, I've watched someone with zero coding experience ship a working SaaS product using Cursor and Claude.

The gap between these two realities is what keeps me up at night.

Let me be clear about something: I don't believe AI is going to replace software developers. Not in the way the Twitter panic threads suggest. The idea that a CEO is going to type "build me Facebook but for dogs" into ChatGPT and fire their entire engineering team — that's fantasy. The technology isn't there. The real threat is subtler and, honestly, more interesting.

AI won't replace you. But someone who knows how to wield AI effectively absolutely will.

Here's what I mean. I spent six years in corporate tech before going solo. I've worked with brilliant engineers who could debug memory leaks in their sleep but refused to touch any AI tool because "it writes bad code." They're not wrong — AI does write bad code sometimes. But they're missing the point the same way developers in 2005 missed the point about Stack Overflow. "You shouldn't copy-paste code you don't understand!" True. Also, irrelevant. The developers who learned when to trust Stack Overflow and when to verify shipped faster than the purists. The same dynamic is playing out now, just accelerated tenfold.

I use AI for the boring parts. Writing test cases. Generating boilerplate. Converting data formats. Drafting documentation that I'll then edit heavily. These are tasks that would take me hours and drain my mental energy for the real work: architecture decisions, user experience, figuring out what to build in the first place.

The junior developers who embrace this approach are terrifyingly productive now. I've talked to bootcamp graduates who are shipping full-stack applications in weeks. Not toy projects — real, deployed, revenue-generating products. They don't understand every line of code, but they understand enough to make it work, and they learn the rest as they go. That used to be impossible. Now it's the default if you're curious and persistent.

So where does that leave the experienced developer who's "waiting to see where the AI thing goes"? Not obsolete, but increasingly expensive. If a junior with AI assistance can produce 80% of your output at 40% of your cost, companies will do the math. They already are.

This isn't a doomsday prediction. It's a call to curiosity. The barrier to learning AI tools is laughably low. You don't need a PhD. You don't need to understand transformers or attention mechanisms. You just need to spend a weekend actually using the tools — not reading about them, not watching YouTube videos about them, but opening the terminal and building something. Anything.

The builders who are winning right now share one trait: they're not precious about "hand-written code." They treat AI as a force multiplier. They know when to lean on it and when to override it. They've developed an intuition for what the model is good at and what requires human judgment. That intuition didn't come from reading blog posts. It came from thousands of hours of trial and error, shipping real things to real users.

I think about the philosophy that guides my work: 叶无限 — Leaf Unlimited. I am not defined by any single role, therefore I am infinite in what I can become. A developer who defines themselves only by their ability to write code from scratch is building walls around their own future. A developer who defines themselves by their ability to solve problems — using whatever tools are available — is positioning themselves for abundance.

The AI wave isn't something that's going to happen in the future. It's happening right now, while you're reading this. The only wrong move is waiting.

More unfiltered thoughts on building in the AI era at xundao.xin.

My $0 to First Customer: The Ugly Numbers

xundao — Sun, 26 Jul 2026 01:06:19 +0000

Tags: startup, productivity, discuss, ai

Month one: $0. Month two: $0. Month three: $0. Month four: $29.

I'm going to be completely transparent about my numbers, because every "how I grew to $10k MRR" thread on here seems to skip the part where the founder ate instant noodles for six months while building something nobody wanted.

My project is an AI automation tool for small businesses — think Zapier but you describe your workflow in plain Chinese or English and it just works. Or at least, that's the pitch. The reality was messier.

Let me walk you through the actual timeline. I quit my corporate job in March 2026 with about eight months of runway saved up. Not a lot. Definitely not the "raised a seed round and have two years to figure it out" story you usually hear. Just a guy with some savings, a ThinkPad, and a questionable amount of confidence.

The first version shipped in late April. Looking back, "shipped" is generous. I deployed a Next.js app to Vercel with a single form that called OpenAI's API and crashed if you typed more than 200 characters. My total users: four friends who felt obligated to test it. Their feedback was brutal in the way only friends can be. "It's slow." "I don't get it." "Why would I use this instead of just asking ChatGPT directly?"

May was the rebuilding month. I rewrote the core workflow engine three times. Each time I thought I'd cracked it. Each time I discovered a new class of edge cases that made the previous architecture look like a house of cards. I spent $127 on OpenAI API credits testing my own product. My runway calculator started blinking yellow.

June is when I almost quit. I'd been at this for three months with nothing to show for it. My GitHub looked active, sure, but my bank account was a countdown timer. I applied for exactly one job — a senior frontend role at a startup in Shanghai. Got to the final round. Didn't get it. In retrospect, that rejection might have been the luckiest break of this entire journey, because it forced me to look at my own project again and ask: what would make this worth paying for?

The answer was embarrassingly simple. I wasn't solving a real problem. I was solving the problem I thought people had. The pivot came in late June: instead of a generic workflow builder, I narrowed the focus to e-commerce sellers who needed to automate their customer service across multiple platforms — Taobao, Shopee, Lazada. Specific. Painful. A problem people actually have.

July 12, 2026. First paying customer. $29/month on the early adopter plan. I didn't do a launch. I didn't post on Product Hunt. I found this person in a niche online community for small e-commerce store owners, where I'd been lurking for weeks just listening to people's complaints. Someone mentioned they spent three hours every day copy-pasting customer inquiries between platforms. I reached out directly. Awkward, but it worked.

That $29 hit my Stripe account and I stared at the notification for a solid minute. It wasn't about the money — $29 doesn't even cover my coffee habit. It was proof. A stranger, somewhere out there, found enough value in something I built to exchange real currency for it.

Here's what the numbers actually look like right now: one customer. $29 MRR. Total lifetime costs: roughly $3,400 in living expenses, $280 in API fees, $12/year for the domain. Burn rate: about $1,200/month in a tier-2 Chinese city. Runway remaining: honestly, not enough. I need to hit $1,000 MRR by November or I'll need to start freelancing.

Am I scared? Yes. Is this sustainable? Not yet. Do I regret it? Not even a little. That single customer taught me more about product-market fit than any book, course, or conference ever did. Every conversation since has been grounded in what that first person actually needed, not what I imagined people needed.

The next milestone is ten customers. I have no idea when I'll get there. But I know exactly what I'll do when I do: the same thing I did for the first one. Listen more than I talk. Solve one specific problem well. Charge money from day one.

I write these numbers down — the ugly ones too — at xundao.xin.

Building in Public Is Terrifying (And That's Why It Works)

xundao — Sat, 25 Jul 2026 01:15:29 +0000

Tags: discuss, startup, beginners, career

The first time I tweeted about my project, I sat with the draft open for forty minutes. I rewrote it six times. I hovered over the "Post" button and felt actual physical nausea. This is a grown man who has given presentations to rooms of two hundred people, who has defended architecture decisions to CTOs, who once handled a production outage during a Super Bowl ad campaign. But posting "Just shipped the first version of my AI automation tool" to an audience of maybe eighty followers — that broke me.

I posted it anyway. Nobody cared. Two likes. One reply from a bot. The world did not end.

That's the dirty secret of building in public: the fear is real, but the risk is imaginary. Nobody is paying that much attention to you. Especially at the beginning. And that's actually the superpower.

Here's what I've learned after months of building in the open: the vulnerability isn't a side effect of the strategy. The vulnerability is the strategy.

When I started writing honestly about my numbers — zero users, the embarrassing bugs, the features I spent three days on that nobody asked for — something shifted. People started reaching out. Not in droves, but one by one. Someone who had the exact same problem with webhook reliability. Someone who had tried building a similar tool and failed. Someone who just wanted to say "I'm on the same journey, keep going."

Those connections are worth more than any polished landing page. They're real. You can't buy them with ads. You can't SEO your way into them. You can only earn them by showing up consistently and being honest about where you actually are, not where you wish you were.

The counterintuitive part: sharing your failures builds more trust than sharing your wins. Everyone posts about their Product Hunt launch. Almost nobody posts about the three months of silence before it, when they were questioning every life choice and their GitHub contribution graph looked like a flatline. When you write about that part, you're not just documenting. You're giving permission. Permission for other builders to be in the messy middle without feeling like they're failing.

I've had to learn where my line is. I share revenue numbers now — the real ones, not the "we grew 300% month over month" vanity metrics. I share technical decisions and why I made them. I share the emotional roller coaster. What I don't share: anything that would compromise user data, anything that would burn bridges with past employers, and anything that's still too raw for me to talk about with clarity. You need boundaries. Public doesn't mean boundaryless.

The accountability piece is real too. When I committed publicly to shipping one feature per week, I suddenly had a reason to finish things that I might have abandoned at 80%. Knowing that a handful of people would notice if I didn't ship — that tiny bit of social pressure — was often the difference between shipping and drifting.

Would I recommend building in public to everyone? Honestly, no. It's not a magic growth hack. It's slow. It's uncomfortable. It takes months before you see any return. But if you're already building alone and you're already documenting your journey anyway, making it public costs almost nothing and opens doors you didn't know existed.

The fear doesn't go away. I still get nervous before hitting publish. But I've learned to recognize that feeling as a signal: if I'm scared to post it, it's probably the right thing to post.

The real, messy updates continue at xundao.xin.

The One Prompt That Changed How I Use AI

xundao — Fri, 24 Jul 2026 01:02:07 +0000

Tags: ai, productivity, beginners, programming

Six months ago I was using AI wrong. Not "wrong" in the sense that I was getting bad outputs — I was getting perfectly reasonable outputs. That was the problem. Reasonable is the enemy of useful.

Here's the context. I was building an automation pipeline that needed to parse user-submitted descriptions of business workflows and map them to actual API calls. My prompts looked like what you'd expect: "You are an expert developer. Given the following user input, generate a JSON schema..." followed by a wall of instructions longer than most README files. The outputs were fine. They were also boring, generic, and wrong about 30% of the time in subtle ways that took me hours to debug.

Then I stumbled across a technique that changed everything. I don't remember where I found it — probably some obscure Reddit thread at 2 AM — but the core idea was so counterintuitive that I almost dismissed it entirely.

The technique is this: instead of telling the model what to do, tell it what it did wrong.

Here's the actual prompt structure that transformed my workflow:

First pass: "Here is a user request. Generate a solution." Standard stuff.

Second pass: "Here is the solution you just generated. Now list everything wrong with it. Be brutal. Find edge cases I haven't considered. Identify assumptions that might break. Flag anything that a senior engineer would reject in code review."

Third pass: "Here is the original problem, your first solution, and your critique. Now generate a final answer that addresses every issue you identified."

That's it. Three messages instead of one. It sounds trivial. It also cut my error rate from roughly 30% down to under 5% in the first week of using it.

Why does this work? I have some theories. LLMs are fundamentally pattern-completion machines — when you ask for a solution, they complete the pattern of "person asks question, expert answers question." The expert persona tends toward confidence and conciseness, which means the model glosses over uncertainty. By explicitly requesting a self-critique, you're forcing the model into a different pattern: the rigorous reviewer who gets paid to find problems. Suddenly it notices the missing null check, the edge case where the timezone is UTC+14, the assumption that the user's input will always be in English.

The weirdest part? The model often catches things I wouldn't have caught myself. Last week it pointed out that my workflow parser would break if a user included emoji in their step descriptions. I had been testing with clean ASCII inputs for two weeks and never once considered that someone might write "Step 1: Check email 📧." The model caught it because in critique mode, it was actively hunting for failure modes rather than trying to sound competent.

This technique has become my default for anything non-trivial. I do it with code generation, with content writing, with system design. The pattern is always the same: generate, critique, regenerate. Three passes. The extra latency is maybe thirty seconds. The reduction in downstream debugging time is measured in hours.

I suspect this works because it mirrors something that good engineers already do instinctively: rubber-duck debugging, code review before pushing, the second draft that's always better than the first. The model is just a very fast rubber duck.

The one thing I'll add: this works best with models that have strong reasoning capabilities. I use it primarily with Claude and GPT-4-class models. On smaller models the critique phase sometimes hallucinates problems that don't exist, which defeats the purpose. But if you're working with frontier models and haven't tried self-critique prompting yet, you're leaving a surprising amount of quality on the table.

I write about practical AI workflows — not the hype, just the stuff that actually ships — at xundao.xin.

I Quit Corporate to Build AI Alone - Here's Week 1

xundao — Thu, 23 Jul 2026 12:51:30 +0000

The last day of my corporate job was a Thursday. I remember walking out of the office building, laptop bag slung over one shoulder, and thinking: that's it. No more standups. No more Jira tickets someone else wrote. No more pretending I cared about quarterly OKRs for a product I didn't believe in.

The first Monday morning alone was disorienting in a way I didn't expect. For six years, my calendar had been filled by other people. Now it was a blank white rectangle stretching into infinity. I sat at my desk at 8:30 AM and realized nobody was waiting for my status update. Nobody cared what I did that day. The silence was louder than any open-plan office.

I panicked, obviously. That first day I wrote exactly zero lines of code. I reorganized my Notion. I watched three YouTube videos about solo founder productivity. I had a minor existential crisis around 2 PM and went for a walk that lasted two hours. By evening, my only tangible output was a grocery list.

Tuesday was slightly better. I opened VS Code. I stared at the blank terminal. I typed mkdir xundao-ai and then sat there for another thirty minutes trying to decide what framework to use. (I went with Next.js. I always go with Next.js. The decision took far longer than it should have.)

Here's what nobody tells you about quitting your job to build alone: the hardest part isn't the code. It's learning to trust your own decisions again. In corporate, every choice has a committee attached to it. You can blame the architecture on the tech lead, the timeline on the PM, the bugs on the offshore team. When you're alone, every bad decision has exactly one person's name on it.

By Wednesday I had a working prototype - barely. It was a simple AI automation tool that took a user's natural language description and turned it into a workflow. The UI was ugly. The error handling was nonexistent. But when I typed "send me a Slack summary of yesterday's GitHub commits every morning at 9 AM" and watched it actually work, I felt something I hadn't felt in years. It wasn't pride exactly. It was more like relief. I could still do this.

The rest of the week was a blur of coding, breaking things, fixing them, and slowly remembering what it felt like to build something because I wanted to, not because a sprint board told me to. I deployed to Vercel on Friday afternoon. Zero users. Zero customers. Just a domain name and a bunch of code that existed because I decided it should.

Week 1 taught me something surprising: the blank calendar isn't the enemy. It's the point. The emptiness is where the work actually happens - not the cushy kind of work with peer reviews and deployment pipelines, but the raw, uncertain kind where you're standing at the edge of what you know and what you don't know, and nobody is going to tell you which way to jump.

I share more of the unfiltered reality at xundao.xin.