Bagaimana cara mengoreksi junior, tetapi mendorongnya untuk berpikir untuk dirinya sendiri? [Tutup]

Saya adalah pemimpin tim kecil di mana setiap orang memiliki pengalaman pengembangan perangkat lunak kurang dari setahun. Saya tidak akan menyebut diri saya seorang guru perangkat lunak, tetapi saya telah belajar beberapa hal dalam beberapa tahun ini bahwa saya telah menulis perangkat lunak.

Ketika kita melakukan review kode, saya melakukan sedikit pengajaran dan memperbaiki kesalahan. Saya akan mengatakan hal-hal seperti "Ini terlalu rumit dan berbelit-belit, dan inilah sebabnya," atau "Apa pendapat Anda tentang memindahkan metode ini ke kelas yang terpisah?" Saya ekstra hati-hati untuk mengomunikasikan bahwa jika mereka memiliki pertanyaan atau pendapat yang berbeda, itu tidak apa-apa dan kita perlu membahas. Setiap kali saya mengoreksi seseorang, saya bertanya, "Bagaimana menurutmu?" atau yang serupa.

Namun mereka jarang jika tidak setuju atau bertanya mengapa. Dan akhir-akhir ini saya telah memperhatikan tanda-tanda yang lebih terang-terangan bahwa mereka secara diam-diam menyetujui pernyataan saya dan tidak membentuk opini mereka sendiri.

Saya membutuhkan tim yang dapat belajar untuk melakukan hal-hal yang benar secara mandiri, tidak hanya mengikuti instruksi. Bagaimana cara mengoreksi pengembang junior, tetapi masih mendorongnya untuk berpikir sendiri?

Sunting: Berikut adalah contoh dari salah satu tanda yang jelas ini bahwa mereka tidak membentuk pendapat mereka sendiri:

Saya: Saya suka ide Anda membuat metode ekstensi, tapi saya tidak suka bagaimana Anda melewati lambda kompleks yang besar sebagai parameter. Lambda memaksa orang lain untuk tahu terlalu banyak tentang implementasi metode ini.

Junior (setelah salah paham dengan saya): Ya, saya sepenuhnya setuju. Kita tidak boleh menggunakan metode ekstensi di sini karena mereka memaksa pengembang lain untuk tahu terlalu banyak tentang implementasi.

Ada kesalahpahaman, dan itu sudah diatasi. Tetapi bahkan tidak ada satu pun logika dalam pernyataannya! Dia pikir dia sedang memuntahkan kembali logika saya kepada saya, berpikir itu akan masuk akal ketika dia benar-benar tidak tahu mengapa dia mengatakannya.

Jawaban singkat:

Libatkan mereka (letakkan puzzle dalam pikiran mereka), berdayakan mereka (percayai jawaban mereka).

Itu adalah pertanyaan yang mendorong kita! - Matriks.

Secara umum, dalam pengamatan saya, bahwa junior memiliki dunia mereka sendiri - pandangan terbatas mereka sendiri tentang bagaimana mereka berpikir dan di beberapa bagian antusiasme mereka sendiri / favorit / pendapat tentang hal-hal.

Tidak ada salahnya mengatakan langsung kepada mereka bahwa Anda salah - tetapi yang terbaik adalah Anda membuat mereka berpikir. Mengapa? Apakah ada cara lain? Adakah cara yang lebih baik untuk melakukan hal yang sama? Salah satu anekdot yang selalu saya gunakan adalah - "Beri saya tiga solusi (untuk masalah ini)!"

Pada saat mereka memikirkan solusi ini, mereka mulai menyadari banyak masalah. Mereka membutuhkan investasi waktu - tetapi seiring waktu mereka cenderung memvisualisasikan keterbatasan dan kekurangan pemikiran mereka. Mereka mulai melihat itu lebih sebagai "Saya tidak memikirkannya!" yang jauh lebih baik daripada pulang dengan perasaan bahwa "Aku salah!" atau bahkan lebih buruk "Saya diberitahu / terbukti salah bahkan ketika saya memiliki sudut pandang yang valid" .

Secara umum, anak-anak yang sangat muda akan cenderung lebih mahir terkait dengan masalah teknis (seperti pola desain mana yang bekerja lebih baik!) Daripada masalah proses , tetapi seiring waktu ketika Anda melatih mereka, itu akan berhasil.

Namun mereka jarang jika tidak setuju atau bertanya mengapa. Dan akhir-akhir ini saya telah memperhatikan tanda-tanda yang lebih terang-terangan bahwa mereka secara diam-diam menyetujui pernyataan saya dan tidak membentuk opini mereka sendiri.

Ini umumnya merupakan hasil yang Anda lakukan mengambil saran mereka tetapi kemudian ini menguasai mereka dan mereka sama-sama yakin tentang pandangan Anda; hanya karena Anda senior mereka menghindari perkelahian!

Hal terbaik yang saya pelajari dari salah satu bos masa lalu saya: Dia akan meminta anggota tim untuk berdebat terlebih dahulu (mereka merasa cukup setara di sini), dan semoga setelah semua argumen habis, dia akan memasuki ruangan dengan hanya satu pertanyaan - "Apa yang poin ketidaksepakatan? " - Intinya adalah, orang selalu suka berpartisipasi dalam debat dan diskusi, tetapi jika poin (valid) mereka tidak diambil untuk bertindak di lain waktu mereka merasa tidak layak untuk berpartisipasi dalam diskusi.

Tidak hanya dalam perangkat lunak, tetapi di mana-mana pada akhirnya hanya rekan tim yang paling berdaya yang akan berani menjawab apalagi mempertanyakan sistem.

Jika Anda ingin junior Anda berpikir sendiri, jangan memperbaikinya: minta mereka untuk memperbaiki diri .

Alih-alih memberi tahu mereka apa yang Anda pikir salah tentang solusi mereka, tanyakan kepada mereka pertanyaan yang relevan tentang hal itu. Dalam contoh Anda, Anda bisa bertanya kepada mereka tentang apa yang perlu diketahui seseorang yang menggunakan metode ekstensi untuk membuat lambda. Terus ajukan pertanyaan seperti ini sampai mereka menyarankan itu masalah. Dengan begitu, Anda tahu mereka telah memahami mengapa solusi mereka bisa menjadi masalah dan lebih jauh lebih mungkin untuk belajar dari itu - jika Anda hanya mengatakan kepada mereka bahwa solusi mereka salah, itu penilaian eksternal, dan mudah diabaikan. Jika mereka sampai pada realisasi sendiri (dengan sedikit dorongan), mereka akan menyadari betapa beralasannya itu dan lebih mungkin untuk belajar dari kesalahan mereka.

Selain itu, ini memberi junior Anda kesempatan untuk mempertahankan desain mereka - mungkin mereka telah memikirkan masalahnya dan memiliki justifikasi yang baik untuk mengatasi masalah Anda, artinya Anda tidak perlu melakukan koreksi apa pun. Itu mengurangi persepsi apa pun (betapapun tidak disengaja) bahwa Anda berkuasa oleh eksekutif fiat.

Karena Anda memiliki beberapa pengembang junior lakukan review kode sebagai grup bukan 1 satu 1.

Buka dengan bertanya pada kelompok "Bagaimana lagi masalah ini dapat diselesaikan?", Dan izinkan pengembang junior lainnya untuk menyarankan implementasi mereka terlebih dahulu. Tambahkan saja implementasi Anda setelah anggota tim lain berbicara dan jika tidak ada yang menyarankan sesuatu yang mirip dengan ide Anda.

Kemudian lakukan diskusi meja bundar tentang keuntungan dan kerugian relatif dari implementasi yang berbeda dengan maksud untuk membimbing para junior devs untuk memilih implementasi terbaik tanpa diberi tahu apa itu.

Sebagai pembangun kepercayaan diri untuk para junior devs, Anda bisa mulai dengan beberapa kasus di mana mereka memilih apa yang Anda anggap sebagai pilihan terbaik dan menjadikan alternatif Anda sebagai tukang jerami yang memiliki cacat semi-jelas dan mengarahkan diskusi ke arah mengapa implementasi asli adalah yang terbaik.

Ketika saya pertama kali mulai bekerja dalam pekerjaan pemrograman, saya melakukan hal yang sama persis seperti yang Anda jelaskan: ketika diberi tahu tentang sesuatu yang bisa saya lakukan, saya akan selalu setuju. Itu terutama karena saya tidak punya cukup pengalaman untuk mengatakan sebaliknya.

Apa yang memberi saya kemampuan untuk benar-benar mendiskusikan metodologi dan ide adalah belajar dari pengalaman serta membaca tentang berbagai pendekatan dan teknologi baru. Agar tim Anda berpikir sendiri, mereka harus benar-benar tahu tentang masalah apa yang dapat timbul dari hal-hal seperti kode "terlalu rumit dan berbelit-belit", dan satu-satunya cara nyata mereka akan mengetahuinya adalah melalui pengalaman.

Cara yang baik untuk memfasilitasi pemikiran individu adalah dengan meminta mereka melihat ke situs web pemrograman seperti Stack Overflow atau Programmer SE. Saya tahu bahwa ini membantu saya belajar tentang berbagai teknik yang ada di luar sana dan memungkinkan saya untuk berdiskusi dengan anggota senior tim, alih-alih menyetujui secara membuta dengan mereka.

Intinya adalah bahwa tanpa pengalaman, saran dari anggota senior akan selalu terdengar benar bagi mereka.

Interaksi dari pos Anda menunjukkan prinsip utama untuk mengajar hampir semua hal: minta mereka untuk menjelaskan apa yang mereka pikir Anda katakan , dan dengarkan baik-baik responsnya: itu akan memberi tahu Anda dengan tepat apa yang perlu diperbaiki.

Saya tanpa malu - malu telah mencuri salinan trik ini dari guru matematika saya sekitar 25 tahun yang lalu, dan itu tidak gagal sejak saat itu. Saya menggunakannya di kelas selama tugas singkat saya sebagai asisten pengajar, di tempat kerja ketika berbicara tentang desain perangkat lunak, dan dengan anak saya yang berusia delapan tahun ketika berbicara tentang tugas sekolahnya.

Tentu saja Anda tidak selalu bisa terus terang tentang meminta mereka mengulangi apa yang baru saja Anda katakan, jadi Anda perlu menyesuaikan strategi Anda. Sebagai contoh, berikut adalah bagaimana saya akan kembali kalimat pernyataan tindak lanjut Anda dari OP sebagai pertanyaan "menyelidik":

Saya suka ide Anda membuat metode ekstensi, tapi saya tidak suka bagaimana Anda melewati lambda kompleks yang besar sebagai parameter. Apakah Anda melihat bagaimana lambda yang kompleks ini memaksa orang lain untuk mengetahui terlalu banyak hal tertentu tentang penerapan metode ini?

Pertanyaan ini tidak mungkin dijawab dengan benar tanpa memahami masalah yang ingin Anda soroti. Saya menemukan bahwa mengakhiri penjelasan saya dengan pertanyaan yang memerlukan analisis apa yang baru saja saya katakan mempercepat proses pembelajaran, dan memberi saya umpan balik bahwa saya perlu melakukan koreksi.

Biasanya ketika orang tidak mengatakan apa yang Anda inginkan, itu berarti Anda harus berusaha mendengarkan Anda. Mendengarkan berarti mendengarkan alasan rancangan mereka sebelum memberikan penilaian. Itu berarti tidak hanya mengatakan kepada mereka bahwa tidak apa-apa untuk tidak setuju, tetapi membuktikannya dengan jujur ​​mempertimbangkan apa yang harus mereka katakan, dan tidak hanya memperbaikinya. Cari hal-hal baik tentang solusi mereka, dan modifikasi solusi Anda untuk memasukkan hal-hal tersebut.

Anda juga harus memimpin dengan memberi contoh. Maksud saya bukan dengan menulis kode yang luar biasa, maksud saya dengan meminta pendapat mereka tentang desain Anda sendiri. Jangan menunggu ulasan kode setelah fakta, tetapi bekerja bersama sepanjang jalan. Katakan hal-hal seperti, "Antarmuka saya tampaknya terlalu rumit, tetapi saya tidak yakin cara terbaik untuk menyederhanakannya." Dan beri mereka waktu untuk menjawab tanpa membiasakan mereka dengan ide Anda sendiri terlebih dahulu.

Ketika saya harus berurusan dengan ini, saya telah mengatakan (jujur) hal-hal seperti:

Anda tahu, itu solusi yang sangat kreatif yang tidak akan pernah saya pikirkan. Bagaimana skala? / Apakah Anda pikir mungkin ada pendekatan yang secara konsep lebih sederhana, untuk membuat pengembangan lebih cepat atau pemeliharaan lebih mudah? / Sayangnya, saya tidak berpikir itu benar-benar cocok dengan sisa arsitektur proyek./Apa yang akan konfigurasi terlihat seperti?

Ini biasanya sudah cukup untuk mengarahkan orang ke arah yang baru.

Tanggung jawab adalah satu hal yang dapat membantu mereka.

Saya telah memimpin satu atau dua tim di masa lalu dan salah satu hal yang membuat junior bersinar adalah beban tanggung jawab pribadi. Ketika seseorang menyadari bahwa tindakannya mungkin berimplikasi pada dirinya pada satu titik, dia biasanya melakukan sedikit lebih banyak dari dirinya sendiri dalam apa yang dia lakukan. Belum lagi bahwa ketika mereka merasakan pekerjaan mereka, hasil yang baik jauh lebih memuaskan.

Saya tidak akan terlalu khawatir tentang fakta bahwa mereka membabi buta mengikuti Anda, inilah yang seharusnya mereka lakukan sebagai junior. Masalahnya adalah bahwa mereka mungkin tidak akan memahami alasan sebenarnya untuk item yang Anda alamatkan dalam ulasan kode sampai mereka pergi dan bekerja di tempat lain yang memiliki pengembang perangkat lunak yang mengerikan, manajemen yang buruk, dan kode yang mengerikan.

Pada saat itu mereka akan mempelajari praktik-praktik baik karena kebiasaan dan harus menjalani kesalahan pengkodean dan desain yang dibuat orang lain dan mereka dipaksa untuk membuat mereka sekarang harus bekerja pada perangkat lunak yang dirancang dan diimplementasikan dengan buruk.

Ini akan menjadi suatu keniscayaan pada akhirnya dalam karier mereka. Anda melakukannya dengan sangat baik dengan membiasakan mereka dengan standar dan praktik pengkodean yang baik. Sayangnya sebagian besar dari kita harus belajar dengan cara yang sulit.

Berdasarkan contoh yang diberikan saya akan mengatakan menindaklanjuti komentar Anda dengan pertanyaan mungkin akan menjadi cara terbaik untuk pergi. Jika Anda mengajukan pertanyaan bersama dengan komentar Anda, itu tidak membuat mereka hanya setuju atau tidak setuju mereka setidaknya harus memikirkan bagaimana mereka dapat mengimplementasikan sesuatu.

misalnya "Saya suka ide Anda membuat metode ekstensi, tapi saya tidak suka bagaimana Anda melewati lambda kompleks besar sebagai parameter. lambda memaksa orang lain untuk tahu terlalu banyak tentang implementasi metode. Dapatkah Anda memikirkan cara yang lebih baik untuk menerapkan metode ekstensi ini yang tidak mengekspos banyak informasi? "

Ini memungkinkan mereka untuk melihat kesalahan dalam apa yang mereka kembangkan sementara pada saat yang sama memberi mereka kesempatan untuk memecahkan masalah yang mereka perkenalkan ke dalam aplikasi.