Tự kiểm tra là khó, nhưng tôi tin rằng chúng ta có thể học hỏi nhiều hơn từ việc nghiên cứu những thất bại hơn là những thành công của chúng ta.
-Norm Kerth, Project Retrospectives
Bối cảnh
Bất cứ ai có đủ năng lực đều sẽ thấy mình đang bị cuốn lên cao hơn trong nấc thang sự nghiệp theo thời gian. Sớm hay muộn bạn sẽ kết thúc với việc việc đội lên mình chiếc mũ phát triển viên cao cấp trong một nhóm công ty hoặc dự án mã nguồn mở. Nếu bạn không thực hiện các bước để chuẩn bị cho mình ở vị trí đó, bạn có thể đột nhiên thấy mình là nạn nhân của Nguyên tắc Peter, khi mà bạn được thăng cấp tới “vị trí mà bạn không có đủ năng lực”.
Vấn đề
Vì số năm và dự án mà bạn tham gia làm việc tăng lên, bạn sẽ thấy mình đang chờ một điều kì diệu diễn ra và khiến bạn trở nên “có kinh nghiệm”.
Giải pháp
Trở thành một chuyên gia thực hành có sự suy tư về phát triển phần mềm. Điều này liên quan đến việc xem xét một cách thường xuyên cách bạn đang làm việc. Xem xét liệu các hoạt động của bạn có mới lạ, đổi mới hay đã lỗi thời. Hãy tự hỏi mình những câu hỏi về những điều mà những người còn lại trong đội của bạn không trân trọng. Nếu có điều gì đặc biệt đau đớn hoặc dễ chịu trong công việc hiện tại của bạn, hãy tự hỏi mình chúng vì sao đã trở nên như thế vậy, và nếu mọi thứ là tiêu cực, làm thế nào để chúng có thể được cải thiện? Mục đích là để trích xuất tối đa giá trị giáo dục từ mọi trải nghiệm bằng cách tách nó ra và rồi đưa trở lại với nhau theo những cách mới lạ và thú vị hơn.
Một kỹ thuật hữu ích trong việc làm cho việc suy ngẫm này trở nên rõ ràng là sử dụng một thứ giống như Bản Đồ Thực Hành Cá Nhân. Đây là một ý tưởng mà Joe Walnes đã giới thiệu tại câu lạc bộ Extreme Tuesday ở London. Nó liên quan đến những người có chủ ý viết xuống những điều họ làm và những kết nối giữa chúng. Sau khi tất cả mọi người đã viết ra các việc tập luyện của họ, nhóm thảo luận về những luyện tập đã được xác định. Nếu bạn xem trang web “Maps of People’s Personal Practices”[1], bạn sẽ thấy các bản đồ được tạo bởi Ade và một số nhà phát triển khác.
Một trong những kết quả của việc sử dụng kỹ thuật này nhiều lần là nó làm nổi bật những thay đổi trong tập luyện của bạn. Ví dụ, trong những năm từ năm 2003, Ade đã chuyển từ “không bao giờ sử dụng trình gỡ lỗi” để thực hành “kiểm tra theo định hướng gỡ lỗi” để bắt đầu chủ ý sử dụng các bất biến khi thực hiện các thuật toán phức tạp. Sự tồn tại của bản đồ hữu hình và rõ ràng về các thực hành của bạn dẫn đến phản ánh sâu hơn về ảnh hưởng của bất kỳ thay đổi nào trong các kỹ thuật mà bạn sử dụng. Trong trường hợp của Ade, việc áp dụng các phát triển dựa vào thử nghiệm đã dẫn đến việc đánh giá lại tất cả các thực hành khác và bản đồ trở thành công cụ để hình dung sự thay đổi này.
Quá trình quan sát, suy ngẫm và thay đổi này không chỉ giới hạn trong các hoạt động của chính bạn. Đừng ngần ngại theo dõi những thợ thủ công và thợ cả trong nhóm của bạn. Suy ngẫm về các thực tiễn, quy trình và kỹ thuật mà họ sử dụng để xem chúng có thể được kết nối với các phần khác mà bạn đã trải nghiệm hay không. Dù là người thợ học việc, bạn cũng có thể khám phá các ý tưởng mới bằng cách quan sát chặt chẽ các thợ thủ công giàu kinh nghiệm hơn khi họ làm việc.
Năm 2004, Dave là thành viên của nhóm XP với nhiều nhà phát triển tầm cỡ thế giới. Họ đã có một phong cách khá chuẩn của lập trình theo cặp: một người sẽ viết một bài kiểm thử và chuyển tiếp cho thành viên khác trong đội, và người này sẽ làm cho nó vượt qua được bài kiểm thử, ngay lập tức viết bài kiểm thử khác, và lại chuyển trở lại cho người đầu tiên. Người đầu tiên sẽ lại vượt qua bài kiểm thử và cứ tiếp tục như vậy. Phương pháp lập trình theo cặp này chưa bao giờ được thảo luận; nó chỉ xuất hiện từ những kinh nghiệm tương ứng.
Dave đã tham gia dự án tiếp theo của anh ấy, và trong khi giải thích phong cách lập trình cặp này cho những đồng đội mới, anh nhận ra rằng phong cách đó cần phải có một cái tên. Dave đã viết blog về nó, điều này đã khởi động một phản ứng dây chuyền, nhanh chóng dẫn tới việc anh được nhận một đề nghị để viết bài cho StickyMinds.com. Tất cả điều này xảy ra chỉ đơn giản bởi vì Dave phản ánh về các phương pháp được giới thiệu bởi các nhà phát triển cao cấp hơn.
Cộng đồng Agile đã làm theo một phiên bản của quá trình này. Được dẫn dắt bởi cuốn sách Project Retrospectives của Norm Kerth, nó liên quan đến việc nhóm nghiên cứu định kỳ họp lại để nhìn lại trạng thái của dự án và từ đó tìm cách cải thiện. Như vậy, việc này mang tính chính thức hơn là sự tự phân tích liên tục mà một người thợ học việc sẽ thực hiện. Nó cũng đòi hỏi sự quản lý ở mức độ thấu hiểu hợp lý, sẵn sàng cung cấp một môi trường an toàn bằng cách tôn trọng chỉ thị chính của Kerth: “Bất kể là chúng ta khám phá những gì, chúng ta hiểu và thực sự tin rằng mọi người đã làm tốt nhất có thể, với những gì họ biết vào thời điểm đó, kĩ năng và khả năng của họ, nguồn lực sẵn có và hoàn cảnh lúc đó.”[2]
Người học việc không phải lúc nào cũng có sự xa xỉ là được làm việc trong những môi trường như vậy, nhưng thói quen suy nghĩ có hiệu quả có thể là hữu ích ngay cả trong những tập đoàn có nền văn hoá ít tha thứ hơn.
Nếu bạn đủ kiên trì, mọi người sẽ dần gọi bạn là “có kinh nghiệm”, nhưng đó không phải là mục tiêu của bạn. Tất cả kinh nghiệm chỉ ra rằng bạn đã có thể sống sót. Nó không chỉ ra số lượng những gì bạn đã học được, chỉ là thời gian bạn đã bỏ ra. Trong một số mảng của lĩnh vực chúng ta, rất dễ dàng lặp lại cùng một năm kinh nghiệm 10 lần mà không có tiến bộ đáng kể nào về năng lực. Trong thực tế, điều này đôi khi có thể biến thành việc phản kinh nghiệm: hiện tượng mà mỗi năm hay kinh nghiệm thêm vào chỉ đơn thuần là củng cố những thói quen xấu mà bạn đã góp nhặt[3]. Đây là lý do tại sao mục đích của bạn nên là trở thành có kỹ năng hơn là có kinh nghiệm. Sự gia tăng mức độ kỹ năng của bạn là bằng chứng có ý nghĩa duy nhất cho nỗ lực của bạn để kiểm tra, thích nghi và cải thiện thói quen làm việc của bạn.
Hành động
Vẽ Bản đồ Thực hành Cá nhân cho các thói quen làm việc của bạn. Tập trung vào các kết nối giữa bất kỳ thực hành nào không thay đổi trong một khoảng thời gian. Hãy tự hỏi bản thân bản đồ của bạn sẽ thay đổi như thế nào nếu bạn phát hiện ra rằng một trong những thực hành đó thực ra lại là không công hiệu. Kiểm tra chặt chẽ một trong những thực hành đó và tìm ra rằng liệu có tồn tại những cách khác để đạt được cùng một mục đích hay không. Chúng không cần phải là những cách tốt hơn; điều đó là đủ đề chúng trở nên khác biệt. Bây giờ tự hỏi bản thân bạn sẽ làm gì với bản đồ của mình nếu bạn đã áp dụng một trong những thực hành khác nhau này.
[2]The Retrospective Prime Directive
Bài tiếp: [Học nghề] Ghi lại những gì đã học
Bài trước: [Học nghề] Sử dụng nguồn
0 Lời bình