Ini adalah serangkaian artikel. Berikut ini bisa dibaca di sini.
Apa yang diharapkan dan bagaimana membantu menumbuhkan pengembang peserta pelatihan menjadi junior yang percaya diri?
Tingkat pengembang adalah apa yang digunakan setiap orang untuk mengukur dan untuk apa semua orang berlari dari perusahaan ke perusahaan.
Dalam beberapa tahun terakhir, tren pasar sedemikian rupa sehingga pengalaman kerja nyata berkurang sehubungan dengan tawaran :: tag ::.
Topik ini menggangguku terutama karena pengalaman bertahun-tahun masih membicarakan sesuatu. Mereka berbicara tentang jumlah waktu selama Anda mengerjakan pekerjaan itu. Dan memang benar secara statistik bahwa lebih banyak makaps dan pasangan dapat terjadi dalam m waktu daripada di n , asalkan m > n . Itu saja. Ini dibuktikan dengan pengalaman bertahun-tahun. Ini bukan indikator di mana saya akan menyaring orang keluar dari posisi (jika itu adalah senior, dengan pengalaman nyata 1,5 tahun), tetapi yang saya akan memutuskan antara dua kandidat yang identik jika saya tidak bisa mengambil dua.
Jadi, tipe pengembang favorit saya adalah trainee . Mereka benar-benar pemula, tidak peduli apa pun age_pol_religion mereka, mereka dapat dilihat sejak hari pertama apakah mata mereka menyala. Lebih jauh, masalah teknis, seperti yang dikatakan oleh salah satu teman baik saya: "Anda bisa mengajari monyet cara menulis kode," dan kami mengajar ... bukan monyet, tentu saja ... tetapi seseorang. Kami mengajar, kami katakan, kami keluar dari pekerjaan ketika mereka masih hidup, dan mereka suka berlama-lama, karena semuanya menarik. Pada tahap ini, tugas pengembang adalah mempelajari cara bekerja dengan alat, memahami bahwa airnya basah, api itu panas, dan berdiri dari kata "berdiri". Setiap bahasa memiliki tugas yang khas. Di Rub - Hartle dan alias Twitter-nya. Dalam javascript, semua orang sangat menyukai lembar itu dan semua jenis implementasi untuk kerangka kerja Anda. Jika dia dapat menulisnya pada panduan langkah demi langkah, dia cocok dengan peserta. Ketika dia dapat menulisnya tanpa panduan langkah demi langkah, Anda dapat berbicara tentang Juni. Saya secara khusus menekankan langkah demi langkah di sini, karena tidak peduli berapa banyak pengalaman yang Anda miliki, Anda akan berjalan di MDN untuk melihat urutan parameter dalam reduce dan melupakan konstruksi dasar.
Lanjut Junior - dan tidak ada transisi yang tiba-tiba. Dia halus. Dan itulah sebabnya perusahaan kami membuat divisi menjadi Junior Beginner / Junior / Junior Strong. Tapi ini adalah tahap di mana Anda dapat segera melihat budaya apa yang ada di tim Anda, saya akan mengakhiri bagian ini di Junior dengan pemikiran ini.
Di tingkat Junior, seseorang sudah tahu cara menulis kode, tetapi kode ini tidak lebih dari menyelesaikan masalah bisnis di sini dan sekarang. Dan ini normal, inilah yang harus bekerja dengan tim teknis, mentor, atau pelatihan. Pada tahap ini, Anda perlu menjelaskan kepada orang tersebut siklus hidup bug, mengapa pengujian sendiri penting, bagaimana biaya bug berubah tergantung pada tahap di mana bug ditemukan.
Untuk membantunya berpikir dan memahami apa yang dia hadapi hampir sepanjang waktu. Artinya, jika dia mengirim permintaan dari browser ke backend selama setengah hari, dia tahu apa permintaan itu dan mengapa browser mengirim 2 permintaan ketika Anda memiliki backend di Origin yang lain. Dia mulai menyadari proses dalam pembangunan. Berangsur-angsur memperhatikan betapa salahnya dia dalam estimasi.
Ini adalah tahap ketika layak bermain scrum poker dengan seseorang dan membuat penilaian dari atas ke bawah tugas, bahkan jika Anda belum menerima ini sebagai sebuah tim.
Dia harus belajar merumuskan pikiran, memperdebatkan posisi, untuk ini kita harus mulai menunjukkan hal-hal yang tidak jelas. Mengapa saya katakan tentang scrum poker dan top-down. Ini adalah cara yang bagus untuk menunjukkan kepada seseorang nuansa yang Anda perhatikan karena pengalaman Anda, detail apa yang Anda klarifikasi, spesifikasi apa yang Anda tidak lagi tampak kabur, dan BAGAIMANA Anda melakukannya.
Hasil penilaian bersama akan menunjukkan keterampilan teknis, tetapi sama pentingnya untuk mengajarkan cara merumuskan pertanyaan, menunjukkan cara berkomunikasi dengan klien atau pemangku kepentingan, cara memasukkan informasi yang diterima ke dalam sistem.
Semakin cepat seorang pengembang belajar untuk memperhatikan detail dan bagaimana berkomunikasi pada tugas-tugas dengan para pemangku kepentingan, semakin mudah baginya. Karena komunikasi proyektif dan analisis yang tidak dapat dipahami adalah cara sadar kita untuk mendorong diri kita ke dalam hal yang tidak diketahui dan mendapatkan kasus baru +1 dalam pengalaman kita.
Secara pribadi, saya tidak berharap sama sekali bahwa di tingkat junior dia setidaknya akan mendapatkan sedikit nilai-nilainya dalam fitur-fitur besar, dalam yang kecil - mungkin, tetapi bukan fakta. Secara besar - tidak, masih tahu sedikit tentang risiko, tidak memperhitungkan pengujian akun, psikologi klien dan tidak memahami perbedaan antara penilaian dalam jam dan ETA.
Yang juga penting adalah mempelajari keterampilan dasar aplikasi debugging, memahami cara menemukan perubahan, beberapa sesi pemrograman berpasangan dengan Juni, dan Anda akan memberinya keterampilan teknik primitif, tetapi sangat "cerdik" untuk jenis seperti instance.freeze . Dia perlu belajar cara menggunakan seluruh multitool ini, tidak selalu efisien, tetapi setidaknya dia harus tahu bahwa ada obeng dan bahwa dia tidak perlu memalu sekrup dengan palu.
Selesai menggambarkan Junior`a , kami akan kembali ke budaya tim. Pada tingkat ini, seseorang akan menyerap budaya komunikasi tim, jika Anda mengguncang penguji dan menganggapnya tidak berguna, tetapi jangan menyadari ini, lihat Juni dan ingat apakah ia seperti itu setengah tahun / tahun yang lalu. Apakah dia berperilaku yang sama terhadap orang-orang ini? Jika "tidak" di arah negatif, maka inilah bel. Dia belajar ini dari Anda dan lingkungan Anda. Dia masih tidak bisa dengan jelas mengatakan mengapa sesuatu itu tidak penting, tetapi itu sudah sheimit. Selain itu, kita semua sudah tahu bahwa setiap tahap dalam pengembangan aplikasi adalah penting dan apa pun timnya, tanpa penguji mereka akan merilis produk yang lebih buruk atau lebih lambat dan lebih mahal.
Awalnya, saya menerbitkan artikel tentang Medium , tetapi bagi saya segmen yang ingin saya gunakan untuk memulai percakapan - ini adalah platform yang buruk. Saya akan menghilangkan bagian dari intro, jika Anda ingin berbicara, tulis ke @_golubev .
Saya memberi bagian ini nama work & dev fun (damentals) . Karena pekerjaan dan pengembangan itu menyenangkan. Tetapi hal-hal mendasar harus dipelajari. Tidak masalah apakah itu soft skill atau hard skill.
Semua yang dijelaskan lebih lanjut adalah pengalaman yang saya dapatkan. Ini terbatas pada pemahaman saya tentang hal-hal yang terjadi di TI. Proses yang terjadi di sini. Keputusan yang dibuat. Pemahaman ini memungkinkan saya dari Trainee ke salah satu pemimpin mereka dalam arah tumpukan penuh. Secara paralel, buat departemen yang berspesialisasi dalam pengembangan teknis dan pemantauan keadaan emosional karyawan, agar pekerjaan mereka nyaman dan memberi mereka pemahaman konkret tentang apa yang diharapkan dari mereka di perusahaan dan proyek.