Nên hỏi khi bạn đã tự thử có phương pháp trong một khoảng thời gian hợp lý mà không tiến triển, thay vì hỏi ngay lập tức hoặc ngồi kẹt cả ngày vì ngại. Một câu hỏi tốt nêu rõ bạn đang làm gì, mong đợi gì, thực tế ra sao và đã thử những gì. Và chọn cách hỏi, lúc hỏi sao cho tôn trọng sự tập trung của người được hỏi.
Chào bạn, đây là Nhà Lập Trình. Người mới đi làm hay rơi vào một trong hai cực: hỏi mọi thứ ngay khi gặp khó, hoặc không dám hỏi gì và ngồi kẹt ba ngày. Cả hai đều có giá. Tập này kể cách tìm điểm cân bằng, và cách hỏi để được giúp nhanh nhất.
Hai cái giá của hai thái cực
Hỏi quá sớm có giá. Bạn mất cơ hội tự học, vì phần học nằm ở chỗ tự vật lộn. Đồng nghiệp bị ngắt quãng liên tục, mà với người lập trình, một lần bị ngắt có thể mất khá lâu mới quay lại được mạch suy nghĩ cũ. Và dần dần, bạn được coi là người không chịu tự tìm hiểu.
Hỏi quá muộn cũng có giá, thường còn đắt hơn. Bạn ngồi cả ngày với một vấn đề mà đồng nghiệp giải thích trong năm phút, vì họ biết một điều về hệ thống mà bạn không thể tự đoán ra. Việc của bạn trễ, và việc của người khác phụ thuộc vào bạn cũng trễ theo.
Người mới hay rơi vào cực thứ hai hơn, vì ngại. Sợ bị đánh giá là kém, sợ làm phiền. Nhưng hầu hết người có kinh nghiệm thà bị hỏi một câu hơn là thấy người mới kẹt cả ngày.
Một chị kỹ sư ở Đà Nẵng kể rằng điều chị lo nhất ở người mới không phải là hỏi nhiều, mà là im lặng. Người hỏi nhiều thì chị biết họ đang ở đâu. Người im lặng thì chị chỉ biết khi đã muộn.
Khi nào thì nên hỏi?
Một quy tắc nhiều đội dùng: tự thử một khoảng thời gian nhất định, rồi hỏi. Khoảng đó tuỳ việc và tuỳ bạn mới hay cũ, thường từ ba mươi phút tới vài giờ. Quan trọng là có một giới hạn, chứ không để trôi vô tận.
Trong khoảng đó, thử có phương pháp: đọc thông báo lỗi, tìm trong tài liệu, tìm trong mã dự án xem có chỗ nào làm tương tự, tìm trên mạng, thử giải thích cho con vịt cao su. Nếu có tiến triển, dù chậm, cứ tiếp tục. Nếu hết giới hạn mà vẫn đứng yên, hỏi.
Có những loại câu hỏi nên hỏi ngay, không cần tự thử: câu hỏi về bối cảnh mà chỉ người trong đội biết, như vì sao hệ thống được thiết kế thế này, quy trình đưa mã lên là gì, dữ liệu này đến từ đâu. Tự đoán những thứ này chỉ tốn thời gian.
Và luôn hỏi ngay khi có dấu hiệu nguy hiểm: sắp chạy một lệnh trên máy thật mà không chắc, phát hiện có thể có lỗ hổng bảo mật, lỡ xoá hay sửa nhầm thứ gì.
Câu hỏi tốt được giúp nhanh
Cách bạn hỏi quyết định bạn được giúp nhanh hay chậm. Câu hỏi tệ: anh ơi cái này không chạy. Người được hỏi phải hỏi ngược lại mười câu mới hiểu bạn đang nói gì.
Câu hỏi tốt có bốn phần. Mình đang làm gì: đang thêm chức năng lọc đơn theo ngày. Mình mong đợi gì: chọn khoảng ngày thì hiện đơn trong khoảng đó. Thực tế ra sao: đơn của ngày cuối khoảng không hiện ra. Mình đã thử gì: đã kiểm tra truy vấn, thấy điều kiện dùng nhỏ hơn thay vì nhỏ hơn hoặc bằng, sửa rồi vẫn không được.
Với câu hỏi như vậy, đồng nghiệp có kinh nghiệm có thể nhận ra ngay: à, ngày cuối lưu kèm giờ, so sánh với nửa đêm đầu ngày nên bị loại. Năm phút thay vì năm mươi.
Và như mình kể ở tập về con vịt cao su, rất nhiều lần trong lúc viết câu hỏi bốn phần này, bạn tự tìm ra câu trả lời.
Hỏi qua tin nhắn hay đến tận bàn?
Với câu hỏi không gấp, tin nhắn thường tốt hơn. Người được hỏi trả lời khi họ tới điểm nghỉ tự nhiên, không bị ngắt giữa lúc đang tập trung. Bạn có thể viết câu hỏi đầy đủ, kèm đoạn mã và thông báo lỗi.
Khi nhắn, đừng chỉ nhắn một chữ chào anh rồi chờ. Người nhận thấy tin nhắn, phải trả lời chào em, rồi chờ bạn gõ câu hỏi, mất hai lượt qua lại vô ích. Hãy viết luôn câu hỏi đầy đủ trong tin nhắn đầu tiên.
Hỏi trong kênh chung của đội thay vì nhắn riêng khi có thể. Nhiều người khác có thể biết câu trả lời, và người khác sau này gặp cùng vấn đề có thể tìm lại.
Với câu hỏi phức tạp cần trao đổi qua lại, hoặc gấp, thì nói trực tiếp hoặc gọi. Nhưng hỏi trước: anh có năm phút không, em đang kẹt ở chỗ này. Tôn trọng việc họ đang làm.
Sau khi được giúp
Khi được giúp xong, đừng chỉ cảm ơn rồi đi. Hãy chắc là bạn hiểu vì sao cách đó đúng, không chỉ là nó chạy. Nếu chưa hiểu, hỏi thêm một câu. Mục tiêu là lần sau gặp vấn đề tương tự, bạn tự giải được.
Ghi lại những gì học được. Một tệp ghi chú cá nhân, hoặc tốt hơn, bổ sung vào tài liệu của đội nếu đó là điều người khác cũng sẽ cần. Người sau sẽ không phải hỏi lại cùng câu.
Nếu câu trả lời bạn nhận được trong tin nhắn riêng, hãy cân nhắc chia sẻ vào kênh chung. Kiến thức nằm trong tin nhắn riêng thì chỉ hai người biết.
Và khi bạn đã có kinh nghiệm, hãy là người sẵn lòng được hỏi. Nhớ lại cảm giác ngại ngùng hồi mới vào, và làm cho người mới cảm thấy hỏi là điều bình thường. Đội mà mọi người dám hỏi là đội học nhanh nhất.
Câu hỏi thường gặp
Bị kẹt bao lâu thì nên hỏi đồng nghiệp?
Tuỳ việc, thường từ ba mươi phút tới vài giờ tự thử có phương pháp mà không tiến triển. Câu hỏi về bối cảnh riêng của hệ thống thì nên hỏi ngay.
Người mới có nên ngại hỏi không?
Không nên. Phần lớn người có kinh nghiệm thà được hỏi còn hơn thấy người mới kẹt cả ngày. Chỉ cần tự thử trước và hỏi có chuẩn bị.
Một câu hỏi kỹ thuật tốt gồm những gì?
Đang làm gì, mong đợi gì, thực tế xảy ra gì và đã thử những gì. Kèm thông báo lỗi và đoạn mã liên quan nếu có.
Nên hỏi qua tin nhắn hay trực tiếp?
Câu hỏi không gấp nên hỏi qua tin nhắn với nội dung đầy đủ, tốt nhất ở kênh chung của đội. Câu hỏi phức tạp hoặc gấp thì nói trực tiếp, nhưng hỏi xem người kia có rảnh không trước.
Làm sao để không phải hỏi lại cùng một câu?
Hiểu vì sao lời giải đúng chứ không chỉ chép lại, ghi chú những gì học được và bổ sung vào tài liệu chung của đội nếu người khác cũng cần.
