Làm thế nào để 1 lập trình viên “lên level”? (phần 2)

51

Level 3: Trở thành 1 thành viên trong đội

Coding là 1 môn thể thao của cả team, và cũng như tất cả tinh thần thể thao thì sẽ luôn có giới hạn trần về khả năng bạn hoàn thành công việc 1 mình.

REVIEW CODE CỦA NGƯỜI KHÁC

“Rà soát nhanh, đọc kĩ, cải thiện nó, test nó và comment” – Vô danh

Thực hiện nhiều reviews hơn để tăng lượng code output nghe khá nghịch lý. Chúng ta có thể điều chỉnh cụm “doing more reviews” bằng “dọn dẹp queue của người khác”. Khi bạn thay đổi quan điểm như thế này, nếu bạn dọn dẹp diff queue của các kĩ sư khác thì họ sẽ review diffs của bạn và gỡ rối cho bạn.

XÂY DỰNG NIỀM TIN VỚI CÁC REVIEWERS/ TEAMMATES CỦA MÌNH

“Tôi đặt niềm tin vào nhóm các kỹ sư chính của mình và nhìn chung, chúng tôi đã nỗ lực để review code của nhau 1 cách nhanh chóng” – Vô danh

Nếu bạn có trong tay đội ngũ các reviewers tin tưởng lẫn nhau và viết được những dòng code tốt, bạn có thể thực hiện những thay đổi 1 cách an toàn, dựa trên động lực rằng nếu 1 kỹ sư phá hỏng thứ gì đó, ngay khi phát hiện ra vấn đề, họ sẽ làm việc chăm chỉ để sửa lại nó.

MINH BẠCH VỚI NHỮNG GÌ BẠN ĐANG LÀM

“Sử dụng RFC (Yêu cầu comment) diffs khi thực hiện greenfield development (phát triển 1 hệ thống trong 1 môi trường hoàn toàn mới mà không cần lo lắng phải tích hợp với hệ thống khác). Việc lấy phản hồi về các Headers/Proposed APIs sẽ tiết kiệm nhiều thời gian hơn so với việc phải thay đổi hướng đi sau đó” – Adam Ernst

Nếu mọi người không biết bạn đang làm gì, thì thông tin mà họ cần để xử lý lúc review 1 diff sẽ rất phức tạp. Khi bạn thông báo sớm đến các reviewers/ teammates, họ có thể góp ý gỡ bỏ những rào cản trước khi bạn phải mất thời gian hoàn tất khối lượng lớn công việc.

ĐƯA RA FEEDBACK TỐT

“Tập trung vào những góp ý chất lượng cao, thay vì để tâm đến những lỗi lầm nhỏ nhặt. Nếu phát hiện bugs, hãy chỉ ra, nhưng hãy tin tưởng các kỹ sư rằng họ đã test rồi (và tin tưởng rằng họ sẽ fix bất kì bug nào bị phát giác” – Bob Baldwin

“Nếu tôi không hiểu được những góp ý, tôi sẽ lướt qua chúng hoặc tôi sẽ đề xuất những thay đổi để tiếp thu những đóng góp có giá trị. Nếu đó là những phản hồi tốt và nếu có đủ những request changes, tôi sẽ đào sâu nghiên cứu những vấn đề pratice/unit, trái lại tôi sẽ chấp nhận với vài dòng notes” – Ari Chivukula

Một xu hướng phổ biến trong hầu hết câu trả lời với câu hỏi: “Chiến lược review 1 diff của bạn là gì?” là sẽ phân tích khả năng hiểu diff từ cấp độ cao trước. Sau khi đã hiểu structure cơ bản của diff, chúng ta tiếp tục phân tích code style và logical checking.

REQUEST CHANGES

“Thường xuyên dùng đến các request changes – điều tồi tệ nhất có thể xảy ra là họ có re-quest review (nếu họ nghĩ request changes của bạn đang gặp vấn đề, việc này có thể động viên người viết)” – Adam Ernst

“Nếu tôi nhận ra mình đang phá hỏng request changes, tôi sẽ nhờ đến unit tests hoặc 1 refactor để hạn chế nguy cơ này. Nếu nó quá lớn và quá phức tạp và nếu không ai muốn để tâm đến nó, hãy yêu cầu break diffs hoặc ít nhất đưa ra những gợi ý cho những cách thức tốt hơn trong tương lai” – Vô danh

Đối với những vấn đề không có tính chuẩn mực, request changes về diffs có thể khiến bạn gặp khó xử. Tuy nhiên, về lâu dài, nó sẽ khuyến khích những practices code và validation tốt hơn, từ đó các kỹ sư có thể học hỏi được từ những sai lầm của mình và phát triển hơn.

THỪA NHẬN RẰNG BẠN KHÔNG BIẾT

“Nếu không biết nhiều về 1 phần nào đó của codebase, tôi sẽ không chối bỏ mà thừa nhận điều đó 1 cách thẳng thắn” – Michael Novati

Bạn sẽ không thực sự góp ý được nhiều trong 1 cuộc đội thoại khi giả vờ biết gì đó mà bạn thực sự không thông thạo. Hãy trung thực với kiến thức của mình và khuyến khích mọi người tìm kiếm những kỹ sư biết nhiều về những hệ thống nào đó.

Level 4: ORGANIZE & HUSTLE

“Tôi sẽ loại bỏ những công việc cá nhân trên lịch của mình và bằng cách bổ sung những cuộc họp, tôi ghi chú những thứ phải làm trong ngày . Nếu không tự nhắc mình trên lịch, tôi sẽ quên ngay” – Michael Novati

Hầu hết những kĩ sư mà tôi phỏng vấn đều sử dụng những công cụ khác nhau để theo dõi những công việc mà họ đang làm. Đó là hệ thống kết hợp giữa nhiều công cụ như giấy, các nhiệm vụ phải làm, email, lịch, danh sách, các mục tiêu cấp độ cao. Nhưng, rất nhiều kĩ sư đã “phân cấp” để quyết định xem công việc nào nên làm trước cũng như xây dựng hệ thống mục lục nhằm sắp xếp các công việc và emails đang chờ xử lý.

FAIL FAST, ITERATE

“Nếu có thể, tôi cố gắng quay vòng code nhanh dù không chắc liệu đây có phải cách tối ưu (để lấy comments) và tôi thích fail fast hơn là cố gắng nghĩ thông suốt ý tưởng 100%” – Ari Chivukula

“Tôi không hề thấy sợ hãi code gì cả, tôi có thể tham gia zone dễ dàng và giải quyết vấn đề” – Michael Novati

Một thứ khiến nhiều kĩ sư nản lòng (trong đó có cả tôi) là nỗi sợ thất bại. Cố gắng tạo nên 1 sản phẩm hoàn hảo ngay lập tức có thể trở thành nỗi ám ảnh khiến chúng ta nghiêm trọng hóa vấn đề. Hãy tập thói quen nhảy vào viết code dù chưa biết chính xác nó sẽ trở thành cái gì vì nó sẽ giúp chúng ta iterate và thấy được những kết quả nhanh hơn.

CÂN BẰNG GIỮA CÔNG VIỆC/ CUỘC SỐNG

“Một ai đó “quan trọng” dành nhiều thời gian xử lý công việc hơn sẽ giúp bạn khá nhiều. Nhưng thay vào đó,, tôi lại thích chạy nước rút bằng cách làm việc thật chăm chỉ và sau đó thả lỏng dần. Ví dụ: 2 tháng chăm chỉ và 1 tháng thảnh thơi. Phân chia như thế này sẽ hiệu quả hơn so với 3 tháng làm việc với tốc độ tương đương nhau (nhưng cách thức này có thể không áp dụng được với tất cả mọi người) vì công việc không phải là thứ tuyến tính (theo 1 đường thẳng) – Vô danh

“Ngụ ý: Thinking about a problem in the shower (nghĩ ra và bàn thảo 1 ý tưởng mới) cũng có ý nghĩa riêng của nó” – Adam Ernst

Thực tế cho thấy những kĩ sư này làm việc rất chăm chỉ. Họ dành lượng lớn thời gian để viết rất nhiều code. Mặc dù tôi không đặt ra câu hỏi riêng về khả năng cân bằng cuộc sống, mặc dù tôi đã lướt qua những mẩu chuyện vụn vặt trong cuộc sống của họ và mặc dù nhiều kĩ sư dường như chỉ biết tập trung vào công việc, tôi vẫn khá ngạc nhiên khi các kĩ sư đạt đến sự cân bằng công việc/ cuộc sống và có thể bắt kịp với các kỹ sư “toàn năng”. Bài học lớn nhất mà tôi rút ra được là bạn có thể vừa là 1 trong những nhân viên năng suất nhất vừa có cuộc sống công việc cân bằng nếu bạn có thể tối ưu hóa workflow của mình.

PARTING THOUGHTS

“Đối xử với người khác theo cách mà bạn muốn được đối xử không khiến bạn trở nên chuyên nghiệp hơn. Bạn cần phải là 1 kỹ sư mà người khác muốn làm việc cùng, mà để trở thành 1 người như thế, hãy học hỏi từ những phản hồi, góp ý. Chủ động hỏi ngay từ ban đầu, hỏi thường xuyên. Những người được lắng nghe là những người cảm nhận được giá trị ở bản thân” – Ari Chivukula

Sau khi thực hiện bài phỏng vấn này, tôi đã nhận ra quy trình lập trình của mình phát triển từng chút một (các thành viên trong team đã rất cố gắng lôi kéo sự chú ý của tôi vì tôi có những chiếc headphones chống ồn). Phân nhỏ các diffs, yêu cầu reviews, và danh sách To-do (những việc phải làm) đã xuất hiện trong quá trình lập trình của tôi trước đây, nhưng bây giờ tôi làm việc hiệu quả hơn khi biết được cách sử dụng tối ưu các công cụ đó.

Tôi muốn gửi lời cảm ơn đến tất cả các kỹ sư Facebook mà mình đã phỏng vấn, Michael, Adam, Ari, Bob và tất cả những người ẩn danh. Tôi cũng muốn cảm ơn Kent vì đã động viên tôi viết bài này và cảm ơn Aimee và Andrew vì đã giúp tôi chỉnh sửa.

PHỤ LỤC

  1. Diff: Khi 1 kỹ sư Facebook đề cập đến diff, họ đang đề cập đến 1 phiên bản khác được tạo ra khi sử dụng công cụ nguồn mở phabricator. Những phiên bản này là các thay đổi về code được đặt vào phabricator để các kỹ sư khác review. Các kĩ sư có thể bình luận, yêu cầu thay đổi và chấp nhận các thay đổi code trước khi code đưa vào production và bắt đầu ảnh hưởng đến những người dùng thực sự. Đây là bước validation cần được thực hiện cho mỗi đoạn code tại Facebook (và rất nhiều công ty khác), vì nó đảm bảo sự phối hợp và góp ý liên tục giữa các kĩ sư.
  2. Stacked Diffs: Stacking diffs là cấp độ cao hơn việc tạo diff thông thường. Khi stack diffs, bạn đang tạo ra 1 logical dependency giữa các diffs, tại đây diff ở phần trên của stack đang xây dựng chức năng của tất cả các diffs dưới nó. Nhờ đó, các kỹ sư phát triển những tính năng với các thay đổi nhỏ, đơn giản, giống như bước tiến triển theo cấp số nhận tiến tới mục tiêu lớn hơn.

Nguồn: IDE Academy via Medium