When the client wanted delivery, I bought another tool
At 10 p.m. last Thursday, I was tweaking a small feature for a client in a Hangzhou coffee shop. They asked whether it could go live the next day. I said yes, but my hand reached first for a new collaboration tool. Later, I realized the tool wasn't slowing me down—the real problem was that a tiny requirement had already gone through three rounds of revisions. I've been stuck here too: when work gets busy, I want a new tool to save me, and all I do is hide what I haven't learned more deeply.
What these five books actually solve
In 2008, Michael A. Foerster listed five programming books worth remembering on his blog in Wisconsin, USA. They aren't quick-reference guides; they're more like five teammates I can call on: to help me understand code, testing, maintenance, and collaboration. Older developers used them to shore up their fundamentals. Today's indie developers can use them to reduce rework. For example, freelance developer Lin Yue, based in Shanghai, used Code Complete while taking over a website redesign to review the handoff checklist and avoid turning vague requirements straight into features.
The cost of replicating this today is smaller than I expected
I did the math: used books cost around CNY 100, while e-books usually run CNY 30–80. With 30 minutes a day, I can read the core chapters of one book in about two weeks. The technical barrier is low: being able to use the table of contents and type through the examples, without needing complicated code knowledge. The first step isn't opening another app. It's opening that old project I keep postponing, writing down why the latest rework happened, and then finding the matching chapter in the table of contents. Starting with the summary and contents is fine too. This tool isn't for everyone, and there's no rush to try it.
How I would sequence this by stage
If I were just starting out, I'd read a book about testing first and turn one of my small projects into a “pre-delivery checklist.” If I already had one or two clients, I'd pick the book on maintenance and clean code, then replace repeated revisions with a fixed checklist. If I were scaling up, I'd prioritize the book on team collaboration and have the team build the process together. I'm still testing this sequence myself: rather than buying another tool that looks faster, I'd rather first make good on the promises my team has already made. I can start with the most recent rework, read only the chapter connected to it, and decide whether I want to continue from there.