Lập trình viên nhận nhiệm vụ bất khả thi: sửa code rác có thể gây sập cả thành phố - và quyết định... không làm
Một lập trình viên từng được giao nhiệm vụ sửa hệ thống giám sát rác tại nhà máy điện, nơi chỉ cần một lỗi nhỏ có thể gây ra thảm họa mất điện toàn thành phố. Sau khi tưởng tượng ra những kịch bản tồi tệ nhất, anh đã quyết định... không động vào bất cứ thứ gì. Câu chuyện là bài học sâu sắc về việc biết khi nào nên từ chối một nhiệm vụ rủi ro cao.

Lập trình viên nhận "nhiệm vụ bất khả thi": sửa code rác có thể gây sập cả thành phố - và quyết định... không làm
Trong một câu chuyện được chia sẻ trên chuyên mục On Call của The Register, một lập trình viên từng đối mặt với tình huống cực kỳ căng thẳng: được giao sửa một hệ thống phần mềm tồi tệ tại nhà máy điện, nơi chỉ cần một sai sót nhỏ cũng có thể gây ra thảm họa mất điện trên diện rộng. Sau khi tưởng tượng ra những viễn cảnh kinh hoàng, anh đã đưa ra quyết định táo bạo nhất trong sự nghiệp: không làm gì cả.
Nhiệm vụ bắt đầu từ một cuộc điện thoại
Câu chuyện bắt đầu khi một kỹ sư được gọi là "Socrates" — hồi đó còn là quản lý trẻ của một bộ phận phần mềm nhỏ — nhận lệnh từ sếp đến một nhà máy điện để hướng dẫn khách hàng sử dụng hệ thống giám sát mà công ty anh đã bán. Vấn đề là hệ thống này được cài đặt bởi một bên khác và hoàn toàn không có tài liệu kỹ thuật đi kèm.
Hồi đó, Socrates tự nhận mình là "cao thủ lập trình" và thấy chuyến đi đến nhà máy điện rất thú vị nên đồng ý ngay. Nhưng khi đến nơi, anh dần nhận ra mọi chuyện không hề đơn giản.
Bước vào "hang ổ" của thiết bị cổ xưa
Khi được dẫn đến khu vực đặt thiết bị cần sửa, Socrates bị ấn tượng bởi quy mô của nhà máy: "Những cỗ máy quay vĩ đại gầm rú, xung quanh gần như không có người". Cuối cùng, anh tìm thấy "vật thể" của mình trong một góc tối: một chiếc máy tính CP/M cũ kỹ, phủ đầy bụi, với các card I/O kết nối vào hàng loạt dây cáp chạy đi mất hút.
Điều đáng sợ nhất là anh không có ý tưởng gì về chức năng thực sự của hệ thống này. Tên của nó — "bộ phát hiện quá tốc độ tua-bin" (turbine overspeed detector) — gợi lên những hình ảnh đầy đe dọa. Socrates mô tả:
"Tua-bin là thứ có cánh quạt sắc như dao, được hơi nước đẩy để quay máy phát điện. Những tua-bin này cực kỳ lớn, và ý nghĩ chúng quay quá tốc độ thực sự đáng sợ."
Kịch bản thảm họa trong đầu
Socrates bắt đầu tưởng tượng ra những viễn cảnh tồi tệ nhất — từ những cánh quạt bị văng ra như dao phóng, đến các lỗi dây chuyền làm sập lưới điện của cả thành phố. Anh liên tưởng đến các cảnh hành động trong phim Mission: Impossible và The Matrix (dù thời điểm đó, cả hai bộ phim này đều chưa ra mắt).
Với quyết tâm "không làm hỏng bất cứ thứ gì", Socrates ngồi xuống trước bàn phím và bắt đầu đọc code.
Phát hiện "code rác" kinh điển
Kết quả kiểm tra còn tệ hơn anh tưởng tượng. Đoạn code mà anh thấy được mô tả là "kinh khủng":
- Hàng loạt lệnh GOTO ngẫu nhiên, khiến luồng chạy của chương trình không thể theo dõi.
- Các thao tác I/O vào địa chỉ bất kỳ, kết hợp với phép tính số học, AND, OR với những con số trông chẳng có ý nghĩa gì.
- Toàn bộ code không có một dòng comment nào để giải thích chức năng.
"Dù còn trẻ, tôi đã từng tiếp xúc với các chương trình có cấu trúc tốt, và đoạn code này thực sự quá tệ. Không có một lời bình luận nào để giúp tôi hiểu mình đang nhìn thấy thứ gì."
Quyết định "anh hùng": không làm gì cả
Sau một hồi đắn đo, Socrates nhận ra rằng phương án khôn ngoan nhất trong hoàn cảnh này không phải là cố sửa code, mà là... lùi lại cẩn thận khỏi bàn phím và để nguyên hệ thống như hiện tại.
Anh rời khỏi nhà máy, báo cáo lại với sếp rằng hệ thống không thể can thiệp an toàn, và chấp nhận rằng mình "không hoàn thành" nhiệm vụ được giao.
Bài học về sự khôn ngoan trong kỹ thuật
Nhìn lại, Socrates đánh giá trải nghiệm này là một bài học quan trọng trong sự nghiệp: "Có những thứ tốt nhất là nên để yên." Câu chuyện của anh là một minh chứng sống động cho nguyên tắc "first, do no harm" trong kỹ thuật — đặc biệt khi làm việc với các hệ thống cũ, quan trọng và thiếu tài liệu.
Đối với các lập trình viên và kỹ sư công nghệ tại Việt Nam, đây cũng là một lời nhắc nhở giá trị: không phải lúc nào nhiệm vụ được giao cũng nên hoàn thành bằng mọi giá. Đôi khi, biết từ chối đúng lúc là quyết định kỹ thuật thông minh nhất, nhất là khi rủi ro tiềm ẩn vượt xa lợi ích có thể đạt được.