Pull request hôm đó đủ nhỏ để review trước giờ ăn trưa, nhưng tôi vẫn nhớ mình dừng lại ở một ô comment khi ly cà phê bên cạnh bàn phím đã nguội dần. Một junior developer đã giải quyết được vấn đề, code chạy được, nhưng hình dạng của đoạn code cho thấy bạn ấy đang đoán nhiều hơn là đang ra quyết định. Tôi có thể để lại ba chỉ dẫn thẳng và đi tiếp. Thay vào đó, tôi hỏi một câu chậm hơn: trade-off mà bạn đang cố bảo vệ ở đây là gì?
Khoảnh khắc đó gần với mentoring thật hơn nhiều ngôn ngữ trang trọng về mentoring. Nó không phải lúc nào cũng trông như career plan, training calendar hay một checklist kỹ năng gọn gàng. Thường thì đó là việc một người senior nhận ra sự lưỡng lự rất nhỏ trong công việc bình thường, rồi chọn làm phần suy nghĩ trở nên nhìn thấy được. Code quan trọng, nhưng người đang học cách suy nghĩ qua code cũng quan trọng không kém.
Khi mới bắt đầu mentor junior developer, tôi từng quá nhanh trong việc trở nên hữu ích. Ai đó hỏi, tôi trả lời. Ai đó gặp lỗi, tôi nhận ra lỗi. Ai đó chưa chắc về design, tôi mô tả con đường tôi sẽ đi. Lúc đó việc ấy có vẻ rộng lượng, nhưng nó âm thầm dạy một thói quen không tốt. Junior học rằng con đường nhanh nhất để đi qua mơ hồ là mượn sự chắc chắn của tôi, còn tôi học cách thấy mình hữu ích vì mọi người tiếp tục quay lại.
Mentoring tốt cần nhiều kiên nhẫn hơn vậy. Một junior developer không chỉ thiếu cú pháp, pattern hay kiến thức framework. Họ còn thiếu context. Họ có thể chưa biết vì sao feature này quan trọng với user, phần nào của codebase dễ vỡ, constraint nào là business rule và constraint nào chỉ là di sản cũ, hoặc loại rủi ro nào cần escalate sớm. Nếu mình chỉ đưa câu trả lời, ticket có thể xong, nhưng tấm bản đồ trong đầu họ vẫn trống.
Context là món quà đầu tiên. Trước khi một task bắt đầu, tôi cố giải thích hình dạng xung quanh nó: feature này để làm gì, ai sẽ bị ảnh hưởng nếu nó lỗi, quyết định cũ nào đang tác động đến nó, cạnh nguy hiểm nằm ở đâu, và một phiên bản đầu tiên đủ tốt trông như thế nào. Việc này không cần biến thành một bài giảng. Năm phút bình tĩnh có thể tiết kiệm nhiều giờ đoán trong lo lắng. Nó nói với junior rằng họ không bước vào một căn phòng tối một mình.
Món quà thứ hai là hỗ trợ đúng mức. Quá ít hỗ trợ biến mentoring thành bài kiểm tra sinh tồn. Quá nhiều hỗ trợ biến nó thành phụ thuộc từng bước. Khoảng giữa hữu ích thường là một task rộng hơn một chút so với vùng thoải mái hiện tại của họ, với một safety net rõ ràng ở gần. Tôi thích thống nhất checkpoint trước khi làm: cho tôi xem plan trước khi implement, hỏi nếu data model thay đổi, gọi tôi nếu lỗi trỏ ra ngoài module này, còn lại hãy thử đi qua phiên bản đầu tiên bằng chính mình.
Sự tự tin lớn lên tốt nhất trong khoảng giữa đó. Nó không đến chỉ từ lời khen, và cũng không đến từ việc được bảo vệ khỏi mọi sai sót. Nó đến từ những bằng chứng nhỏ được gom lại: tôi đã điều tra bug, tôi đã đưa ra một lựa chọn design nhỏ, tôi đã đi qua code review, tôi đã sửa phần mình bỏ sót, và hệ thống vẫn ổn. Mỗi vòng hoàn thành nhỏ trở thành một chút trust để họ mang sang task tiếp theo.
Code review là một trong những nơi mạnh nhất để xây hoặc làm mòn trust đó. Một review comment có thể dạy ai đó cách suy luận, hoặc dạy họ cách che giấu. Khi review công việc của junior, tôi cố tách tính đúng đắn khỏi sự xấu hổ. Nếu có gì sai, hãy nói rõ. Nhưng cũng giải thích vì sao nó quan trọng, rủi ro nào được tạo ra, và lần sau nên nghĩ về trường hợp tương tự như thế nào. Một comment cụ thể giúp cải thiện judgment đáng giá hơn mười chỉnh sửa nhỏ chỉ chứng minh reviewer là người senior.
Cũng có một giới hạn cho lượng bài học nên nhét vào một review. Khi một pull request có nhiều vấn đề, rất dễ biến thread thành cả một khóa học về architecture, testing, naming, error handling và product thinking. Thường điều đó làm người viết bị ngợp. Tôi thà chọn hai bài học quan trọng nhất, giúp họ hoàn thành công việc hiện tại một cách an toàn, rồi mang phần còn lại sang pairing, một ghi chú sau đó hoặc task tiếp theo. Mentoring là sự tích lũy, không phải một màn review kịch tính duy nhất.
Những sai sót có thể phục hồi là một phần của sự tích lũy đó. Một junior developer không bao giờ được phép mắc lỗi an toàn cũng sẽ không học được trọng lượng của một quyết định. Việc của mentor là giữ blast radius hợp lý, không phải xóa hết rủi ro. Hãy để họ chọn một hướng implement, bỏ sót một edge case ở vùng ít rủi ro, hoặc debug một test failure lâu hơn bạn sẽ làm. Sau đó ngồi lại cùng họ và hỏi lần sau tín hiệu nào nên được nhìn thấy sớm hơn. Bài học không chỉ nằm ở việc tránh lỗi. Nó nằm ở việc phục hồi mà không thấy xấu hổ.
Psychological safety trở nên rất thực tế ở đây. Nó không phải một câu khẩu hiệu trên tường. Nó là việc một junior có dám nói mình đang rối trước khi sự rối đó thành một tuần trôi âm thầm hay không. Nó là việc họ có thể nói mình vừa làm hỏng gì đó mà không cần chuẩn bị lời bào chữa hay không. Nó là việc một câu hỏi trong code review có cảm giác như lời mời cùng suy nghĩ, không phải một cái bẫy. Phản ứng đầu tiên của người senior trong những khoảnh khắc ấy dạy cả team rằng kiểu thành thật nào là an toàn.
Sự độc lập nên đến từ từ. Ban đầu, mentor có thể giúp định hình plan khá sát. Sau đó, junior bắt đầu mang đến các lựa chọn thay vì chỉ mang vấn đề. Rồi dần dần, họ tự quyết các việc bình thường và chỉ escalate khi rủi ro thay đổi. Tôi thích chuyển động này vì nó tôn trọng cả hai phía: junior có thêm không gian nhờ judgment đã nhìn thấy được, còn mentor học cách không giữ những việc không cần giữ nữa.
Mentoring cũng phản chiếu lại sức khỏe của hệ thống. Nếu nhiều junior hỏi cùng một câu, có thể onboarding chưa rõ. Nếu task nào cũng cần context riêng từ một senior engineer, có thể codebase đang giấu quá nhiều lịch sử. Nếu mọi người ngại hỏi sớm, có thể team đã thưởng cho sự chắc chắn nhiều hơn việc học. Một mentor tốt không chỉ cải thiện junior. Họ cải thiện điều kiện xung quanh junior.
Tiến bộ tốt nhất trong mentoring thường rất dễ bị bỏ qua khi nó đang diễn ra. Một ngày nào đó, chính developer từng chờ xác nhận bắt đầu giải thích trade-off cho người khác. Họ viết pull request description bình tĩnh hơn. Họ bắt được rủi ro trước khi review. Họ hỏi thêm context mà không xin lỗi vì mình cần context. Không điều nào xuất hiện sau một đêm. Đó là kết quả của nhiều khoảnh khắc nhỏ nơi sự hỗ trợ đủ gần, nhưng không gần đến mức lấy mất ownership.
Có lẽ mentoring hiệu quả chỉ đơn giản là thế này: giúp một người đủ an toàn để thành thật, đủ được hỗ trợ để thử, và đủ được tin tưởng để dần ít phụ thuộc vào bạn hơn. Nếu bạn từng mentor một junior developer, hoặc từng được ai đó mentor qua giai đoạn đầu còn nhiều lưỡng lự, tôi rất muốn nghe khoảnh khắc nhỏ nào đã tạo khác biệt lớn nhất với bạn.