The Pragmatic Programmer — Hành trình lập trình viên trách nhiệm

Mở đầu

Mình đang tiếp tục series đọc sách "The Pragmatic Programmer" (20th Anniversary Edition) — cuốn sách mà bất kỳ lập trình viên nào cũng nên đọc ít nhất một lần trong đời. Hôm nay mình tới Topic 2: The Cat Ate My Source Code. Nghe cái tên hài hước vậy thôi, nhưng nội dung bên trong lại nói về một trong những phẩm chất quan trọng nhất của một lập trình viên: tinh thần trách nhiệm.

Ảnh: Alexandra Krainyukhova — Pexels

The Cat Ate My Source Code — Lỗi tại con mèo?

Bạn đã bao giờ nghe đồng nghiệp than thở: "Máy chủ sập, không phải lỗi tôi", "Thằng vendor không giao API kịp", hay "Sếp đổi yêu cầu vào phút chót" chưa? Chắc chúng ta ai cũng từng ít nhất một lần rơi vào tình huống đó — hoặc tệ hơn, tự mình nói ra những câu tương tự 😅

Topic này dạy mình một bài học đơn giản nhưng sâu sắc: Người lập trình viên chuyên nghiệp đưa ra giải pháp, không đưa ra lý do.

Tác giả nói rất hay: nếu bạn nhận trách nhiệm làm một việc gì đó, bạn phải chịu trách nhiệm cho cả kết quả — dù có những yếu tố ngoài tầm kiểm soát của bạn. Ổ cứng cháy mà không có backup? Lỗi của bạn. Vendor giao hàng trễ mà không có phương án dự phòng? Lỗi của bạn luôn. Bạn có quyền từ chối nhận một trách nhiệm nếu nó quá rủi ro hoặc viển vông, nhưng một khi đã nhận thì phải chịu trách nhiệm đến cùng.

Ảnh: Christina Morillo — Pexels

Tip 4 trong sách là thứ mình tâm đắc nhất: "Provide Options, Don't Make Lame Excuses". Trước khi đến gặp sếp hay đồng nghiệp để giải thích tại sao cái này trễ, cái kia hỏng, hãy tự hỏi: mình có thể làm gì để cứu vãn tình hình? Thay vì nói "em không làm được", hãy nói "em có thể làm A, B, hoặc C". Khác biệt hoàn toàn về mặt tinh thần đúng không?

Một điểm thú vị khác là về trust trong team. Tác giả ví von team tin tưởng nhau như một nhóm ninja cao cấp đột nhập vào hang ổ của kẻ ác — xong tới lượt mình setup laser guidance grid thì nói "Sorry, tụi bây ơi tao quên cái laser ở nhà, con mèo nó chơi với cái đèn đỏ rồi" 🙈 Nghe buồn cười nhưng nếu thiếu tin tưởng, teamwork sụp đổ ngay lập tức. Một lập trình viên không giữ lời, không trung thực về sai sót của mình sẽ làm xói mòn lòng tin của cả đội.

Cảm nhận của mình

Mình thấy Topic 2 này cực kỳ thực tế. Không phải ai cũng dám nhận lỗi, đặc biệt là trong môi trường mà sai lầm bị "soi" rất kỹ. Nhưng theo mình, chính sự trung thực và dám chịu trách nhiệm mới là thứ giúp mình trưởng thành nhanh nhất.

Cá nhân mình từng nhiều lần nói "Em không biết" và tập thói quen nói thêm "— nhưng em sẽ tìm hiểu". Cái "nhưng" nó thay đổi toàn bộ thông điệp: từ bó tay thành chủ động. Khách hàng hay sếp đều đánh giá cao điều đó hơn là một câu excuse thiếu thuyết phục.

Một điểm hay nữa: tác giả khuyên mình hãy nói chuyện với con mèo (hoặc rubber duck trên bàn) trước khi nói với người thật. Nghe vô lý nhưng khi đọc to lên, cái excuse nghe ngu vãi luôn, mình sẽ tự nhận ra liền 😂

Ảnh: Kira auf der Heide — Pexels

Kết

Topic 2 là một lời nhắc nhở nhẹ nhàng nhưng thẳng thắn: làm lập trình viên chuyên nghiệp không chỉ là code giỏi, mà còn là thái độ sống có trách nhiệm. Khi bạn nhận lỗi và đưa ra giải pháp, bạn không chỉ cứu được dự án — bạn còn xây dựng được lòng tin với đồng đội. Và đó mới là thứ giá trị nhất.

Hẹn mấy bạn ở bài sau với Topic 3: Software Entropy — khi code bắt đầu mục nát và làm sao để ngăn nó biến thành "bình nước sôi hỏng bỏng không" nhé! 👋