Làm thế nào để khích lệ các lập trình viên?

Chắc hẳn khi đọc bài viết sau đây thì cho dù bạn làm nghề gì (không nhất thiết là một lập trình viên) cũng dễ dàng nhận ra hình ảnh của chính mình trong đó. Nếu đang là “lính” thì bạn có thấy Sếp mình áp dụng mấy chiêu này không? Nếu đang là Sếp thì có lẽ bạn cũng nên tham khảo cách này khi mà nhân viên của bạn bị xuống tinh thần. :smile:

Bài viết được dịch từ blog Coding Horror

Có một nghịch lý cố hữu trong việc khích lệ các lập trình viên. Tôi nghĩ rằng câu chuyện vui Geek Hero Comic này là một minh họa hoàn hảo về nghịch lý đó:

“Randall ơi. Bác sĩ nói rằng anh có thể nghe thấy tôi nói, thậm chí dù anh đang ở trong tình trạng hôn mê. Tôi chỉ đến để nói với anh rằng, anh có thể được nghỉ phép cho đến khi hoàn toàn bình phục, bởi vì cậu Ross đang đảm trách vị trí của anh rất tốt. Cậu ta thậm chí còn tìm thấy một nút thắt cổ chai (bottleneck) trong những dòng code của anh, và nói rằng bây giờ tốc độ hệ thống sẽ tăng lên gấp đôi.”

“Cái… cái… gì? Điều đó là không thể!!! Đưa tôi về công ty ngay!”

Đó là một hiện tượng tâm lý mà tôi để ý thấy xuất hiện thậm chí ngay chính trong bản thân mình. Không có gì khích lệ hơn khi có một lập trình viên khác nói với bạn rằng, họ đang viết lại những dòng code của bạn bởi vì nó rất tồi. Dave Thomas cũng đã nói về vấn đề này nhiều năm về trước trong một buổi thuyết trình kinh điển về Phát triển Chuyên môn, trong đó có một đoạn như sau:

Thú vị thay, một người bạn của tôi (người đang là một quản lý về khâu kiểm soát chất lượng tại một bệnh viện) cũng nói về hiện tượng tâm lý giống hệt như vậy khi đề cập đến các bác sĩ mà ông ta đang quản lý: Những yêu cầu lịch sự, ép buộc, v.v… thì không có hiệu quả gì và thường lại có tác dụng ngược. Chính những áp lực của đồng nghiệp và sự cạnh tranh mới là chìa khóa để tạo ra sự khích lệ.

Đừng cố bắt cừu chạy đua,
Đừng cố lùa những con ngựa đua thành đàn.

Vâng, việc sử dụng hình ảnh con cừu thì hơi xúc phạm một chút, nhưng về nguyên tắc chung thì nó giống nhau: sử dụng các kỹ thuật để khích lệ còn tùy thuộc vào đẳng cấp của các lập trình viên mà bạn đang làm việc cùng. Nếu bạn có những lập trình viên mới vào nghề, hãy tập hợp họ cùng với thật nhiều chỉ dẫn và các quy tắc nhất quán. Còn nếu bạn có những lập trình viên nhiều năm kinh nghiệm, thì các quy tắc hầu như vô tác dụng. Thay vì đó, hãy cổ vũ họ vào một cuộc đua: gắn với một chút cạnh tranh lành mạnh và tuyên dương những nhân viên này giỏi này trước mặt các đồng nghiệp của họ.

Về tác giả bài viết:

Jeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow.

12 Likes

Hợp lý, hay. Rút kinh nghiệm.

Kinh nghiệm xương máu là có trường hợp mình chỉ ra lỗi trong trường trình của người khác khá gay gắt. Cái này hình như dân tộc nào cũng bị chứ không phải mỗi VN. Khi bị chỉ trích người ta khó chịu lắm, về sau làm việc cúng khó nữa.

Hoặc ngược lại cũng có người nhận xét code của mình chạy sai, nghe cũng nóng máu lắm. Ngay trước khi chuẩn bị code review, mình toàn phải nghiên cứu lại code thật kỹ, không hôm sau bị chê quê lắm :smiley:

5 Likes

rất hay, sẽ cố gắng làm sếp để áp dụng phương pháp trên :smiley:

2 Likes

3 Likes

Cái này hay nè :slight_smile:
Nhiều lúc sở trường của mình mà bị người khác chê là ức chế lắm, nhiều lúc không thể tập trung lại để làm việc, cứ suy nghĩ lại câu ns đó mãi :frowning:

2 Likes

Cố gắng apply không biết có thành công không :smiley:

2 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?