Tư Duy Nhận Task "Chuẩn Chỉnh" Cho Fresher Tập 3: "Nguyên Tắc Không Im Lặng" (Giao tiếp trong quá trình làm).

Trong ngành phần mềm, đặc biệt là khi làm việc với các hệ thống backend phức tạp hay kiến trúc microservices, sự im lặng của Fresher chính là "bom nổ chậm" tàn phá tiến độ của cả team. Bệnh chung là sợ bị chê kém, gặp bug thì giấu, tự cắm mặt debug 2-3 ngày không ra rồi đến sát giờ release mới báo cáo là "em làm không kịp".

Dưới đây là cách setup mindset giao tiếp cho Fresher:

1. Chủ động cập nhật (Proactive Status Update)

Đừng đợi đến lúc Daily Meeting hoặc khi mentor réo tên mới rụt rè báo cáo. Fresher cần học cách tự đẩy luồng thông tin đi.

• Tư duy cốt lõi: Quản lý/Mentor cần "Visibility" (tầm nhìn) để kiểm soát rủi ro. Bạn báo cáo tiến độ không phải để bị giám sát, mà để team biết bạn đang ở đâu trên bản đồ.
• Hành động cần làm: Báo cáo ngắn gọn vào cuối ngày hoặc đầu ngày theo công thức: Done (Đã xong gì) - To Do (Sắp làm gì) - Blocker (Đang vướng gì).
• Ví dụ thực chiến:

  "Hôm nay em đã dựng xong core logic bằng Go và viết xong Unit Test cho layer Repository. Ngày mai em sẽ tích hợp với RabbitMQ. Hiện tại mọi thứ vẫn đúng tiến độ, không có blocker nào ạ."

2. Quy tắc Time-boxing (Đóng khung thời gian bế tắc)

Fresher rất dễ rơi vào "hố đen debug". Cứ nghĩ sửa thêm 5 phút nữa là xong, nhưng ngoảnh lại đã hết nửa ngày mà bug vẫn còn nguyên.

• Tư duy cốt lõi: Thời gian của công ty là tiền. Kẹt quá lâu mà không hỏi là làm lãng phí resource.
• Hành động cần làm: Thiết lập quy tắc 30-60 phút. Nếu gặp một cái bug (ví dụ: message đẩy vào Queue rồi nhưng worker không consume được, hoặc config Redis TTL không hoạt động như ý) và đã thử search StackOverflow, đọc document suốt 1 tiếng mà vẫn bế tắc -> BẮT BUỘC PHẢI ĐỨNG DẬY ĐI HỎI.

3. Hỏi như một Kỹ sư (Nghệ thuật mang theo Giải pháp)

Đi hỏi không có nghĩa là ném thẳng cái màn hình đỏ lòm báo lỗi hoặc quăng một cục log cho mentor rồi hỏi "Anh ơi sao code em không chạy?". Đó là cách làm của thợ gõ, không phải của kỹ sư.

• Tư duy cốt lõi: Mentor là người định hướng, không phải là thợ fix bug thuê cho bạn.
• Công thức đặt câu hỏi thông minh (Context - Action - Proposal):
  • Context (Ngữ cảnh): Trình bày rõ đang làm luồng nào, input là gì, expected output (kết quả mong đợi) là gì, và lỗi hiện tại đang hiển thị ra sao.
  • Action (Đã làm gì): Liệt kê những cách mình đã thử để mentor không phải đi lại vết xe đổ đó (Ví dụ: "Em đã check log hệ thống và thử restart lại container nhưng vẫn bị").
  • Proposal (Đề xuất): Đưa ra ít nhất 1-2 phương án mình tự suy nghĩ ra để mentor chốt.
• Ví dụ thực chiến:

  "Anh ơi, luồng thanh toán đang bị lỗi duplicate transaction. Em đã trace log và thấy có vẻ do client click đúp gửi request 2 liên tiếp. Em đang phân vân 2 hướng giải quyết: Một là dùng Redis để lưu key Idempotent khóa request lại trong 3 giây, hai là áp dụng Row-level locking dưới database. Anh thấy hướng nào tối ưu hơn cho hệ thống của mình ạ?"

Red Flags (Dấu hiệu cảnh báo nguy hiểm) cần trị tận gốc:

• "Báo cáo láo" để câu giờ: Khi sếp hỏi tiến độ, luôn miệng đáp "Em sắp xong rồi", "Code em chạy được rồi, chỉ còn vài lỗi vặt", nhưng thực chất là chưa đâu vào đâu, đến lúc review thì bung bét.
• Hỏi lắt nhắt, thiếu bối cảnh: Nhắn tin cho mentor mỗi câu "Anh ơi hàm này lỗi", xong lặn mất tăm bắt mentor phải tự đoán xem hàm đó nằm ở file nào, branch nào.