Cara Mentor Pengembang Junior

99

Judul ini sedikit luas tetapi saya mungkin perlu memberikan sedikit latar belakang sebelum saya dapat mengajukan pertanyaan dengan benar.

Saya tahu bahwa pertanyaan serupa sudah diajukan di sini . Tetapi dalam kasus saya, saya tidak bertanya apakah saya harus membimbing seseorang atau apakah orang itu cocok untuk menjadi pengembang perangkat lunak. Itu bukan tempat saya untuk menilai. Saya belum diminta secara langsung, tetapi jelas bahwa saya dan sesama pengembang senior lainnya akan membimbing para pengembang baru yang mulai di sini. Saya tidak punya masalah dengan ini sama sekali dan, dalam banyak kasus, itu memberi saya perspektif baru tentang berbagai hal dan akhirnya saya belajar dalam prosesnya. Juga, saya ingat betapa bermanfaatnya itu di awal karir saya ketika seseorang akan meluangkan waktu untuk mengajari saya sesuatu.

Ketika saya mengatakan "pengembang baru" mereka bisa berada di mana saja dari yang baru lulus dari perguruan tinggi hingga memiliki satu atau dua tahun pengalaman.

Baru-baru ini kami memiliki orang-orang mulai di sini yang tampaknya memiliki sikap terhadap pengembangan / pemrograman yang berbeda dari saya sendiri dan sulit bagi saya untuk berdamai; mereka mengekstrak informasi yang cukup untuk menyelesaikan tugas tetapi tidak benar-benar belajar darinya. Saya menemukan diri saya berulang kali mengalami masalah yang sama dengan mereka. Saya mengerti bahwa sebagian dari ini bisa menjadi masalah kepribadian, tetapi saya merasa itu adalah tugas saya untuk melakukan yang terbaik dan mendorong mereka keluar dari sarang saat mereka berada di bawah sayap saya, sehingga untuk berbicara.

Bagaimana saya bisa memberikan informasi yang cukup sehingga mereka akan belajar tetapi tidak memberi begitu banyak untuk menyelesaikan masalah bagi mereka?

Atau mungkin:

Apa jawaban yang tepat untuk pertanyaan yang dirancang untuk mengambil jalan dengan resistensi paling rendah dan, pada dasarnya, memaksa mereka untuk belajar alih-alih mengambil jalan keluar yang mudah?

Pertanyaan-pertanyaan ini mungkin pertanyaan pengajaran yang lebih umum dan tidak memiliki banyak yang harus dilakukan secara khusus dengan pengembangan perangkat lunak.

Catatan: Saya tidak mendapat suara dalam tugas apa yang sedang mereka kerjakan. Manajemen membagi tugas dan bisa berupa apa saja dari perbaikan bug yang sangat sederhana hingga memulai seluruh aplikasi sendiri. Walaupun ini tidak ideal dengan cara apa pun dan jelas menyajikan tantangan tantangannya sendiri, saya merasa ini adalah topik terbaik yang tersisa untuk pertanyaan lain. Jadi yang terbaik yang bisa saya lakukan adalah membantu mereka dengan masalah yang ada dan mencoba membantu mereka memecahnya menjadi masalah yang lebih sederhana dan juga memeriksa log komit mereka dan menunjukkan kesalahan yang mereka buat.

Tujuan utama saya adalah:

  • Bantu mereka dan berikan mereka alat yang mereka butuhkan untuk mulai menjadi lebih mandiri.
  • Arahkan mereka ke arah yang benar dan hentikan kebiasaan buruk perkembangan sejak dini.
  • Mengurangi jumlah waktu yang saya habiskan bersama mereka (tipe kepribadian yang dijelaskan di atas cenderung membutuhkan lebih banyak waktu tatap muka dan tidak bekerja dengan baik melalui IM atau email. Meskipun secara umum baik-baik saja, saya tidak selalu bisa menghentikan apa yang saya m sedang mengerjakan, mematahkan langkah saya, dan membantu mereka men-debug kesalahan pada saat pemberitahuan; Saya punya proyek sendiri yang perlu dilakukan).
Josh Johnson
sumber
1
Anda hanya dapat membantu seseorang menjadi apa yang mereka inginkan. Bimbing mereka yang ingin dibimbing.
Darknight
14
Anda benar bahwa ada banyak hal tentang hal ini yang tidak spesifik untuk pengembangan perangkat lunak, tetapi ini tentang menjadi guru yang baik (bahkan jika itu bukan pekerjaan utama Anda). Dalam konteks pengajaran, saya menulis sedikit di Chronicle of Higher Ed yang mengatakan bahwa kesuksesan dapat terjadi ketika Anda memainkan tiga peran: menjadi panutan yang baik, bertindak sebagai dukungan teknologi (sampai mereka mengetahui bagaimana cara mengajukan pertanyaan yang bagus & di mana ), dan jadilah pemandu sorak (sabar dan suportif).
jcmeloni
1
Ada banyak tanggapan yang bagus tentang topik ini di sini: programmers.stackexchange.com/questions/137708/…
KodeKreachor
Mengapa Anda membeli retorika "mentoring"? Gunakan kata "pelatihan": Anda mendeskripsikan "pelatihan untuk pekerjaan" , ini bukan hal filosofis, cara Anda melihat kehidupan alam semesta dan segalanya, ini adalah hal yang seharusnya dilakukan di perusahaan Anda. (dan perusahaan Anda harus berpikir lebih banyak tentang memberi mereka yang resmi)
ZJR
3
Dan .. pastikan kubus mereka berada di tengah jalan dari kubus Anda ke kamar kecil ...
vrdhn

Jawaban:

121

Pernah ada pertanyaan di sekitar sini yang berisi informasi semacam ini, dan bagian yang paling menempel padaku adalah jangan menyentuh keyboard mereka

Singkatnya, beri tahu junior Anda bagaimana mencapai apa yang mereka coba lakukan, tetapi jangan lakukan itu untuk mereka.

Namun selain itu, berikut adalah beberapa tips lainnya:

  • Dorong Google (atau alat pencarian lainnya). Jika Anda tahu jawabannya dapat ditemukan online dengan mudah, beri tahu mereka untuk mencarinya daripada memberi tahu mereka jawabannya. Pada akhirnya Anda ingin mengajari mereka cara mengajar diri mereka sendiri , dan tidak membuat mereka menjadi tergantung pada Anda.
  • Jadikan diri Anda siap menjawab pertanyaan. Jika Anda tidak pernah ada atau tidak ingin diganggu, jelaskan kepada mereka bahwa mereka harus menyimpan pertanyaan mereka sampai waktu yang ditentukan.
  • Lakukan tinjauan kode secara teratur untuk memberi tahu mereka apa yang mereka lakukan benar / salah. Gunakan ini sebagai kesempatan untuk menunjukkan praktik terbaik
  • Mulailah sejak dini dengan praktik terbaik. Lebih baik mengambil waktu ekstra untuk mengajar mereka dengan cara yang benar, daripada mencoba dan mengubah metode mereka nanti.
  • Mulailah mereka dari awal dengan merencanakan / mendokumentasikan apa yang akan mereka lakukan alih-alih membiarkan mereka memulai dengan menulis kode.
  • Terbuka untuk belajar dari mereka. Mereka mungkin menghabiskan lebih banyak waktu daripada yang Anda pelajari, dan mungkin mereka belajar sesuatu yang tidak Anda ketahui.
  • Bantu mereka belajar dari kesalahan mereka. Akan ada kesalahan, jadi pastikan Anda menunjukkan kepada mereka bahwa kesalahan adalah bagian dari pembelajaran, dan bahwa mereka harus menggunakannya sebagai kesempatan untuk belajar.

  • (Dari RuneFS di bawah) Alih-alih memberi tahu mereka cara melakukan sesuatu, cobalah untuk membantu mereka mencari tahu sendiri. Ini akan membantu meningkatkan kemampuan mereka untuk secara logis mengatasi masalah, dan meningkatkan kemampuan belajar mereka

  • (Dari RuneFS di bawah) Alih-alih memberi tahu mereka apa yang mereka lakukan salah, beri tahu mereka cara mereka bisa memperbaikinya. Pastikan untuk memasukkan mengapa cara Anda lebih baik daripada cara mereka. Ini akan meningkatkan kepercayaan diri mereka bukannya melemahkannya. Tentu saja, jika mereka tidak mendengarkan Anda maka jangan takut untuk hanya memberitahu mereka untuk melakukannya dengan benar :)
Rachel
sumber
68
+1 untuk jangan menyentuh keyboard. Sebagian karena mengajari mereka cara melakukan sesuatu lebih penting daripada menyelesaikannya dalam situasi mentoring, tetapi sebenarnya karena saya benar-benar benci orang mencuri keyboard saya.
fire.eagle
3
Saya tahu itu sudah dikatakan tetapi "jangan sentuh keyboard". Adalah poin yang SANGAT bagus
Tom Squires
3
Saya terkejut bahwa banyak dari ini hanya mengajar pengembang junior untuk mengajukan pertanyaan yang lebih cerdas. Sumber yang bagus untuk ini: catb.org/esr/faqs/smart-questions.html
TALlama
4
Sulit saya setuju dengan sebagian besar poin Anda ada dua bagian saya berusaha sangat keras untuk mengajar pelatih dan orang lain dengan tanggung jawab pengembangan orang lain. Jangan pernah memberi tahu mereka cara melakukan sesuatu. Bantu mereka mencari tahu sendiri dan tidak pernah memberi tahu mereka apa kesalahan mereka, katakan pada mereka bagaimana mereka bisa meningkat. Yang pertama karena itu meningkatkan pembelajaran mereka yang terakhir karena alih-alih melemahkan kepercayaan, itu bisa meningkatkannya
Rune FS
1
@ Ja: sarannya adalah mentor tidak menyentuh keyboard junior.
ftr
21

Saya memiliki sekitar 4 tahun pengalaman, dan saya dapat memberi tahu Anda dari pengalaman saya sebagai pengembang junior tentang apa yang saya inginkan dalam pendampingan. Tampaknya Anda benar-benar menggambarkan jenis pengembang saya ketika saya mulai :)

Pada dasarnya Anda ingin mendorong mereka untuk belajar. Beberapa orang berpikir bahwa setelah mereka selesai kuliah, mereka tidak perlu membaca buku atau belajar lagi. Sikap seperti ini bisa mengarah pada mencari jalan pintas dan hanya "menyelesaikannya".
Dapatkan mereka "Programmer Pragmatis" dan minta mereka membacanya. Buku ini akan membantu mereka menyadari bahwa pemrograman adalah keahlian / karier dan bukan hanya pekerjaan. Rekomendasikan buku untuk mereka baca setiap kuartal atau lebih. Bantu mereka membangun "portofolio pengetahuan" mereka (sebagaimana disebutkan dalam Programmer Pragmatis). Saya sangat merekomendasikan Safari Books Online yang memiliki banyak buku CS / Pemrograman.

Dengan portofolio pengetahuan mereka, mereka akan tahu ke mana harus mencari jika mereka memiliki masalah. Ajari mereka di mana mencarinya. Saya sendiri menemukan manfaat dari StackOverflow baru-baru ini (dan seperti yang Anda tahu, lebih baik mencari di sini daripada hanya di Google).

Sepertinya Anda tidak dapat menghabiskan banyak waktu dengan mereka, tetapi Pair Programming sangat membantu. Jika Anda tidak dapat melakukannya, maka setidaknya lakukan tinjauan kode menggunakan CodeCollaborator atau alat serupa lainnya. Mereka tidak mengambil waktu sebanyak yang Anda pikirkan.

Tes unit juga sangat penting. Mereka dapat dengan cepat mengungkapkan praktik pembangunan yang buruk, terutama jika Anda menyandingkannya dengan integrasi berkelanjutan.

Atif
sumber
10

Ajukan pertanyaan yang mengarah kembali untuk mengarahkannya ke jawaban daripada hanya mengatakan kepadanya (baik Anda bisa memberitahunya beberapa hal dasar seperti apa nama server dan apa database menyimpan informasi). Tunjukkan padanya bagaimana menemukan jawabannya.

Dan jangan pernah menulis ulang kode ketika salah, katakan padanya apa yang salah dan berharap dia memperbaikinya. Anda mendapatkan apa yang Anda harapkan. Anda tidak membantu siapa pun dengan membuatnya bergantung pada Anda.

Ulasan kode juga penting. Dan jika Anda memasangkan program, biarkan dia sering menggunakan keyboard. Bahkan jika Anda memberi tahu dia apa yang harus diketik, dia akan belajar dari melakukan pengetikan lebih banyak bahwa dia akan belajar hanya duduk di sebelah Anda saat Anda memprogram.

Ambil beberapa contoh dari perangkat lunak yang khas tentang bagaimana aplikasi disusun dan lalui bersama dengannya baris demi baris memastikan dia mengerti mengapa setiap baris diperlukan dan apa fungsinya. Adalah tugas Anda untuk memastikan dia mengetahui standar pengkodean dan bagaimana kode tersebut disusun dan mengapa Anda (sebagai perusahaan) melakukan hal-hal seperti yang Anda lakukan.

Jika ia memiliki cara berbeda untuk menyarankan, dengarkan dengan cermat. Pertama, dia mungkin benar. Kedua, mendengarkan akan memberi tahu Anda di mana kelemahannya dalam memahami jika apa yang ia sarankan tidak praktis. Lebih jauh, orang cenderung lebih menghargai Anda jika Anda mendengarkan mereka. Ketika dia salah, maka kembali ke pertanyaan utama untuk membuatnya melihat sendiri mengapa idenya salah. JIKA dia bahkan hampir benar, pergi dengan ide-idenya kadang-kadang, tidak ada yang lebih mengecewakan daripada selalu diberitahu bahwa ide-ide Anda tidak berharga.

Ajukan pertanyaan tentang latar belakangnya. Dia mungkin tahu beberapa hal yang belum sempat Anda kerjakan. Jika demikian dan kesempatan untuk menggunakannya, tanyakan kepadanya tentang pengetahuannya.

Jika aplikasi Anda sudah lama, mungkin aplikasi ini memiliki "gotcha" yang licik daripada seseorang yang baru tidak memiliki cara untuk mengetahuinya. Jadi, ketika dia mulai bekerja pada area di mana Anda memiliki satu atau lebih gotcha ini, Anda mungkin memberitahunya tentang hal itu saat ia bangun dengan kecepatan sebelum pengkodean, kemudian lihat apakah ia jatuh ke dalam gotcha ketika ia membuat kode.

Akhirnya, Anda mendapatkan rasa hormat dengan memberikan rasa hormat. Perlakukan setiap orang yang Anda bimbing dengan hormat. Jangan membuat mereka merasa diremehkan atau bodoh. Mereka akan mendengarkan Anda lebih baik jika Anda memperlakukan mereka dengan hormat.

HLGEM
sumber
1
Hampir identik dengan jawaban yang akan saya berikan kepada diri saya sendiri, tetapi saya juga akan menambahkan: Biarkan junior Anda membuat kesalahan (sediakan kesempatan untuk membuat mereka seimbang) karena kesalahan memberikan kesempatan terbaik untuk belajar. Kegagalan memicu rangsangan emosional yang lebih cenderung menghasilkan asosiasi memori yang mendorong pembelajaran, dan semoga junior Anda akan terdorong oleh kegagalan mereka untuk mengajukan lebih banyak pertanyaan. Saya sering memberi tahu junior saya bahwa tidak apa-apa untuk mencoba tetapi gagal pada awalnya jika mereka juga mencoba belajar dari kegagalan mereka, dan saya menggunakan pengujian dan ulasan kode untuk memandu upaya pembelajaran mereka.
S.Robins
Mengajukan pertanyaan memimpin adalah salah satu teknik terbaik yang saya temukan untuk membawa seseorang ke tingkat kedewasaan lain. Tujuan utama Anda bukan untuk membuat mereka mendapatkan jawaban yang benar, tetapi untuk membawa mereka ke tempat di mana mereka dapat mengenali jawaban yang tepat ketika mereka menemukannya (dan dengan demikian, dapat membuang jawaban yang salah di sepanjang jalan.)
rami
1
@ S.Robins, saya telah menemukan bahwa membantu juga menunjukkan bahwa Anda mengetahui hal ini karena kesalahan yang Anda alami.
HLGEM
8
  • Saya selalu memastikan pengembang menginginkan bantuan saya, dan saya sangat berhati-hati untuk tidak masuk ke penjelasan yang lebih dalam daripada yang sabar bisa toleransi. Seperti semua orang, saya suka suara saya sendiri!
  • Saya memperlakukan mereka sederajat, dan pastikan untuk menanyakan pendapat mereka sesering yang saya dengar.
  • Tangkap mereka melakukan sesuatu dengan benar dan beri tahu mereka.
  • Saya selalu belajar sesuatu ketika saya melakukan ini dengan benar - tentang kerajinan saya, tentang profesi saya, tentang pengembang, dan tentang mengajar.
  • Pelajaran pertama selalu adalah: kapan harus tahu bahwa Anda sudah mencobanya sendiri terlalu lama. Banyak orang bangga menemukan jawaban mereka sendiri, dan menghabiskan waktu yang berharga berputar-putar.
Tom McNamee
sumber
Re: "Tangkap mereka melakukan sesuatu yang benar": Saya tidak yakin saya setuju dengan ini, karena itu menyiratkan bahwa Anda selalu melihat dari balik bahu mereka, atau setidaknya, secara teratur memeriksa mereka. Mungkin ada beberapa hubungan di mana itu perlu, tetapi saya tidak berpikir hubungan mentor / anak didik adalah salah satunya; dan itu bertentangan dengan saran bagus Anda untuk "memperlakukan mereka secara setara".
ruakh
Ruak, Anda membuat poin yang bagus. Saya diajari oleh manajer saya ketika saya pertama kali menjadi manajer sendiri (dia adalah mentor saya, tetapi dia dari Brooklyn ...) dan saya tidak pernah mempertanyakan kata-katanya sampai sekarang. Lebih tepat: "Perhatikan sesuatu yang benar tentang apa yang mereka lakukan." Saya memimpin dengan itu. Ketika masalah 'off by 1' yang tak terhindarkan muncul dengan programmer C, saya mungkin berkomentar bahwa konstruksi loop-nya kompak dan berkomentar dengan baik, dan kemudian memintanya untuk memandu saya melalui logika. Terima kasih.
Thomas McNamee
OK, ya, saya setuju. +1. :-)
ruakh
7

Saya seorang pengembang junior dan saya pikir mentor saya menangani hal-hal ini dengan sangat baik. Secara umum, dia akan memberi tahu saya beberapa cara untuk melakukan sesuatu, tetapi tidak bagaimana melakukannya. Kemudian saya biasa duduk di sana dan mencoba dua cara, dan memutuskan solusi mana yang paling bersih untuk masalah tersebut.

Juga, jika dia melakukan sesuatu yang mungkin berguna bagi saya, dia akan memanggil saya hanya untuk memberikan jalan melalui apa yang dia lakukan dan mengapa.

Ini menghasilkan sejumlah kecil waktu yang dihabiskan bersama saya dan pada dasarnya berarti bahwa saya sendiri harus mempelajari jawaban yang benar dan bagaimana menerapkan sesuatu. Tentu saja, jika saya pernah terjebak dia akan ada di sana untuk membantu tetapi ini beberapa kali. Setelah hanya 5 bulan bekerja dengannya, saya mungkin mendapatkan lebih banyak pengetahuan tentang hal-hal daripada seluruh kursus universitas saya.

Yang penting untuk diingat adalah bahwa saya hanya seorang individu dan ini bekerja dengan baik bagi saya karena bagaimana saya dan bagaimana dia. Ini tentang menemukan struktur yang cocok yang akan membantu Anda berdua.

ediblecode
sumber
5
+1 Saya belajar lebih banyak tentang pekerjaan daripada yang pernah saya dapatkan di Universitas, hanya karena orang-orang meluangkan waktu untuk mengajar saya.
James Khoury
7

Bergantung pada tugas yang diberikan, saya akan tergoda untuk mengambil beberapa pendekatan berbeda:

  • Tanyakan kepada mereka apa yang akan mereka coba selanjutnya untuk menyelesaikan tugas. Ini dapat memberikan gambaran dari mana dari kategori "Saya tidak tahu apa yang harus dilakukan" hingga "Ya, saya akan mencoba ini tapi ..." adalah mereka dalam hal memiliki ide mereka sendiri yang mungkin berguna untuk titik awal .

  • Lihatlah dengan cepat apa yang ingin mereka lakukan dan berikan petunjuk agar mereka menemukan masalah. Ini daripada memberikan jawaban, "Ambil saja baris kode ini," sarankan mereka melihat apa yang ada di sana dan apakah itu semua diperlukan.

  • Jika pasangan pertama tidak akan bekerja, maka saya akan mencoba membuat mereka mengikuti arahan saya tentang apa yang harus dilakukan untuk menyelesaikan masalah. Ini adalah langkah selanjutnya dalam perkembangan di mana jika mereka tidak tahu harus mulai dari mana dan petunjuk tidak berfungsi, ini adalah poin berikutnya.

  • Terakhir, jika tidak ada yang berfungsi maka saya akan melakukan pekerjaan untuk mereka, tetapi saya akan mencoba untuk menghindari ini sebanyak mungkin karena ini adalah bagaimana masalah seperti satu orang secara intim mengetahui sistem bisa dibuat karena seseorang mungkin mengambil pandangan dari pekerjaan pembongkaran kepada saya untuk sistem ini yang sepertinya saya kenal dengan baik.

JB King
sumber
+1 Saya akan menulis sesuatu tetapi ini meringkaskannya dalam pendekatan saya.
Jason Sebring
5

Satu hal yang saya lakukan di sini dalam pekerjaan saya yang saya temukan sangat berguna adalah menyiapkan forum (yaitu PHPbb) untuk tanya jawab internal, dan ikuti aturan bahwa jika pertanyaan dan / atau jawabannya memakan waktu lebih dari 5 menit, seharusnya tanya dan jawab melalui forum. Keuntungan-keuntungan:

  • Itu memaksa junior dev untuk menyatakan pertanyaan dengan jelas, yang membuatnya lebih mudah untuk dijawab, belum lagi saat-saat di mana dia menemukan jawabannya sendiri, hanya dengan memikirkan sedikit lebih banyak tentangnya
  • Ini menghindari pertanyaan yang digandakan, karena junior dev harus mulai dengan mencari pertanyaan serupa yang sudah dibuat
  • Ini membantu dalam membangun basis pengetahuan yang akan berguna untuk perekrutan di masa depan dan untuk mendokumentasikan banyak hal kecil yang bisa hilang dalam waktu.
Fabio Ceconello
sumber
4

Saya akan melawan tren di sini dan menyarankan agar Anda tidak mencoba mendorong pengembang junior untuk belajar bagaimana menemukan jawabannya sendiri. Ini seperti permainan "Saya memilikinya tetapi saya tidak akan memberikannya kepada Anda."

Sebaliknya, berpasanganlah dengan mereka dalam menemukan jawabannya. Anda tetap akan mencari Google, jadi lakukan sambil duduk bersama mereka. Mereka akan mengetahui bahwa ini adalah cara untuk menemukan jawaban.

Jika Anda bekerja sama dengan mereka, mereka akan mengambil cara menggunakan IDE dengan benar; Bagaimana cara menormalkan suatu basis data; bagaimana mengeluarkan kode Anda ... apa pun yang Anda ketahui yang perlu diketahui.

Kuncinya adalah: satu - untuk membuat diri Anda tersedia bagi mereka sehingga mereka dapat melihat bagaimana Anda bekerja. Dan dua - untuk mengatakan dengan lantang mengapa Anda melakukan apa yang Anda lakukan. "Kode ini berulang, jadi saya akan refactor," tidak "menggunakan metode ekstrak pada tiga baris."

Sean McMillan
sumber
Saya tidak percaya Anda merusak tren. Ini tip yang bagus; untuk bekerja dengan mereka dan menunjukkan kepada mereka bagaimana Anda akan menyelesaikan masalah (meskipun, orang mungkin harus berpura-pura tidak tahu jawabannya [tidak menyembunyikannya] untuk menunjukkan proses menemukan itu).
Josh Johnson
Dan untuk lebih jelasnya, saya tidak punya niat untuk menyembunyikan pengetahuan. Tetapi telah menjadi jelas bahwa apa yang saya tahu adalah dimanfaatkan (secara sadar atau tidak sadar). Dan saya tidak berbicara tentang gua tersembunyi yang tersembunyi dari teknologi yang kami gunakan; Saya sedang berbicara tentang perbedaan antara primitif dan objek, atau variabel instan dan lokal, atau pesan kesalahan yang mengatakan dengan tepat apa kesalahan itu dan di mana harus mulai mencarinya. (untuk referensi, murid saya saat ini memiliki 5 tahun pengalaman profesional; Saya tidak berpikir saya tidak masuk akal.)
Josh Johnson
4

Saya hanya pernah melatih seorang programmer junior sekali. Itu untuk membantu memelihara sistem yang telah saya bangun. Tujuannya adalah untuk akhirnya menyerahkan seluruh sistem kepadanya.

Setelah beberapa saat di mana dia membayangi saya, saya melemparkannya ke dalam api. Saya akan memberikan kasus kepadanya, dan berharap mereka akan selesai. Jika dia memiliki masalah, saya ingin dia menjelaskan apa masalahnya, dan ke mana dia mencari. Saya kemudian akan menasihatinya dalam istilah yang paling umum, ke mana harus mencari berikutnya. (Aplikasi mana, mungkin modul mana yang harus dilihat dll). Saya tidak akan pernah meninggalkannya dalam kesulitan, tetapi saya juga tidak akan pernah melakukan pekerjaan apa pun. Hanya berikan arahan. Jika dia masih memiliki masalah, saya hanya akan mengangkat bahu dan berkata "Mulai melacak kode". Dan setiap kali saya mengatakan itu, dia akan merasa ngeri - mengetahui bahwa dia akan melakukan latihan yang membosankan. Itu membuatnya gila, karena kami berdua tahu aku mungkin bisa menemukan masalah dalam 10 menit jika aku hanya akan keluar dari pantat dan bantuanku.

Bertahun-tahun kemudian, dia pindah ke hal-hal yang lebih besar dan sekarang dia melatih juniornya sendiri. Dan kisah favoritnya adalah bagaimana saya selalu mengatakan kepadanya untuk "melacak kode", dan bagaimana latihan pelacakan kode itu penting untuk menjadikannya programmer seperti sekarang ini.

Brett
sumber
3

Setiap kali saya ditanya pertanyaan yang saya tahu dapat diselesaikan dengan pencarian Google cepat, saya akan menemukan dokumentasi atau artikel relatif dan menyampaikannya kepada orang yang mengajukan pertanyaan.

Mengetahui di mana harus mencari sesuatu adalah keterampilan yang penting, dan kadang-kadang lebih sulit daripada yang Anda pikirkan untuk pengembang baru. Mereka bahkan mungkin tidak tahu apa yang mereka cari, dan di sinilah Anda perlu membantu mereka.

Begitu berada di tangan mereka, artikel dan dokumentasi akan memaksa mereka untuk membaca tentang solusi alih-alih mencakar pengembang lain untuk mendapatkan jawaban cepat.

Ini akan mencapai yang berikut:

  • Mengambil beberapa beban dari pengembang berpengalaman.
  • Memaksa pengembang baru untuk belajar.
  • Kebahagiaan untuk semua.

Kadang-kadang Anda hanya perlu memberi mereka cinta yang kuat, terutama jika mereka sepertinya tidak ingin belajar. Jangan memberi mereka jawaban, tetapi pastikan Anda mengarahkan mereka ke arah yang benar.

BrandonV
sumber
3

Saya akan merekomendasikan mulai memberikan bagian dari tugas nyata yang Anda miliki dan membuat segalanya untuk dapat menggunakan kode-nya. Dengan kata lain latih dia sebagai pengganti dirimu sendiri.

Dengan cara ini Anda akan berkomitmen untuk mengalokasikan waktu untuk bekerja dengan junior dan dia akan dapat melihat "kehidupan nyata". Dengan mengerjakan tugas nyata dan mendengar umpan balik yang hidup, dia akan dapat mempercepat dengan cepat.

vang
sumber
1

Saya telah mengajar orang berbagai mata pelajaran di masa lalu, dan hal yang paling mengejutkan saya adalah bagaimana kebanyakan orang tidak memiliki keterampilan memecahkan masalah . Artinya, jika Anda menunjukkan kepada mereka solusi yang tepat, maka mereka dapat menggunakannya kembali nanti jika mereka mengenali atau diberitahu bahwa mereka membutuhkannya.

Tetapi, sangat sedikit situasi dalam kehidupan seperti itu. Kecuali jika pekerjaan Anda adalah "pabrik mental" yang melibatkan menempel widget A ke widget B dengan alat C, maka Anda perlu memiliki beberapa item:

  • Kotak peralatan keterampilan dan alat
  • Metode pemecahan masalah

Misalnya, lihat jawaban yang saya posting ini . Itu mencakup metode pemecahan masalah yang tidak dimiliki banyak orang . College tidak mengajarkan ini kepada siapa pun dalam program CompSci, Anda sudah tahu atau menemukan jawabannya sendiri.

Begitu junior dev mengerti bagaimana cara menyelesaikan masalah, mereka membutuhkan seperangkat alat untuk melakukannya.

  • Debugger (Perguruan tinggi tidak pernah menyebut ini)
  • Profiler
  • Editor teks
  • Shell (dan utilitas terkait)
  • Sumber daya (buku, google, SO, manual)

Tentukan apa yang kurang untuk dev junior, dan Anda dapat membantu mereka meningkatkan. Perlu diketahui bahwa beberapa orang benar-benar tidak tertarik untuk belajar bagaimana menyelesaikan masalah mereka sendiri dan hanya ingin solusi "langkah demi langkah yang jelas" diberikan kepada mereka. Ini bukan pengembang yang baik.

Semoga Anda tidak memilikinya. Jika Anda melakukannya, sadarilah bahwa tidak peduli berapa banyak waktu yang Anda habiskan, mereka tidak akan membantu diri mereka sendiri. Itu akan membutuhkan usaha, dan lebih mudah untuk hanya meminta Anda melakukannya untuk mereka. Ini mirip dengan masalah kesejahteraan, dan dijelaskan oleh teori ekonomi.

Kepentingan diri yang tercerahkan mengatakan orang akan mengambil apa yang mereka pandang sebagai pilihan paling menguntungkan dalam situasi apa pun. Perhatikan bahwa itulah yang mereka lihat. Saya melihat hal yang paling penting sebagai kemandirian dan pembelajaran. Jadi, saya melakukan sendiri. Tetapi yang lain mungkin melihat bahwa mereka hanya perlu memberikan kode kerja sebelum batas waktu. Jadi mereka mencari metode yang paling murah untuk melakukannya. Dengan memberi mereka "gratis" mereka perlu mengeluarkan upaya terkecil untuk menyelesaikan tujuan mereka. Sampai Anda menghapus kruk itu, mereka tidak akan tumbuh.

Spencer Rathbun
sumber
1

Organisasi Anda seperti yang Anda gambarkan sangat berbeda dengan milik saya. Saya menentang pekerjaan junior saya, dan saya melihatnya sebagai peran saya untuk menilai. Jadi banyak yang berbeda.

Satu hal yang saya ingin menyarankan Anda lakukan, adalah sering mengunjungi meja mereka dalam dua minggu pertama khususnya. Sesuatu seperti tiga kali sehari pada minggu pertama, secara bertahap menurun.

Pesan yang saya coba kirim dengan cara ini adalah saya peduli dengan produktivitas mereka. Saya memastikan mereka tidak terjebak. Saya memastikan mereka mengikuti aturan, dan tidak menemukan kembali kemudi. Saya mengajar mereka untuk berkomitmen sesering mungkin. Pelajari mereka untuk berkembang secara bertahap, dan pikirkan tentang desain secara bertahap.

Mimpi terburuk saya adalah pengembang yang setiap hari memberi tahu Anda bahwa mereka hanya perlu satu hari lagi untuk menyelesaikan fitur mereka. Setelah berminggu-minggu menunda, Anda mendapatkan desain yang terlalu rumit, yang diretas sejak awal oleh pembuatnya. Fitur buggy ekstra tanpa pertanyaan, dilemparkan ke dalam campuran untuk mengimbangi keterlambatan, dan karena mereka adalah efek samping bebas dari desain.

Saya percaya bahwa banyak pengembang cenderung pada pendekatan ini. Jika Anda dibiarkan sendiri dengan tugas compex, itu adalah reaksi alami untuk mencoba membuktikan bahwa Anda dapat melakukannya sendiri. Tapi itu respon yang salah. Kualitas adalah kerja tim, dan semakin cepat mereka belajar, semakin baik.

jdv-Jan de Vaan
sumber
1

Jawaban lainnya sangat bagus, tetapi saya ingin mengomentari satu kalimat ini.

Baru-baru ini dan di masa lalu kita memiliki orang-orang mulai di sini yang tampaknya memiliki sikap terhadap pengembangan / pemrograman yang berbeda dari saya dan sulit bagi saya untuk berdamai; mereka tampaknya mengekstrak informasi yang cukup untuk menyelesaikan tugas tetapi tidak benar-benar belajar darinya.

Kebanyakan orang ingin tahu bagaimana melakukan sesuatu. Sikap ini baik-baik saja pada awalnya ketika Anda kewalahan dengan mempelajari hal-hal baru dan belajar bagaimana melakukan pekerjaan Anda.

Langka adalah orang-orang yang ingin tahu mengapa sesuatu dilakukan. Inilah orang-orang yang diinginkan oleh manajer cerdas, walaupun kadang-kadang mereka sulit dikelola.

Beberapa kode orang mendapat bayaran dengan baik. Yang lain dengan senang hati menerima uang untuk pengkodean. Jauh lebih baik untuk bekerja dengan orang-orang yang memiliki hasrat untuk desain dan pengkodean. Sayangnya bagi saya, itu juga sangat jarang. Setidaknya sampai saya menemukan Stack Overflow.

Gilbert Le Blanc
sumber
1

Suatu hal yang harus diwaspadai, bagi mereka yang bersemangat pada prospek melakukan semua pendampingan ini untuk pengembang junior: pastikan manajemen Anda memahami apa yang terjadi.

Mengajar orang lain adalah kerja keras, secara umum. Dibutuhkan fokus dan konsentrasi, perencanaan dan upaya, dan yang paling penting adalah waktu. Apa pun pendekatan yang Anda ambil, jika Anda mengajar dan membimbing dengan cara serius apa pun akan memakan waktu Anda.

  • Jika manajemen Anda mempekerjakan pengembang yang kurang berpengalaman dengan harapan bahwa pengembang senior akan melakukan tugas pelatihan, pastikan itu eksplisit. Cari tahu seperti apa kerangka waktunya dan pastikan bahwa jadwal pengembangan Anda mencerminkan waktu dan upaya yang dihabiskan untuk pelatihan. Pastikan manajemen memiliki beberapa rencana untuk mengevaluasi keberhasilan upaya pendampingan pada waktu yang disepakati. (Tentu saja, jika mereka merekrut pengembang yang membutuhkan pengajaran dan bimbingan, tetapi manajemen tidak merencanakannya, maka itu jelas merupakan masalah serius.)

  • Tidak semua orang adalah guru atau mentor yang baik, dan tidak semua orang menginginkannya. Saya tidak bermaksud terdengar kasar atau pahit; Saya suka mengajar, banyak. Tetapi konyol untuk berharap bahwa semua orang akan pandai dalam hal itu (terlepas dari bakat mereka sendiri), kita juga tidak dapat mengharapkan semua orang menikmati prosesnya (ingat, itu tidak mudah). Selain itu, jika Anda adalah pengembang senior yang tidak menikmati bimbingan, atau jika Anda benar-benar merasa bahwa Anda adalah pilihan yang buruk untuk seorang guru atau mentor, pastikan manajemen Anda memahami bahwa rencana yang melibatkan Anda melakukan tugas-tugas itu adalah rencana dengan kesalahan serius. Di sisi lain, jika Anda ingin menjadi pandai mengajar atau membimbing, itu adalah hal yang baik untuk dikomunikasikan.

  • Jika pengajaran dan pendampingan merupakan beban yang dibagi secara tidak merata di seluruh populasi pengembang senior, pastikan bahwa tugas-tugas tersebut diakui sebagai berharga bagi perusahaan dengan cara yang sama seperti pencapaian pengembangan produk diakui.

Runcing
sumber
1

Saya akan memberikan tampilan saya pada Anda.

Pada dasarnya, saya belajar dengan baik ketika saya:

  1. Diberi pengantar formal untuk topik tersebut. Saya tidak pernah dapat mempelajari sesuatu yang baru tanpa seseorang (ya, seseorang) menjawab semua pertanyaan yang saya miliki tentang konsep-konsep baru. Setelah saya selesai saya ...
  2. Dapatkan buku. Sebagai mentor saya, Anda harus memiliki buku yang sama persis sehingga saya selalu bisa mengatakan sesuatu seperti, "Hei, apa artinya di bab empat, halaman 72, paragraf 6 ..." dan Anda akan tahu persis apa yang saya bicarakan tentang. Setelah saya memiliki buku, saya lebih mandiri, dan benar-benar hanya bertanya. Lalu aku ...
  3. Mulai proyek bersama. Ini adalah bagian terpenting dari proses. Di sinilah Anda dapat mulai mengajar saya tentang Praktik Terbaik, Algoritma, fitur bahasa yang sulit (tapi berguna), dll.

Sekarang Anda telah mengatakan bahwa Anda memiliki proyek sendiri untuk diurus, dan bahwa Anda tidak selalu punya waktu. Itu sebabnya kami diberkati dengan StackOverflow . Saya yakin mereka akan dengan senang hati membantunya men-debug kodenya. Adapun pertanyaan yang tidak pada topik di sana, dia bisa bertanya di sini.

Dengan itu, Anda masih harus bekerja dengannya secara teratur. "Garis waktu" umum seharusnya:

  • 1 bulan. Harus tahu sintaks dasar. Masih belum mandiri saat coding.
  • 3 bulan. Pada titik ini ia harus mengetahui sintaksis seperti punggung tangannya, dan harus dapat menyelesaikan masalah sederhana dengan mudah. Dia jauh lebih mandiri, hanya belum sampai di sana.
  • 6 bulan. Mereka harus tahu, di atas segalanya: Praktik Terbaik, Algoritma Umum, dll. Dia harus bisa membuat proyek sendiri, mungkin dengan sedikit bantuan dari SO.

Selain hal di atas, cara termudah untuk membuat seseorang mandiri adalah memberi mereka topik yang sulit dipelajari, dan tidak memberi mereka apa pun untuk membantu mereka selain internet. Dia akan dipaksa untuk belajar sendiri dan dia akan tahu barang-barangnya.

Setelah dia tahu apa yang Anda ingin dia tahu, bebaskan dia. Biarkan dia pergi dan belajar apa yang ingin dia pelajari (Anda bisa selalu mengatakan Anda ingin dia terus bekerja dalam bahasa itu).

Saya harap ini membantu! Omong-omong, biarkan dia membaca ini: Teach Yourself Programming dalam Sepuluh Tahun .

Dynamic
sumber
0

Buat perbedaan antara tingkat pembelajaran yang lebih rendah dan lebih tinggi. Jika itu terkait dengan pengetahuan, pemahaman, atau aplikasi, saya tidak punya masalah langsung memberi mereka jawaban, dengan penjelasan singkat tentang bagaimana mereka dapat mencarinya nanti. Ini bukan sekolah, itu tidak curang, dan mereka tidak akan bergantung padamu selamanya. Hanya saja, jangan berencana melakukan hal lain untuk satu atau dua minggu pertama, jadi itu tidak akan mengganggu Anda ketika Anda tidak melakukannya.

Setelah beberapa minggu pertama, jika Anda terlalu sering terganggu dengan pertanyaan-pertanyaan semacam ini, gunakan timer pomodoro dan jangan jawab pertanyaan apa pun sampai akhir pomodoro. Google sekarang mudah bagi Anda karena Anda tahu apa yang harus dicari. Mereka sering tidak, jadi jika Anda harus memberi tahu mereka sesuatu ke google, beri tahu mereka istilah pencarian apa yang akan digunakan yang akan mendapatkan hasil terbaik.

Jika masalah terkait dengan analisis, sintesis, atau evaluasi, saya menghabiskan lebih banyak waktu untuk topik tersebut. Di sinilah Anda memberikan alasan Anda di balik keputusan Anda dan membantu mereka mencapai kesimpulan yang sama. Ini muncul paling sering dalam hal desain dan gaya. Jangan hanya memberi tahu mereka untuk menggunakan desain tertentu, tunjukkan kepada mereka mengapa itu lebih unggul dari pilihan pertama mereka. Biarkan mereka membuat kesalahan, dan biarkan mereka memperbaiki kesalahan mereka sendiri.

Karl Bielefeldt
sumber
0

Saya belum melihat seorang pun di sini menyebut-nyebut pahlawan pribadi saya, Randy Pausch .

Saya pikir itu dapat bermanfaat bagi siapa saja yang benar-benar melakukan, mengajar atau membimbing pemrograman (atau bahkan bagi siapa pun yang ingin menjalani kehidupan yang bermakna). Anda dan / atau kolega Anda mungkin menganggap menonton kuliah ini sepadan dengan waktu saya, pada

Lorand Kedves
sumber
-4

Saya, sebagai pengembang junior merasa bahwa jika saya menemukan suatu masalah akan lebih baik langsung mendapatkan jawaban dan menghabiskan waktu untuk memahami bagaimana itu diselesaikan.

Saya dibayar. majikan saya tidak berharap membayar saya untuk belajar. Saya diharapkan untuk melakukan pekerjaan pada akhir hari. Tidak ada gunanya membuang waktu di lingkungan kerja mencoba menemukan solusi. Itulah sesuatu yang akan saya ambil pada waktunya, semoga cepat jika saya pandai apa yang saya lakukan.

MaxSan
sumber
9
Entah
13
Anda kurang bernilai bagi atasan Anda jika Anda tidak pernah, menjadi lebih baik daripada saat Anda dipekerjakan sebagai programmer junior.
10
Max, Anda salah, kecuali Anda memiliki majikan yang buruk. Majikan yang baik AKAN membayar Anda untuk belajar, bekerja, atau bahkan dengan mengirim Anda ke konferensi atau kelas. Jika Anda tetap dengan sikap Anda saat ini, jangan berharap untuk keluar dari menjadi pengembang junior. Judul-judul seperti junior / senior tidak dibagikan berdasarkan semata-mata pada jumlah waktu Anda melakukan sesuatu; jika Anda telah melakukan hal yang sama sejak lama tetapi tidak belajar Anda masih akan dianggap junior.
Andy
5
@ MaxSan Masalahnya adalah pengembang senior jarang ingin menyuap Anda. Kami tidak mempekerjakan pekerja magang sebagai penghitung waktu penuh karena mereka tidak dapat memecahkan solusinya sendiri. Kami berharap Anda meluangkan waktu untuk mencari tahu, dan hanya ketika Anda telah menghabiskan banyak waktu untuk meminta bantuan. Sebagai senior, Anda diharapkan untuk menyelesaikan masalah yang tidak dapat dilakukan orang lain, dan Anda tidak akan dapat melakukannya jika Anda menggunakan sendok.
Andy
6
Jika Anda menginginkan solusi "di atas piring", Anda tidak akan pernah tumbuh dari status Anda sebagai pengembang junior. Belajar dari solusi lengkap yang diberikan kepada Anda mungkin dimungkinkan tetapi tentu saja itu tidak efektif . Begitulah cara otak bekerja: Jika Anda mengalami jalan menuju solusi, bukan hanya solusi itu sendiri, Anda akan belajar lebih banyak dari sekadar mempelajari solusi yang disajikan orang lain kepada Anda.
perdian