จะแก้ไขจูเนียร์ได้อย่างไร แต่สนับสนุนให้เขาคิดด้วยตัวเอง? [ปิด]

ฉันเป็นผู้นำของทีมเล็ก ๆ ที่ทุกคนมีประสบการณ์การพัฒนาซอฟต์แวร์น้อยกว่าหนึ่งปี ฉันจะไม่เรียกตัวเองว่าเป็นกูรูด้านซอฟต์แวร์เลย แต่ฉันได้เรียนรู้เล็ก ๆ น้อย ๆ ในช่วงไม่กี่ปีที่ฉันได้เขียนซอฟต์แวร์

เมื่อเราทำการตรวจสอบโค้ดฉันทำการสอนและแก้ไขข้อผิดพลาดเล็กน้อย ฉันจะพูดสิ่งต่าง ๆ เช่น "นี่ซับซ้อนเกินไปและซับซ้อนและนี่คือสาเหตุ" หรือ "คุณคิดอย่างไรเกี่ยวกับการย้ายวิธีการนี้ไปสู่ชั้นเรียนที่แยกจากกัน" ฉันระมัดระวังเป็นพิเศษในการสื่อสารว่าหากพวกเขามีคำถามหรือความคิดเห็นที่ไม่เห็นด้วยก็โอเคและเราต้องหารือ ทุกครั้งที่ฉันแก้ไขใครบางคนฉันถาม "คุณคิดอย่างไร?" หรือสิ่งที่คล้ายกัน

อย่างไรก็ตามพวกเขามักไม่ค่อยเห็นด้วยหรือถามว่าทำไม และเมื่อเร็ว ๆ นี้ฉันสังเกตเห็นสัญญาณที่ชัดเจนขึ้นว่าพวกเขาเห็นด้วยกับข้อความของฉันและไม่สร้างความคิดเห็นของพวกเขาเอง

ฉันต้องการทีมที่สามารถเรียนรู้ที่จะทำสิ่งต่าง ๆ ได้อย่างอิสระไม่เพียงแค่ทำตามคำแนะนำ ใครจะแก้ไขนักพัฒนารุ่นเยาว์ได้อย่างไร แต่ยังคงสนับสนุนให้เขาคิดด้วยตัวเอง?

แก้ไข: นี่คือตัวอย่างของหนึ่งในสัญญาณที่ชัดเจนเหล่านี้ว่าพวกเขาไม่ได้สร้างความคิดเห็นของตัวเอง:

ฉัน: ฉันชอบความคิดของคุณในการสร้างวิธีการขยาย แต่ฉันไม่ชอบวิธีที่คุณส่งแลมบ์ดาที่ซับซ้อนขนาดใหญ่เป็นพารามิเตอร์ แลมบ์ดาบังคับให้คนอื่นรู้มากเกินไปเกี่ยวกับวิธีการใช้งาน

จูเนียร์ (หลังจากเข้าใจผิดฉัน): ใช่ฉันเห็นด้วยทั้งหมด เราไม่ควรใช้วิธีการขยายที่นี่เพราะพวกเขาบังคับให้นักพัฒนาคนอื่นรู้มากเกินไปเกี่ยวกับการใช้งาน

มีความเข้าใจผิดและได้รับการแก้ไข แต่ไม่มีแม้แต่ตรรกะของออนซ์ในคำพูดของเขา! เขาคิดว่าเขาสำรอกตรรกะของฉันกลับมาให้ฉันคิดว่ามันจะสมเหตุสมผลเมื่อจริง ๆ แล้วเขาไม่มีเงื่อนงำทำไมเขาพูดมัน

คำตอบสั้น ๆ :

มีส่วนร่วม (ไขปริศนาไว้ในใจ) เสริมพลังพวกเขา (เชื่อคำตอบ)

มันเป็นคำถามที่ผลักดันพวกเรา! - เมทริกซ์

โดยทั่วไปในการสังเกตของฉันจูเนียร์มีโลกของตัวเอง - มุมมองที่ จำกัด ของพวกเขาว่าพวกเขาคิดอย่างไรและในบางส่วนมีความกระตือรือร้น / รายการโปรด / ความคิดเห็นเกี่ยวกับสิ่งต่าง ๆ

ไม่มีอะไรผิดที่จะบอกพวกเขาว่าคุณคิดผิด - แต่สิ่งที่ดีที่สุดคือคุณทำให้พวกเขาคิด ทำไม? มีวิธีอื่นอีกไหม? มีวิธีที่ดีกว่าในการทำสิ่งเดียวกันหรือไม่? หนึ่งในเกร็ดเล็กเกร็ดน้อยที่ฉันมักจะใช้คือ - "ให้สามโซลูชั่น (กับปัญหานี้)!"

ตามเวลาที่พวกเขาคิดเกี่ยวกับการแก้ปัญหาเหล่านี้พวกเขาเริ่มตระหนักถึงปัญหามากมาย พวกเขาใช้เวลาในการลงทุน - แต่เมื่อเวลาผ่านไปพวกเขามักจะเห็นข้อ จำกัด และข้อบกพร่องของการคิด พวกเขาเริ่มเห็นอีกว่า"ฉันไม่ได้คิดถึงมัน!" ซึ่งดีกว่ากลับบ้านด้วยความรู้สึกว่า"ฉันผิด!" หรือแม้แต่เลว"ผมก็บอก / พิสูจน์ความผิดแม้ในขณะที่ผมมีมุมมองที่ถูกต้อง"

โดยทั่วไปแล้วเด็กเล็กมากมักจะมีความเชี่ยวชาญมากขึ้นเกี่ยวกับปัญหาทางเทคนิค (เช่นรูปแบบการออกแบบทำงานได้ดีกว่า!) ในเรื่องของกระบวนการแต่เมื่อเวลาผ่านไปเมื่อคุณสอนพวกเขามันทำงานได้ดี

อย่างไรก็ตามพวกเขามักไม่ค่อยเห็นด้วยหรือถามว่าทำไม และเมื่อเร็ว ๆ นี้ฉันสังเกตเห็นสัญญาณที่ชัดเจนขึ้นว่าพวกเขาเห็นด้วยกับข้อความของฉันและไม่สร้างความคิดเห็นของพวกเขาเอง

ซึ่งมักจะเป็นผลที่คุณทำใช้คำแนะนำของพวกเขา แต่ต่อมาลบล้างพวกเขาและพวกเขาได้อย่างเท่าเทียมกันไม่มั่นใจเกี่ยวกับมุมมองของคุณ เพียงเพราะคุณอาวุโสพวกเขากำลังหลีกเลี่ยงการต่อสู้!

สิ่งที่ดีที่สุดที่ฉันได้เรียนรู้จากหนึ่งในผู้บังคับบัญชาที่ผ่านมาของฉัน: เขาจะขอให้สมาชิกในทีมอภิปรายก่อน (พวกเขารู้สึกเท่าเทียมกันที่นี่) และหวังว่าหลังจากการโต้แย้งทั้งหมดหมดลงแล้วเขาจะเข้าห้องด้วยคำถามเดียว - " ประเด็นของความขัดแย้ง? " - ประเด็นคือคนมักจะชอบที่จะมีส่วนร่วมในการอภิปรายและการอภิปราย แต่ถ้าคะแนน (ที่ถูกต้อง) ของพวกเขาจะไม่ถูกดำเนินการในครั้งต่อไปที่พวกเขารู้สึกว่ามันไม่คุ้มค่าที่จะมีส่วนร่วมในการอภิปราย

ไม่เพียง แต่ในซอฟต์แวร์เท่านั้น แต่ทุกที่ในที่สุดเพื่อนร่วมทีมที่มีอำนาจมากที่สุดเท่านั้นที่กล้าตอบคำถามเพียงอย่างเดียว

หากคุณต้องการรุ่นน้องของคุณไปคิดว่าตัวเองไม่ได้แก้ไขให้ถูกต้อง: พวกเขาได้รับการแก้ไขตัวเอง

แทนที่จะบอกพวกเขาถึงสิ่งที่คุณคิดว่าผิดเกี่ยวกับวิธีการแก้ปัญหาของพวกเขาให้ถามคำถามที่เกี่ยวข้องกับพวกเขา ในตัวอย่างของคุณคุณสามารถถามพวกเขาเกี่ยวกับสิ่งที่คนใช้วิธีการขยายจะต้องรู้เพื่อสร้างแลมบ์ดา ถามคำถามต่อไปเรื่อย ๆ จนกว่าพวกเขาจะแนะนำว่าเป็นปัญหา ด้วยวิธีนี้คุณรู้ว่าพวกเขาเข้าใจว่าทำไมการแก้ปัญหาของพวกเขาอาจเป็นปัญหาและยิ่งมีแนวโน้มที่จะเรียนรู้จากมัน - ถ้าคุณเพียงแค่บอกพวกเขาว่าการแก้ปัญหาของพวกเขาผิดนั่นคือการตัดสินจากภายนอก หากพวกเขาตระหนักถึงตนเอง (ด้วยการกระตุ้นเตือนเล็กน้อย) พวกเขาจะตระหนักว่ามีเหตุผลดีเพียงใดและมีแนวโน้มที่จะเรียนรู้จากความผิดพลาดมากขึ้น

นอกจากนี้จะช่วยให้รุ่นน้องของคุณมีโอกาสที่จะปกป้องการออกแบบของพวกเขา - บางทีพวกเขาได้คิดว่าปัญหาที่เกิดขึ้นและมีเหตุผลที่ดีที่อยู่ในความกังวลของคุณมีความหมายมีความจำเป็นสำหรับคุณที่จะแก้ไขใด ๆ ที่ช่วยลดการรับรู้ใด ๆ (แต่ไม่ได้ตั้งใจ) ว่าคุณจะถูกตัดสินโดยผู้บริหารระดับสูง

เนื่องจากคุณมีนักพัฒนาจูเนียร์หลายคนทำการเขียนโค้ดเป็นกลุ่มไม่ใช่ 1 1 1

เปิดโดยถามกลุ่มว่า "จะแก้ไขปัญหาได้อย่างไร" และอนุญาตให้ผู้พัฒนารุ่นเยาว์คนอื่น ๆ แนะนำการใช้งานของพวกเขาก่อน เพิ่มการใช้งานเฉพาะหลังจากสมาชิกทีมคนอื่นพูดและถ้าไม่มีใครแนะนำอะไรที่คล้ายกับความคิดของคุณ

จากนั้นมีการอภิปรายโต๊ะกลมเกี่ยวกับข้อดีและข้อเสียของการใช้งานที่แตกต่างกันโดยมีจุดประสงค์เพื่อเป็นแนวทางในการเลือกใช้งานที่ดีที่สุดโดยไม่ต้องบอกว่ามันคืออะไร

ในฐานะผู้สร้างความมั่นใจให้กับผู้พัฒนาระดับรองคุณสามารถเริ่มต้นด้วยบางกรณีที่พวกเขาเลือกสิ่งที่คุณคิดว่าเป็นตัวเลือกที่ดีที่สุดและสร้างทางเลือกของคุณให้เป็นคนทำหมวกฟางที่มีข้อบกพร่องกึ่งชัดแจ้ง

เมื่อฉันเริ่มทำงานในการเขียนโปรแกรมครั้งแรกฉันทำสิ่งเดียวกับที่คุณอธิบาย: เมื่อบอกเกี่ยวกับสิ่งที่ฉันสามารถทำได้ฉันจะเห็นด้วยเสมอ ส่วนใหญ่เป็นเพราะฉันไม่มีประสบการณ์เพียงพอที่จะพูดเป็นอย่างอื่น

สิ่งที่ทำให้ฉันมีความสามารถในการหารือเกี่ยวกับวิธีการและความคิดคือการเรียนรู้จากประสบการณ์เช่นเดียวกับการอ่านเกี่ยวกับวิธีการที่แตกต่างกันและเทคโนโลยีใหม่ เพื่อให้ทีมของคุณคิดด้วยตนเองพวกเขาจำเป็นต้องรู้จริง ๆ ว่าปัญหาใดบ้างที่เกิดขึ้นจากสิ่งต่าง ๆ เช่นรหัส "ซับซ้อนเกินไปและซับซ้อน" รหัสและวิธีเดียวที่พวกเขาจะค้นพบก็คือผ่านประสบการณ์

วิธีที่ดีในการอำนวยความสะดวกในการคิดเป็นรายบุคคลคือให้พวกเขาเข้าไปดูเว็บไซต์การเขียนโปรแกรมเช่น Stack Overflow หรือโปรแกรมเมอร์ SE ฉันรู้ว่าสิ่งเหล่านี้ช่วยให้ฉันเรียนรู้เกี่ยวกับเทคนิคต่าง ๆ ที่อยู่ข้างนอกและอนุญาตให้ฉันได้พูดคุยกับสมาชิกอาวุโสของทีมแทนที่จะเห็นด้วยกับพวกเขา

ประเด็นก็คือหากไม่มีประสบการณ์คำแนะนำจากสมาชิกอาวุโสจะส่งผลดีต่อพวกเขาเสมอ

ปฏิสัมพันธ์จากโพสต์ของคุณแสดงให้เห็นถึงหลักการสำคัญในการสอนเกือบทุกอย่าง: ขอให้พวกเขาอธิบายสิ่งที่พวกเขาคิดว่าคุณพูดและฟังคำตอบอย่างระมัดระวัง: มันจะบอกคุณอย่างแม่นยำถึงสิ่งที่จำเป็นต้องได้รับการแก้ไข

ฉันถูกขโมยอย่างไร้ยางอายลอกเลียนแบบเคล็ดลับนี้จากติวเตอร์ของฉันเมื่อ 25 ปีก่อนและมันก็ไม่ได้ล้มเหลวตั้งแต่ฉัน ฉันใช้มันในชั้นเรียนในช่วงสั้น ๆ ของฉันในฐานะผู้ช่วยสอนในที่ทำงานเมื่อพูดถึงการออกแบบซอฟต์แวร์และเมื่ออายุแปดขวบของฉันเมื่อพูดถึงงานมอบหมายของโรงเรียน

แน่นอนว่าคุณไม่สามารถทื่อได้เกี่ยวกับการขอให้พวกเขาทำซ้ำสิ่งที่คุณเพิ่งพูดดังนั้นคุณต้องปรับกลยุทธ์ของคุณ ตัวอย่างเช่นนี่คือวิธีที่ฉันจะเติมคำแถลงการติดตามผลของคุณจาก OP ให้เป็นคำถาม "การตรวจสอบ":

ฉันชอบความคิดของคุณในการสร้างวิธีการขยาย แต่ฉันไม่ชอบวิธีที่คุณส่งแลมบ์ดาที่ซับซ้อนขนาดใหญ่เป็นพารามิเตอร์ คุณเห็นไหมว่าแลมบ์ดาคอมเพล็กซ์นี้บังคับให้คนอื่นรู้ว่ามีอะไรบางอย่างมากเกินไปเกี่ยวกับวิธีการนำไปใช้

คำถามนี้เป็นไปไม่ได้ที่จะตอบอย่างถูกต้องโดยไม่เข้าใจปัญหาที่คุณพยายามเน้น ฉันพบว่าการสิ้นสุดคำอธิบายของฉันด้วยคำถามที่ต้องการการวิเคราะห์สิ่งที่ฉันเพิ่งพูดจะช่วยเร่งกระบวนการเรียนรู้ให้เร็วขึ้นและให้ข้อเสนอแนะแก่ฉันว่าฉันต้องทำการแก้ไข

โดยปกติเมื่อคนไม่พูดในสิ่งที่คุณต้องการหมายความว่าคุณต้องทำงานในการฟังของคุณ การฟังหมายถึงการได้ยินเหตุผลของการออกแบบก่อนที่จะตัดสินใจ มันไม่ได้หมายความว่าเพียงแค่บอกพวกเขาว่ามันไม่เป็นไรที่จะคัดค้าน แต่พิสูจน์ด้วยการพิจารณาสิ่งที่พวกเขาพูดโดยสุจริตและไม่เพียงแก้ไขพวกเขา ค้นหาสิ่งที่ดีเกี่ยวกับโซลูชันของพวกเขาและแก้ไขโซลูชันของคุณเพื่อรวมสิ่งเหล่านั้น

คุณต้องเป็นผู้นำด้วยตัวอย่าง ฉันไม่ได้หมายถึงการเขียนรหัส uber-Awesome ฉันหมายถึงการขอให้พวกเขาแสดงความคิดเห็นเกี่ยวกับการออกแบบของคุณเอง อย่ารอการตรวจสอบโค้ดหลังจากข้อเท็จจริง แต่ทำงานร่วมกันตลอดทาง พูดอย่างเช่น "อินเทอร์เฟซของฉันดูซับซ้อนเกินไป แต่ฉันไม่แน่ใจว่าวิธีที่ดีที่สุดในการทำให้มันง่ายขึ้น" และให้เวลาพวกเขาตอบโดยไม่เอนเอียงความคิดของคุณก่อน

เมื่อฉันต้องจัดการกับสิ่งนี้ฉันได้พูดในสิ่งที่ชอบ:

คุณรู้ไหมว่านั่นเป็นทางออกที่สร้างสรรค์อย่างแท้จริงซึ่งฉันไม่เคยนึกถึง มันปรับขนาดได้อย่างไร / คุณคิดว่าอาจมีวิธีการที่ง่ายกว่าในการพัฒนาและบำรุงรักษาได้ง่ายขึ้น / น่าเสียดายที่ฉันไม่คิดว่ามันเหมาะกับสถาปัตยกรรมส่วนที่เหลือของโครงการ / สิ่งที่จะ การกำหนดค่ามีลักษณะอย่างไร

สิ่งนี้มักจะเพียงพอที่จะชี้ผู้คนในทิศทางใหม่

ความรับผิดชอบเป็นสิ่งหนึ่งที่สามารถช่วยพวกเขาได้

ฉันได้นำทีมหนึ่งหรือสองคนในอดีตและหนึ่งในสิ่งที่ทำให้จูเนียร์เปล่งประกายคือภาระของความรับผิดชอบส่วนบุคคล เมื่อมีคนตระหนักว่าการกระทำของเขาอาจเกี่ยวข้องกับเขา ณ จุดหนึ่งเขา / เธอมักจะทำตัวเองมากกว่าที่เป็นอยู่ในสิ่งที่เขาทำ ไม่ต้องพูดถึงว่าเมื่อพวกเขารู้สึกว่างานของพวกเขาผลลัพธ์ที่ดีเป็นที่น่าพอใจมากขึ้น

ฉันไม่ต้องกังวลเกี่ยวกับความจริงที่ว่าพวกเขาติดตามคุณอย่างเด็ดขาดนี่คือสิ่งที่พวกเขาควรทำในฐานะรุ่นน้อง สิ่งที่พวกเขามีแนวโน้มที่จะไม่เข้าใจเหตุผลที่แท้จริงของรายการที่คุณอยู่ในการตรวจสอบรหัสจนกว่าพวกเขาจะไปและทำงานที่อื่นที่มีนักพัฒนาซอฟต์แวร์ที่น่ากลัวการจัดการที่น่ากลัวและรหัสที่น่ากลัว

เมื่อถึงเวลานั้นพวกเขาจะได้เรียนรู้วิธีปฏิบัติที่ดีนอกนิสัยและจะต้องดำเนินชีวิตผ่านข้อผิดพลาดในการเขียนโค้ดและการออกแบบที่คนอื่นทำและพวกเขาถูกบังคับให้ต้องทำให้พวกเขาต้องทำงานกับซอฟต์แวร์ที่ออกแบบและใช้งานไม่ดี

นี่จะเป็นสิ่งที่หลีกเลี่ยงไม่ได้ในที่สุดในอาชีพของพวกเขา คุณกำลังทำให้พวกเขามีบริการที่ดีเยี่ยมโดยทำให้พวกเขาคุ้นเคยกับมาตรฐานและแนวทางปฏิบัติที่ดี น่าเสียดายที่พวกเราส่วนใหญ่ต้องเรียนรู้วิธีที่ยากลำบาก

จากตัวอย่างที่ให้มาผมจะบอกว่าการติดตามความคิดเห็นของคุณด้วยคำถามอาจเป็นวิธีที่ดีที่สุด หากคุณถามคำถามพร้อมกับความคิดเห็นของคุณมันไม่ปล่อยให้พวกเขาเห็นด้วยหรือไม่เห็นด้วยอย่างน้อยพวกเขาต้องคิดเกี่ยวกับวิธีที่พวกเขาอาจนำไปใช้บางสิ่งบางอย่าง

เช่น "ฉันชอบความคิดของคุณในการสร้างวิธีการขยาย แต่ฉันไม่ชอบวิธีที่คุณส่งแลมบ์ดาขนาดใหญ่ที่ซับซ้อนเป็นพารามิเตอร์แลมบ์ดาบังคับให้คนอื่นรู้มากเกินไปเกี่ยวกับวิธีการใช้งานของคุณลองนึกถึงวิธีที่ดีกว่า ใช้วิธีส่วนขยายนี้ซึ่งไม่เปิดเผยข้อมูลมากพอหรือไม่ "

สิ่งนี้ช่วยให้พวกเขาเห็นข้อบกพร่องในสิ่งที่พวกเขากำลังพัฒนาในขณะเดียวกันก็ให้โอกาสพวกเขาในการแก้ปัญหาที่พวกเขาแนะนำในแอปพลิเคชัน