Từ chuyện ngày xưa Ngày xửa ngày xưa, à thật ra cũng không xưa lắm, khoảng những năm 75-90, có một số lão lập trình viên rảnh hơi, thực hiện một số nghiên cứu rảnh hơi để … đo năng suất làm việc của developer. Kết quả thu được thật đáng ngạc nhiên! Chênh lệch về năng suất làm việc của 2 developer là rất lớn. Một developer giỏi có thế có năng suất gấp 10 lần một developer khác. Người đời gọi những developer giỏi này là rockstar developer, 10x developer. Huyền thoại về các developer “siêu nhân”, “thần thánh” cũng ra đời từ đó.

Đến chuyện ngày nay

Thuở đi làm, mình cũng từng gặp 2 dạng coder “siêu nhân”:

• Dạng thứ nhất thường gặp ở các bác senior. Họ thường là những người giàu kinh nghiệm, trầm mặc, ít khoe khoang, nhưng là người chịu trách nhiệm cho kiến trúc hệ thống, vấn đề technical phức tạp, các module chính. Họ debug nhẹ nhàng như chuồn chuồn giỡn nước, code trong sáng như nước hồ thu, ngồi pair programming với họ một buổi mà như được truyền thụ mấy năm công lực của các bậc thánh nhân.

• Dạng thứ hai là các thanh niên mới ra trường hoặc mới đi làm 1,2 năm. Họ cũng khá có tài, rất tự tin về tốc độ và khả năng code của mình. Dạng coder này thoắt ẩn thoắt hiện, đi như mây bay, đến như gió thoảng. Họ luôn ôm nhiều việc, hoàn thành công việc trước thời hạn nên rất được lòng các developer.

Dạng thứ nhất chính là dạng developer mà chúng ta nên học hỏi. Tuy nhiên, cần cố gắng tránh trở thành dạng thứ hai. Vì sao vậy? Hãy đọc đoạn bên dưới.

Các cấp độ của developer

Trong cuốn Mastery, tác giả có nhắc đến các cấp độ cần đạt đến để thực sự “master” một cái gì đó, mình thấy cũng khá đúng với ngành lập trình:

• Cấp độ một: Đây là giai đoạn nhập môn học hỏi. Lúc này, do chưa có kinh nghiệm, không biết cách giải quyết vấn đề nên tốc độ code của bạn khá chậm.
• Cấp độ hai: Sau một thời gian sẽ chuyển qua cấp độ này. Do đã có kinh nghiệm. dần nắm được cách giải quyết vấn đề nên tốc độ code của bạn tăng lên. Tuy nhiên, bạn sẽ gặp khó khăn khi gặp vấn đề mới.
• Cấp độ ba: Sau khi tích luỹ được nhiều kinh nghiệm thì bạn sẽ code … chậm lại. Tại sao? Lúc này với một vấn đề, bạn sẽ nghĩ nhiều hơn trước khi code. nhìn ra nhiều điều cần lưu ý hơn, có nhiều hướng giải quyết hơn. Lúc đó bạn sẽ phân vân giữa các hướng giải quyết để chọn cách tối ưu và tốt cho tương lai.
• Cấp độ bốn: Bạn sẽ mất khá lâu để đạt tới cấp độ này. Lúc này, bạn có thể nhanh chóng tìm ra giải pháp tối ưu nhờ kinh nghiệm nhiều. Bạn sẽ có cái nhìn tổng quát về solution, về hệ thống chứ không chỉ là module nữa.

Nếu đi làm được một thời gian, thấy mình bắt đầu code chậm lại so với lúc trước, không phải là do bạn … già đâu ;)), đây chỉ là quá trình lột xác từ cấp độ hai lên cấp độ ba đấy.

Vậy mấy thằng “coder thần thánh” đạt cấp nào???

Mấy bác senior ở cấp độ bốn, code vừa nhanh và hiệu quả thì không cần nói rồi! Tuy nhiên, đa phần các “thánh code” mình gặp thường là những người ở cuối cấp độ hai. Thật vậy, ngày xưa mình cũng từng tưởng mình giỏi, mình là “thánh”.

Ta thường hay lầm tưởng là code nhanh, hoàn thành task nhanh là coder giỏi. Thế nhưng, tốc độ code không phải là tất cả. Đôi khi các “thánh” design ẩu. code ẩu cho xong module mà không chịu test, hoặc không cover đủ các case. Lối code nhanh mà ẩu sẽ làm tăng thêm technical debt cho team, để các thành viên khác phải hốt shit (refactor code).

Tệ hơn, do hoàn thành task nhanh, những coder dạng này thường tự phong mình là “siêu nhân”, là “thánh” và tiếp tục coi khinh những thằng chậm hơn. Chịu khó đọc bạn sẽ thấy thể loại này được manager thương, nhưng đôi khi lại bị developer ghét vì làm chậm tiến độ dự án và mất thời gian người khác. Đừng để mình trở thành một người như vậy nhé!

Để hạn chế tác hại các “thánh code” kiểu này, các team phải có qui trình rõ ràng, có unit test, có code review. Tuy nhiên, không phải công ty nào cũng có qui trình bài bản. Do đó, nếu đôi khi bạn phải hốt shit của “coder thần thánh” nào đó thì cũng đành cắn răng chịu đựng thôi nhé.

Vài lời khuyên

Thuở mới ra trường, thích chứng tỏ bản thân, mình thường cố gắng code nhanh để “thể hiện trình độ”. Lớn lên mới biết, chất lượng code quan trọng hơn “tốc độ code” rất nhiều.

Hãy tập cho mình thói quen code chậm lại một chút, suy nghĩ kĩ hơn một chút, bạn sẽ nhận ra nhiều cách để giải quyết vấn đề hơn. (Mình nhận được lời khuyên này từ một ông senior bên ASWIG Solution).

Bạn cũng không nên ăn thua về hiệu suất làm việc làm gì. Nếu muốn gây ấn tượng trong mắt team leader, PM và đồng đội, hãy giúp đỡ các thành viên khác chứ đừng thể hiện sự “thần thánh” của mình ra nhé!