- Chỉ bản thân hành động mới là thực sự bắt tay vào làm; suy nghĩ hay chuẩn bị không phải là thực thi
- Liên tục chỉ ra rằng lập kế hoạch, học tập, thảo luận, mua công cụ đều không phải là ‘làm việc’
- Chỉ hành vi trực tiếp thử làm, kể cả khi thất bại hoặc còn vụng về mới được xem là thực thi thật sự
- Bắt đầu dù chỉ là một chút là điều quan trọng; không cần chuẩn bị hoàn hảo hay có điều kiện lý tưởng
- Bài viết nhắc lại rằng thái độ chuyển sang hành động thực tế là cốt lõi của sáng tạo và phát triển
Phân biệt giữa thực thi và không thực thi
- Bài viết liệt kê rằng “suy nghĩ, mơ mộng, hình dung, chuẩn bị” đều không phải là ‘làm việc’
- Ví dụ: “suy nghĩ”, “mơ mộng”, “tưởng tượng thành công”, “chờ đến khi sẵn sàng”
- Hành vi nói ra, giải thích hoặc tranh luận cũng không được xem là thực thi
- Bao gồm “giải thích cho người khác”, “tranh cãi trên mạng”, “tuyên bố rằng sẽ bắt đầu”
Cái bẫy của chuẩn bị và tiêu thụ
- Nghe podcast, xem tutorial, đọc các trường hợp của người khác đều không phải là thực thi
- Thiết kế một hệ thống hoàn hảo, mua công cụ hoặc dọn dẹp không gian làm việc cũng không được xem là thực thi
- Thái độ tự an ủi bằng cảm giác tội lỗi hay bận rộn cũng không phải là hành động thực tế
Hình thức của thực thi thật sự
- Làm trong lúc thất bại, làm một cách vụng về, làm dù chỉ là ít thôi đều được công nhận là ‘làm việc’
- Dù không hoàn hảo, việc thực sự động tay vào làm mới là quan trọng
- Ở phần cuối, bài viết nói rằng “ngay cả việc viết blog cũng không phải là làm việc”, đưa ra một kết luận mang tính tự phản tỉnh
Thông điệp cốt lõi
- Chỉ hành động mới là thực thi thật sự, còn mọi thứ khác không phải là sự thay thế cho việc bắt tay vào làm
- Bắt đầu dù chỉ nhỏ thôi, chấp nhận thất bại và tự mình làm thử là cách tiến lên duy nhất
- Câu cuối của bài viết, “Giờ tôi phải quay lại làm việc thôi”, tượng trưng cho tinh thần hành động ngay lập tức
2 bình luận
Đây là một câu rất hay cho những người như tôi, những người không giỏi trong việc thực thi.
Ý kiến trên Hacker News
Nguyên tắc “Doing it badly” đã thay đổi hoàn toàn cách suy nghĩ của tôi
Tôi đã dành nhiều tuần để cố thiết kế một kiến trúc hoàn hảo, nhưng cuối cùng lại dừng việc lập kế hoạch và làm ra một phiên bản thô để giải quyết vấn đề của mình
Điều đáng ngạc nhiên là phiên bản đầu tiên đó đã dạy cho tôi những điều mà chỉ lập kế hoạch thì không bao giờ học được. Tôi học được điều người dùng thực sự coi trọng, những edge case quan trọng trong thực chiến, và tiêu chuẩn của “đủ tốt” là gì
Điều khó nhất là chấp nhận triển khai dù biết nó còn khiếm khuyết. Nhưng vòng phản hồi từ việc sử dụng thực tế có giá trị hơn rất nhiều so với hàng tuần tranh luận giả định
Dạo này trên các subreddit về năng suất có rất nhiều bài kiểu này. Tôi nghi ngờ việc dành vài tuần chỉ để lên kiến trúc cho một công cụ tự động hóa cá nhân có thực tế hay không
Nhìn vào lịch sử bình luận của tác giả thì thấy cùng một văn phong lặp đi lặp lại nên khó tạo được sự tin tưởng
Xem quá trình đó thực sự rất thú vị
Trong quá trình tự tay triển khai và refactor, có rất nhiều điều để học về cả vấn đề lẫn lập trình nói chung
Những abstraction ban đầu nghĩ ra đa phần đều sai. Khi bắt tay vào làm, cấu trúc thay đổi hoàn toàn, và cuối cùng lại cho ra đoạn code đẹp hoàn toàn khác lúc đầu
Ý chính là hãy làm phiên bản đầu tiên với tâm thế sẽ bỏ đi, nhưng trên thực tế thì đa số không vứt bỏ mà cải tiến lặp dần
Giờ đây nhờ công cụ và quy trình mà chúng ta có thể tiếp tục iterate
Cấu trúc nội bộ cũng cần lặp và prototype, nhưng những phần như cấu trúc dữ liệu, xử lý lỗi, logging, naming thì nên được quyết định cẩn thận từ sớm để sau này có thể cải tiến nhanh hơn
Tôi rất thích câu “Doing it badly is doing the thing”
Đây là bài học tôi học được từ HN: khi bị mắc kẹt, đừng ngồi lo làm cho hoàn hảo mà hãy cứ bắt tay vào làm
Lúc đầu có thể rất tệ, nhưng cứ cải thiện dần dần thì đến một lúc nào đó bức tranh sẽ trở nên rõ ràng. Cảm giác gần như ma thuật
Một là lời khuyên của Dan Harmon về writer’s block,
còn một là “The Gap” của Ira Glass
Cốt lõi là đừng chờ sự hoàn hảo, mà hãy viết ra cả một bản nháp tệ hại, rồi sửa dần nó bằng con mắt của người phê bình
Vì vậy dạo này tôi cố tình nói “vẫn chưa xong” cho đến khi nó thực sự hoàn thành
Tôi thường làm thật nhanh trước, rồi trau chuốt, và cuối cùng thì viết lại từ đầu
Điều quan trọng là đừng rơi vào chủ nghĩa hoàn hảo ở giai đoạn beta
Thực ra nếu cải tiến từng bước là hiệu quả thì là con người hay AI cũng đâu khác gì
Ở công ty cũ, chúng tôi gọi ban điều hành là “hội cảm thán về vấn đề”
Họ chỉ mải thảo luận vấn đề, phân tích và tìm người chịu trách nhiệm, chứ không thực sự giải quyết gì cả
Cuối cùng điều quan trọng vẫn là ‘thực sự làm nó’
Cách tiếp cận tốt nhất là vừa quan tâm đến vấn đề, vừa có ý chí giải quyết theo hướng lặp dần
Dogfooding dùng nội bộ là cách tốt để giữ được sự cân bằng đó
Điều quan trọng là quyết định theo hướng có lợi nhất cho mình trong phạm vi có thể
Ít phải điều phối để cập nhật hơn, và một tổ chức thực sự làm việc sẽ hiệu quả hơn
Bài này rất giống với bài luận trên strangestloop.io
Nhìn tiêu đề tôi đã thấy quen, nhưng bấm vào thì lại là một trang khác và thời điểm đăng cũng chỉ cách vài ngày nên khá bất ngờ
Nội dung giống nhau đến mức khó mà coi là ngẫu nhiên
Trước đây tôi nghĩ chuẩn bị là quan trọng, nhưng rồi có lúc nhận ra chuẩn bị có thể trở thành một vòng lặp vô tận
Nhóm của chúng tôi đã hoàn thành sản phẩm trong 4 tháng với một bản spec 2 trang, còn nhóm cạnh tranh thì viết tài liệu suốt 8 tháng rồi bị giải thể
Lập kế hoạch chỉ cần 20% là đã xử lý được 80% vấn đề. Sau đó chỉ còn là sự nghiêm ngặt được gói dưới dạng lo âu
Rốt cuộc phần lớn những gì tôi học được đều đến từ việc tung ra thứ gì đó còn đáng xấu hổ rồi sửa dần
Đã được trích trong một bình luận HN trước đây
Analysis paralysis là thứ có thật
Muốn không bị khựng lại thì phải bắt đầu trước. Hãy xử lý happy path trước, rồi sau đó trau chuốt edge case
Giờ chi phí làm prototype đã thấp nên cần thử mà không sợ thất bại
Đây cũng là lý do LLM hiệu quả đến ngạc nhiên — chúng thực thi ngay thay vì phân tích
Kết quả có thể không hoàn hảo, nhưng thường vẫn đủ dùng, và nếu cần thì tối ưu sau
Trước khi tạo framework, bạn nên xây ít nhất ba hệ thống thật. Chỉ khi đó bạn mới biết chỗ nào là quá tay hay còn thiếu
Câu “đủ ổn” có thể trở thành một kiểu tự lừa dối bản thân
Một prototype thất bại không phải bằng chứng là thị trường không tồn tại. Nó chỉ là tín hiệu rằng còn thiếu điều gì đó
Bài này mang thông điệp gần như giống hệt bài đăng trước
Cũng đã được bàn trong thảo luận HN trước đó
Ngược lại, đôi khi chính ‘doing the thing’ lại là lựa chọn sai
Vì vậy tôi vẫn kiên trì với tài liệu thiết kế và code review
Trong thời đại GenAI, việc ‘cứ làm đại không cần kế hoạch’ đã trở nên quá dễ, nên càng cần một đối trọng để cân bằng
Ta mất hết thời gian vào tính không xác định và vấn đề độ trễ (latency), và cuối cùng unit economics mới là thử thách thực sự
Trong Remains of The Day, việc ‘chỉ nói về the thing’ được gọi là một hành vi tự thỏa mãn bản thân
Rất nhiều lúc nó chỉ dừng ở những cuộc trò chuyện khiến ta thấy dễ chịu chứ thực tế chẳng đạt được gì
Mặt khác, lập kế hoạch, chuẩn bị và mise-en-place có thể hỗ trợ cho việc thực thi thật sự