Điều gì khiến lập trình viên làm việc hiệu quả

• Nhiều yếu tố ảnh hưởng đến năng suất của lập trình viên
• Một số yếu tố rõ ràng và dễ đo lường, nhưng một số khác khó đo lường nên thường bị bỏ sót

Biết cần xây dựng gì (Knowing what to build)

• Xây dựng nhanh một thứ sai lầm hoàn toàn không hề hiệu quả
  • Cần biết khách hàng đang yêu cầu điều gì,
  • Biết điều gì là có thể chấp nhận được với các nhóm khác (có thể có bao nhiêu chỉ mục trên bảng DB, có thể chia sẻ loại thông tin nào nếu xét về mặt pháp lý?),
  • Và cần biết những gì đã từng được thử trước đây nhưng không hiệu quả

Làm ít việc hơn

• Hoàn thành công việc nhanh là tốt, nhưng còn tốt hơn nếu ngay từ đầu đã có thể "không cần làm"
• Quy trình của công ty có thể thêm vào những "công việc bận rộn" làm giảm năng suất
  • Đôi khi có những cách điều chỉnh quy trình khá đơn giản để tạo ra cùng một giá trị với lượng công việc ít hơn nhiều
• Có thể cần một mức nỗ lực nhất định để "duy trì hệ thống hoạt động" (Keep the lights on, KTLO)
• Đây là những việc phải làm liên tục (ví dụ: trả lời ticket hỗ trợ), nhưng không giúp dự án tiến lên
• Những công việc này có thể trông rất hiệu quả nếu nhìn qua nhiều chỉ số khác nhau (số ticket hoàn tất, số commit được merge), nhưng chúng không giúp công ty trở nên tốt hơn

Công cụ phản hồi nhanh

• Lập trình viên liên tục sử dụng công cụ: editor, git, hệ thống build
• Thời gian mà các công cụ này cộng thêm có thể tạo ra chi phí rất lớn tùy theo mức độ chúng được dùng thường xuyên đến đâu
• Không chỉ là chi phí theo giờ, mà còn làm đứt mạch tập trung của lập trình viên

Kiến thức trong đầu của lập trình viên

• Khó đo lường
• Nếu mọi điều kiện khác là như nhau, lập trình viên có nhiều kiến thức liên quan hơn sẽ làm việc hiệu quả hơn
  • Vì họ biết code hoạt động như thế nào nên không cần đào sâu vào code quá nhiều,
  • Họ biết cách sử dụng công cụ và biết những cạm bẫy cần tránh
  • Họ đặt ra đúng câu hỏi
  • Lập trình viên 10x là có thật, và họ là những người "hiểu rõ codebase"
• Điều này có nghĩa là một nhóm không nên sở hữu nhiều thứ hơn mức mà cả nhóm có thể cùng nhau lưu giữ trong đầu. (Lý tưởng là bus factor phải lớn hơn 1: lý thuyết Bus Factor)
  • Điều đó cũng có nghĩa là nên giảm thiểu tần suất thay đổi quyền sở hữu
  • Không ai có thể hiểu rõ thứ đó hơn người đã tạo ra nó
  • Lý tưởng nhất là những người lần đầu làm việc với hệ thống nên cùng làm việc và học hỏi từ những người đã quen với hệ thống đó
• Cần có ranh giới rõ ràng giữa các hệ thống
  • Một interface gọn gàng với ngữ nghĩa đơn giản có nghĩa là bạn có thể suy nghĩ về các thuộc tính của interface mà không cần phải biết toàn bộ hệ thống phía sau nó
• Tài liệu là một cách tốt để truyền đạt kiến thức
  • Đặc biệt quan trọng khi lập trình viên cần thực hiện một công việc cụ thể mà họ chưa quen
  • Nếu thiếu tài liệu, lập trình viên có thể phải tự nghiên cứu cách làm, mắc lỗi rồi phải làm lại, hoặc phải chờ nhóm khác trả lời câu hỏi, khiến tiến độ chậm đi
  • Điều này có thể nhanh chóng biến một công việc 1 giờ thành một công việc 2 ngày
  • Nếu có 100 lập trình viên đều phải làm việc này, chi phí do thiếu một trang tài liệu có thể tương đương với lương cả năm của một lập trình viên
• Điều này cũng có nghĩa là cần tăng mức độ chuyên môn hóa (Specialization)
  • Yêu cầu mọi lập trình viên làm đủ loại việc một cách dàn trải là không hiệu quả
  • Một giờ dành cho quy trình viết một số hệ thống bảo mật hoặc lập kế hoạch năng lực khác hẳn với một giờ dành để hiểu domain nhằm giải quyết vấn đề

Hạ tầng hữu ích

• Hạ tầng nên là trợ lực chứ không phải vật cản
• Nó nên được căn chỉnh một cách hợp lý với mọi loại công việc cần thực hiện
• Mọi phần của hạ tầng đều được thiết kế với một số use case cụ thể trong đầu, nhưng trong dự án đôi khi có những trường hợp vượt ra ngoài các use case đó
  • Khi đó, thật bực bội nếu nghe rằng "bạn chỉ được dùng hạ tầng của chúng tôi" hoặc "hạ tầng của chúng tôi không làm được việc này"
  • Khi đó bạn либо phải tìm cách lách quanh hạ tầng, либо phải tốn thời gian vào các cuộc họp để thuyết phục chủ sở hữu hạ tầng về yêu cầu của mình

Ít nợ kỹ thuật

• Code hiện có sẽ không bao giờ hoàn toàn phù hợp với chính xác công việc bạn sắp làm
  • Người viết code ban đầu không có "quả cầu tiên tri" để biết bạn sẽ thay đổi điều gì
  • Nhưng có những đoạn code dễ thay đổi hơn rất nhiều so với những đoạn khác
• Câu trả lời cho "Làm sao để làm được X?" không nên là "chúng ta phải thiết kế lại toàn bộ thứ này"
• Nếu có quá nhiều nợ kỹ thuật, chỉ một thay đổi nhỏ về tính năng cũng buộc bạn phải thay đổi hệ thống ở quy mô lớn hơn
• Giảm nợ kỹ thuật giúp giảm thiểu phạm vi bạn phải (a) hiểu và (b) chỉnh sửa
• Các dự án nhằm trả nợ kỹ thuật phải được hoàn thành
  • Nếu bỏ dở giữa chừng hoặc hạ thấp ưu tiên, hệ thống có thể còn tệ hơn lúc ban đầu

Tỷ lệ lỗi thấp

• Nếu xảy ra lỗi khi chạy công cụ, lỗi build, lỗi triển khai hoặc hồi quy do lỗi production thì đó là thời gian bị lãng phí
• Giảm xác suất các lỗi này sẽ cải thiện năng suất
• Ngoài kỹ sư trực tiếp gặp lỗi, những lỗi này còn có xu hướng làm tốn thời gian của cả nhóm sở hữu hệ thống bị lỗi (vì họ phải cùng phân tích và sửa lỗi)

Thực hành hiệu quả là thực dụng (Productive practices are practical)

• Cách tốt nhất để học cách giải quyết một vấn đề cụ thể là viết prototype
• Nếu môi trường cản trở việc tạo prototype, thì ngay cả cách tiếp cận hiệu quả nhất cũng có thể bị cản trở
• Nếu việc sử dụng công cụ giám sát quá khó khăn, lập trình viên sẽ tạo ít dashboard hơn, đo lường ít hơn, và các quyết định sẽ bớt dựa trên dữ liệu hơn
• Ngược lại, nếu chia một thay đổi lớn thành các code review nhỏ hơn, việc review và triển khai code sẽ dễ dàng hơn

Kỹ sư có thể tập trung đến mức nào

• Kỹ sư làm việc theo tiến độ sản xuất và cần có khả năng tập trung
• Sự tập trung đó có thể bị lấy mất bởi các cuộc họp và sự gián đoạn
• Sự gián đoạn còn bao gồm các lệnh CLI chậm, test chậm, và những việc mà bạn phải điều tra vì không biết cách thực hiện
• Phải suy nghĩ về quá nhiều việc trong một tuần cũng làm suy giảm khả năng tập trung
• Deadline sắp tới hoặc những câu hỏi chưa được quản lý trả lời cũng chiếm dụng "RAM tinh thần" ngay cả khi bạn đang cố tập trung vào việc khác

Hoàn tất công việc

• Xây được 50% không phải là 50% năng suất mà là 0% năng suất
• Không có gì kém hiệu quả hơn công việc bị bỏ đi
• Đôi khi bỏ dở dự án giữa chừng lại là quyết định đúng
  • Chống lại ngụy biện chi phí chìm đôi khi là điều đúng đắn
  • Nhưng không nên có một kiểu mẫu nhất quán là cứ thay đổi ưu tiên trước khi dự án hoàn thành
  • Nếu vậy, năng suất của cả nhóm có thể rơi về 0

Kết lại

• Không phải lúc nào cũng có thể xây dashboard để đo lường tất cả những yếu tố đa dạng này, nhưng ta vẫn có thể biết những điều ở trên ảnh hưởng thế nào đến năng suất
• Giải quyết những vấn đề này có thể làm tăng mạnh khối lượng công việc thực sự hoàn thành
• Một số vấn đề lại dễ sửa đến bất ngờ
  • Chỉ cần bỏ ra vài giờ để viết tài liệu, công ty có thể tiết kiệm hàng nghìn giờ
• Khi cần đốn cây thật nhanh, hãy bắt đầu bằng việc mài sắc lưỡi cưa

[kofmania]

Đây là một bài viết có khá nhiều phần kết thúc bằng “và”.

[laeyoung]

"Nếu thiếu tài liệu, tốc độ làm việc của lập trình viên có thể chậm lại vì họ phải tự nghiên cứu cách thực hiện công việc, mắc lỗi rồi làm lại, hoặc chờ đội khác trả lời câu hỏi."

Không phải là tài liệu phát triển, nhưng khi tôi nhờ những người vừa được onboarding cập nhật tài liệu onboarding của công ty sau 1 tuần, tài liệu thực sự trở nên tốt hơn. Vì ở thời điểm mới vào công ty và chưa có bất kỳ thông tin nào, chính họ là những người hiểu rõ nhất mình cần gì.

Tôi cũng nghĩ có lẽ việc nhiều Readme.md của các dự án mã nguồn mở trên GitHub được viết khá tốt là nhờ có rất nhiều người dùng đầu tiên đến và để lại phản hồi.

[devsepnine]

Dạo này có quá nhiều việc đổ về nên đầu óc rối tung cả lên T_T

[ahwjdekf]

Hạ tầng phải là thứ hỗ trợ chứ không phải rào cản --> nhưng hiện tại ở các công ty trong nước Hàn Quốc, người ta lấy bảo mật làm cái cớ nên điều này hoàn toàn không đúng.

[hero512]

Tôi hiểu cảm xúc đó, nhưng bài viết này được viết bằng tiếng Anh. Có vẻ như tình hình ở các công ty nói tiếng Anh cũng tương tự.

[kuroneko]

Có vẻ như đây không chỉ là tóm tắt mà gần như ở mức độ bản dịch rồi... Cảm ơn bạn đã tổng hợp chi tiết.