Khi nào bạn đã là Senior dev

Như thế nào là một Senior dev, có rất nhiều chuẩn mực được đặt ra như

  • Senior dev là những người viết code tốt hơn junior dev. Thực tế có những junior dev viết code rất tốt, và không ít senior dev viết code méo thể nào maintain nổi
  • Senior dev là người biết tuốt những công nghệ mới nhất. Thế hệ trẻ mới thật sự là người tiếp cận công nghệ mới nhất.
  • Senior dev hoàn thành công việc nhanh hơn. Không hẳn, nếu bạn giao task cho một principle dev, anh ta phải viết unit test coverage 90%, phải thực hiện một loạt các bài test khác, document cho toàn bộ những gì anh ta làm, thời gian có khi cần gấp đôi, gấp ba lần
  • Senior là những người viết code ít bug hơn, thậm chí không có bug, nhưng chúng ta điều biết một sự thật hơi đau đớn, tất cả code điều có bug, dev cũng chỉ là người và viết code chạy trên những môi trường không thể nào biết hết được, với tỉ tỉ use case khác nhau được tạo ra từ cả triệu người sử dụng.

Vậy thì tiêu chí nào để đánh giá một bạn là Senior dev nói chung?

Đây là cách mà các sếp mình dùng để đánh giá bậc Senior Dev

Nên

  • Khi tiếp nhận từ đồng nghiệp, hãy suy nghĩ, dù là bất cứ câu hỏi nào, nó vẫn là câu đáng để hỏi, không có câu hỏi nào vô lý, hỏi vậy cũng hỏi. Luôn luôn lắng nghe, lâu lâu trả lời :D
  • Không đưa ra bất kỳ đánh giá cá nhân trên code review, thảo luận mang mục đỉnh giải quyết vấn đề chứ không phán xét.
  • Khi review code, luôn luôn tìm ít nhất một điểm gì đó để đóng góp, trên tinh thần thảo luận, đặt câu hỏi, không đưa ra chỉ thị phải làm như thế nào
  • Sẵn sàng giải thích, một cách kiên trì, tìm ra giải pháp cho những vấn đề mà team đang vướng phải.
  • Tự thân tìm hiểu học hỏi những kỹ năng nâng cao nghề nghiệp
  • Không cần người cầm cây dí đít mới làm, luôn có tình thần trách nhiệm cao trong công việc được giao phó
  • Tìm giải pháp khi có vấn đề, chứ không phải ngồi đó la làng khó quá sao làm, khó quá anh tự đi mà làm
  • Khi đưa ra giải pháp, cân nhắc đảm bảo cân đối giữa các yếu tố: thời gian hoàn thành, best practice, chi phí thực hiện, mức độ rủi ro tới các phần khác của hệ thống

Tránh

  1. Khi gặp một cách code nào đó hơi lạ, style code bạn không thích thì sẽ là lối kiểu Đưa nào viết cái gì tào lao quá vậy, viết thế này như anh đi
  2. Khi review code - "nên đổi thế này, thế này đi"
  3. Áp đặt cách tư duy lập trình của mình lên người khác

Còn gì nữa không, mọi người góp ý thêm.