Làm thế nào để tôi khiến mọi người ngừng đạp xe (tập trung vào những chuyện nhỏ nhặt)?

Tôi đã được giao nhiệm vụ dạy cho các đội khác một cơ sở mã mới, nhưng tôi tiếp tục gặp phải một vấn đề. Bất cứ khi nào tôi thực sự đi bộ mã với mọi người, chúng tôi sẽ không đi quá xa trước khi toàn bộ bài tập bị phá hủy thành một cuộc đua xe đạp (các thành viên của một tổ chức có trọng lượng không tương xứng với các vấn đề tầm thường). Vì họ không biết codebase, nhưng nghĩ rằng họ cần giúp cải thiện nó, họ tập trung vào những điều họ có thể hiểu:

Why is that named that? _{(2 phút để giải thích lý do tại sao nó được đặt tên như vậy, hơn 10 phút tranh luận về một tên mới)}

Why is that an abstract base class rather than an interface? _{(2 phút để giải thích, hơn 10 phút tranh luận về giá trị tương đối của quyết định này)}

... và cứ thế. Bây giờ, đừng hiểu sai ý tôi - tên tốt và thiết kế phù hợp, tốt là rất quan trọng, nhưng chúng tôi không bao giờ thảo luận về những gì mã thực sự làm hoặc cách hệ thống được thiết kế theo bất kỳ cách có ý nghĩa nào. Tôi đã thực hiện một số cuộc họp trọng tài để đưa mọi người ra khỏi những tiếp tuyến này, nhưng họ đã biến mất - bị phân tâm bởi những gì mã sẽ / nên khi tầm thường thú cưng của họ được sửa chữa, và họ bỏ lỡ bức tranh lớn hơn.

Vì vậy, chúng tôi thử lại sau (hoặc với một phần khác của cơ sở mã) và vì mọi người không có đủ kiến ​​thức để vượt qua hiệu ứng đạp xe, nên nó lặp lại.

Tôi đã thử các nhóm nhỏ hơn, các nhóm lớn hơn, mã, bảng trắng, sơ đồ thị giác, các bức tường văn bản khổng lồ, cho phép họ tranh luận về cái chết, cắt ngắn lập luận ngay lập tức ... một số giúp đỡ nhiều hơn những người khác, nhưng không có gì hiệu quả . Quỷ quái, tôi thậm chí đã cố gắng để những người khác trong nhóm của mình giải thích điều đó bởi vì tôi nghĩ có thể là tôi chỉ tệ trong việc giải thích mọi thứ.

Vì vậy, làm thế nào để bạn giáo dục các lập trình viên khác đủ để họ ngừng sửa chữa những điều tầm thường và có thể đóng góp một cách có ý nghĩa vào thiết kế?

Tôi nghĩ vấn đề là nhiệm vụ: "Tôi đã được giao nhiệm vụ dạy cho các đội khác một cơ sở mã mới".

Bạn đã được giao sai công việc, hoặc có thể hiểu sai công việc bạn đã được giao.

Bằng cách trình bày ở cấp mã, bạn mời tư duy cấp mã.

Bắt đầu ở cấp hệ thống và trình bày thiết kế và các lựa chọn thiết kế đã được thực hiện. Đừng cho phép thảo luận mở rộng: bạn không xem xét nó. Đừng cho phép câu hỏi: bạn muốn họ hiểu hệ thống. Nếu mọi người "sẽ làm điều đó khác đi", tốt thôi. Có lẽ đồng ý. Hay không. Nhưng di chuyển trên. Đó là cách của nó ngay bây giờ.

Khi bạn đạt đến cấp độ mã, bạn sẽ có được chúng theo nguyên tắc hệ thống. Các tên (tôi giả sử) sẽ có ý nghĩa. Tương tự như trên: không có thảo luận mở rộng, câu hỏi để hiểu. Tiến lên.

Bây giờ đặt một số vấn đề lớp để giải quyết. Làm thế nào chúng ta có thể thực hiện tăng cường X? Chọn một cái gì đó không tầm thường "đi theo dòng chảy" của thiết kế hệ thống và xử lý những gì bạn sẽ thay đổi. Họ nên có được sự hợp lý của hệ thống bây giờ. Chọn một cải tiến khác có thể phá vỡ hệ thống nếu thực hiện sai và chỉ ra cách thực hiện đúng. Đó nên là một khoảnh khắc Ah Ha cho họ. Một số thậm chí có thể đánh bại bạn với nó!

Đó là một hợp đồng khó khăn, đặc biệt là sau khi bắt đầu sai bạn đã có. Có vẻ như bạn đã đầu tư rất nhiều thời gian và công sức, và có lẽ có một chút cảm giác của tôi so với họ. 'Fess up, và bắt đầu lại. Chúng tôi cho rằng họ là những người thông minh. Cung cấp cho họ những thách thức về tư duy ở cấp độ cao hơn. Và chia nhỏ các nhóm đã tồn tại bằng cách chọn các phần khác nhau của các nhóm cho các phiên mới.

"Đậu chúng". Khi bắt đầu bài học, hãy giải thích những gì bạn sẽ thảo luận và giải thích rõ ràng những gì được coi là Off Topic. Nếu bạn được hỏi một câu hỏi rõ ràng là OT, hãy nói như vậy và tiếp tục. Nếu họ quay lại với nó, hãy viết câu hỏi lên bảng trắng (Điều này rất quan trọng) để thảo luận sau và tiếp tục. Vào cuối bài học, khi họ ở vào thời gian riêng của họ, không phải của bạn, hãy xem những câu hỏi đó được giải quyết nhanh như thế nào.

Đặt kỳ vọng chính xác và trung thực, cởi mở và trả trước.

Hãy chắc chắn rằng mục tiêu của bạn là công khai và minh bạch.

Bắt đầu các cuộc thảo luận với chế độ xem cấp cao như được quảng bá bởi andy256 (+1) nhưng cũng đảm bảo rằng bạn bao gồm các mục tiêu của mình, ví dụ:

"... khi chúng tôi xem xét vấn đề này, hãy đảm bảo rằng chúng tôi không tập trung vào x, y và z. Hãy đảm bảo rằng chúng tôi không xem xét các chi tiết triển khai như chi tiết a, b, c hoặc tầm thường chẳng hạn như j, k, l. Tôi biết chắc chắn có rất nhiều chi tiết trong mã và chi tiết những điều có thể được giải quyết, cải thiện hoặc làm cho chuẩn hơn, nhưng trước tiên hãy thử xem những gì nó thực sự đạt được ở cấp cao hơn "

Vì vậy, làm thế nào để bạn giáo dục các lập trình viên khác đủ để họ ngừng sửa chữa những điều tầm thường và có thể đóng góp một cách có ý nghĩa vào thiết kế?

Đầu tiên, đừng nghĩ về mối quan tâm của họ là "tầm thường" hay "đạp xe". Đó là những lời phán xét, và họ đang xúc phạm. Mối quan tâm của họ là hợp lệ. Chúng chỉ không quan trọng vào lúc này.

Chìa khóa cho bất kỳ cuộc họp tốt là cho mọi người biết:

• tại sao bạn có một cuộc họp và
• những gì bạn hy vọng để thoát khỏi nó
• nó sẽ kéo dài bao lâu

Nêu rõ những điều này lên phía trước, một cách rõ ràng và giải thích các mục tiêu.

Ví dụ: bạn có thể nói: "Cuộc họp này là để tôi làm quen với gói Foo và cách nó được sử dụng trong mô-đun báo cáo của chúng tôi. Mục tiêu của tôi là giúp bạn hiểu đủ về Foo để bạn có thể làm việc trong dự án Báo cáo Bar sắp tới tuần tới. Tôi muốn chúng tôi hoàn thành trong 90 phút tới. "

Sau đó, khi một chủ đề xuất hiện, nó có thể diễn ra như sau:

Người mới: "Tại sao FooWidget được triển khai như một mô hình mặt tiền?"

Bạn: "Chà, tôi nghĩ đó là vì (giải thích ngắn gọn về quyết định thiết kế)" hoặc "Tôi không biết."

Nếu câu trả lời là đủ, điều đó thật tuyệt. Nếu không, và nó tiếp tục:

NP: "Bạn không nghĩ rằng nó sẽ được thực hiện tốt hơn như là một singleton?"

Bạn: "Tôi đã không thực sự nghĩ về điều đó, nhưng tôi muốn tiếp tục tiến lên với việc giải thích cách FooWidget hoạt động."

NP: "Nhưng nếu nó được thực hiện dưới dạng đơn lẻ thì chúng ta có thể--"

Bạn: "Tôi xin lỗi vì làm gián đoạn, nhưng tôi cần tập trung vào việc FooWidget hoạt động. Cuộc họp này chỉ được lên kế hoạch đến 11:00 và chúng tôi có rất nhiều việc phải làm. Cuộc thảo luận thiết kế sẽ phải chờ một thời gian khác . "

Sau khi bạn trải qua điều đó một hoặc hai lần, bạn có thể viết tắt nó thành "Điều đó nằm ngoài phạm vi của cuộc họp này."

Lưu ý rằng bạn không nói "Điều đó thật ngu ngốc để lo lắng" hoặc "Không thành vấn đề" hoặc "Im lặng" hoặc "Bạn quá mới để có đầu vào." Bạn chỉ đơn giản là tập trung cuộc họp vào những gì cần hoàn thành và thời gian liên quan.

Trong một số tổ chức nhất định, bạn sẽ không bao giờ có thể đạt được điều này. Nhiều tổ chức coi trọng sự thay đổi chính trị và cách leo thang hơn là năng lực trí tuệ, sự siêng năng và lòng trung thành. Và tại sao họ sẽ không. Leo thang đặt con người vào vị trí quyền lực, cho phép họ nâng cao cuộc sống cá nhân với thu nhập tùy ý hơn và thực sự không bao giờ trở nên lỗi thời.

Trái ngược với sức mạnh này - giải quyết vấn đề thực tế, suy nghĩ trừu tượng và đưa ra quyết định về các vấn đề khó khăn mà họ có thể phải chịu trách nhiệm cho hậu quả sau này, và nhiều nhân viên đã cân nhắc rất nhiều về việc cố gắng đạp xe hết mức có thể.

Lời khuyên duy nhất tôi đề nghị là bạn làm cho nó rõ ràng, trong bối cảnh tổ chức của bạn, nếu có thể, rằng những người tham gia này số phận cá nhân phụ thuộc vào sự hiểu biết, đóng góp và nỗ lực của họ đối với vấn đề thực sự mà bạn đang cố gắng giải quyết. Nếu đó là kiến ​​trúc doanh nghiệp, được thể hiện trong mã cơ sở dữ liệu này và tất cả những gì nó thất bại, thì đó là nó. Hãy nói rõ với họ rằng họ phải cung cấp đầu vào có ý nghĩa đáng kể về điều đó . Không phải là một sự ngẫu nhiên nào khác, điều đó tình cờ trở thành thú cưng của một người cao cấp hoặc người khác và sẽ đạt được điểm số tốt đẹp bằng cách đồng ý với người cao cấp nói trên.

Điều này thường khó thực hiện, vì người cao cấp thường không hiểu công nghệ đang diễn ra, không quan tâm và thật không may, kiểm soát các thành phần thô: thời gian của nhân viên; thuê và chữa cháy, chính trị phòng hội nghị, chương trình khuyến mãi, vv, vv nghiêm túc, et cetera đến thứ n.

Những gì bạn gọi là đi xe đạp, tôi sẽ gọi việc chuyển đổi dòng suy nghĩ của ai đó thành của chúng ta. Bằng cách thảo luận về tên, mẫu, họ có thể hiểu mã theo các thuật ngữ của riêng họ và không có cách nào để ngăn chặn nó, điều đó là cần thiết.

Bên cạnh đó, không cần phải đi theo hướng dẫn chi tiết về toàn bộ cơ sở mã, bởi vì các chi tiết sẽ bị lãng quên từ lâu trước khi chúng bắt đầu làm việc với nó.

Dựa trên hai ý tưởng này, tôi sẽ đề xuất chia cơ sở mã thành các đơn vị và người học thành các nhóm hai người. Đối với mỗi đơn vị mã, mỗi nhóm sẽ có khoảng 25 phút (tất nhiên phụ thuộc vào LỘC ), để có thể thực hiện một đoạn giới thiệu 5-10 phút cho các mã khác. Ba phút câu hỏi và lặp lại với các đơn vị tiếp theo. Giải thích là từ khóa; họ phải đảm bảo những người khác đã hiểu tất cả về nó.

Bạn sẽ chỉ ở đó để thực thi thời gian, không có chủ đề ngoài phạm vi và kiểm soát đơn vị đã được hiểu đủ. Họ sẽ là diễn viên của việc học của họ và sẽ tập trung vào việc giải thích cho những người khác hơn là đi xe đạp.

Bạn có thể yêu cầu một lược đồ vẽ tay cấp cao từ chúng của đơn vị mã, chúng sẽ được sao chép và lưu giữ trên các tài liệu được chia sẻ theo nhóm, để chúng có một cái gì đó hữu hình để tham khảo trong tương lai. Điều đó cũng tốt để neo giữ ký ức.

Xin lỗi nếu bạn đã thử ...

Bạn đã thử làm những bài học trước mà mọi người nhìn qua chưa?

Tạo các video hoặc bài thuyết trình ngắn giải thích nội dung, cách thức hoạt động của mã hoặc về cơ bản tất cả những gì bạn muốn dạy chúng theo định dạng mà chúng cần tự xem và tìm hiểu thông tin bạn đang cố gắng dạy chúng.

Sau đó, bạn sử dụng các phiên dựa trên nhóm để thảo luận về các vấn đề liên quan đến nội dung. Bạn cần xác định rõ rằng các phiên nhóm chỉ dành cho thảo luận và khắc phục các sự cố liên quan đến nội dung.

Nếu bạn cung cấp các bài học cho mọi người trên cơ sở cá nhân, bạn có thể tránh được vấn đề xã hội khác khi một vấn đề duy nhất có thể trở thành tiếng nói của nhóm như một tập thể và làm sao lãng mục đích thực tế của các bài học.

Trước tiên hãy thử dạy họ thiết kế cơ sở mã, hướng dẫn họ làm tròn kiến ​​trúc, TRƯỚC KHI bạn bắt đầu xem xét các ví dụ cụ thể. Bằng cách đó, họ có thể thấy các ví dụ mã mà bạn nhìn phù hợp với bức tranh lớn hơn. Hãy suy nghĩ về cách chương trình đào tạo của bạn được cấu trúc. Và bao gồm các động lực kinh doanh đằng sau thiết kế.

Tôi đã dành vài năm để đào tạo các nhà phát triển khác và tôi chưa bao giờ đi sâu vào mã trước khi chỉ cho họ cách hệ thống kết hợp với nhau. Sau đó, khi tôi yêu cầu họ thực hiện các bài tập mã trong khung, các câu hỏi được cấu trúc và theo chủ đề.