- Theo nghiên cứu tâm lý học nhận thức, giới hạn deep work của con người là 3–4 giờ mỗi ngày; sau đó khả năng tập trung và chất lượng mã giảm mạnh
- Kết quả phân tích hơn 250.000 lập trình viên cho thấy thời gian coding trung vị thực tế chỉ là 52 phút mỗi ngày, phần còn lại tiêu tốn cho họp hành, quản lý và cộng tác
- Sau một lần bị gián đoạn, cần 23 phút để quay lại công việc ban đầu; với lập trình viên, khôi phục toàn bộ ngữ cảnh mất 30–45 phút
- Trong trạng thái flow, năng suất tăng 500%, nhưng cần 15–25 phút tập trung liên tục để đi vào trạng thái này
- Vai trò của engineering manager không phải là thêm quy trình mà là loại bỏ yếu tố gây nhiễu và bảo vệ thời gian deep work
Giới hạn nhận thức: Deep work có trần trên là 4 giờ mỗi ngày
- Cal Newport định nghĩa deep work là "hoạt động chuyên môn được thực hiện trong trạng thái tập trung không bị xao nhãng, đẩy năng lực nhận thức đến giới hạn", và với đa số người, mức tối đa trung bình là 4 giờ mỗi ngày
- Nghiên cứu về nghệ sĩ violin của K. Anders Ericsson cũng xác nhận rằng sau 4 giờ luyện tập tập trung, sự mệt mỏi bắt đầu xuất hiện
- Phát triển phần mềm cũng là công việc nhận thức cường độ cao, bao gồm giải quyết vấn đề sáng tạo và thiết kế hệ thống, nên sau 3–4 giờ sẽ xuất hiện hiện tượng lợi ích giảm dần
- Nhà toán học Henri Poincaré làm việc 2 giờ buổi sáng và 2 giờ buổi chiều; G.H. Hardy chỉ làm việc buổi sáng; Charles Darwin, B.F. Skinner và C.S. Lewis cũng duy trì lịch làm việc 3–4 giờ mỗi ngày
- Theo nghiên cứu của Gloria Mark tại UC Irvine, thời gian tập trung vào màn hình trung bình hiện nay là 47 giây, giảm mạnh so với 2,5 phút vào năm 2004
Cách lập trình viên thực sự sử dụng thời gian
- Kết quả phân tích hơn 250.000 lập trình viên của Software.com cho thấy thời gian coding trung vị là 52 phút/ngày (khoảng 4 giờ 21 phút/tuần)
- Chỉ 10% lập trình viên code hơn 2 giờ mỗi ngày, và 40% code hơn 1 giờ
- Theo phân tích 1,5 triệu cuộc họp của Clockwise, kỹ sư phần mềm dành trung bình 10,9 giờ/tuần cho họp hành
- Engineering manager dành 18 giờ/tuần cho họp, gần bằng một nửa tuần làm việc 40 giờ
- Lập trình viên ở tổ chức lớn tiêu tốn 12,2 giờ/tuần cho họp, trong khi ở tổ chức nhỏ là 9,7 giờ
- Nếu loại trừ họp hành, quản lý, code review và cộng tác, thời gian có thể tập trung mỗi tuần chỉ còn 19,6 giờ, và phần lớn bị chia thành các mảnh thời gian ngắn khó sử dụng
- 45% tổng thời gian coding diễn ra trong khoảng 14:00–17:00, trong khi 9:00–11:00 chỉ chiếm 10%
- Không phải vì lập trình viên vốn là người làm việc hiệu quả vào buổi chiều, mà vì buổi sáng bị các cuộc standup, sync và ceremony chiếm hết
Chi phí rất cao của sự gián đoạn
- Theo nghiên cứu của Gloria Mark, sau khi bị gián đoạn, cần chính xác 23 phút 15 giây để quay lại hoàn toàn công việc ban đầu
- Nghiên cứu của Georgia Institute of Technology cho thấy với lập trình viên, cần 10–15 phút để quay lại việc chỉnh sửa mã, và 30–45 phút để tái dựng toàn bộ ngữ cảnh tinh thần
- Bài luận "maker schedule" của Paul Graham: họp không chỉ là chuyển đổi tác vụ đơn thuần mà là một ngoại lệ (exception) làm thay đổi cả chế độ làm việc
- Một cuộc họp có thể phá hỏng cả buổi chiều, và chỉ riêng việc biết có lịch họp buổi chiều cũng khiến người ta ngại bắt đầu một việc tham vọng vào buổi sáng
Trạng thái flow: Bộ nhân năng suất của lập trình viên
- Trong nghiên cứu của Mihaly Csikszentmihalyi, trạng thái flow được định nghĩa là "trạng thái hoàn toàn đắm chìm vào chính hoạt động, đến mức cái tôi biến mất và mất cảm giác về thời gian"
- Kết quả nghiên cứu suốt 10 năm xác nhận rằng ở trạng thái flow, năng suất tăng 500% so với trạng thái thông thường
- Yếu tố cốt lõi để vào flow là cân bằng giữa mức độ thử thách và kỹ năng; thử thách quá cao hoặc quá thấp đều cản trở flow
- Trong các nhóm phần mềm, những nhóm thường xuyên trải nghiệm flow sẽ tạo ra nhiều giá trị hơn, nhanh hơn và với mức độ hài lòng cao hơn
- Flow không tự nhiên xuất hiện; bắt buộc phải bảo vệ nó khỏi các yếu tố làm tiêu hao
Cách đi vào trạng thái flow khi coding
- Tạo môi trường không bị làm phiền: tắt Slack, chuyển thông báo sang im lặng, dùng trạng thái hiển thị rõ ràng để báo hiệu chế độ deep work
- Ngay cả khi không phản hồi thông báo, chỉ cần nhìn thấy chúng cũng đủ làm giảm khả năng tập trung
- Đặt mục tiêu rõ ràng trước mỗi phiên coding: thay vì "làm backend", hãy định nghĩa cụ thể như "sửa endpoint xác thực để trả về phản hồi lỗi phù hợp"
- Giải quyết vấn đề khó vào thời điểm đỉnh cao nhận thức: theo nghiên cứu về nhịp sinh học ngày đêm, hiệu năng nhận thức thay đổi 9–40% theo từng khung giờ
- Với phần lớn người trưởng thành, 10:00–14:00 là khoảng thời gian có khả năng giải quyết vấn đề tốt nhất
- Người dậy sớm ("chim sơn ca") và người thức khuya ("cú đêm") có thời điểm đỉnh khác nhau, nên cần bảo vệ khung giờ đỉnh của từng cá nhân
- Time blocking cho maker schedule: chặn trước trên lịch các block deep work 2–4 giờ, và gom họp về cuối ngày hoặc vào các ngày cố định
- Mỗi block công việc chỉ đặt một mục tiêu, rồi chia nhỏ thành ba tác vụ có thể thực thi
- Loại bỏ context switching: thay vì phản hồi ngay, hãy bố trí cửa sổ giao tiếp hai lần mỗi ngày và đóng các tab trình duyệt không liên quan đến công việc hiện tại
- Làm việc theo các phiên tập trung thay vì marathon sprint: pomodoro 25 phút không phù hợp với công việc phát triển phức tạp, vì thường bị timer cắt ngang đúng lúc sắp vào flow
- Mục tiêu không phải là tối đa thời lượng mà là chất lượng tối đa trong phạm vi năng lực nhận thức
- Hiệu ứng lãi kép của phản tư và học hỏi: trong nghiên cứu về deliberate practice của Ericsson, thứ tạo nên chuyên môn không phải là số giờ làm việc mà là tư duy phản tư
4 chiến lược deep work của Cal Newport
- Chiến lược tu viện (Monastic): loại bỏ hoàn toàn công việc nông
- Ví dụ tiêu biểu là Donald Knuth đã bỏ email từ năm 1990
- Chiến lược hai chế độ (Bimodal): chia tuần thành ngày deep work và ngày làm việc nông
- Ví dụ: không liên lạc từ thứ Hai đến thứ Tư, thứ Năm đến thứ Sáu xử lý họp và email
- Chiến lược nhịp điệu (Rhythmic): deep work vào cùng một thời điểm mỗi ngày, không ngoại lệ
- Cách tiếp cận "đừng phá vỡ chuỗi" của Jerry Seinfeld
- Chiến lược nhà báo (Journalistic): hễ có khoảng trống là lập tức chuyển vào deep work
- Có thể tận dụng cả các khoảng 30–45 phút, nhưng trên thực tế dễ nhầm lẫn giữa context switching và deep work
- Với đa số lập trình viên, chiến lược nhịp điệu là hiệu quả nhất; điểm mấu chốt là giữ buổi sáng cho coding và không rơi vào cám dỗ phản ứng liên tục của Slack
Vì sao engineering manager cần quan tâm
- Khi thời gian code thực tế mỗi ngày của lập trình viên chỉ là 52 phút, thì một lần gián đoạn tiêu tốn hơn 23 phút khôi phục đồng nghĩa một tin nhắn có thể ăn gần một nửa chỉ tiêu coding trong ngày
- Thí nghiệm của TechSmith: khi loại bỏ hoàn toàn họp hành, mức năng suất cảm nhận tăng 15%, và 85% nhân viên nói rằng họ sẵn sàng thay thế họp bằng giao tiếp bất đồng bộ
- Trong khảo sát 31.000 người của Microsoft, họp kém hiệu quả là yếu tố cản trở năng suất nơi làm việc số 1
- Khuyến nghị cho manager:
- Bảo vệ buổi sáng không bị làm phiền
- Áp dụng no meeting day (ví dụ: thứ Tư)
- Đặt giao tiếp bất đồng bộ làm mặc định thay vì đồng bộ
- Đặt deadline thực tế, cho phép có khoảng trống để khám phá sáng tạo
- Chỉ số để đo hiệu quả: giảm cycle time, mức độ hài lòng của nhóm, điểm số gắn kết, cùng các chỉ số chất lượng như tỷ lệ bug và tỷ lệ phải làm lại
Kết luận
- 3–4 giờ deep programming mỗi ngày không phải là vấn đề thói quen mà là giới hạn vật lý của tải nhận thức
- Trọng tâm là tối ưu những thứ có thể kiểm soát, như tắt thông báo, báo trước với nhóm rằng sẽ phản hồi vào buổi chiều, hoặc thương lượng để tránh họp buổi sáng 2 lần mỗi tuần
- 4 giờ deep work luôn tạo ra kết quả tốt hơn 8 giờ "tập trung nửa vời"
- Vào được trạng thái flow vài giờ mỗi ngày sẽ dẫn tới mã chất lượng cao, rủi ro bug thấp hơn, giải pháp sáng tạo hơn và cân bằng công việc - cuộc sống tốt hơn
- Lập trình viên không phải vận động viên chạy nước rút mà là người chạy marathon, nên cần giữ gìn năng lượng
Ghi chú về AI coding assistant
- Các công cụ như Copilot, Cursor và Claude không kéo dài thời gian deep work, mà chỉ chuyển dịch trọng tâm công việc
- Thay vì viết code từ đầu, việc rà soát đầu ra của AI vẫn đòi hỏi cùng một mức ngữ cảnh, phán đoán và tập trung
- Giới hạn 3–4 giờ không phải do tốc độ gõ mà là giới hạn của bộ não trong việc duy trì các quyết định chất lượng cao, nên việc code xuất hiện nhanh hơn không làm thay đổi điều đó
- Nơi AI thực sự hữu ích là các giờ làm việc nông (shallow hours): phác thảo tài liệu, sinh boilerplate, hỏi cách dùng thư viện...
- Giao các việc này cho AI giúp giữ lại ngân sách deep work cho tư duy kiến trúc và giải quyết vấn đề phức tạp
- Cái bẫy là dùng AI để tạo ra nhiều code hơn mức bạn có thể xử lý bằng tinh thần
- Mục tiêu không phải là có thêm nhiều dòng code mỗi ngày, mà là tập trung tài nguyên nhận thức hữu hạn vào những quyết định quan trọng nhất
13 bình luận
Bản thân nhóm đối chứng đã sai.
Nghiên cứu về nghệ sĩ violin của K. Anders Ericsson không lấy người thành thạo làm chuẩn mà nghiên cứu dựa trên việc luyện tập. Với nhạc cụ, dù có luyện một bản nhạc đến mức hoàn hảo thì vẫn không phải lúc nào cũng bảo đảm một màn trình diễn hoàn hảo (vì mỗi lần biểu diễn đều có biến số). Ngược lại, trong phát triển phần mềm, nhu cầu thường rõ ràng và sau khi hoàn thành thì luôn cho ra cùng một kết quả. Làm liên tục một việc có điểm kết thúc và làm liên tục một việc không có điểm kết thúc là hai chuyện khác nhau rất lớn. Vì vậy, ngay cả việc quy định rằng năng lực nhận thức của con người trung bình là 3~4 tiếng cũng đã có vấn đề, bởi giữa việc phát triển trong 3~4 tiếng do người khác chỉ đạo và tự nguyện phát triển trong 3~4 tiếng lại phát sinh một khác biệt nữa. Bài viết này cho tôi cảm giác là một bài cố gắng khái quát hóa mọi thứ để thuyết phục nghe có vẻ hợp lý rằng 3~4 tiếng là giới hạn năng lực nhận thức của con người. Việc họ có thời gian tập trung là 3~4 tiếng không có nghĩa mọi người đều chỉ có thể tập trung 3~4 tiếng. Trái lại, nó còn giống như một bài viết đặt sẵn giới hạn rồi kêu gọi chúng ta thỏa hiệp rằng chỉ làm việc 3~4 tiếng thôi.
Chuẩn luôn~! Thực sự có nhiều người làm việc rất giỏi mà
Mong mọi người đừng tự đóng khung bản thân bằng đỉnh cao tập trung trong sự nghiệp rồi nghĩ “mình là kiểu người như thế này”. Bài viết này đặt
deep worklàm trạng thái làm việc lý tưởng và cố gắng quá mức để bước vào trạng thái đó. Dĩ nhiên, khi nhìn ra ý tưởng giải quyết vấn đề thú vị và hướng thử nghiệm, thìdeep worksẽ xuất hiện và hiệu suất tăng lên. Nhưng nếu không nhìn ra điều đó mà vẫn tin rằng não của mình thực ra còn thiên tài hơn thế, rồi lúc nào cũng sống trong bất mãn, thì rốt cuộc bạn sẽ càng làm giảm xác suất bản thân bước vào “flow”. Càng thiếu metacognition thì ta càng dễ nghĩ bộ não là của mình nên mình tự quyết được, nhưng trạng thái của bộ não đó tuyệt đối không phải do một mình ta tạo ra. Cần thừa nhận những sự giúp đỡ từ xung quanh đã góp phần tạo nên sự tập trung ấy, không chỉ là để yên cho mình hay cho mình tiền, mà còn là vô số kích thích khác nhau, rồi đến một thời điểm nào đó chúng được kết nối tinh vi theo một hướng, và đó chính là trạng thái tập trung. Dù kết quả ra sao, việc âm thầm biết ơn, không nhất thiết phải thể hiện với người khác, mà tự mình hài lòng ở mức vừa phải và giữ lòng tích cực với bản thân sẽ nâng cao khả năng tập trung và thể trạng về lâu dài.Tôi đang làm ở một công ty làm 3 tiếng buổi sáng, ăn trưa xong rồi làm tiếp 3 tiếng buổi chiều (tổng 7 tiếng, 4 ngày/tuần). Chỉ như vậy thôi mà tôi đã thấy thoải mái hơn rất nhiều về mặt tinh thần.
Công ty tốt quá!
Ai cũng từng có lúc tan làm rồi, khi không còn ai xung quanh và ngồi code một mình thì mọi thứ lại trôi chảy hẳn ra.......;;;
Vì thế nên khi người khác tăng ca thì ngược lại tôi lại về sớm.
Tôi nghĩ có thể tăng thêm đôi chút nhờ rèn luyện, nghỉ ngơi và môi trường phù hợp, nhưng đó vẫn là vắt kiệt sức người nên rất khó duy trì lâu dài. Công ty thì cứ ép để vắt kiệt, dù ngoài mặt không nói ra, và tôi cũng thường thấy có những kỹ sư phải dùng thuốc (thuốc chống trầm cảm, thuốc ADHD) để làm việc.
Đúng vậy, sự thật khó chịu là dịch vụ tâm thần ở Pangyo làm ăn rất tốt.
Tôi nghĩ mỗi ngày chỉ cần một tiếng để lập trình là đủ. Ngay cả trước thời AI, thời gian thực sự dành cho việc lập trình vốn cũng không nhiều, và giờ thì lại càng giảm hơn nữa.
Khi làm phát triển, chơi game hay đọc sách theo kiểu "điều mình muốn làm", có vẻ tôi có thể tập trung hàng giờ liền cho đến khi xong việc đó.
Vậy nên ở đây 4 giờ có lẽ là đang nói đến khả năng tập trung vào những việc "không muốn làm nhưng vẫn phải làm vì đó là nghề nghiệp" (có thể gọi là tập trung bị động chăng?)
Đơn giản thôi. Chắc người nào cũng từng có trải nghiệm vừa chơi game vừa thức trắng đêm mà vẫn giữ được sự tập trung.
Theo kinh nghiệm cá nhân của tôi, khi được làm công việc phát triển mà mình muốn thì dù làm liên tục trong nhiều giờ cũng không thấy đặc biệt mệt.
Việc chạy nhiều phiên tự nó đã trở thành làm nhiều việc cùng lúc, nên cũng có thể làm giảm mức độ tập trung.