How Do You Know They Are Wrong?

Dear diary,

Có một câu anh senior từng hỏi mình trong công việc mà đến giờ mình vẫn nhớ: “Làm sao em biết họ sai?”

Chuyện xảy ra trong một đợt release gần đây. Team mình làm việc với nhiều team ở những nơi khác nhau trên thế giới. Mỗi bên có một cách viết code, thiết kế hệ thống và giải quyết vấn đề riêng. Có những cách mình nhìn vào là thấy khó hiểu ngay.

Một team trong số đó thường khiến bọn mình có cảm giác như vậy. Code nhìn khá chán. Có những quyết định kỹ thuật mà team mình không hiểu tại sao họ lại chọn. Một vấn đề tưởng không quá phức tạp cũng mất nhiều cuộc họp để thống nhất; có pull request kéo dài cả sprint chỉ để review và phản hồi.

Ban đầu là khó chịu với một đoạn code cụ thể. Sau một thời gian, nó thành một nhận xét quen miệng: “Team đó code dở.” Có issue mới từ họ, mình dễ nghĩ chắc họ lại làm sai. Gặp một quyết định mình không thích, mình cũng chẳng thấy cần hỏi thêm. Team đó trước giờ vẫn vậy mà.

Mình đã nghĩ như thế, cho đến lúc anh hỏi câu đó.

Mình im. Thật sự là không biết trả lời sao. Mình thấy cách của họ không tốt, nhưng nếu phải giải thích vì sao nó sai trong hoàn cảnh của họ thì mình lại thiếu quá nhiều thứ.

Mình đâu biết hết yêu cầu ban đầu, thời gian họ có, hay những giới hạn của hệ thống lúc đó. Mình cũng không biết trước khi team mình tham gia, hệ thống đã trải qua những lần thay đổi nào. Có thể mình đang nhìn một quyết định cũ bằng những gì mình biết ở hiện tại, rồi cho rằng người đưa ra quyết định ấy cũng phải biết như mình.

Điều khiến mình nghĩ lâu hơn lại là chuyện trong chính team mình. Từ bao giờ bọn mình mặc định rằng team kia luôn sai? Có thể nó bắt đầu từ một lỗi thật, một lần review không tốt, rồi được nhắc lại đủ nhiều. Người mới vào nghe người cũ kể, sau đó cũng nhìn code của họ với cùng một suy nghĩ.

Chẳng ai cần nói ra thành quy tắc. Chỉ một câu “team đó code dở” cũng đủ trở thành cách cả nhóm nhìn những việc họ làm.

Mình thấy mình cũng có thể nhìn bất kỳ ai như vậy. Một người làm chậm, mình nghĩ họ kém. Một quyết định mình không đồng ý, mình nghĩ người đưa ra nó thiếu năng lực. Trong khi có khi mình mới chỉ thấy phần cuối của câu chuyện.

Có thể họ thiếu thời gian hoặc nguồn lực. Có thể yêu cầu đổi giữa chừng. Cũng có thể đó là một đánh đổi họ đã biết rõ: cách này chưa đẹp, có nợ kỹ thuật, nhưng hiện tại chưa thể sửa. Mình không biết điều nào đúng nếu chưa hỏi.

Hiểu bối cảnh cũng không làm một đoạn code sai trở thành đúng. Nếu hệ thống có vấn đề, mình vẫn cần nói ra và tìm cách sửa. Chỉ là mình muốn phân biệt được lỗi mình có thể chỉ rõ với cảm giác “mình sẽ không làm như vậy”. Hai chuyện đó dễ bị trộn vào nhau quá.

Từ đó, trước khi kết luận, mình muốn biết yêu cầu là gì, giới hạn nằm ở đâu, và vì sao họ chọn cách này. Nếu cuối cùng vẫn thấy họ sai, ít nhất mình có thể giải thích bằng một điều rõ ràng hơn là “vì cách của em tốt hơn”.

Trong hơn một năm đi làm, mình thấy đây là một trong những điều đáng nhớ nhất. Anh không chỉ cho mình một design pattern hay cách sửa đoạn code ấy. Anh khiến mình nhận ra mình đã nhìn người viết nó như thế nào trước cả khi bắt đầu đọc.

Mình không chắc lần sau sẽ thôi phán xét ngay được. Có lẽ vẫn sẽ có lúc nhìn một đoạn code rồi nghĩ “ai lại làm thế này”. Nhưng mình muốn nhớ để hỏi thêm một câu trước khi tin vào nhận xét đầu tiên của mình.

“Làm sao mình biết mình đúng?”