# Đọc The Pragmatic Programmer như một FDE: ba thói quen cho người làm việc một mình ở chỗ khách hàng > Ở chỗ khách hàng, bạn không có trưởng nhóm đứng ra đỡ lời, và cuốn sách của David Thomas với Andrew Hunt dạy đúng những thói quen bạn cần khi chỉ có một mình. Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-the-pragmatic-programmer/ Một trong những mục đầu tiên của *The Pragmatic Programmer* có tên "The Cat Ate My Source Code", tức là con mèo đã ăn mất mã nguồn. Đó là kiểu bào chữa mà một forward deployed engineer không thể nói trước mặt khách hàng, vì ở đó không có ai đứng ra nhận lỗi thay bạn. Cuốn sách của David Thomas và Andrew Hunt ra mắt lần đầu vào tháng 10/1999. Một trong những bài học mà nhà xuất bản liệt kê thẳng ra là hãy chịu trách nhiệm cho công việc và sự nghiệp của chính mình, và đó cũng là điều đầu tiên một FDE phải học khi đứng một mình trước hệ thống của người khác. Nếu bạn là developer có 2 đến 8 năm kinh nghiệm và đang muốn chuyển sang FDE, cuốn này đáng đọc trước nhiều sách kỹ thuật khác. Nó không dạy công cụ. Nó dạy thói quen, mà thói quen mới là thứ quyết định bạn có trụ được khi làm việc một mình hay không. Bản nên đọc là *The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery* (Addison Wesley, tháng 9/2019, 320 trang), một bản viết lại có thêm tip, thêm chủ đề và chỉnh sửa trong toàn bộ cuốn sách. Sách không dựng một lý thuyết có hệ thống mà gom nhiều lời khuyên ngắn, không gắn với ngôn ngữ, framework hay phương pháp nào. ## Ý thứ nhất: mang phương án đến, đừng mang lời bào chữa Tip mà FDE dùng nhiều nhất có lẽ là "Provide options, not excuses". Nó là cách biến lời dặn về trách nhiệm ở trên thành hành động cụ thể. Thử hình dung một tình huống. Khách hàng muốn agent đọc toàn bộ kho hợp đồng scan trước thứ Sáu, nhưng chất lượng OCR trên bản scan cũ rất tệ. Nếu bạn chỉ nói "dữ liệu xấu, không kịp", bạn đang đưa ra lời bào chữa. Nếu bạn mang đến ba phương án thì khác: chỉ chạy trên bản scan mới, chạy hết nhưng gắn cờ độ tin cậy thấp để người duyệt lại, hoặc lùi hạn một tuần để làm sạch dữ liệu. Lúc đó bạn đang giúp khách hàng ra quyết định. Hãy ghi những lần như vậy vào nhật ký công việc, mỗi lần chừng ba dòng. Khi đi phỏng vấn, dòng nhật ký đó có thể viết lại thành câu trả lời STAR. *Situation*: kho hợp đồng scan quá cũ so với hạn demo. *Task*: phải có kết quả vào thứ Sáu. *Action*: đề xuất ba phương án và nói rõ cái giá của từng phương án. *Result*: khách chọn phương án có người duyệt và demo diễn ra đúng hạn. Dòng CV tương ứng có thể viết là: "Proposed three scope trade-offs when legacy scans blocked the pilot; shipped the human-review option on the original demo date." Một dòng như vậy kể được cả quyết định lẫn kết quả, thay vì chỉ liệt kê công nghệ đã dùng. **Điểm mấu chốt:** Ở chỗ khách hàng, lời bào chữa khiến bạn mất uy tín, còn các phương án lựa chọn giúp bạn được tin tưởng hơn. ## Ý thứ hai: không để cửa sổ vỡ, kể cả trong hệ thống của người khác Phần đầu sách có mục "Software Entropy", và từ đó ra đời tip "No broken windows": thấy thiết kế hay đoạn code tồi thì sửa ngay. Bản tóm tắt của Dan Lebrero đánh số tip này là Tip 5, còn các bản tóm tắt khác đánh số khác. Với FDE, khó nhất là cửa sổ vỡ thường nằm trong hệ thống của khách. Giả sử bạn thấy một script ETL để mật khẩu cứng ngay trong code. Bạn có thể chưa được phép sửa, nhưng bạn nên ghi lại, báo cho người phụ trách và đề xuất cách sửa ngay trong ngày. Nếu chỗ hỏng đầu tiên bị bỏ qua, những chỗ hỏng sau sẽ dễ được bỏ qua hơn. ## Ý thứ ba: dựng tracer bullet trong tuần đầu Tip 20 trong bản tóm tắt của Lebrero là "Tracer Bullets", còn gọi là walking skeleton. Ý tưởng là dựng một đường đi mỏng chạy xuyên suốt hệ thống từ đầu đến cuối, rồi mới làm dày từng phần. Ở chỗ khách hàng, điều đó có nghĩa là trong tuần đầu tiên, chỉ cần một loại tài liệu đi được từ lúc tải lên đến lúc ra câu trả lời trên màn hình của chính khách hàng. Chạy bằng dữ liệu thật trên hạ tầng thật sẽ giúp bạn phát hiện sớm những vấn đề như firewall, quyền truy cập hay định dạng lạ. Nếu đợi đến tuần thứ sáu mới thấy thì đã quá muộn. ## Áp dụng sai thì sao? Ba thói quen này dễ bị làm nửa vời. Lỗi thường gặp nhất là đưa ra phương án mà không nói cái giá: "chạy hết nhưng gắn cờ" nghe hay, nhưng nếu bạn không nói rõ ai sẽ duyệt và mất bao nhiêu giờ, khách vẫn không có đủ thông tin để chọn. Lỗi thứ hai là sửa cửa sổ vỡ của khách khi chưa ai cho phép. Đẩy thẳng bản vá cho script ETL kia có thể làm hỏng một job khác mà bạn không biết, và biến thiện chí thành sự cố. Ở hệ thống của người khác, "sửa ngay" nên hiểu là báo ngay, đề xuất ngay. Lỗi thứ ba là dựng tracer bullet trên dữ liệu mẫu hay máy của chính mình. Khi đó nó không còn là tracer bullet nữa, vì nó né đúng những thứ bạn cần phát hiện sớm. ## Đọc theo thứ tự nào? Hãy đọc trọn phần "A Pragmatic Philosophy" trước. Phần này gồm bảy mục ngắn, đi từ trách nhiệm với sự nghiệp, chuyện bào chữa, entropy của phần mềm, đến phần mềm đủ tốt, knowledge portfolio và giao tiếp. Mục "Good-Enough Software" đặc biệt hữu ích khi khách hàng muốn kết quả hoàn hảo trong một khoảng thời gian không đủ. Sau đó, đọc phần về tracer bullets trước khi nhận dự án đầu tiên. Đến khi bắt đầu phải làm việc với đội của khách hàng, hãy đọc phần "Pragmatic Projects", phần nói về làm việc nhóm và cách khiến người dùng hài lòng. Tip "Be a Catalyst for Change" hợp với giai đoạn này: thay vì ép đội của khách đổi cách làm, hãy cho họ tận mắt thấy cách làm mới sẽ trông ra sao, để chính họ muốn đổi. Cuối cùng là "Invest Regularly in Your Knowledge Portfolio". Mỗi dự án FDE buộc bạn học một lĩnh vực mới, nên hãy coi việc ghi lại những gì đã học là một khoản đầu tư đều đặn chứ không để dành đến lúc rảnh. Cuốn sách đáng được mở lại đúng lúc bạn cần nó nhất: khi đứng trước hệ thống của người khác, một mình, và cần một câu trả lời tốt hơn "con mèo đã ăn mất mã nguồn". **Thử ngay tuần này:** - Đọc 7 mục của phần 'A Pragmatic Philosophy', từ 'It's Your Life' đến 'Communicate!', mỗi tối một mục - Lần tới khi phải nói 'không làm được', hãy chuẩn bị sẵn ba phương án kèm cái giá phải trả của từng cái, rồi ghi lại vào nhật ký - Chọn một dòng nhật ký trong tuần và viết lại thành một câu trả lời STAR và một dòng CV ## Nguồn - [The Pragmatic Programmer, 20th Anniversary Edition (Pragmatic Bookshelf)](https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) - [The Pragmatic Programmer - Wikipedia](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) - [The Pragmatic Programmer 20th Anniversary Edition book summary (Dan Lebrero)](https://danlebrero.com/2020/07/08/the-pragmatic-programmer-20th-anniversary-edition-book-summary/) - [Pragmatic Programmer Tips (gloutnikov.com)](https://gloutnikov.com/post/pragmatic-programmer-tips/)