Slow Productivity cho Solo Dev: Đừng mù quáng

Sáng thứ ba tuần trước, lúc 10h43, tôi chính thức ném cái to-do list dài 18 gạch đầu dòng của mình vào sọt rác. Làm solo dev ở Việt Nam thường đồng nghĩa với việc bạn tự biến mình thành một cỗ máy cày cuốc ngày đêm, nhưng tôi nhận ra mình đang code như một cái máy hỏng. Tôi kiệt sức và quyết định mang khái niệm Slow Productivity ra thử nghiệm thực tế cho dự án cá nhân.

Slow Productivity thực sự là gì?

Khái niệm này xoay quanh ba nguyên tắc cốt lõi: làm ít việc hơn, làm theo nhịp độ tự nhiên và ám ảnh về chất lượng. Nghe rất thơ mộng trên giấy.

Nhưng áp dụng nó vào thế giới phát triển phần mềm độc lập lại là một câu chuyện hoàn toàn khác. Khi bạn code một mình, không có công ty nào trả lương cho việc bạn ngồi suy nghĩ về kiến trúc hệ thống cả tuần. Mọi thứ đều quy ra tiền túi và thời gian sống của chính bạn.

Cái bẫy của việc làm ít đi

Đánh đổi bằng thời gian ra mắt

Hồi tháng 3, thay vì tung ra bản MVP trong 2 tuần như thói quen, tôi quyết định áp dụng nguyên tắc làm chậm. Kết quả là tôi mất đúng 73 ngày để release. Việc Deep Work trong Tech: Không thần thánh như bạn nghĩ đã từng cảnh báo về việc chìm đắm quá sâu vào lý thuyết là hoàn toàn chính xác. Lần này tôi nếm mùi thật.

Thị trường không hề đứng chờ bạn làm việc một cách thong thả. Khi tôi đẩy code lên production, một đối thủ khác đã tung ra tính năng tương tự từ trước đó 3 tuần. Họ chiếm hết tệp người dùng sớm chỉ vì họ nhanh tay hơn.

Nhịp độ tự nhiên hay ngụy biện cho lười biếng?

Ranh giới mong manh của kỷ luật

Làm theo nhịp độ tự nhiên rất dễ biến thành việc chỉ mở IDE lên khi có hứng. Tuần trước, tôi dùng Cursor kết hợp với Claude Sonnet 4.6 để refactor lại core engine. Dự kiến việc này chỉ mất 3 ngày nếu tập trung.

Nhưng vì tự nhủ phải làm theo “nhịp độ chậm”, tôi kéo dài nó ra thành 9 ngày. Bạn mất đi áp lực cần thiết để hoàn thành công việc. Nếu không cẩn thận, phương pháp này sẽ giết chết startup cá nhân của bạn trước khi nó kịp tạo ra dòng tiền đầu tiên. Cảm giác không hoàn thành sản phẩm thực ra còn bào mòn tinh thần khủng khiếp hơn cả việc làm việc quá sức.

Chất lượng cao có thực sự đáng giá?

Over-engineering là kẻ thù

Ám ảnh về chất lượng khiến tôi ngồi tối ưu một API endpoint từ 340ms xuống còn 112ms. Tôi mất 4 ngày cắm mặt vào profiler cho việc đó. Khách hàng thực tế không hề nhận ra sự khác biệt, vì 340ms vốn dĩ đã đủ nhanh cho một tác vụ background.

Bạn có thể dùng các tool AI mạnh mẽ hiện tại như Gemini 3.1 Pro để viết test coverage 100%. Nhưng để làm gì khi tính năng đó không ai dùng? Bài viết về Tool calling trong AI agents: Phân tích thực tế cũng chỉ ra rằng, đôi khi việc sở hữu công cụ xịn không bù đắp được việc bạn đang giải quyết sai vấn đề cốt lõi.

So sánh các phương pháp làm việc

Tiêu chí	Hustle Culture	Slow Productivity	Hybrid (Thực tế)	Ghi chú
Tốc độ ra mắt	Rất nhanh	Rất chậm	Vừa phải	Solo dev cần ra mắt sớm để validate ý tưởng
Chất lượng code	Thường nợ kỹ thuật nhiều	Hoàn hảo	Chấp nhận nợ kỹ thuật có kiểm soát	Over-engineering giết chết MVP
Nguy cơ burnout	Rất cao	Thấp	Vừa phải	Cần cân bằng giữa thu nhập và sức khỏe

Cách áp dụng thực tế mà không chết đói

Bạn không thể bê nguyên xi lý thuyết vào việc làm solo dev. Đây là cách tôi điều chỉnh nó cho thực tế khắc nghiệt:

1. Giới hạn đúng 2 dự án cùng lúc. Không hơn. Khi bạn có ít việc, bạn buộc phải tập trung vào những tính năng tạo ra giá trị lớn nhất.
2. Sprint dài hơn nhưng vẫn phải có deadline cứng. Thay vì chạy nước rút 1 tuần, tôi chuyển sang chu kỳ 3 tuần. Hết 3 tuần, dù chưa hoàn hảo cũng phải ship.
3. Phân biệt rõ code cần chất lượng và code vứt đi. Core engine cần viết cẩn thận. Nhưng giao diện landing page thì cứ dùng Llama 4 Maverick gen ra thật nhanh rồi đẩy lên, không cần tối ưu CSS từng pixel.
4. Chuẩn bị quỹ dự phòng. Làm chậm đồng nghĩa với việc tiền vào chậm. Bạn cần ít nhất 6 tháng sinh hoạt phí dự phòng trước khi dám giảm nhịp độ làm việc.

Câu hỏi thường gặp

Slow productivity có hợp với người mới học code không?

Không. Khi mới học, bạn cần số lượng dòng code và số lỗi gặp phải càng nhiều càng tốt để tích lũy kinh nghiệm. Chậm lại ở giai đoạn này chỉ làm bạn tụt hậu so với thị trường.

Dùng AI có giúp làm chậm hiệu quả hơn không?

Có, nhưng phải cẩn thận. GPT-5.2 có thể viết boilerplate code rất nhanh, giúp bạn có thêm thời gian rảnh. Vấn đề là thường người ta lại dùng thời gian rảnh đó để nhét thêm tính năng rác vào dự án thay vì nghỉ ngơi.

Làm sao để biết mình đang chậm hay đang lười?

Nhìn vào commit log của bạn. Nếu bạn đang chậm, commit của bạn ít nhưng giải quyết những vấn đề kiến trúc lớn. Nếu bạn lười, bạn chẳng có commit nào đáng giá trong cả tuần ngoài vài dòng chỉnh sửa typo.

Kết luận

Slow Productivity không phải là viên thuốc tiên cho dân làm phần mềm. Nó là một khái niệm được viết ra bởi những người làm hàn lâm, được trả lương ổn định hàng tháng từ các trường đại học. Với solo dev, áp dụng mù quáng sẽ khiến bạn nhanh chóng cạn kiệt tài chính trước khi đạt được sự thanh thản trong tâm hồn. Hãy dùng nó như một bộ lọc để dẹp bỏ những việc vô nghĩa, chứ đừng dùng nó làm cái cớ để trốn tránh áp lực sống còn của thị trường.