Bài viết được anh Trung Vu chia sẻ tại group Facebook Viet Tech

1. Don’t (just) patch the open wound

Hồi mới đi làm, mình hay bị cái tật được giao bug cái là ráng nhảy vào reproduce rồi solve sao cho “fix” là được, ko còn repro được nữa là “ổn”. Nhưng khi push code lên thì reviewer hay boss sẽ hỏi những câu đại loại như root cause là gì, tại sao tới giờ này bug mới surface mà ko phải trước đây, có gì mới đổi trong code base caused nó ko, etc. Và boss mình có nói với mình 1 câu

“Don’t just dive in head first. Take a step back, take a broader look. What is the true root cause of the problem? Because if we fix the problem not knowing its root cause, all we are doing is just putting a bandage on an open wound. And that wound will keep getting bigger over time.”

Cái này về sau cũng giúp mình khá nhiều trong cuộc sống. Vì tính mình khá nóng (vội), nên thường thấy gì là giải quyết đó. Nhưng thời gian sau này thì mình sống chậm lại hơn. Giải quyết vấn đề gì cũng ráng suy nghĩ xem cái cốt lõi của nó là gì mình có đang truly fix nó không, hay chỉ vẫn đang tìm cách dán cái miếng bandage đó.

2. Don’t offer solution(s), before truly knowing/understanding the problem. No one knows everything

Hồi lúc mình mới vào cty hiện tại, cty có 1 ông VP rất giỏi, lại rất siêng, và rất chịu khó đọc code. Sáng nào mình vào cty chạy bộ lúc 6am là cỡ 6:30-7am đã thấy ổng vào ngồi máy rồi. Và ngày nào cũng 6-7pm mới về. Ổng có lẽ là người hiểu cái code base tốt và tường tận nhất trong cả cty. Nhưng điều mình học được và nể nhất là khi trao đổi 1 vấn đề gì, 1 con bug nào, ổng luôn luôn là người đặt rất nhiều câu hỏi, trước khi offer cái thought hay solution. Mình nói chuyện với ổng mình học được rất nhiều thứ. Ổng nói

“You may think I know a lot, but actually I don’t. No one knows everything. That’s why I ask a lot of questions. And I know how to ask the right question, to get the information I wanted. But I can’t offer you my thought before I get to know those answers, because if I do, I may very well lead you down to the wrong path.”

Từ những lời này (nhất là câu cuối) mà mình từ đó cũng cẩn trọng hơn với lời nói của mình. Giờ ai đó hỏi mình việc gì, mình đều khá dè dặt trong việc đưa ra lời khuyên, và luôn tự hỏi bản thân đã đủ hiểu đủ (và hiểu đúng) về vấn đề của người đối diện hay chưa, đủ để đưa ra lời khuyên hay chưa. Và mình bắt đầu học cách có trách nhiệm với những lời nói, lời khuyên của mình hơn, vì “wrong solution, may end up making the problem bigger”.

3. Respect others’ differences

“Coders can be very, and I truly mean very, opinonated about their code.”

Mình vào cty lúc cty có khoảng 300-400ng, và chỉ cỡ hơn 40 devs (giờ là hơn 600 devs). Nên mình đã được trải qua những buổi họp để set nền móng coding standard, format ra sao, prettier hay ko prettier (thậm chí là set max width to default 80 hay lên 100 😅), coding style thế nào, unit test nên dùng thằng nào, có nên đem thằng (technology) mới này vào ko, etc. Và dĩ nhiên có họp là có tranh luận, và dev nhiều người cũng rất specific và opinionated về style mà mình thích hoặc mình muốn, và có nhiều cuộc họp kéo dài dài. Cuối cùng thì mình nhận ra 1 điều, trừ những cái về performance, có data benchmark rõ ràng để support, còn lại cái gì thuộc về style thì đều là personal’s choice, và nhiều lúc cũng chẳng đáng để make a big deal out of it. Mỗi người mỗi kiểu, mỗi style, mỗi cái path khác nhau. Và cái gì có trong set coding standard thì cứ theo đó mà follow and enforce (còn chưa có thì raise lên để add thêm vào), còn lại thì cũng ko nên nit pick quá.

“Respect the way others code, just like we want others to respect ours.”

Reference: Trung Vu - Viet Tech Group