Quản Lý Thời Gian Và Năng Lượng Khi Làm Senior Engineer: Deep Work, Context Switching Và Burnout

Càng lên vị trí cao hơn, thời gian thực sự ngồi code sâu càng ít đi. Trong khi kỳ vọng về chất lượng kỹ thuật lại cao hơn.

Nghịch lý đó ít ai nói thẳng. Một ngày của Senior Engineer bị xé bởi code review, trả lời câu hỏi đồng nghiệp, họp sync, và mentoring. Việc nào cũng quan trọng. Mà việc nào cũng giành thời gian với phần khó nhất của công việc.

Càng lên cao, càng ít thời gian code sâu

Thử hình dung một ngày không có kế hoạch. 9h vào làm, check Slack, trả lời vài câu hỏi. 9h30 vào một cuộc họp sync 30 phút. 10h quay lại code được 20 phút thì có người hỏi về một bug production. 10h30 code tiếp thì bị interrupt bởi một review request cần xong gấp. Đến 11h, bạn nhận ra mình chưa thực sự vào mạch được lúc nào.

Vấn đề không nằm ở việc có quá nhiều việc. Nằm ở chỗ không có khối thời gian nào đủ dài và liên tục để não bộ đi vào trạng thái tập trung sâu.

Lấy ví dụ thiết kế lại luồng đồng bộ dữ liệu giữa service booking và hệ thống thanh toán. Việc đó không giải quyết được trong các mẩu 15-20 phút rời rạc. Nó cần ít nhất 90 phút liên tục để não nạp đủ ngữ cảnh, rồi mới bắt đầu tạo ra insight thật sự.

Ngày đó trôi đúng theo trình tự này:

timeline
    title Một ngày không kế hoạch
    9h : Vào làm<br/>check Slack, trả lời vài câu hỏi
    9h30 : Họp sync 30 phút
    10h : Code được 20 phút<br/>thì có người hỏi về bug production
    10h30 : Code tiếp, bị interrupt<br/>bởi review request cần xong gấp
    11h : Vẫn chưa vào mạch được lúc nào

Đổi ngữ cảnh ăn mất bao nhiêu

Mỗi lần bị ngắt giữa chừng một việc đang tập trung cao, bạn mất thời gian của riêng việc bị ngắt. Chưa hết. Bạn còn mất thêm một khoảng để nạp lại ngữ cảnh — toàn bộ mental model của vấn đề đang giải quyết: những biến số, giả định, nhánh logic đang cân nhắc. Phải nạp xong mới làm tiếp hiệu quả như trước lúc bị ngắt.

Cảm giác “hôm nay họp nhiều mà chẳng làm được gì” không sai đâu. Tổng thời gian họp có thể chỉ 2 tiếng. Nhưng nó phá vỡ 2-3 khối deep-work tiềm năng, mỗi khối vốn tạo ra nhiều giá trị hơn 2 tiếng họp cộng lại.

Người giỏi quản lý năng lượng không từ chối mọi cuộc họp. Họ chủ động gom các việc nông (shallow work) lại với nhau, rồi giữ phần thời gian còn lại cho việc sâu.

Block lịch deep-work thế nào

Vài nguyên tắc cụ thể mình áp dụng:

• Giờ vàng cố định: chọn 2-3 tiếng mỗi ngày, thường là buổi sáng sớm trước khi Slack/email bắt đầu ồn ào, đánh dấu “busy” trên lịch như một cuộc họp thật. Không ai được đặt lịch đè lên, kể cả chính mình.
• Batch shallow work: dồn việc trả lời tin nhắn, review code nhỏ, cập nhật ticket vào 1-2 khung giờ cố định trong ngày, ví dụ 11h và 16h. Đừng xử lý ngay khi notification xuất hiện.
• Tắt notification khi vào deep-work. Không phải vì thiếu trách nhiệm. Mà vì một bug production thật sự khẩn cấp hiếm khi xảy ra, và đồng đội biết cách gọi trực tiếp nếu thật sự cần gấp.
• Một việc một lúc: trong khối deep-work chỉ mở một vấn đề duy nhất. Phát hiện vấn đề phụ trong lúc làm thì ghi chú lại để xử lý sau, đừng nhảy sang ngay.

Khi làm backend cho hệ thống booking ở SmileViet, những workflow phức tạp nhất gần như không thể thiết kế đúng nếu chỉ có 20 phút rảnh giữa hai cuộc họp. Ví dụ thiết kế lại saga xử lý đặt tour với nhiều bước compensation: giữ chỗ, xử lý thanh toán, xác nhận, rollback nếu lỗi. Mấy thiết kế đó luôn ra đời trong khối deep-work được bảo vệ nghiêm ngặt.

Mentoring có nhất thiết đối đầu với deep-work?

Nhiều người nghĩ càng ít bị hỏi thì càng năng suất. Không hẳn. Mentoring là trách nhiệm cốt lõi của Senior, không phải thứ tranh giành thời gian với deep-work. Vấn đề nằm ở thời điểm, không phải ở việc có làm hay không.

Cách mình dùng: đặt office hours cố định mỗi ngày, ví dụ 15h-16h. Đồng đội biết đó là lúc tốt nhất để hỏi, pair-program, hoặc review sâu cùng nhau. Số lần bị interrupt bất ngờ trong giờ deep-work giảm hẳn. Đồng đội cũng có kỳ vọng rõ ràng thay vì phải đoán khi nào bạn rảnh.

Gom lại, một ngày có deep-work trông như thế này:

flowchart TD
    S["Sáng sớm<br/>2-3 tiếng giờ vàng"] --> DW["Deep work<br/>một vấn đề duy nhất, tắt notification"]
    DW --> B1["11h - batch shallow work<br/>tin nhắn, review code nhỏ, ticket"]
    B1 --> OH["15h-16h - office hours<br/>hỏi, pair-program, review sâu"]
    OH --> B2["16h - batch shallow work"]

Dấu hiệu burnout đến sớm

Burnout không đến đột ngột. Nó tích luỹ dần, và thường bị bỏ qua vì mình vẫn “làm được việc” trong một thời gian dài trước khi sụp đổ thật sự. Vài dấu hiệu sớm mình tự theo dõi:

• Giảm hứng thú với vấn đề kỹ thuật mà trước đây thấy thú vị. Bài toán khó không còn khiến bạn tò mò, chỉ thấy mệt.
• Chất lượng quyết định giảm dần: hay chọn giải pháp “cho xong” thay vì giải pháp đúng, dù biết rõ sự khác biệt.
• Khó ngủ dù cơ thể mệt. Não vẫn “chạy” công việc ngay cả khi đã rời bàn phím từ lâu.
• Cáu gắt với những việc nhỏ mà bình thường không đáng để ý.

Giữ được lâu dài, không phải nghỉ phép một tuần

“Nghỉ phép một tuần rồi quay lại y như cũ” không giải quyết được gì. Phải sửa cấu trúc công việc hàng ngày để không rơi vào trạng thái quá tải liên tục.

• Giữ ranh giới rõ ràng giữa giờ làm và giờ nghỉ. Tắt thông báo công việc ngoài giờ đã thống nhất, trừ trường hợp thực sự khẩn cấp.
• Định kỳ nhìn lại khối lượng công việc đang gánh, và chủ động trao đổi với quản lý khi thấy vượt khả năng bền vững. Đừng âm thầm gồng cho đến khi kiệt sức.
• Dành thời gian cho những hoạt động hoàn toàn không liên quan đến màn hình — đi bộ, tập thể dục, đọc sách giấy. Não cần nghỉ thật, không phải chuyển từ màn hình này sang màn hình khác.

Quản lý năng lượng không phải một kỹ năng “mềm” tách riêng khỏi công việc kỹ thuật. Một Senior Engineer kiệt sức sẽ đưa ra những quyết định kiến trúc tệ hơn một Middle Engineer còn tỉnh táo. Mà những quyết định đó thì nằm lại trong codebase lâu hơn cả cơn mệt.