Vì sao FDE nên đọc The Missing README không theo mục lục

Mỗi lần nhận một engagement mới, FDE lại thành kỹ sư mới vào nghề. Codebase lạ, quy trình review lạ, và có thêm một người quản lý không nằm trong sơ đồ tổ chức của bạn.

Phần lớn sách nghề nghiệp mặc định bạn chỉ là người mới một lần. The Missing README: A Guide for the New Software Engineer của Chris Riccomini và Dmitriy Ryaboy cũng vậy: No Starch Press phát hành bản giấy ngày 4/8/2021, dày 288 trang, viết cho người mới bước vào nghề.

Trang chính thức của sách hứa dạy những kỹ năng kỹ thuật phần mềm mà quản lý muốn bạn biết. Phần giới thiệu trên Barnes & Noble nói thẳng hơn: biết lập trình mới chỉ là một nửa chặng đường, vì nhiều kỹ năng và quy trình quyết định thành bại không được dạy ở trường hay bootcamp nào.

Với người đang làm hoặc muốn làm FDE, giá trị của cuốn sách nằm ở chỗ khác. Nó là checklist cho cái “tuần đầu” mà bạn phải lặp lại ở mỗi khách hàng, và bạn đi qua tuần đầu càng nhanh thì càng sớm tạo ra giá trị.

Một buổi cà phê với mentor, đóng thành sách

Penguin Random House giới thiệu đây là cuốn sách trưởng nhóm kỹ thuật mong mọi kỹ sư mới đọc trước ngày đầu, còn Gwen Shapira ví nó như buổi cà phê với một mentor cấp cao.

Theo Greg Wilson, phạm vi sách trải từ continuous integration, refactoring, hỗ trợ kỹ thuật, lập kế hoạch agile đến làm việc với quản lý. Đó là thói quen nghề, thứ FDE phải học lại theo cách riêng của từng khách.

Mười bốn chương, nhưng đừng đọc theo mục lục

Sách có 14 chương. Những gợi ý dưới đây là cách đọc dựa trên tên chương và mô tả ngắn mà sách công bố, ghép với nhịp làm việc của một FDE chứ không phải tóm tắt từng trang.

Thứ tự hợp lý là chương 2 trước ngày đầu, chương 10 trước tính năng lớn đầu tiên, phần viết code vận hành được khi code bắt đầu chạy trên hạ tầng của khách, rồi chương 9 trước go-live. Phần làm việc với quản lý thì đọc dần suốt engagement, vì bạn có cả quản lý của mình lẫn quản lý phía khách.

Ý thứ nhất: gọi tên cái mình chưa biết

Riêng tên chương 2, “Getting to Conscious Competence”, đã là một lời khuyên dùng được ngay. Hiểu theo nghĩa đen, đó là làm được việc trong khi biết rõ ranh giới hiểu biết của mình. Ở đội của khách, người mới nguy hiểm nhất là người chưa biết mình thiếu gì.

Thử hình dung tuần đầu ở một chuỗi bán lẻ cần pipeline dự báo tồn kho. Bạn kẻ bảng ba cột: đã hiểu (ngôn ngữ, framework), hiểu một phần (cách họ deploy), chưa biết (bảng nào là nguồn sự thật cho số tồn kho).

Cột thứ ba chính là danh sách câu hỏi cho buổi họp đầu tiên. Nó cũng là thứ khiến khách thấy bạn nghiêm túc.

Ý thứ hai: design doc bắt đầu từ định nghĩa vấn đề

Chương 10 là chương có mô tả rõ nhất: quy trình thiết kế gồm thử nghiệm, xác định vấn đề, tài liệu hóa và cộng tác. Ở khách hàng, bước xác định vấn đề là chỗ customer discovery gặp kỹ thuật, và cũng là chỗ dễ sai nhất.

Lời khuyên thực tế: trước tính năng lớn đầu tiên, viết một tài liệu ngắn mở đầu bằng định nghĩa vấn đề mà khách đã xác nhận, rồi mời ít nhất một kỹ sư phía khách duyệt. Họ sẽ bắt được những ràng buộc không ai ghi lại, và sẽ là người bảo vệ thiết kế đó khi bạn đã rời đi.

Ý thứ ba: ai bị gọi lúc hai giờ sáng?

Khi code bắt đầu chạy ở khách, phần dạy viết code vận hành được trở nên thiết thực: logging, metrics, cấu hình và lập trình phòng thủ. Ngay sau đó là chương 9, “Going On-Call”.

Một cuốn sách cho người mới mà dành hẳn một chương cho việc trực sự cố thì thông điệp đã rõ: hệ thống chạy thật sẽ có lúc hỏng, và người mới cũng phải sẵn sàng.

Với FDE, hai phần này phải đọc cùng nhau, vì hệ thống chạy trên hạ tầng và dữ liệu của người khác. Cũng với ví dụ bán lẻ, giả sử pipeline lỗi vào đêm trước đợt khuyến mãi. Nếu không có log, không có metric và chưa ai thống nhất ai nhận cảnh báo, sự cố kỹ thuật sẽ biến thành sự cố niềm tin.

Việc nên làm: trước go-live, kiểm tra code của bạn ghi log gì và đẩy metric về đâu, rồi chốt bằng văn bản với khách ai trực, ai được xem log.

Chỗ sách bỏ trống

Greg Wilson đặt tên bài bình luận là “What’s Missing from ‘The Missing README’”. Ông chỉ ra sách không bàn đến quyền riêng tư, phân biệt đối xử bởi thuật toán, quấy rối nơi làm việc, quyền người lao động hay trách nhiệm pháp lý.

Với FDE, khoảng trống này lớn hơn so với một kỹ sư nội bộ, vì bạn chạm vào dữ liệu thật của khách và đôi khi của khách hàng của họ. Đọc sách xong, hãy tự thêm một câu vào checklist ngày đầu: dữ liệu này về ai, được dùng cho việc gì, và phía khách đã xác nhận bạn được phép dùng như vậy chưa.

Ai nên đọc, và đọc xong thì làm gì

Sách hợp nhất với kỹ sư phần mềm đang chuyển sang FDE, nhất là người đã quen một codebase duy nhất trong nhiều năm. FDE lâu năm có thể đọc lướt, chỉ dừng ở chương 2, 10, phần operable code và chương 9.

Khi phỏng vấn một vị trí FDE, bạn nên hỏi thẳng hai câu rút từ sách: design doc do ai duyệt, và sau go-live ai trực on-call. Câu trả lời giúp bạn hình dung mình sẽ chịu trách nhiệm đến đâu trước khi nhận việc.

Trong CV, đừng chỉ ghi “triển khai hệ thống X”. Nếu từng viết design doc cùng kỹ sư phía khách hay từng trực on-call cho hệ thống chạy dữ liệu thật, hãy ghi rõ và kèm một chi tiết cụ thể, chẳng hạn tài liệu đó đã được ai phía khách duyệt.

Cuốn sách được viết để giúp bạn qua năm đầu đi làm. FDE thì gặp lại năm đầu đó ở mỗi khách hàng mới, chỉ khác là phải đi qua nó nhanh hơn.