Bạn là 1 lập trình viên & muốn “lên level”? (phần 1)

174

Để trở thành 1 dev có hiệu suất cao, bạn có thể học từ kinh nghiệm, sách vở hoặc từ những lần thử nghiệm và lỗi lầm. Nhưng, 1 trong những cách tốt nhất là học trực tiếp từ 1 dev đã có hiệu suất cao. Tôi đã phỏng vấn 1 vài kĩ sư tại Facebook để tìm ra lý do cơ bản giúp các dev làm việc với năng suất cao nhất.

Cấp độ 1: Giảm thiểu những thứ gây xao nhãng không cần thiết

Điều này trông có vẻ hiển nhiên nhưng khi nếu dồn nén lại thì hệ quả sẽ ảnh hưởng lớn đến năng suất làm việc.

Trì hoãn những cuộc họp

“Tôi chỉ tham dự vài cuộc họp khi có thể. Nhìn chung tôi không tham dự bất kì cuộc họp thường niên nào. Điều này có thể không áp dụng được cho tất cả mọi người vì các nhà quản lý thích sắp xếp lịch họp định kì, còn bạn lại không muốn làm quản lý giận dữ. Nhưng tôi đề nghị trình bày chi phí của 1 cuộc họp như sau: 10 kỹ sư x 30 phút/ tuần + 10 phút task switching với chi phí cao = chúng ta trả tiền 1 kỹ sư để dành 1 nửa ngày/ tuần cho cuộc họp đó. Tốn rất nhiều thời gian. Tôi luôn mong có thể thay thế các cuộc họp định kì bằng 1 cuộc họp khi có điều gì đó cần thảo luận hoặc cần giải quyết” – Vô danh

Một điều mà rất nhiều kĩ sư cần đề xuất mạnh mẽ là cuộc họp chỉ có thể  mang đến giá trị khi buổi họp đó thực sự cần thiết. Lúc này, chúng ta cần cẩn trọng và xác định liệu mỗi cuộc họp cá nhân có quan trọng hay không.

Sẵn sàng làm những nhiệm vụ nhỏ

“Khi lập trình hoặc diffing, tôi nhanh chóng dọn dẹp danh sách email của mình để đưa về trạng thái inbox 0” – Michael Novati

Có thời điểm khi bạn chỉ mới kết thúc 1 nhiệm vụ và có 5-15 phút trước cuộc họp hoặc bạn vừa tạo 1 test run sẽ chạy trong 1, 5 hoặc 15 phút. Phản ứng thông thường sẽ là “Tôi không thể hoàn thành được nhiều việc như vậy chỉ trong lượng thời gian như thế”. Đây là phản ứng thông thường và xem ra khá logic khi rất nhiều nhiệm vụ tốn của bạn từ 30 phút đến 1 giờ để có sự tập trung cao độ, nhưng nên nhớ không phải tất cả nhiệm vụ đều như thế. Rất nhiều kĩ sư đề cập rằng xuyên suốt 1 ngày, họ duy trì danh sách các nhiệm vụ mà họ có thể dễ dàng thực hiện trong những khoảng thời gian ngắn hơn. Theo dõi emails, phân loại các reviews, phản hồi các bài đăng nội bộ hoặc thậm chí các công việc nhỏ có thể điền vào những slot thời gian ngắn để giúp bạn năng suất hơn và luôn cập nhật tin tức cả ngày.

Hãy đeo headphones để loại bỏ tiếng ồn

Nếu từng làm việc ở 1 trong những công ty phần mềm, bạn sẽ nhận ra cách thiết kế những tầng lầu theo những vùng không gian rộng mở. Đây là vũ khí lưỡi kép dành cho các kỹ sư. Một mặt, bạn có thể ngồi gần hơn với team của mình. Sự phối hợp và tình đồng đội giữa những người trong team cũng đạt mức cao khi bạn có thể đặt những câu hỏi và xây dựng mối quan hệ với các thành viên. Khuyết điểm ở đây là khả năng tập trung quý giá của bạn có thể ảnh hưởng bởi tiếng ồn ở khu vực xung quanh. Âm thanh có tính lan truyền và khi bạn đang cố gắng nắm bắt 1 vấn đề, 1 cuộc hội thoại lớn tiếng phía sau sẽ  ảnh hưởng đến năng suất của bạn. Đây chính là thời điểm để bạn đeo headphones. Không chỉ đơn giản dựng nên những “bức tường” quanh tai của mình và bật to âm lượng mà công nghệ đã trở nên hiện đại hơn rất nhiều. Những tai nghe ngăn tiếng ồn thực sự sẽ loại bỏ tiếng ồn nền (background noise) và giảm những cuộc hội thoại ở khu vực gần. Sau cuộc phỏng vấn với Michael Novati, tôi đã mua những tai nghe mà anh ấy giới thiệu và tôi thực sự không thể tưởng tượng được quy trình lập trình của mình sẽ ra sao nếu không có chúng.

Làm việc khi mọi người không thể làm phiền bạn

(Về việc giải quyết những gián đoạn) “Chuyển đến New York cách đây 2 năm thực sự đã giúp tôi rất nhiều” – Adam Ernst

“Tôi thường lưu lại những công việc khó khăn hơn, phức tạp hơn cho những ngày thứ Tư (khi tôi làm việc ở nhà và không bị làm phiền)” – Bob Baldwin

“Tôi không thể thực sự hoàn thành công việc trong những giờ làm việc “bình thường” và phải phụ thuộc vào những giờ làm thêm để thực sự hoàn thành chúng” – Vô danh

“So với các thời điểm khác trong ngày, tôi thường hoàn thành việc trong khoảng từ 6h đến 9h sáng. Thời gian không bị làm phiền nhiều sẽ đóng vai trò rất quan trọng” – Vô danh

Phải thừa nhận rằng thông tin quan trọng nhất mà tôi có được khi nói chuyện với các kỹ sư là rất nhiều người phải làm việc nhiều giờ. Tuy nhiên, lý do họ làm việc nhiều giờ như thế cũng rất thú vị. Khi sáng sớm, vào buổi tối muộn và cuối tuần – vì đây là những thời điểm không ai làm phiền họ. Bằng cách tìm kiếm thời điểm có ít sự phiền nhiễu trong ngày, họ đã có thời gian thúc đẩy những nhiệm vụ lớn và viết code.

Giảm thiểu những emails/ thông báo ồn ào

“Tôi đã tắt tất cả những thông báo email không quan trọng, chỉ nhận những email cần phải hành động và thúc giục bản thân kiểm tra những trang review/ các nhiệm vụ ở tỷ lệ hợp lý thực sự giúp tôi ít bỏ lỡ những thứ mà mình cho spam” – Ari Chivukula

Nếu bạn đã ngừng kiểm tra email ngay lúc nhận được 1 mail mới, 1 ngày của bạn sẽ không bị lệch định hướng bởi những thứ gây xao nhãng. Bằng cách loại bỏ và lọc lại những thông báo, bạn có thể làm việc những khoảng thời gian dài hơn mà không bị xao nhãng.

Đừng để mất trạng thái 

“Khi tôi đã bị làm phiền (hoặc phải đi vào nhà vệ sinh), tôi “lưu lại trạng thái” trong đầu, giống như lưu lại tình trang trong 1 gameboy giả lập để có thể trở lại và phục hồi nhanh nhất có thể” – Michael Novati

“Luôn dừng 1 ngày giữa lúc đang làm 1 nhiệm vụ đơn giản hoặc khi nhiệm vụ liên quan đến máy móc. Điều này sẽ giúp bạn có được 1 điểm bắt đầu dễ dàng trong ngày kế tiếp và trở lại cái “vùng” đó, thay vì làm lại từ đầu” – Adam Ernst

Đối với tôi, khi bị mất trạng thái lập trình tức là khi tôi đang suy nghĩ sâu sắc về một vấn đề thì bị gián đoạn và quên những gì tôi đã suy nghĩ. Như vậy, tôi phải trải qua quá trình tư duy một lần nữa.

Trong trường hợp gián đoạn khi bạn đang ở trong “zone”, cách tốt nhất là trì hoãn việc bị gián đoạn. Nếu bạn đang bị gián đoạn trong khi tập trung, nói với người bạn đang trò chuyện rằng bạn sẽ trở lại với họ, ghi chú nhanh và tiếp tục làm việc cho đến khi bạn có 1 điểm dừng hợp lý. Sau đó, giải quyết tất cả những thứ gián đoạn đang “chồng chất” đợi bạn.

Có rất nhiều cách để “save your state” – lưu lại trạng thái như viết xuống quá trình suy nghĩ hiện tại, viết 1 test đang dang dở, hoặc đơn giản hóa vấn đề trong tâm trí của bạn.

Cấp độ 2: Viết các diff nhỏ “tốt hơn”

Code tốt đồng nghĩa với nhiều thứ: có tính chức năng, dễ review, bền vững…

Hãy viết những diffs nhỏ hơn

“Rất nhiều diffs “showing your work” khi thực hiện 1 bộ vấn đề trong engineer” – Vô danh

Mỗi kỹ sư mà tôi phỏng vấn đều nhấn mạnh cách thức phân chia những thay đổi về code thành các modules logical sẽ giúp mọi người hiểu và chấp nhận nhanh chóng. Bằng cách giảm các cognitive load (cognitive load mô tả gánh nặng của con người về trí nhớ ngắn hạn khi phải làm các task phức tạp) đến từ các diffs mà họ gửi đi, những người review sẽ tự tin chấp nhận thay đổi hơn. Ngoài ra, khi giảm kích cỡ diffs, những thay đổi trở nên ít đáng sợ hơn đối với các reviewers, nhờ đó băng thông cũng nhanh hơn.

Trước 6 tháng, tôi đã tập hợp danh sách những kỹ sự được hỏi bằng cách truy vấn kĩ sự nào đã cam kết nhiều diff nhất. Điều này nhiều khả năng sẽ đến 1 bộ các kĩ sư viết rất nhiều diff nhỏ, trong khi số lượng người viết các diff lớn sẽ ít hơn.

STACKING DIFFS[2] & MULTITASKING

Hầu hết các kỹ sư đều đề cập rằng họ sẽ tập stack những thay đổi về diff, tạo các dependencies phù hợp với logic của chúng:

“Thỉnh thoảng, khi tôi có 1 diff thực sự lớn lập trình 1 cách có tổ chức, tôi sẽ trở lại và bắt đầu lại từ đầu và chia chúng thành các bước logic, hệ quả là tôi sẽ thay đổi mọi thứ trong lúc cải thiện chất lượng code tổng thể” – Vô danh

“Tôi không bao giờ stack diff, thay vào đó tôi làm vài công việc độc lập song song và luân phiên chuyển đổi giữa chúng khi tôi đợi reviews. Ngoài ra chia nhỏ 1 thay đổi lớn thành những phần độc lập cũng rất hiệu quả, ví dụ: thêm 1 interface, thêm 1 endpoint với vài thứ phải làm… Stack hiệu quả mà không cần các dependencies cứng giữa các diffs và thay vào đó sử dụng placeholders. Nhìn chung, structure code của mình để bạn không cần stacking hoặc sub branch có nghĩa là mỗi diff có thể được review, ra mắt và hoàn lại 1 cách dễ dàng” – Michael Novati

“Nếu tôi cảm thấy mình đang gộp nhiều diffs vào 1 diff đơn, tôi sẽ ngưng stack lại và đặt vào đó 1 trong các logical pieces” – Vô danh

“Các diff phải nhỏ hoặc ít nhất phải dễ review. Chúng không chỉ cần review dễ dàng và nhanh hơn, mà khi tôi sẽ suy xét những gì mình đang làm 1 logical pieces, tôi nhận ra viết code tốt hơn, tốn rất ít thời gian debug. Ngoài ra, tôi cũng thành thục các diffs đã được stack để tạo ra những diff nhỏ dễ quản lý” – Ari Chivukula

“Tôi sử dụng các stacked diffs 1 cách rộng rãi. Ngoài việc cho phép bản thân giữ được trạng thái không block khi tôi đang đợi code reviews, việc suy nghĩ về các cách thức chia code thành những diff nhỏ hơn cũng giúp tôi thấy được bức tranh toàn cảnh về những gì mình đang làm và thậm chí còn đơn giản hóa được cấu trúc” – Vô danh

Kể cả khi kĩ sử đã sử dụng stacked diffs hay làm việc với nhiều diffs song song đều ít bị ảnh hưởng đến hiệu suất, cho thấy 2 phương thức đều hỗ trợ các kĩ sư làm việc năng suất 1 cách đáng kinh ngạc.

UNIT TESTING

“Để bản thân cảm thấy thoải mái, tôi rất test rất ít” – Michael Novati

“Mọi người tự tin hơn khi chấp nhận code có unit test” – Vô danh

Unit testing có thể là vấn đề gây tranh cãi ở 1 vài công ty công nghệ và hầu hết team/ công ty sẽ có chỉ dẫn riêng xác định liệu các kĩ sư có nên viết tests hay không. Nếu đang ở công ty mà 1 ai đó khác đang tính thay đổi code mà bạn đã viết, thì cách tốt nhất là đảm bảo người đó không phá dòng code kia và thực thi chức năng của code đó trong các test.

GIAO TIẾP

“Với các diff phức tạp hơn, tôi sẽ thêm 1 số ít các reviewers phù hợp, chia sẻ diff trong những nhóm phù hợp. Nếu không có bất kì hành động nào, tôi thường ping 1 diff 1 lần trong ngày. Nếu không có hành động nào trong vài ngày, tôi sẽ hỏi mọi người về những gì họ thấy hoảng sợ về diff đó và thực hiện các thay đổi trong structure. Cuối cùng, tôi luôn giao tiếp nhiều nhất có thể thông qua tiêu đề. Tôi luôn bắt đầu với “[Product/ Tag]” – để mọi người mập mờ biết được diff đó nói về cái gì, và nếu muốn 1 lời chấp nhận nhanh chóng tôi sẽ đặt tiêu đề “[Product-Asap] hoặc “Product-Pushblocker]” – Michael Novati

Thực tế, có rất nhiều cách để đối thoại với các diff reviews của bạn. Theo kinh nghiệm, hãy “play diff by diff”. Nếu diff sẽ được 1 ai đó review mà người này không tương tác với bạn 1 cách thường xuyên, bạn có thể bổ sung context vào phần mô tả và tiêu đề nếu bạn chỉ có được 1 review từ người trong team. Trong trường hợp logic rắc rối, bạn có thể comment trong sections của diff mà bạn thực sự muốn mọi người kiểm tra lần 2.

Đặt ra những tiêu chuẩn sớm trong những cuộc họp design có thể giảm nhẹ quy trình viết code và xây dựng APIs và structure tốt để tích hợp các hệ thống có thể giảm những khó khăn trong development line.

Đừng ngần ngại ping reviews về diff. Nếu các reviewers thực sự không muốn review diff của bạn, họ có thể thôi việc hoặc đề xuất 1 người khác. Những diff cứ xếp hàng chờ đợi như vậy sẽ biến thành những xung đột trong tương lai.

Nguồn: IDE Academy via Medium