Kapan Anda tidak memberikan bantuan kepada programmer yang kurang berpengalaman? [Tutup]


57

Apakah Anda pikir itu ide yang baik ketika seorang programmer junior perlu bantuan untuk selalu masuk dan mencoba mendidik mereka? Atau akankah mereka mengabaikan semua nasihat "mengajar memancing" yang Anda berikan dan hanya fokus pada "ikan" yang baru saja Anda bawa? Apakah Anda membiarkan mereka selalu mencari tahu sendiri, mengetahui bahwa kesalahan adalah cara terbaik untuk belajar? Atau apakah Anda takut mereka akan sangat terbakar dan frustrasi sehingga mereka akan kehilangan keinginan untuk mempercepat?

Kapan Anda memilih kapan untuk membantu seseorang yang lebih junior daripada Anda dan kapan harus mundur dan membiarkan mereka belajar dari kesalahan mereka?


5
+1. Pertanyaan yang sangat bagus Memberi makan sendok tidak membantu siapa pun, tetapi membiarkan seseorang menggelepar juga merupakan kegagalan besar.
Steve

1
Jangan lupa bahwa Anda tidak selalu dapat melakukan hal-hal sendiri, kadang-kadang Anda memiliki masalah atau kesalahan dan Anda perlu pikiran segar untuk menyelesaikannya. Dan jika mereka kehilangan keinginan untuk melakukan lebih banyak usaha, itu mungkin mereka tidak benar-benar layak untuk dididik. Anda tidak bisa menyuapi otak, itu tidak pernah berhasil. Saya sering mengajukan pertanyaan yang tidak bisa dijawab oleh guru saya karena banyak alasan: karena beberapa alasan saya selalu memiliki rasa ingin tahu lapar yang membuat saya tidak melakukan pekerjaan saya sampai saya tahu banyak. Waspadalah terhadap siswa semacam itu, mereka tidak hanya akan menyedot waktu Anda, tetapi mereka juga. Sisi baiknya, saya lebih jernih ...
jokoon

1
Jangan menulis kode mereka. Tunjukkan pada mereka milikmu. Beri mereka saran (jika mereka ingin mendengarkan).
Kamil Tomšík

Jawaban:


51

Di salah satu pekerjaan saya, saya belajar dan mengajar (karena saya tentu saja tidak tahu segalanya, tetapi saya tahu lebih dari beberapa)

Tidak di semua biaya meletakkan tangan Anda pada keyboard. Ini membuat frustrasi bagi Anda, dan orang yang Anda ajar. Bahkan jika Anda memberi mereka petunjuk langkah demi langkah, ketika Anda meletakkan tangan Anda pada keyboard itu setara dengan memberi mereka sepotong kode dan mengatakan "ini memperbaikinya".

Dalam apa yang saya pelajari:

  • Jangan mengetik kode untuk mereka
  • Cobalah untuk mengajar pada level mereka (jika mereka memahami sintaksis, jangan jelaskan kepada mereka. Ini hanya akan membuat mereka bosan; alih-alih ajarkan kelas / fungsi yang digunakan)
  • Jangan abaikan mereka atau katakan "cari tahu sendiri". Yang akhirnya Anda dapatkan adalah mereka mendatangi Anda kecuali untuk sekarang 3 baris kode yang bermasalah, kini 50 baris tersebar di 8 file yang mencoba mengatasi masalah tersebut.
  • Ajari mereka untuk belajar sendiri. Salah satu cara terbaik adalah memberi tahu mereka untuk menggunakan stackoverflow. Saya kadang-kadang, bahkan tahu jawabannya, jika mereka bertanya kepada saya. Saya akan mengatakan "baik, saya akan menanyakan pertanyaan ini di stackoverflow". Dan saya akan memberi mereka tautan ke pertanyaan itu. Istirahat kopi dan lihat beberapa kode berbeda. Ketika mereka kembali bertanya "jadi bagaimana cara memperbaiki masalah itu" katakan saja kepada mereka untuk mencari pertanyaan mereka pada SO (menggunakan URL yang Anda berikan kepada mereka). Saya telah menemukan bahwa massa biasanya guru yang lebih baik daripada saya.
  • Ketika mereka menyalin dan menempelkan kode dari internet dan bertanya mengapa itu tidak berhasil, minta mereka untuk menjelaskan apa yang dilakukan setiap baris. Jika tidak bisa, maka suruh mereka untuk meneliti fungsi / kelas yang digunakan. Jika perlu, berikan penjelasan untuk kelas dan fungsi
  • Lakukan tinjauan kode untuk memastikan mereka memecahkan masalah, tidak hanya menyelesaikannya agar masalah dapat muncul nanti.
  • Bersikap baik. Ketika seseorang baru memulai dalam basis kode Anda tanpa dokumentasi, jangan hanya meminta mereka untuk membaca kode sumber. Berikan ringkasan fungsi tingkat tinggi yang dirangkum di atas. Atau, lebih baik lagi, mulai menulis dokumentasi :)
  • Jadilah rendah hati. Jangan BS tentang masalahnya. Jika Anda tidak mengetahuinya, katakan Anda tidak dan bantu mereka mencarinya. Sering kali, cukup mengetahui domain untuk mengetahui kata kunci apa yang harus dicari cukup membantu bagi Anda untuk memberikannya.

9
+1 untuk "Jangan ketik kode untuk mereka" yang akan saya tambahkan: memanipulasi keyboard mereka sehingga menekan Ctrl-V memberikan sengatan listrik yang kekuatannya sebanding dengan jumlah garis di clipboard. :)
Ingo

Wow. Saya tidak berharap untuk mendapatkan banyak upvotes ini lol
Earlz

2
Saya kira ini adalah hal yang paling penting: "Sering kali, hanya mengetahui domain yang cukup untuk mengetahui kata kunci apa yang dicari adalah bantuan yang cukup bagi Anda untuk memberikannya." - pernah ke sana (sebagai junior)
JCasso

"Ajari mereka untuk belajar sendiri.", Saya pasti setuju.
Steven Mou

+1 Untuk penggunaan SO. Selain mendapatkan beragam pendapat, jawabannya juga dicatat untuk ditinjau nanti. Saya menemukan bahwa tidak semua orang mempertahankan pengetahuan tentang solusi juga.
Chris

27

Metode Sokrates, yaitu mengajukan pertanyaan yang mengarahkan mereka untuk berpikir ke arah yang positif

[ini berguna bahkan ketika Anda tidak tahu apa masalahnya, apalagi solusinya]


3
+1 untuk mengajukan pertanyaan. Ini mengejutkan cara yang menakjubkan untuk mengajar. Saya tidak ingat di mana artikel itu, tetapi di suatu tempat seorang guru mengajar sekelompok penambahan dan pengurangan biner kelas 1 dengan hanya mengajukan pertanyaan.
Earlz

-1 untuk tidak langsung menjawab pertanyaan ... +100 untuk memberikan jawaban yang sangat baik untuk masalah pendampingan yang mendasarinya: -) ...
Newtopian

@ Earlz, jika Anda menemukannya, silakan tambahkan tautannya.


22

Saya telah belajar untuk membantu mereka arsitek dan berhenti di sana. Pilih alat yang tepat, buat desain umum untuk satu atau dua masalah kompleks, dan biarkan mereka melakukannya. Jika mereka kembali dan meminta nasihat, berikan kepada mereka dalam potongan-potongan kecil. Jika tidak, biarkan saja.

Anda sepenuhnya benar tentang "terbakar dan frustrasi". Mereka akan persis seperti itu jika Anda mengelola mikro atau nit-pick. Akhirnya, sangat membantu untuk menjalin hubungan kerja yang ramah dengan rekan kerja Anda. Waktu yang dihabiskan untuk mendapatkan kepercayaan dan saling menghormati akan membayar sendiri 10x lebih.


1
Di sisi lain saya pernah bekerja dengan seseorang yang sangat malas sehingga setiap kali mereka perlu mengingat parameter untuk API, mereka akan bertanya kepada saya alih-alih mencarinya sendiri. Membuatku gila: mereka bisa mencari memcpy sebaik orang lain - jika mereka mau. Pada masa itu kami telah mencetak salinan halaman manual. Saya akhirnya menyerahkan buku itu dan berkata "untuk chrisakes, cari sendiri!".
cepat,

1
@ cepat, atau "Saya akan membantu Anda dengan hal sederhana ini ketika saya punya waktu" dan kemudian kembali lagi ... nanti ...!

10

Saya membantu mereka ketika saya benar-benar membutuhkan hal-hal yang harus diselesaikan dengan cepat, ketika jelas bahwa mereka telah menabrak dinding bata, dan ketika itu jelas tidak masuk akal untuk mengharapkan mereka mengetahuinya tanpa bantuan. Namun, jika mereka belum menaruh waktu untuk sesuatu, maka lebih baik bagi mereka untuk mencobanya terlebih dahulu.

Sejauh mengambil "ikan" alih-alih "mengajar ikan", cara terbaik untuk melakukannya adalah dengan tidak memecahkan masalah orang-orang untuk mereka . Beri mereka ide dan biarkan mereka menjalankannya. Jika mereka menjalankannya, dan gagal, maka bantu mereka lebih banyak. Jika mereka berhasil, bahkan lebih baik.


6

Jika mereka adalah programmer yang baik, mereka harus menemukan cara untuk menyelesaikannya sendiri. Sekarang dalam situasi di mana hampir tidak mungkin untuk menemukan informasi atau solusi untuk masalah yang diberikan meminjamkan uluran tangan tampaknya masuk akal selama Anda menyimpannya dalam alasan. Jangan sendok memberi mereka jawaban.

Mungkin sebagai contoh saya berusia 18 tahun dan telah belajar selama bertahun-tahun sekarang sendiri dan telah menulis beberapa hal gila termasuk kompiler saya sendiri dan saya belajar sendiri. Saya hanya mencari bantuan dengan hal-hal yang benar-benar membuat saya terjebak (seperti dalam saya telah mencari dan bereksperimen setidaknya untuk sehari tetapi tidak berhasil). Saya juga ingin memberikan contoh tandingan: Di kelas pemrograman saya pernah meminta seorang siswa untuk men-debug kode yang bahkan belum dikompilasi!

Pada dasarnya seorang programmer yang baik, bahkan yang junior, harus dapat bereksperimen dan meneliti solusi untuk sebagian besar masalah.


9
Memberi orang ide di awal pekerjaan mereka sering kali merupakan pendorong serius bagi produktivitas bahkan jika mereka adalah orang-orang senior. Dalam pengalaman saya, dalam lingkungan bisnis lebih baik meminta bantuan setelah satu atau dua jam daripada setelah satu atau dua hari, karena delapan jam waktu seseorang adalah terlalu banyak uang untuk sebuah pertanyaan yang mungkin sudah diketahui jawabannya oleh orang lain.
jprete

5
Tapi ingat, klien Anda yang membayar waktu Anda! Apakah mereka akan senang dengan Anda menghabiskan satu hari meneliti solusi, yang bisa diselesaikan dalam 15 menit dengan bertanya kepada pengembang senior?
Adam Harte

3
Dalam lingkungan bisnis saya kira Anda perlu menjatah waktu Anda sesuai. Sehari tidak akan memotongnya. Namun saya masih berpikir menyelesaikan masalah sendiri akan menguntungkan Anda karena keterampilan pemecahan masalah Anda harus meningkat. Pada akhirnya Anda dapat membayarnya sekarang atau nanti.

1
@ Adam, pertanyaannya adalah apakah pengembang senior harus ditanya atau bertanya sendiri. Bagaimanapun ini adalah proses pembelajaran.

3

Saya akan membimbing tetapi saya pergi jika mereka ingin saya melakukan pekerjaan mereka untuk mereka. Biasanya hanya beberapa saran tentang cara mengatasi masalah, atau mengulangi kembali deskripsi tugas yang dapat membantu. Bahkan hanya dengan memberi tahu mereka kata-kata yang seharusnya mereka gunakan di google bisa cukup membantu. 2 menit maksimal.


3

Saya baru-baru ini mulai menggunakan teknik pomodoro . Akibatnya, jika saya tidak dapat menjawab pertanyaan tanpa mematahkan pemikiran saya tentang tugas saya saat ini, saya mulai bertanya apakah saya dapat menunda jawaban sampai akhir pomodoro, rata-rata sekitar 15 menit penundaan. Efek samping yang menarik dari hal ini yang saya temukan adalah ketika saya mampir ke meja mereka untuk menjawab pertanyaan, mereka sudah sering menyelesaikannya sendiri. Jika tidak, pada saat itu saya jauh lebih siap untuk memberi mereka perhatian penuh saya.

Ini bukan sekolah. Itu tidak curang jika Anda dengan cepat memberikan fakta yang akhirnya bisa mereka temukan sendiri. Sebaliknya, masuk akal bisnis untuk menghemat waktu mereka, dan dalam pengalaman saya keterampilan diasah sangat sedikit dengan coba-coba dibandingkan dengan seorang mentor yang memberi Anda dorongan kecil yang sering ke arah yang benar. Saya lebih suka mereka belajar 10 cara yang benar untuk melakukan sesuatu dengan bantuan saya daripada 9 cara yang salah dan satu cara sendiri.

Jika sesuatu dapat dengan mudah dilihat, ajari mereka cara melakukannya. Di sisi lain, jika itu adalah sesuatu yang hanya dapat Anda ketahui dari pengalaman, seperti file mana yang akan diselidiki untuk gejala bug tertentu, saya benar-benar tidak melihat ada yang salah dengan hanya memberikan jawaban yang tidak dapat dijelaskan.

Sebaliknya, hal-hal yang lebih subyektif seperti panduan arsitektur harus selalu disertai dengan alasan di baliknya. Untuk satu hal, pengembang junior telah berpikir jauh lebih mendalam tentang tugas spesifik mereka daripada yang Anda miliki. Membicarakannya memastikan Anda tidak langsung menarik kesimpulan. Untuk yang lain, itu mencegah mereka dari menerapkan aturan secara membabi buta ke situasi masa depan di mana mereka mungkin tidak berlaku.

Saya hanya bisa memikirkan satu kasus di mana saya langsung menolak untuk terus membantu rekan kerja, dan setelah menghabiskan beberapa jam menjelaskan sesuatu beberapa kali dan melalui beberapa contoh, setelah itu dia benar-benar masih tidak tahu pernyataan selanjutnya untuk mengetik dengan beberapa petunjuk yang sangat terkemuka. Pada saat itu dia memiliki sedikit harapan untuk mempertahankan pekerjaannya tanpa mempelajari kembali dasar-dasar yang serius, dan tentu saja dia hanya bertahan beberapa bulan.


1

Saya berhenti membantu mereka ketika mereka kembali dengan pertanyaan yang sama untuk ketiga kalinya.

Saya memberi tahu mereka bahwa saya akan senang membantu mereka tetapi hanya jika mereka membantu diri mereka sendiri terlebih dahulu. Dari sana mereka pergi mencari kolam lain untuk mencari makanan gratis, dan biasanya mereka dipecat sesaat setelah itu. Atau mereka mengerjakannya dan mendapatkan jackpot ketika mereka kembali untuk lebih ... itu lebih banyak hal untuk dipelajari daripada lebih banyak dari yang sama!


1

Saya pikir konteks itu penting.

Jika kita berhadapan dengan masalah dukungan produksi kritis di mana waktu respons penting, maka saya akan benar-benar memberikan banyak bantuan bersama dengan banyak penjelasan sehingga mereka dapat mempelajari masalah tersebut.

Jika tenggat waktu kurang sensitif, maka kompleksitas menjadi driver. Anda dapat, tentu saja, banyak membantu pemula hanya dengan menetapkan tugas-tugas sesuai tingkat keterampilan, tetapi jika itu adalah sesuatu yang dapat diselesaikan melalui penelitian, maka saya setuju dengan poster-poster lain yang membimbing mereka tanpa memberikan jawaban yang tepat adalah pendekatan yang bagus .

Jika mereka mengajukan pertanyaan yang mudah dijawab dengan mencari di tempat lain, maka saya mengarahkan mereka untuk melakukan pekerjaan mereka sendiri. Sejalan dengan itu, jika ada proses atau solusi yang cukup hafal dan ada sedikit nilai dalam membuat mereka menjadi budak untuk itu, maka malu pada Anda jika Anda tidak memiliki wiki yang berguna untuk mereka periksa.

Ketika datang untuk mentransfer pengetahuan domain yang khusus untuk bisnis, maka saya tidak berbasa-basi. Ceramah langsung sesegera mungkin. Pemula membutuhkan itu untuk membantu segala sesuatu yang datang kemudian. Tidak ada yang namanya dididik tentang bisnis terlalu cepat atau terlalu mudah. Saya pernah punya bos yang memainkan semua jenis trik selama satu jam mencoba membimbing saya ke jawaban. Saya masih baru, belum tahu apa-apa tentang aplikasi atau bisnis, dan saya sedang berurusan dengan masalah dukungan produksi. Saya ingin berteriak, "Mengapa kamu & # @ $! Bermain # @ & (* $%! Game? Pengguna yang mencoba mengeluarkan faktur sedang menunggu jawaban!"


1

Saya pikir hal pertama yang harus Anda tanyakan kepada mereka sebelum membantu mereka adalah apakah Anda menyelidiki tentang ini? jika ya tanyakan kepada mereka apa yang telah mereka temukan dan arahkan mereka ke arah yang benar. Menyelidiki itu sering dianggap remeh, tetapi merupakan salah satu praktik terbaik yang saya pelajari, menemukan informasi tentang apa yang Anda butuhkan memberi Anda kekuatan untuk belajar sendiri, juga akan membuatnya jelas bahwa mereka harus mencoba dulu.

Jika masalahnya lebih rumit cobalah untuk tidak memberi tahu mereka apa yang harus dilakukan tetapi membagikan beberapa ide, tanyakan kepada mereka bagaimana menurut mereka mereka bisa mendekati masalah.

Jika mereka tidak memiliki petunjuk maka cobalah untuk memecahnya ke tingkat yang sangat dasar di mana Anda tidak memberikan semua detail tetapi menggambarkan solusi yang cukup untuk mereka coba, ada alat yang sangat membantu untuk ini seperti algoritma atau diagram alur .

Sebagai kesimpulan, cobalah untuk membimbing mereka tanpa mengganggu proses belajar, selalu membantu mereka akan membuat mereka bergantung pada Anda untuk setiap tugas yang ditugaskan, yang akan memakan waktu Anda dan tidak produktif.


1

Saya menghindari membantu dalam hal-hal sederhana seperti sintaksis yang harus mereka ketahui, atau jika mereka tidak tahu mereka harus dapat memahami sendiri. Jika itu adalah sesuatu yang lebih kompleks, saya tidak keberatan menjelaskan sekali.

Ketika sampai pada hal-hal seperti menjelaskan proses, atau standar pengkodean organisasi / proyek kami dll, saya menggunakan aturan tiga pukulan. Saya benar-benar berpikir bahwa seseorang lumpuh jika dia harus dijelaskan tiga kali lipat. Bahkan itu juga salah satu kriteria dalam penilaian kami.

Banyak yang bergantung pada pelajar. Saya mengharapkan mereka untuk mengambil beberapa barang sendiri. Jika mereka datang dengan: "Saya menghadapi masalah ini, saya mencoba metode A, B dan C tapi saya tidak bisa menyelesaikan masalah", saya akan membantu mereka. Jika mereka hanya datang dengan "Saya menghadapi masalah ini" dan tidak melakukan apa pun saya akan meminta mereka untuk kembali ke buku dan mencari solusi.


1

Sebagai programmer pemula sendiri (sekitar 9 bulan dalam pekerjaan saya saat ini menggunakan sebagian besar Perl dan SQL dan dengan a) tidak memiliki pengetahuan tentang Perl dan b) beberapa bulan bermain-main dengan SQL sebelum pekerjaan ini), ketika mengajukan pertanyaan pemrograman, saya mencoba untuk menunjukkan apa yang telah saya lakukan sejauh ini, atau dalam kasus sesuatu yang tidak berfungsi (dan menjadi sulit untuk di-debug), di mana saya pikir bug itu mungkin ada. Jika memungkinkan, saya sudah berusaha belajar cara memancing.


1

Saya berhenti membantu dalam keadaan berikut:

  • Jika saya digunakan untuk menyalurkan Google / Stack
  • Jika saya telah memberikan dokumentasi dan komentar yang memadai, dan mereka memendekkan tahap RTFM
  • Jika mereka kotor, tidak ada komentar, "Saya akan meretas ini sekarang dan kembali lagi nanti" & & £>! $

Jika saya belum memberikan dokumen yang memadai, atau mereka bekerja dengan alat / kelas yang saya tulis, maka itu adalah tanggung jawab saya untuk membantu mereka

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.