‘Can’t be fucked’: Nguyên nhân bị đánh giá thấp của nợ kỹ thuật
(jesseduffield.com)- Năng lực phát triển không chỉ được quyết định bởi kiến thức; ngay cả khi biết mình nên làm gì, nếu cứ trì hoãn việc viết test, refactor và tạo ca tái hiện vì thiếu động lực, nợ kỹ thuật sẽ tích tụ
- Lập trình viên giỏi sẽ điều tra và sửa flaky test, biến bug đã phát hiện thành ticket hoặc sửa ngay, và nếu tính năng mới không khớp với code hiện có thì sẽ refactor trước
- Những châm ngôn như “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” hữu ích khi xử lý các ràng buộc thực tế, nhưng cũng có thể bị dùng như cách che giấu việc đơn giản là không muốn làm
- Với Lazygit, tác giả đã xây dựng hệ thống test end-to-end trong nhiều tháng và cảm nhận rõ hiệu quả của nó, nhưng lại không thêm cùng loại test vào Lazydocker, đồng thời cũng trì hoãn cả yêu cầu về kho lưu trữ tái hiện tối thiểu lẫn việc refactor God Struct
- Ngay cả khi không còn năng lượng để viết code hoàn hảo, nếu thẳng thắn bộc lộ những phần còn thiếu, sẽ dễ hơn trong việc đánh giá tiêu chuẩn bảo trì và mức độ ưu tiên của công việc tiếp theo
Thiếu động lực tạo ra nợ kỹ thuật
- “Can’t Be Fucked” là tiếng lóng kiểu Úc, chỉ trạng thái không muốn làm gì đó hoặc không có năng lượng và động lực để làm
- Từng nghĩ rằng học thêm nhiều kiến thức phát triển sẽ giúp mình trở thành lập trình viên giỏi hơn, nhưng trên thực tế, những lập trình viên khiến ta nể trọng không chỉ có kiến thức mà còn có sự chăm chỉ bền bỉ
- Lập trình viên giỏi hiểu rằng xử lý vấn đề cho đúng khi nó còn nhỏ sẽ tiết kiệm thời gian về lâu dài, và họ hành động theo điều đó
- Nếu có flaky test thì sẽ điều tra và sửa
- Nếu phát hiện bug ngoài thực tế thì sẽ tạo ticket hoặc sửa ngay
- Nếu tính năng mới không hợp với code hiện có thì thay vì nhét ép vào, họ sẽ refactor trước
- Khi cần, họ sẽ lần xuống tận dưới stack để tìm ra nguyên nhân
- Những lập trình viên như vậy cũng biết phân biệt khi nào “good enough” là đủ, khi nào cần thu hẹp phạm vi, và khi nào nên học thêm về domain rồi mới thay đổi kiến trúc
- Vấn đề là tách biệt với những phán đoán đó, có những lúc thiếu động lực lại trở thành ràng buộc mạnh hơn cả các ràng buộc bên ngoài của dự án
Thành thật thay vì trốn sau những châm ngôn
- Hệ thống test end-to-end của Lazygit được xây dựng bán thời gian trong nhiều tháng, sau đó đã ngăn được rất nhiều lỗi hồi quy, và tác giả tin chắc rằng nếu để đến bây giờ mới thêm vào thì sẽ còn khó hơn
- Dù vậy, lý do không thêm test end-to-end cho Lazydocker đơn giản là vì CBF
- Sau khi tạo issue ở một kho mã nguồn mở khác, tác giả được yêu cầu cung cấp một kho Git tái hiện tối thiểu nhưng đến giờ vẫn chưa làm; đồng thời một đợt refactor lớn đã bắt đầu hơn 1 năm trước cũng chưa thể hoàn tất, nên code vẫn còn rất nhiều God Struct
- Tác giả không khẳng định chắc đó là burnout, thiếu growth mindset hay vấn đề tính cách
- Biết được nỗi đau dài hạn của nợ kỹ thuật có thể trở thành động lực để né tránh nó, nhưng biết và thực sự hành động cho đúng là hai chuyện khác nhau
- Những câu như “nếu có quá nhiều test thì gánh nặng bảo trì sẽ tăng”, “tôi sẽ refactor sau khi xem các tính năng khác ảnh hưởng thế nào”, “premature optimisation”, “cut scope aggressively” có thể dùng cho những phán đoán tốt, nhưng cũng có thể là cái cớ
- Nếu thừa nhận rằng một phần code hay pull request còn thiếu sót vì lười, reviewer sẽ có thể tự đánh giá xem mức thiếu sót đó có vượt ngưỡng chấp nhận hay không, hoặc liệu nên dành thời gian cho việc tiếp theo thì hơn
- Khi rơi vào trạng thái CBF, thay vì nản lòng thì nên thành thật; và nếu đã chạy ở mức 100% quá lâu, có lẽ bạn cần một kỳ nghỉ
1 bình luận
Ý kiến trên Hacker News
Một phần đáng kể của CBF có thể được giải thích chỉ bằng đãi ngộ và cơ chế khuyến khích
Khi mới vào công ty hiện tại, tôi đầy năng lượng: sửa các bản build bị hỏng, làm cho các bài test bị bỏ bê chạy qua, refactor pipeline triển khai, tìm và sửa nguyên nhân gốc của bug
Nhưng theo thời gian, mọi người chẳng những không noi theo tôi mà còn thành kiểu “dù sao người đó cũng sẽ sửa thôi”, và tôi nhận ra làm việc vặt chỉ khiến thêm nhiều việc vặt đổ về mình
Ngược lại, người làm kiểu hack cho xong thì đóng gói kết quả thật đẹp và được thăng chức trước; đến lúc vấn đề nổ ra trong vận hành thì họ đã chuyển sang dự án khác rồi
Junior mà tôi giúp vài giờ mỗi tuần thì nhờ được tuyển vội vào năm 2022 nên kiếm nhiều hơn tôi; còn tôi năm 2023 được đánh giá “vượt kỳ vọng” nhưng vì thời kỳ khó khăn nên không được tăng lương
Rốt cuộc, ở vị trí người làm công ăn lương, nếu nỗ lực không được đền đáp hoặc thậm chí lại thành hình phạt, thì mất động lực cũng chẳng có gì lạ
Hãy rời đi, tìm nơi mình thuộc về và những người của mình
Khi được công nhận, chi phí động lực giảm mạnh, và con người thích phần thưởng
Người ta chơi game hàng nghìn giờ cũng vì chi phí động lực rất thấp
Không có ý nói nên game hóa nơi làm việc, nhưng nếu tự biện hộ cho mình thì trông có vẻ nhỏ nhen, nên đồng nghiệp cần công nhận lẫn nhau
Nợ kỹ thuật cũng có các lãi suất khác nhau, và năng lực nằm ở việc để yên khoản nợ 0% rồi trả các khoản nợ lãi cao trước
Khi lát sàn tủ đồ ở tầng hầm, tôi thiếu vật liệu nên không lát hết được phía sau; nhìn thì hơi xấu, nhưng nó luôn bị hộp che lại và sống vài chục năm cũng chẳng ảnh hưởng gì. Đây là nợ kỹ thuật 0%
Ngược lại, nếu máng thoát nước bị tắc thì theo thời gian chi phí sẽ tăng vì tầng hầm rò nước hoặc máng bị bung, nên đó là khoản nợ có lãi. Bậc thềm trước cửa bị hỏng khiến người ta cứ vấp ngã cũng là khoản nợ lãi cao cần sửa sớm
Trong kỹ thuật phần mềm, một vấn đề kiến trúc làm chậm mọi phát triển tính năng có thể là nợ lãi cao, còn code bừa bộn hay TODO trong một file hầu như không ai đụng tới trên thực tế có thể là nợ lãi thấp
Kỹ sư một mặt bỏ lỡ việc quan trọng hơn vì mải sửa nợ 0%, mặt khác lại nói “sản phẩm/lãnh đạo không hỗ trợ xử lý nợ kỹ thuật”, nhưng thường không giải thích rõ được chi phí thực tế và lãi suất
Từ trên xuống dưới, người ta chỉ chú ý đến những thứ mới mẻ và hào nhoáng, không quan tâm đến việc duy trì cái hiện có
Dù có thuyết phục được về tầm quan trọng, ban lãnh đạo cũng chỉ đồng ý rằng việc đó là cần thiết, chứ không có bất kỳ tác động tích cực nào đến đánh giá thành tích. Tôi lại phải gánh một việc mà nếu sai thì chỉ bị khiển trách
Nếu codebase bừa bộn và thiếu nhất quán, dù là file ẩn khuất, các developer cũng sẽ giảm mong muốn triển khai tính năng mới một cách nhất quán và chất lượng
Nó sẽ thành “dù sao cả module này cũng phải viết lại, nên cứ gắn tạm vào đây đã, sau này dọn dẹp”
https://en.wikipedia.org/wiki/Broken_windows_theory
Đây là sự mở rộng tự nhiên của cách gọi nợ kỹ thuật, truyền tải trọng tâm ngắn gọn nên tôi cũng muốn dùng ở công ty
Vì vậy đổ lỗi rằng “developer đã không giải thích được chi phí thực tế” là một cái cớ hơi dễ dãi
Nếu vấn đề lộ ra với khách hàng thì có khả năng được giải quyết, nhưng nếu chỉ là vấn đề nội bộ thì khả năng thấp hơn nhiều
Khi nghiêm túc dùng những cách nói như “nợ kỹ thuật 0%”, có lẽ nên xem lại liệu mình có hiểu sai khái niệm không
Nợ thì phải trả hoặc phải trả lãi; nếu không có những thứ đó thì không phải là nợ
Chắc lần tới cả tính năng chưa triển khai cũng sẽ bị gọi là nợ kỹ thuật 0% mất
Tôi không phải fan của Steve Jobs, nhưng tôi luôn thích những câu trích dẫn của ông về tinh thần thủ công và thái độ chú ý đến chi tiết
“Nếu bạn là một thợ mộc làm một chiếc tủ ngăn kéo đẹp, bạn sẽ không dùng ván ép cho mặt sau chỉ vì nó quay vào tường và không ai nhìn thấy. Vì bạn biết nó ở đó, bạn sẽ dùng gỗ đẹp cả ở mặt sau. Để ngủ ngon vào ban đêm, thẩm mỹ và chất lượng phải được duy trì đến tận cùng”
Tôi nghĩ phần lớn ngành phần mềm chịu khổ vì thái độ “tôi đã vừa đủ đáp ứng yêu cầu về mặt kỹ thuật, vậy là việc của tôi xong”
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Có nhiều chuyện kể rằng ông từ chối phát hành phần cứng và phần mềm không đạt chuẩn, và sa thải những người không thể làm ra đúng thông số
Ngược lại, đa số chúng ta làm việc dưới kiểu lãnh đạo hoàn toàn trái ngược: “làm xong nhanh nhất có thể để bán được nhiều hơn, và chỉ cần vá víu những thứ cần thiết sao cho qua được kiểm thử chất lượng”
Thợ mộc thực tế phải thực dụng và hiệu quả về chi phí để cạnh tranh trên thị trường
Nếu dùng gỗ đắt tiền hoặc tốn thời gian cho chỗ không ai nhìn thấy, sản lượng sẽ giảm và chi phí của khách hàng sẽ tăng không cần thiết
Với thợ thủ công, thời gian và tiền bạc cũng hữu hạn; thời gian dành cho những việc không ai thấy là thời gian không thể dùng cho những việc dễ thấy hơn
Trong một thị trường nơi những thợ mộc cùng trình độ sản xuất được nhiều hơn với chi phí thấp hơn, người thợ như vậy sẽ bị đào thải
Tôi nghĩ vấn đề của phần mềm gần với vấn đề incentive hơn là thái độ. Tôi thích làm việc tốt và dùng phần mềm tốt, nhưng thời gian mỗi ngày có hạn, và tôi không đến mức hy sinh thời gian cá nhân vì lợi ích kinh doanh mà tôi không được hưởng
Hơn nữa, nếu bắt đầu refactoring, ta hoàn toàn có thể dự đoán hợp lý rằng một ngày nào đó sẽ đột nhiên xuất hiện một tính năng bắt buộc phải xong ngay trong hôm nay
Ngay cả khi ban lãnh đạo đồng ý xử lý nợ kỹ thuật, cuối cùng vấn đề cũng không được giải quyết trừ khi ta thổi phồng ước lượng lịch trình rồi refactor thay vì làm việc được giao
Trong một cuốn sách nào đó, có nhân vật thợ rèn sửa bộ phận của xe ngựa và nói “hãy luôn làm tốt nhất trong khả năng của mình”
Khi có người nói “đó là bộ phận nằm bên dưới, chẳng ai nhìn thấy đâu”, ông đáp: “Nhưng tôi biết nó ở đó. Nếu tôi không làm nó tốt nhất có thể, tôi sẽ thấy xấu hổ mỗi lần chiếc xe đó đi ngang qua. Và tôi sẽ thấy chiếc xe đó mỗi ngày”
https://news.ycombinator.com/item?id=28086786
Nếu bạn viết unit/integration/end-to-end test tử tế, và khi thấy code lộn xộn thì refactor thay vì chồng thêm lên trên, năng suất trên giấy tờ của bạn sẽ thấp hơn đồng nghiệp liên tục “giải quyết” ticket
Điều này đặc biệt nặng trong các tổ chức “hoàn toàn agile” không hề tính đến refactoring hay dọn dẹp chất lượng code
Apple ít nhất đã từng là ngoại lệ. Giá sản phẩm cao nên khách hàng kỳ vọng chất lượng, công ty có biên lợi nhuận để làm được điều đó, và trên hết là có Steve Jobs, người có con mắt về trải nghiệm
Ở thái cực ngược lại là những trường hợp như Juicero, làm một chiếc máy ép túi nước trái cây bằng kỹ thuật cấp hàng không vũ trụ
Trong phần lớn sự nghiệp, tôi đã dọn nợ kỹ thuật mỗi khi thấy cơ hội, dù không ai yêu cầu. Vì tôi có sự gắn bó và cảm giác sở hữu
Giờ thì nơi làm việc bị micromanagement dựa trên Jira và không có quyền tự chủ, nên tôi không làm gì ngoài những việc bắt buộc phải làm
Trước đây, nỗ lực tự nguyện là cốt lõi trong sự nghiệp của tôi, nhưng bây giờ chi phí quản lý dự án về mặt quan liêu và xã hội cho bất kỳ thay đổi nào cũng quá lớn, không đáng để làm
Tôi không quan tâm sản phẩm về lâu dài có tốt lên hay công ty có thành công không; tôi chỉ xử lý ticket cho đến khi tìm được việc tiếp theo
Ngược lại, nếu làm theo kiểu “refactoring thì đừng xin phép, cứ làm”, bạn sẽ bị mắng vì tạo PR không theo các pattern hiện có của repository
Nó sẽ thành “ý tưởng hay đấy, nhưng cần thảo luận với cả team”
Vì vậy nợ kỹ thuật cứ lớn dần, merge một PR mất vài tháng, còn test thì bất ổn đến mức giống máy đánh bạc casino, phải bấm nút khởi động lại cho đến khi build được. Agile đúng là tuyệt vời
Theo kinh nghiệm của tôi, hành động chủ động ở một nơi làm việc chỉ vận hành theo kiểu phản ứng thì tuyệt đối không được tưởng thưởng
Khi bạn phát hiện vấn đề, ngay khoảnh khắc đó nó trở thành vấn đề của bạn; nếu sau này nó lại nổ ra, đó sẽ thành lỗi do bạn làm hỏng
PM và tầng quản lý luôn vận hành với các giả định tiêu cực, nên không đáng
Đặc biệt là có những người nghĩ rằng họ đã giác ngộ con đường đi đến code tốt, nhưng thực tế thường là họ chọn con đường dễ hơn so với việc đọc và hiểu code hiện có
Trong phần bình luận ở đây có một số hiểu lầm
Với từng lập trình viên, động lực, nỗ lực, năng lượng, ý chí — gọi là gì cũng được — đều là tài nguyên hữu hạn, và điều này hoàn toàn bình thường
Ưu điểm của tổ chức là làm được nhiều việc hơn một lập trình viên cá nhân, nhưng trong quá trình ghép nhiều yếu tố lại với nhau, các khe hở xuất hiện và công việc rơi lọt qua đó
Những người được trả lương để vận hành tổ chức chứ không phải làm kỹ thuật, như COO, HR, product manager, cần tạo ra quy trình để xử lý các khe hở đó
Nhưng ngày càng nhiều công ty đẩy việc này sang từng kỹ sư và designer, vì nó khó đo bằng lãi lỗ hay OKR
Công ty thì đau đớn, còn kỹ sư thì burnout. Có giới hạn cho việc liên tục chăm nom những ticket và công việc nhỏ bị rơi vào khe hở mà không có thêm thù lao
Không khí tiêu cực ở đây khá nặng, nhưng tôi mừng vì bài viết này mô tả chính xác cảm xúc hằng ngày của mình
Khi thấy độ phủ test rất tốt và những lần refactor có nguyên tắc của các dự án mã nguồn mở, có những ngày tôi cũng vào chế độ “làm cho tử tế” và làm được nhiều thứ chất lượng
Rồi đến một ngày năng lượng đó biến mất, tôi cũng trở thành CBF như tác giả. Bỏ qua test, chèn thêm code vào chỗ mà mình biết là không tốt, và đang lát một con đường mà bản thân trong tương lai sẽ chẳng cảm ơn
Tôi thấy chuyện đó diễn ra ngay theo thời gian thực, nhưng không có năng lượng hay động lực để quay lại chế độ “làm cho tử tế” đầy cảm hứng nữa
Tất cả chuyện này cũng xảy ra với phần mềm do chính tôi tự làm và bán
Tôi ấn tượng khi biết tác giả là người tạo ra Lazygit, và tôi thật sự rất thích lazygit. Trong đầu tôi, anh ấy luôn thuộc nhóm maintainer mã nguồn mở làm mọi thứ đến nơi đến chốn
Có vẻ cả hai chúng ta có trải nghiệm khá giống nhau về động lực
Rất vui vì bạn thích lazygit, và hy vọng tôi vẫn giữ được đánh giá tốt đó trong tương lai
Phần lớn quyết định thật ra là vô thức
Trạng thái “không tài nào làm nổi” nghĩa là một mạch nào đó trong não đang phán rằng những việc như refactor hay test không đáng làm
Mạch đó cũng có thể đúng. Vì nếu nhìn khách quan và tổng thể, phần thưởng so với công sức bỏ ra trong nhiều trường hợp thật sự không đủ
Ví dụ nếu bạn dành hai tháng để làm test end-to-end, rồi trong 6 tháng sau đó chỉ tiết kiệm được 3 tuần cho việc debug và tương tự, thì phép tính đó không hợp lý
Có hai thái cực thường gặp. Một bên là doanh nghiệp ép kỹ sư chấp nhận technical debt như một thỏa hiệp thật sự tệ, bên kia là kỹ sư dành thời gian cho một cấu trúc lý tưởng và cả đống test khổng lồ mà rốt cuộc sẽ không được tưởng thưởng
Một phần trong đó cũng là vì người ta lo rằng ai đó sẽ tìm thấy cấu trúc code tốt hơn hoặc test bổ sung rồi đánh giá mình
Nếu tôi cảm thấy mình đang đưa ra thứ không đạt chuẩn của bản thân, dù chuẩn đó cao hơn nhu cầu thực tế, tinh thần và động lực sẽ bị tổn hại nghiêm trọng
Tôi nghĩ vấn đề lớn nhất của technical debt, trái lại, là nó phá hoại tinh thần
Với Lazygit, tôi đã dành vài tháng để xây dựng một phần hệ thống test end-to-end, và mỗi ngày tôi đều nghĩ về những regression mà hệ thống đó đã chặn được, cũng như nếu bây giờ mới thêm vào thì sẽ khó hơn đến mức nào
Tôi biết rõ nó đáng giá, nhưng lý do tôi không thêm test end-to-end cho Lazydocker chỉ đơn giản là CBF
Test end-to-end nếu không có công cụ phù hợp thì phiền như địa ngục và là một khối lượng việc khổng lồ. Các framework nền tảng có thể nhét vào dễ dàng cần phải tốt hơn nữa
Nếu may mắn thì người đó còn thời gian để lo cả integration test
Tôi thấy cách xã hội và thế giới này nhìn con người là lười biếng nhìn chung thật vô lý
Kiểu như phải làm việc 40 giờ mỗi tuần suốt mấy chục năm, rồi đầu thai xong mới được nghỉ, vậy mà còn muốn nói về lười biếng ở đây sao
Năng lượng tinh thần bị rút ra để tạo ra của cải cho người khác, rồi khi quá già không làm được gì nữa thì bị vứt bỏ
Tuần nào cũng lại có một tính năng lẽ ra phải xong từ hôm qua, vậy rốt cuộc khi nào mới được sửa technical debt? Làm trong thời gian rảnh à? Tôi còn không hiểu vì sao mình phải tiếp tục tồn tại nữa
Trong một dự án đã trưởng thành của một nhóm nhỏ, những ticket còn lại toàn là các bug khó mà chẳng ai muốn đụng đến
Dù bỏ ra vài ngày cũng chẳng có gì để trình bày ngoài việc gạch vài mục khỏi danh sách nghi ngờ, và đó là những bug mà nếu gạch nhầm thì một tuần sau lại quay trở lại
Mỗi ngày phải dồn toàn bộ năng lượng tinh thần vào những ticket như vậy, dựa vào cà phê hay chất kích thích để chật vật sửa xong bug, rồi submit code, đóng ticket và lập tức chuyển sang ticket tiếp theo
Không có nghỉ ngơi thật sự; chỉ ở giai đoạn đầu của ticket kế tiếp, khi chưa ai kỳ vọng có kết quả ngay, mới được cho đầu óc nghỉ một chút
Nhưng vài ngày trôi qua thì mọi người bắt đầu hỏi từ trước đến giờ bạn đã làm gì, có bị kẹt không, và bạn phải bịa ra vài lời nói dối nhỏ về lý do mình tụt lại, dù thật ra gần như còn chưa bắt đầu
Lúc cần nghỉ ngơi nhất thì mình đã tụt lại xa nhất và mọi người đã nhận ra, nên ngay cả việc xin nghỉ phép cũng không còn giống một lựa chọn
Bây giờ tôi làm 20–30 giờ mỗi tuần, đôi khi ít hơn, tại một tổ chức phi lợi nhuận về kỹ thuật; tiền thì eo hẹp, nhưng tôi thật sự không thể làm nhiều hơn
Tôi có chút thời gian cho side project và đạp xe, cuối tuần thì tuyệt đối không làm việc. Thứ Ba cũng không làm, trừ trường hợp đặc biệt
Tôi thật sự yêu công việc hiện tại, đó là công việc trong mơ, nhưng không đáng để làm đến mức tự giết mình. Đời chỉ có một lần, và tôi sẽ sống bằng cách yêu thương cho đúng nghĩa
Hôm nay tôi vừa hoàn thành một công việc kéo dài 1 tháng, gần như viết lại toàn bộ firmware cho thiết bị của công ty; ban đầu nó được ước lượng là việc 1 tuần để sửa một bug nhỏ trong một phần module truyền thông
May là tôi có PM và đồng nghiệp thoải mái, nên họ công nhận rằng giờ đây các bug legacy 8 năm tuổi trong đoạn code đó thực sự có thể được sửa
Vẫn còn test edge case và chỉnh sửa bổ sung, nhưng cập nhật code từ xa đã hoạt động nên có thể xuất xưởng thiết bị
Ở đây “nói dối” gần như là một khuyến nghị hành động. Ban đầu tôi mở đầu bình luận bằng “hãy nói dối”, nhưng đã có hiểu lầm
Cũng là để nói với đồng nghiệp rằng việc có thời gian suy nghĩ về những hàm ý rộng hơn của công việc là quan trọng
Và cũng là để đóng góp suy nghĩ của mình vào những cộng đồng như thế này, ăn chocolate, dắt chó đi dạo nếu có thể, và nghe bài giảng của Alan Watts trên YouTube
Với tư cách một người cố gắng làm mọi thứ cho đúng, tôi nghĩ điều quan trọng trong technical debt là theo dõi
Chỉ mất vài phút để tạo một task cho một vấn đề nhìn thấy được, và task đó trở thành technical debt
Lãnh đạo có trách nhiệm ưu tiên technical debt và liên tục giảm bớt một lượng nhất định
Đôi khi technical debt cũng được giảm bằng cách quyết định không làm một việc nào đó, và điều đó hoàn toàn ổn
Mục đích của quy trình ghi lại, kiểm tra và xử lý là cho các “vấn đề chưa phải lúc này” một cơ hội được xem xét lần thứ hai
Trực giác ban đầu có thể đã sai và X là không cần thiết, hoặc ngược lại nó có thể đã đúng vì một lý do mà khi đó chưa nghĩ ra
Trên hết, một phần trong những việc “giờ chưa làm được” thực sự quan trọng. Nếu không dành thời gian nhìn vào chúng, bạn sẽ không thể tìm ra những việc đó