Khi nào bạn không giúp đỡ cho các lập trình viên ít kinh nghiệm? [đóng cửa]

Bạn có nghĩ rằng đó là một ý tưởng tốt khi một lập trình viên cơ sở cần giúp đỡ để luôn luôn nhảy vào và cố gắng giáo dục họ? Hay họ sẽ bỏ qua tất cả những lời khuyên "dạy cá" mà bạn dành cho họ và chỉ tập trung vào "con cá" bạn vừa mang cho họ? Bạn có để họ luôn tự mình tìm ra mọi thứ, biết rằng sai lầm là cách tốt nhất để học? Hay bạn sợ rằng họ sẽ bị bỏng và thất vọng đến mức họ sẽ mất đi mong muốn tăng tốc?

Khi nào bạn chọn khi nào giúp ai đó hơn đàn em và khi nào bạn nên đứng lại và để họ học hỏi qua những sai lầm của họ?

Tại một trong những công việc của tôi, tôi vừa học vừa dạy (vì tất nhiên tôi không biết tất cả mọi thứ, nhưng tôi biết nhiều hơn một số)

Đừng bao giờ đặt tay lên bàn phím. Điều này gây khó chịu cho cả bạn và người bạn đang dạy. Ngay cả khi bạn đưa cho họ các hướng dẫn từng bước, khi bạn đặt tay lên bàn phím, điều đó tương đương với việc đưa cho họ một đoạn mã và nói "điều này sửa nó".

Trong những gì tôi đã học được:

• Đừng gõ mã cho họ
• Cố gắng dạy theo cấp độ của họ (nếu họ hiểu cú pháp, đừng giải thích cho họ. Điều này sẽ khiến họ chán nản; thay vào đó hãy dạy các lớp / hàm được sử dụng)
• Đừng bỏ qua chúng hoặc nói "tự mình tìm ra". Những gì bạn sẽ kết thúc là chúng sẽ đến với bạn sau đó ngoại trừ 3 dòng mã mà chúng gặp vấn đề, hiện có 50 dòng trải rộng trên 8 tệp đang cố gắng khắc phục sự cố.
• Dạy chúng tự học. Một trong những cách tốt nhất là bảo họ sử dụng stackoverflow. Tôi đôi khi, thậm chí biết câu trả lời, nếu họ hỏi tôi. Tôi sẽ nói "tốt, tôi sẽ hỏi câu hỏi này trên stackoverflow". và tôi sẽ cung cấp cho họ một liên kết đến câu hỏi. Nghỉ giải lao và xem xét một số mã khác nhau. Khi họ quay lại hỏi "vậy làm cách nào để khắc phục vấn đề đó" chỉ cần bảo họ tra cứu câu hỏi của họ trên SO (sử dụng URL bạn đã cung cấp cho họ). Tôi đã thấy rằng quần chúng thường là một giáo viên tốt hơn tôi.
• Khi họ sao chép và dán mã từ internet và hỏi tại sao nó không hoạt động, hãy yêu cầu họ giải thích mỗi dòng làm gì. Nếu họ không thể, sau đó bảo họ nghiên cứu các chức năng / lớp được sử dụng. Nếu cần, cung cấp giải thích cho lớp và chức năng
• Tiến hành đánh giá mã để đảm bảo rằng họ đang giải quyết vấn đề, không chỉ làm việc xung quanh nó để hiển thị sau.
• Hãy tử tế Khi ai đó chỉ mới bắt đầu trong cơ sở mã của bạn mà không có tài liệu, đừng chỉ bảo họ đọc mã nguồn. Đưa ra một tổng quan cấp cao tóm tắt của chức năng trong câu hỏi. Hoặc, tốt hơn nữa, bắt đầu viết tài liệu :)
• Khiêm tốn. Đừng hỏi BS về vấn đề này. Nếu bạn không biết điều đó, hãy nói rằng bạn không và giúp họ tìm kiếm nó. Nhiều lần, chỉ cần biết tên miền đủ để biết từ khóa nào cần tìm là đủ giúp bạn cung cấp cho họ.

Phương pháp xã hội, tức là hỏi họ những câu hỏi khiến họ suy nghĩ theo hướng tích cực

[điều này hữu ích ngay cả khi bạn không biết vấn đề là gì, ít hơn là giải pháp]

Tôi đã học được để giúp họ kiến ​​trúc sư và dừng lại ở đó. Chọn các công cụ phù hợp, đưa ra một thiết kế chung cho một hoặc hai vấn đề phức tạp và để chúng đi theo nó. Nếu họ quay lại và xin lời khuyên, hãy đưa nó cho họ trong những khối nhỏ. Nếu họ không, hãy để họ được.

Bạn hoàn toàn đúng về "cháy và thất vọng". Chúng sẽ chính xác nếu bạn quản lý vi mô hoặc chọn nit. Cuối cùng, nó giúp ích rất nhiều để thiết lập mối quan hệ làm việc thân thiện với đồng nghiệp của bạn. Thời gian dành cho sự tin tưởng và tôn trọng lẫn nhau sẽ trả cho chính nó gấp 10 lần.

Tôi giúp họ khi tôi thực sự cần mọi thứ được hoàn thành nhanh chóng, khi rõ ràng là họ đã va vào một bức tường gạch, và khi đó rõ ràng là không hợp lý để mong họ tìm ra nó mà không cần giúp đỡ. Tuy nhiên, nếu họ không đặt bất cứ lúc nào vào một cái gì đó, thì tốt hơn là họ nên thử nó trước.

Theo như "bắt cá" thay vì "dạy cá", cách tốt nhất để làm điều đó là không giải quyết vấn đề của mọi người cho họ . Cung cấp cho họ ý tưởng và để họ chạy với nó. Nếu họ chạy với nó, và thất bại, sau đó giúp họ nhiều hơn. Nếu họ thành công, thậm chí tốt hơn.

Nếu họ là một lập trình viên giỏi, họ nên tìm cách hoàn thành nó. Bây giờ trong một tình huống không thể tìm thấy thông tin hoặc giải pháp cho một vấn đề nhất định, việc cho mượn một bàn tay trợ giúp dường như nằm trong lý do miễn là bạn giữ nó trong lý do. Đừng cho chúng ăn câu trả lời.

Có lẽ như một ví dụ tôi 18 tuổi và đã tự học nhiều năm nay và đã viết một số điều điên rồ bao gồm trình biên dịch của riêng tôi và tôi tự học. Tôi chỉ tìm kiếm sự giúp đỡ với những thứ tôi thực sự bị mắc kẹt (như tôi đã tìm kiếm và thử nghiệm ít nhất một ngày nhưng không có kết quả). Tôi cũng muốn cung cấp một ví dụ ngược lại: Trong một lớp lập trình tôi đã từng có một sinh viên yêu cầu tôi gỡ lỗi mã mà anh ta thậm chí không biên dịch!

Về cơ bản, một lập trình viên giỏi, thậm chí là một thiếu niên, có thể thử nghiệm và nghiên cứu các giải pháp cho hầu hết các vấn đề.

Tôi sẽ cố vấn nhưng tôi bỏ đi nếu họ muốn tôi làm việc cho họ. Thông thường chỉ là một số lời khuyên về cách giải quyết vấn đề, hoặc diễn đạt lại mô tả nhiệm vụ có thể đi một chặng đường dài. Thậm chí chỉ cần nói với họ những từ họ nên sử dụng trong google cũng có thể đủ giúp đỡ. Tối đa 2 phút.

Gần đây tôi đã bắt đầu sử dụng kỹ thuật pomodoro . Kết quả là, nếu tôi không thể trả lời một câu hỏi mà không phá vỡ suy nghĩ về nhiệm vụ hiện tại của mình, tôi đã bắt đầu hỏi liệu tôi có thể hoãn câu trả lời cho đến khi kết thúc pomodoro hay không, trung bình là khoảng 15 phút chậm trễ. Một tác dụng phụ thú vị của điều này tôi đã phát hiện ra là khi tôi ghé qua bàn của họ để trả lời câu hỏi, họ thường tự mình giải quyết nó. Nếu họ không có, tại thời điểm đó tôi đã chuẩn bị nhiều hơn để cung cấp cho họ toàn bộ sự chú ý của tôi.

Đây không phải là trường học. Sẽ không gian lận nếu bạn nhanh chóng cung cấp một sự thật mà cuối cùng họ có thể tự mình tìm thấy. Ngược lại, nó có ý nghĩa kinh doanh tốt để tiết kiệm thời gian cho họ, và theo kinh nghiệm của tôi, kỹ năng của tôi được mài giũa rất ít bằng cách thử và sai so với một người cố vấn cho bạn những cú đẩy nhỏ thường xuyên theo đúng hướng. Tôi muốn họ học 10 cách đúng đắn để làm mọi việc với sự giúp đỡ của tôi hơn 9 cách sai và một cách đúng.

Nếu một cái gì đó có thể dễ dàng tra cứu, hãy dạy họ cách làm như vậy. Mặt khác, nếu đó là điều mà bạn chỉ có thể biết từ kinh nghiệm, như tập tin nào cần điều tra cho một số triệu chứng lỗi nhất định, tôi thấy hoàn toàn không có gì sai khi chỉ đưa ra một câu trả lời không giải thích được.

Ngược lại, những thứ chủ quan hơn như hướng dẫn kiến ​​trúc nên luôn đi kèm với lý do đằng sau nó. Đối với một điều, nhà phát triển cơ sở đã suy nghĩ sâu hơn về nhiệm vụ cụ thể của họ hơn bạn có. Nói qua nó đảm bảo bạn sẽ không đi đến kết luận. Mặt khác, nó giữ cho họ khỏi áp dụng các quy tắc một cách mù quáng vào các tình huống trong tương lai mà họ có thể không áp dụng.

Tôi chỉ có thể nghĩ về một trường hợp mà tôi hoàn toàn từ chối tiếp tục giúp đỡ đồng nghiệp, và đó là sau khi dành vài giờ để giải thích điều gì đó nhiều lần và trải qua một vài ví dụ, sau đó cô ấy vẫn không biết câu tiếp theo nào để gõ một số gợi ý rất hàng đầu. Vào thời điểm đó, cô có rất ít hy vọng duy trì công việc của mình mà không cần phải học lại các nguyên tắc cơ bản nghiêm túc, và chắc chắn rằng cô chỉ kéo dài một vài tháng.

Tôi ngừng giúp đỡ họ khi họ quay lại với cùng một câu hỏi lần thứ ba.

Tôi nói với họ rằng tôi rất vui lòng giúp đỡ họ nhưng chỉ khi họ tự giúp mình trước. Từ đó, họ đi tìm một cái ao khác để câu cá để kiếm thức ăn miễn phí, trong trường hợp đó họ thường bị đuổi việc một thời gian ngắn sau đó. Hoặc họ làm việc với nó và trúng số độc đắc khi họ quay lại để kiếm thêm ... đó là nhiều thứ để học hơn là nhiều thứ tương tự!

Tôi nghĩ vấn đề bối cảnh.

Nếu chúng ta đang giải quyết một vấn đề hỗ trợ sản xuất quan trọng trong đó thời gian phản hồi là quan trọng, thì tôi thực sự sẽ cung cấp rất nhiều trợ giúp cùng với rất nhiều lời giải thích để họ có thể tìm hiểu vấn đề.

Nếu thời hạn ít nhạy cảm hơn, thì sự phức tạp sẽ trở thành trình điều khiển. Tất nhiên, bạn có thể giúp đỡ người mới rất nhiều chỉ bằng cách giao nhiệm vụ phù hợp ở cấp độ kỹ năng, nhưng nếu đó là điều có thể giải quyết thông qua nghiên cứu, thì tôi đồng ý với các áp phích khác hướng dẫn họ mà không đưa ra câu trả lời chính xác là một cách tiếp cận tuyệt vời .

Nếu họ đặt câu hỏi dễ dàng trả lời bằng cách tìm ở nơi khác, thì tôi sẽ điều khiển họ làm công việc của họ. Dọc theo những dòng đó, nếu có một quy trình hoặc giải pháp khá vất vả và có ít giá trị trong việc biến chúng thành nô lệ cho nó, thì thật xấu hổ cho bạn nếu bạn không có wiki để họ kiểm tra.

Khi nói đến việc chuyển kiến ​​thức tên miền tùy chỉnh cho doanh nghiệp, thì tôi không băm chữ. Bài giảng thẳng càng sớm càng tốt. Người mới cần điều đó để giúp đỡ với mọi thứ đến sau. Không có điều gì như được giáo dục về doanh nghiệp quá nhanh hoặc quá dễ dàng. Tôi đã có một ông chủ một lần chơi đủ loại mánh khóe trong một giờ cố gắng dẫn tôi đến một câu trả lời. Tôi là một thương hiệu mới, chưa biết gì về ứng dụng hoặc doanh nghiệp và tôi đang giải quyết vấn đề hỗ trợ sản xuất. Tôi muốn hét lên, "Tại sao bạn & # @ $! Chơi # @ & (* $%! Trò chơi? Người dùng đang cố lấy hóa đơn ra ngoài đang chờ câu trả lời!"

Tôi nghĩ rằng điều đầu tiên bạn phải hỏi họ trước khi giúp họ là bạn đã điều tra về vấn đề này chưa? nếu có, hãy hỏi họ những gì họ đã tìm ra và chỉ cho họ đi đúng hướng. Điều tra nó thường được đánh giá thấp nhưng là một trong những thực tiễn tốt nhất tôi đã học được, tìm kiếm thông tin về những gì bạn cần cho bạn sức mạnh để tự học, cũng sẽ làm rõ rằng họ phải thử trước.

Nếu vấn đề phức tạp hơn, cố gắng không nói cho họ biết phải làm gì ngoài việc chia sẻ một số ý tưởng, hãy hỏi họ làm thế nào để họ nghĩ rằng họ có thể tiếp cận vấn đề.

Nếu họ không có đầu mối thì hãy cố gắng chia nó xuống mức rất cơ bản, nơi bạn không cung cấp tất cả các chi tiết nhưng mô tả giải pháp đủ để họ thử, có những công cụ rất hữu ích cho việc này như thuật toán hoặc sơ đồ .

Tóm lại, hãy cố gắng hướng dẫn họ mà không can thiệp vào quá trình học tập, luôn luôn giúp đỡ họ sẽ khiến họ phụ thuộc vào bạn cho mọi nhiệm vụ sau đó được giao, điều đó sẽ làm mất thời gian của bạn và phản tác dụng.

Tôi tránh giúp đỡ về những điều đơn giản như cú pháp mà họ nên biết hoặc nếu họ không biết họ có thể tự hiểu được. Nếu nó là một cái gì đó phức tạp hơn, tôi không ngại giải thích một lần.

Khi nói đến những việc như giải thích quy trình, hoặc các tiêu chuẩn mã hóa của tổ chức / dự án của chúng tôi, v.v., tôi sử dụng quy tắc ba lần đình công. Tôi thực sự nghĩ rằng một người là khập khiễng nếu anh ta phải giải thích mọi thứ ba lần. Trong thực tế đó cũng là một trong những tiêu chí trong thẩm định của chúng tôi.

Rất nhiều phụ thuộc vào người học. Tôi mong họ tự mình nhặt một vài thứ. Nếu họ nghĩ ra: "Tôi đã đối mặt với vấn đề này, tôi đã thử các phương pháp A, B và C nhưng tôi không thể giải quyết vấn đề", tôi sẽ giúp họ. Nếu họ chỉ đơn giản nghĩ ra "Tôi đang đối mặt với vấn đề này" và chưa làm gì thì tôi sẽ yêu cầu họ quay lại sách và tìm kiếm giải pháp.

Là một lập trình viên mới, bản thân tôi (khoảng 9 tháng trong công việc hiện tại của tôi sử dụng chủ yếu là Perl và SQL và với a) không có kiến ​​thức về Perl và b) vài tháng mày mò với SQL trước công việc này), khi đặt câu hỏi về lập trình, tôi cố gắng thể hiện những gì tôi đã làm cho đến nay, hoặc trong trường hợp một cái gì đó không hoạt động (và khó gỡ lỗi), nơi tôi nghĩ rằng lỗi có thể nằm. Khi có thể, tôi đã tìm cách học cách câu cá.

Tôi ngừng giúp đỡ trong các trường hợp sau đây:

• Nếu tôi đang được sử dụng để kênh Google / Stack
• Nếu tôi đã cung cấp tài liệu và nhận xét đầy đủ, và họ đang rút ngắn giai đoạn RTFM
• Nếu chúng là một thứ bẩn thỉu, không có bình luận, "Tôi sẽ hack cái này ngay bây giờ và quay lại sau" & & £>! $

Nếu tôi chưa cung cấp tài liệu đầy đủ hoặc họ đang làm việc với một công cụ / lớp mà tôi đã tạo ra, thì tôi có trách nhiệm giúp đỡ họ