Bagaimana saya bisa berurusan dengan sikap pemrograman kargo-kultus?

Saya memiliki beberapa siswa ilmu komputer dalam kursus pemrograman pengantar wajib yang melihat bahasa pemrograman sebagai seperangkat mantra sihir, yang harus dilemparkan untuk mencapai beberapa efek (alih-alih melihatnya sebagai media yang fleksibel untuk mengekspresikan ide mereka tentang solusi) .

Mereka cenderung menyalin-menempelkan kode dari penugasan sebelumnya yang serupa tanpa mempertimbangkan esensi masalahnya.

Apakah ada beberapa latihan atau analogi untuk membuat para siswa ini lebih percaya diri bahwa mereka dapat, dan harus, memahami struktur dan makna setiap potongan kode yang mereka tulis?

Anda bisa mempresentasikan serangkaian latihan, masing-masing latihan pada sebelumnya sambil menambahkan beberapa elemen tambahan atau memutarbalikkan masalah, atau menyelidiki masalah dari perspektif yang berbeda, yang mengungkapkan kelemahan dari solusi sebelumnya, membutuhkan pendekatan baru, berbeda . Ini memaksa mereka untuk memikirkan, menganalisis, memodifikasi, dan bereksperimen dengan setiap solusi, alih-alih hanya menyalin bagian kode yang sudah jadi.

Kemungkinan lain - meskipun tidak sepenuhnya tugas pemrograman - adalah meminta mereka untuk memperkirakan berbagai hal. Misalnya berapa banyak air yang mengalir melalui delta Mississippi per detik? Pertanyaan semacam itu tidak memiliki jawaban yang pasti, terutama karena seseorang perlu membuat asumsi tertentu untuk mendapatkan nilai (kisaran) yang meyakinkan. Dan - walaupun jawaban untuk banyak dari yang "klasik" ini memang bisa di-google-Anda dapat dengan mudah membuat yang baru yang belum ditemukan di internet.

Contoh untuk kedua jenis latihan ini dapat ditemukan di misalnya Pemrograman Mutiara oleh Jon Bentley. Juga The Programmer Pragmatis memiliki beberapa tantangan yang baik.

Jenis tugas ketiga adalah memberi mereka beberapa kode dengan (satu atau lebih) bug di dalamnya, yang harus mereka temukan dan perbaiki. Ini lagi-lagi memaksa mereka untuk menggunakan keterampilan analitis mereka dan alasan tentang bagaimana sebenarnya program bekerja.

Memperbarui

Umpan balik dari komentar oleh Billy ONeal:

Masalah dengan "rangkaian latihan" adalah bahwa siswa yang memiliki masalah dengan latihan sebelumnya benar-benar kacau untuk latihan yang tersisa.

Anda benar, meskipun saya merasa ini lebih tentang masalah umum pengaturan kesulitan kursus ke tingkat yang tepat / pengelompokan siswa dari tingkat keterampilan yang sama bersama-sama. Selain itu, seseorang dapat mengatur siswa menjadi kelompok-kelompok kecil di mana mereka diminta untuk berdiskusi dan berdebat tentang masalah dan solusi, dan menyelesaikan masalah bersama. Jika seseorang tidak mendapatkannya, yang lain dapat membantu (pengaturan ini juga akan meningkatkan keterampilan kerja tim). Dan jika seseorang mencoba menjadi malas dan membiarkan yang lain melakukan semua pekerjaan, itu pasti diperhatikan oleh guru (yang seharusnya berjalan di sekitar, mengawasi dan membimbing siswa, tidak bermain WoW di laptopnya di sudut ;-)

Dan seseorang juga dapat menyesuaikan latihan untuk mengakomodasi siswa dengan tingkat keterampilan yang berbeda. Pemula bisa lebih lambat, yang berpengalaman lebih cepat.

Anda sedang berjuang melawan tindakan menyeimbangkan siswa tentang kebutuhan mereka untuk peduli tentang subjek Anda dan kebutuhan mereka untuk mendapatkan nilai kelulusan . Banyak siswa merasakan bahwa:

(Get it Wrong || Experiment) == (Nilai Gagal && Limbah)

Begitu seorang siswa merasa bahwa waktu atau nilai mereka dalam bahaya, bahkan untuk mata pelajaran yang menarik, mereka berhenti belajar dan langsung melompat ke "Saya tidak peduli, berikan saja jawaban yang tepat kepada guru". Murid-murid Anda mencoba untuk mengambil jalan pintas (atau menurut mereka) dengan berpikir sesedikit mungkin tentang masalah dan hanya meretasnya dengan menyalin dan menempel.

Berikut adalah saran saya tentang cara menghadapinya:

1. Gunakan metode Bob Ross: Buktikan kepada mereka bahwa mungkin dan lebih cepat untuk memulai lagi dari menyalin dan menempel. Buat program baru di depan mata mereka selama kelas - benar - benar menunjukkan kepada mereka bahwa pemrograman bisa seperti melukis gambar.
2. Berikan tugas yang membutuhkan kreativitas . Misalnya, mintalah setiap siswa membuat struktur data mereka sendiri (benda apa saja yang diperlukan untuk membuat Kebun Binatang, Toko Hewan Piaraan, Kota, Perguruan Tinggi, dll.) Di atas kertas untuk digunakan selama kursus. Penugasan # 2 dapat mengubah struktur-struktur itu ke kelas atau objek, dll. Pada dasarnya, membujuk mereka untuk berpikir secara abstrak - ganjilah mereka karena menjadi kreatif, dan kemudian ganjilah mereka karena mengubah kreativitas mereka menjadi program komputer.
3. Gunakan jumlah sintaks yang paling sedikit. Hal-hal seperti boilerplate seperti membuat kelas dan sintaksis bahasa begitu lazim dalam pengenalan pemrograman sehingga sering menyesatkan siswa untuk berpikir bahwa semua pemrograman hanya mengetahui di mana harus meletakkan kurung kurawal - mereka tidak menyadari bahwa apa yang ada di tengah keriting kawat gigi adalah tempat kreativitas mengalir . Pilih bahasa yang sederhana, dan berikan file sampel (seperti file kelas kosong) untuk siswa yang masih ingin menyalin dan menempelkan sesuatu. Anda dapat secara bertahap menjadi lebih ketat tentang sintaks dan tugas yang dapat dikompilasi saat kursus berlangsung.

Beberapa hal yang terlintas di pikiran saya:

• Beri mereka tugas di mana mereka sebenarnya harus menjelaskan kode yang ditulis orang lain (Anda). Memahami kode sebelumnya atau lebih khusus kurang dari itu adalah penyebab terbesar dan bahaya pemrograman kultus kargo. Minta mereka untuk menggunakan komentar, baris demi baris jika perlu, untuk menjelaskan program Anda dalam bahasa Inggris biasa (atau bahasa manusia mana pun yang Anda gunakan).

• Hanya setelah mereka menjelaskan kode, minta mereka untuk memodifikasinya untuk membuat perubahan tertentu. Misalnya, jika Anda memberi mereka fungsi pengurutan yang mengurutkan turun, minta mereka untuk membuatnya mengurutkan. Atau sesuatu yang lebih menuntut. Tapi pastikan itu sesuatu yang membutuhkan pemahaman kode yang diberikan.

• Anda bisa, jika mau, memasukkan beberapa telur paskah ke dalam kode. Satu atau dua baris yang tidak berguna atau bahkan terkait dengan masalah sama sekali. Beri mereka petunjuk bahwa garis tersebut ada dan berikan poin tambahan kepada mereka yang menghapusnya.

• Kemudian dan hanya kemudian Anda dapat memberi mereka tugas untuk menulis sepotong kode dari awal sendiri. Pada titik ini mereka harus memiliki pemahaman yang lebih baik tentang kode apa sebenarnya. Mereka bahkan mungkin merasa sedikit lebih mudah untuk melakukannya sendiri.

Ide dasarnya adalah pemrograman tidak hanya menulis kode, tetapi juga membacanya. Kode bacaan juga harus diajarkan.

Lihatlah dengan cara lain. Fenomena pemujaan kargo ini adalah tahap pemula dari Model Dreyfus untuk memperoleh keterampilan . Inilah cara kita belajar. Ketika saya pertama kali belajar memprogram, yang saya lakukan hanyalah mengetik halaman kode dari belakang Compute! majalah. Pengulangan adalah kuncinya. Bayi belajar berbicara dengan menyalin suara yang mereka dengar dari orang tua mereka. Segala sesuatu yang kita pelajari adalah melalui peniruan. Kita hanya perlu diajari cara beralih dari imitasi menjadi penguasaan.

Masalah yang Anda miliki adalah siswa Anda tidak mengulangi apa pun, mereka menyalinnya dari Internet. Ada beberapa manfaat untuk itu tetapi keuntungannya minimal. Tindakan mengetikkan kode adalah apa yang membuat saya sampai pada tempat pemahaman. Saya mulai melihat pola dalam apa yang saya ketik dan mendapatkan pemahaman tentang apa yang saya lakukan.

Salah satu opsi adalah menyusun lab Anda sebagai kode dojo. Mintalah siswa bergiliran berpasangan satu sama lain pada masalah yang sama. Pilih masalah yang membutuhkan waktu sekitar 10 hingga 15 menit untuk dipecahkan. Ulangi masalah itu di beberapa laboratorium dan berikan sentuhan baru pada masalah tersebut seiring dengan meningkatnya kemampuan kelas. Mungkin mulai lab dengan meminta siswa melihat Anda memprogram solusinya, dan minta mereka mengulanginya. Berpindah pasangan dengan setiap iterasi.

Untuk tes Anda memiliki kode kata di mana setiap siswa mengerjakan masalah dari semester di depan seluruh kelas. Fokus tidak hanya pada kebenaran tetapi bentuk dan kreativitas. Saya pikir ini akan memberikan pemahaman yang lebih dalam tentang cara memprogram daripada memberikan tugas untuk dibawa pulang.

Saya telah mengajar kelas pengantar di masa lalu dan seingat saya melihat ke belakang sekarang:

Beberapa siswa berpikir pemrograman seperti itu untuk alasan yang berbeda. Saya ingat sekali seorang anak yang baik yang banyak melakukan pemujaan terhadap kargo:

Percaya bahwa itu bukan masalah yang terisolasi, tetapi siswa lain di kelas yang sama mungkin memiliki perilaku yang sama atau mendekati masalah dan tidak mengungkapkannya, saya selalu berbicara di kelas.

1. Beberapa waktu dihabiskan untuk menjelaskan beberapa hal seperti determinisme, yang berarti bagi mereka bahwa dalam lingkungan yang sama dengan data dan kode yang sama, mereka akan memiliki hasil yang sama (menghilangkan "keacakan"),

2. Karena penyelesaian masalah tergantung pada tindakan siswa dan bukan hal lain, perhatian harus ada dalam memecahkan masalah dan tidak menemukan mantra yang tepat,

3. Mereka berada dalam lingkungan pendidikan, sehingga masalahnya dibuat untuk menawarkan pengalaman belajar, hasilnya adalah belajar bagaimana memprogram (atau dalam beberapa kasus seperti kelas untuk Administrator Sistem, bagaimana program bekerja, yang berbeda) dan tidak untuk beri saya solusi. ("Dunia tidak membutuhkan kalkulator lain, ini adalah latihan"), sehingga masalah mereka dapat diselesaikan dengan materi yang tersedia (misalnya: catatan disediakan),

4. Saya pikir itu dalam Kode Lengkap: "Bahkan jika Anda menyalin dan menempel, kode itu milik Anda". Jika seseorang melakukannya, itu tidak harus bergaya kargo. Setiap baris harus dijelaskan kepada saya (secara individu) atau kepada siswa lain (sama) atau ke kelas.

Apakah siswa Anda mulai pada 'tingkat abstraksi' yang benar di awal kursus? Misalnya pekerjaan rumah yang memperkenalkan mereka ke struktur pemrograman utama seperti loop dan kondisional tanpa menulis satu baris kode pun?

Ketika saya mengambil intro untuk pemrograman, tugas pertama kami disebut ' Rick the Robot '. Kami memiliki selembar kertas dengan peta udara kota dengan poin menarik, seperti bank, toko kelontong, dll ... Kami memiliki seorang pria bernama 'Rick' dan melakukan tindakan seperti 'ambil satu langkah', 'lihat ke kiri', 'terlihat benar', 'menyeberang jalan' dan kita dapat menggunakan hal-hal seperti 'ulangi' dan 'jika sesuatu, maka lakukan sesuatu'. (Ini bukan 100%, karena saya tidak dapat menemukan tugas ini) Idenya adalah bahwa Rick hanya bisa menggunakan apa yang diberikan kepadanya dan dia harus pergi ke berbagai tempat di peta.

Ini adalah latihan yang menyenangkan dan sesuatu yang memperkenalkan Anda pada dasar-dasar (yang terkadang paling sulit untuk dipahami oleh pendatang baru). Tidak ada satu jawaban yang baik untuk masalah ini (ini permainan) dan tidak ada solusi untuk menyalin dan menempel. Sesuatu seperti ini mungkin juga memungkinkan Anda bermain dengan kreativitas mereka sedikit lebih banyak tanpa mengintimidasi mereka dengan kode.

Akhirnya, idenya adalah Anda mulai dengan yang abstrak dan bergerak ke arah yang konkret . Mereka tidak dapat menyalin abstrak tempel. Mereka harus memahaminya untuk menyelesaikan masalah.

Apa yang Anda minta mereka lakukan adalah mendemonstrasikan analisis dan sintesis dalam domain kognitif Taksonomi Bloom , di mana mereka saat ini hanya menunjukkan aplikasi.

Sayangnya, ini semacam situasi "pimpin kuda air". Analisis dan sintesis juga sangat sulit dilakukan ketika Anda masih berjuang dengan pemahaman. Tanpa pemahaman di tempat, kegiatan analisis dan sintesis akan bertindak lebih sebagai menyingkirkan daripada kegiatan belajar.

Pendapat pribadi saya adalah tidak apa-apa untuk tidak mengharapkan sesuatu yang lebih dari aplikasi dalam kelas pemrograman intro. Ini adalah pertama kalinya siswa mempelajari konsep-konsep ini, jadi ini seperti mengajar anak-anak membaca sebelum meminta mereka menulis esai. Keterampilan tingkat tinggi akan mengikuti di kelas mereka nanti.

Sudahkah Anda mempertimbangkan untuk memberi mereka beberapa kode untuk memulai? Apapun perancah sederhana yang dibutuhkan oleh tugas, seperti fungsi utama kosong (saya tidak tahu bahasa apa yang Anda gunakan). Sesuatu yang mengkompilasi dan menjalankan dan tidak melakukan apa pun. Kemudian mereka dapat mulai menambahkan kode mereka dengan tingkat kepercayaan tertentu yang setidaknya sebagian berfungsi.

Ini sebenarnya cukup umum di "dunia nyata"; banyak IDE dan alat lain membuat proyek kosong dengan pustaka / templat / file konfigurasi yang sudah ada.

Segala jenis mentalitas pemujaan kargo (termasuk pemujaan kargo sendiri) berasal dari kurangnya pemahaman mendasar tentang teknologi yang terlibat.

Pemrograman kargo-kultus seharusnya tidak dianggap sebagai kebiasaan yang bermasalah, melainkan gejala kebingungan mendasar yang dihadapi programmer.

Lebih penting lagi, asumsi bahwa kurangnya pemahaman siswa hanyalah hasil dari kurangnya kepercayaan dirinya secara fundamental salah arah dan tidak mengatasi masalah yang mendasarinya.

Alih-alih, gaya pemrograman salin-rekat siswa harus berupa bendera merah yang memberi tahu Anda bahwa siswa ini kewalahan oleh kerumitan apa yang diharapkannya dilakukannya.

Dia secara naluriah menggunakan karya masa lalu sebagai perancah untuk membangun proyeknya saat ini, mencoba untuk menyusun solusi menggunakan masalah yang sebelumnya diselesaikan sebagai blok bangunan. Kita semua melakukan ini sampai batas tertentu, tetapi kebanyakan dari kita melakukan ini dengan menggunakan pengetahuan yang diperoleh dari pekerjaan sebelumnya sebagai blok bangunan kita. Siswa ini malah menggunakan karya itu sendiri, yang berarti dia tidak benar-benar memahami blok yang dia kerjakan. Dia mendekomposisi pekerjaan sejauh pengertiannya mengizinkan, dan memperlakukan blok kode besar sebagai unit atom karena dia tidak mengerti cara kerjanya . Dia hanya tahu apa yang mereka lakukan.

Mengubah Anda ide proyek!

Dalam dunia pemrograman, jarang kita benar-benar membuat proyek baru untuk setiap solusi yang muncul. Sebagian besar waktu kami memodifikasi yang lama.

Ubah ide Anda tentang proyek dari satu solusi untuk setiap penugasan ke satu solusi untuk seluruh semester. Setiap tugas dibangun di atas tugas sebelumnya.

Contoh

Proyek: Membangun sistem lift

• Tugas 1: Cetak lantai saat ini
• Tugas 2: Buat struktur data untuk kelas lift dan cetak lantai berdasarkan lift
• Tugas 3: Buat kode yang "menggerakkan lift", mencetak lantai. Terima input keyboard (> masukkan lantai:)
• Tugas 4: Tangani beberapa elevator

Intinya adalah bahwa Anda membangun pada tugas sebelumnya alih-alih mendaur ulang tugas lama untuk tugas baru.

Pertimbangkan untuk menggunakan bahasa tingkat tinggi yang membutuhkan kode boilerplate minimum.

Bagi saya, sering kali kode boilerplate dalam kerangka besar atau bahasa verbal yang terasa seperti mantra sihir dan menghambat pemahaman.

Saya secara pribadi diajarkan ML pada kursus pemrograman CS pengantar saya. Selama bertahun-tahun, Lisp diajarkan sebagai pengantar pemrograman di MIT. Keduanya adalah pilihan yang sangat baik. Beberapa manfaat yang mereka miliki adalah

• Penerjemah interaktif. Sangat penting, karena ini memungkinkan eksplorasi.
• Sangat singkat. Tidak ada boilerplate sama sekali. Ini memungkinkan siswa untuk berkonsentrasi pada ide-ide yang mereka coba ekspresikan.
• Relatif tidak jelas dan asing (setidaknya dibandingkan dengan bahasa Jawa, C atau bahasa utama lainnya yang mungkin sudah dimiliki oleh siswa). Ya, saya daftar itu sebagai pro. Ini tingkat lapangan bermain bagi siswa, karena kemungkinan tidak ada yang akan memiliki pengalaman sebelumnya. Dan itu membuatnya lebih kecil kemungkinannya bahwa mereka hanya dapat menyalin-menempel solusi ke pekerjaan rumah dari web.

Saya melakukan riset tentang masalah programmer pemula di tahun 80-an. Berdasarkan pengalaman saya dengan programmer pemula hari ini, tidak banyak yang berubah. Pemula tidak memiliki model mental yang berguna tentang apa yang sebenarnya dilakukan komputer. Mereka menggunakan mantra sihir karena mesin itu sendiri ajaib.

Pemrograman membutuhkan pemecahan tugas-tugas sederhana secara alami menjadi langkah-langkah kecil yang tidak wajar. Karena pemula tidak berurusan dengan rincian halus dalam kehidupan sehari-hari, sulit bagi mereka untuk mencari tahu apa langkah-langkah kecil yang seharusnya, terutama ketika tidak jelas langkah-langkah kecil apa yang disediakan mesin. Tetapi bahkan jika mereka berhasil mengetahuinya, mereka kemudian dihadapkan dengan sintaks yang kaku dan semantik terbatas dari bahasa pemrograman (bahasa yang tidak wajar yang disamarkan sebagai bahasa semi-natural) yang mengendalikan mesin misteri dengan remote control.

Karena mereka tidak dapat membuat hubungan antara solusi logis untuk masalah dan fungsionalitas mesin, mereka fokus untuk memenuhi tuntutan bahasa. Tujuan pertama adalah menulis sesuatu - apa saja - yang mengkompilasi. Yang kedua adalah men-tweak program itu - apa pun itu sebenarnya - agar tidak crash. Kemudian, jika mereka punya waktu, energi, dan minat, mereka mencoba untuk mendapatkan program untuk menghasilkan hasil yang menyerupai apa yang dibutuhkan masalah. Sepanjang jalan, mereka mungkin secara tidak sengaja menghasilkan kode yang ditulis dengan baik.

Kemungkinan besar, para pemula yang belajar memprogram berhasil karena mereka telah menemukan model mental komputer yang berguna, bukan karena mereka telah secara sengaja diberikan dan diinternalisasi.

Anda dapat mengajukan pertanyaan tentang potongan kode yang memerlukan tanggapan tertulis kepada mereka? Seperti "Apa yang dilakukan kode ini?" "Mengapa programmer menyelesaikannya seperti ini?" "Apakah ada cara yang lebih baik?", Dll?

Itu benar-benar akan membuat mereka berpikir tentang masalah, yang merupakan sesuatu yang dapat mereka lakukan tanpa menyentuh kode.

• Tantang mereka untuk membuat solusi sesingkat mungkin untuk masalah tersebut.
• Hadiahi solusi yang lebih ringkas dengan insentif.
• Buat latihan yang sepenuhnya berputar di sekitar kode refactoring
• Mintalah siswa menukar tugas, dan menilai nilai mereka untuk efisiensi dan kebersihan kode, dan gunakan beberapa yang paling tidak efisien sebagai contoh, pada proyektor overhead.

Mirip dengan ide JoelFans adalah meminta mereka melakukan tugas awal di atas kertas menggunakan kode pseudo (bahasa) yang Anda buat. Anda dapat menambahkan struktur sesuai keinginan Anda dan mereka tidak khawatir tentang kotak ajaib.

Saya akan berasumsi bahwa dengan 'pemujaan kargo', maksud Anda mereka memasukkan hal-hal yang dianggap perlu, tetapi sebenarnya tidak melakukan apa pun untuk menyelesaikan masalah.

Jika itu masalahnya, Anda selalu dapat menambahkan beberapa faktor ke dalam penilaian yang didasarkan pada keringkasan - meninggalkan kode yang tidak perlu atau berlebihan dalam program Anda meminta masalah di masa depan, karena mungkin rusak, atau hanya membuatnya lebih sulit untuk dipertahankan.

Mereka akan dinilai sama dalam latihan menulis di kelas bahasa Inggris - tidak ada yang mau barang-barang yang berbunyi singgung acak atau hanya bertele-tele tanpa maksud.

Ketika saya mengikuti kelas perakitan, guru akan memberi tahu kami untuk setiap latihan jika dia ingin kami menulis kode untuk kecepatan, ukuran, atau penggunaan memori, dan dia menandai jika Anda tidak mendekati untuk mengoptimalkan apa yang dia minta untuk.

...

Jika mereka menyalin & menempelkan kode dari penugasan sebelumnya yang serupa, dan itu sebenarnya sesuatu untuk menyelesaikan masalah baru ... yah, itu hanya menggunakan kembali kode, dan kecuali mereka membuat asumsi buruk tentang kesesuaian kode untuk digunakan kembali , Saya pikir itu sangat masuk akal untuk mereka lakukan. (misalnya, membaca dari file, mengajukan masukan ... semua bagian modular yang dapat digunakan kembali. Jika Anda tidak ingin mereka melakukannya, Anda perlu membuat latihan yang berbeda.

Sayangnya, itulah cara otak banyak orang bekerja. Jadi masuklah ke dalam pemahaman ini bahwa ada orang-orang yang Anda tidak bisa 'sembuhkan' dari ini. Ada banyak orang yang tidak dapat bekerja pada tingkat ketelitian mental yang diperlukan untuk pemrograman. Beberapa orang sama sekali tidak dirancang untuk itu. Saya tidak mengatakan menyerah pada siswa - saya katakan jangan menganggap Anda gagal jika tidak semua orang mengambilnya.

Tanpa mengetahui lebih banyak tentang konteks kelas, saya akan mengatakan lebih fokus dengan siswa-siswa bermasalah ini pada struktur yang sangat mendasar - sederhana jika / kemudian, loop, dll. Rutinitas sederhana untuk mencetak angka ganjil, setiap angka kesepuluh, dll. Tidak ada masing-masing lebih dari 10 baris kode. Jika mereka 'berpikir ajaib' mereka jelas belum menguasai dasar-dasar itu. Mintalah mereka melakukan banyak rutinitas sederhana yang berbeda sampai mereka memahami apa yang sedang terjadi. Orang lain yang disebutkan menulis kode di atas kertas - saya pikir itu juga akan menjadi cara yang bagus untuk melakukan rutinitas sederhana ini.

Anda mungkin juga mempertimbangkan untuk meminta mereka mempelajari diagram alur. Bagi sebagian orang, bisa melihat aliran suatu algoritma, dan kemudian bagaimana itu terhubung ke kode, mungkin membantu mereka menghubungkan kode ke aliran.

Idealnya di kuliah pertama, mulailah dengan sesuatu yang sepenuhnya abstrak: minta mereka (sebagai kelompok, dengan Anda sebagai pemimpin) menuliskan instruksi tentang cara berbelanja bahan makanan dari daftar, dan memecah instruksi tingkat tinggi secara progresif sampai mereka mencapai pencerahan.

Ini membantu untuk memberi tahu mereka bahwa instruksi ini akan diikuti secara harfiah oleh robot, yang tidak tahu bagaimana menyimpulkan sesuatu. Itu harus menjadi kegiatan yang sangat langsung di mana Anda bertanggung jawab untuk membimbing mereka.

Alistair Cockburn berbicara tentang konsep Shu-Ha-Ri dan bagaimana itu berlaku untuk pemrograman, http://alistair.cockburn.us/Shu+Ha+Ri . Saya pikir mungkin penting untuk mengingat di mana siswa Anda berada dalam rangkaian ini. Pertama, itu akan membantu meringankan frustrasi Anda. Menyalin / meniru adalah respons yang sangat alami dan mode yang diterima ketika Anda pertama kali mulai mempelajari sesuatu. Kedua, ini mungkin membantu Anda mendapatkan beberapa ide tentang bagaimana untuk maju. Misalnya, Anda mungkin ingin mempertimbangkan untuk memilih masalah yang dapat diselesaikan dengan berbagai cara (loop vs rekursi, konsol vs web / gui) kemudian secara eksplisit minta mereka terlebih dahulu menyelesaikannya dengan satu cara, kemudian dengan cara lain - bonus yang dapat mereka pelajari tentang penggunaan kembali kode yang sah, komponen, membuat pustaka yang dapat digunakan kembali, dll.

Cara sukses lain yang pernah saya lihat digunakan adalah memiliki serangkaian proyek yang dibangun di atas satu sama lain, membuat versi standar yang berfungsi tersedia di setiap langkah setelah tugas telah diberikan untuk mencegah orang dari ketinggalan. Setiap langkah dari proses harus memperkenalkan sesuatu yang baru. Saya akan memberi tahu Anda bahwa ini mungkin lebih mudah dilakukan di kelas desain daripada kelas pemrograman, tetapi itu masih bisa dilakukan. Satu hal yang menyenangkan tentang ini adalah bahwa Anda secara eksplisit memberi mereka implementasi yang baik (mudah-mudahan) untuk dibandingkan dengan mereka di setiap langkah. Paparkan perbandingan ini sebagai tugas, yaitu, lakukan tinjauan kode mini terhadap kode mereka sendiri terhadap upaya mereka. Anda mungkin ingin menjadikan ini sebagai salah satu dari beberapa opsi kredit tambahan.

Meskipun saya biasanya tidak besar pada "komentar," Anda mungkin ingin membuat dokumentasi kode salah satu item kelas. Mintalah mereka membuat dokumen "Teori Operasi" untuk setiap proyek yang menggambarkan pendekatan mereka, bagaimana masing-masing komponen cocok, dan bagaimana mereka bersama-sama memecahkan masalah. Biasanya, saya ingin kode melakukan banyak hal ini sendiri, tetapi itu akan mendorong mereka untuk memakai topi berpikir mereka dan meletakkannya di atas kertas.

Terakhir, Anda mungkin ingin menjadi kreatif dan meminta siswa Anda meninjau kode masing-masing dan memberikannya evaluasi. Beri tekanan rekan kerja untuk Anda. Izinkan ini menjadi bagian dari nilai atau kredit ekstra untuk kode berperingkat tertinggi (dan dokumen).

Hanya saran singkat. Setiap kali saya memiliki masalah pemrograman yang perlu diselesaikan atau debug saya suka melihat kode saya dan 'mainkan komputer' di mana Di kepala saya, saya melacak variabel dan nilai-nilai mereka dan apa yang saya harapkan ketika setiap baris dijalankan . Jadi jika saya menyalin beberapa kode dari suatu tempat, kecuali jika sudah lengkap dan saya hanya perlu referensi, saya ingin pergi baris demi baris untuk memahami apa yang sedang terjadi. Pada dasarnya memainkan komputer. VBA Debugger pada dasarnya membuat tugas ini lebih mudah tetapi membuat siswa Anda melakukannya di atas kertas mungkin memberi mereka dasar-dasar seperti. Apa yang sebenarnya dilakukan garis ini?

Saya mengajar pemrograman pengantar di tingkat perguruan tinggi. Itu adalah kursus roti dan mentega, semua fakultas melakukannya, dan saya pikir kami melakukannya dengan cukup baik. Kami mengikuti teks umum dan ujian umum, tetapi kami masing-masing memiliki metode kelas kami sendiri yang berhasil. Sudah lama sejak itu, tapi kadang-kadang saya bisa mengajar beberapa anak dalam pemrograman, dan seluruh gambar hampir sama.

Cara saya melakukannya adalah mulai dari bawah, sekonkret mungkin. Apa yang siswa ketahui adalah sebuah struktur. Mereka sudah punya banyak konsep. Saya sedang membangun konsep lebih lanjut di atas semua itu, dan saya memangkas konsep yang mungkin mereka bentuk yang kontra-produktif. Pada saat yang sama, saya membuat mereka belajar sambil melakukan .

Saya telah membangun komputer kecil dengan chip Intel 8008, beberapa EPROM, dan beberapa sirkuit. Saya telah memprogramnya untuk memainkan duet kecil ketika chip I / O terhubung ke beberapa speaker. Saya akan menjelaskan bagaimana program kecil itu bekerja, dengan loop dalam untuk menghitung mundur sebuah penghitung. Itu akan bertindak sebagai penundaan. Maka itu akan beralih bit output dan melakukannya lagi. Itu akan melakukan itu untuk sementara waktu, dan kemudian beralih ke penundaan lain, memberikan nada lain, dan seterusnya. Chip memori memiliki timer kecil, dan jika saya memasukkan kapasitor di bawah salah satu input timer, program akan berjalan dengan lambat . Kelas dapat mendengar speaker berbunyi klik, klik, klik ... Saya ingin kelas memahami bahwa komputer melakukan hal-hal yang sangat sederhana selangkah demi selangkah. Lalu saya akan melepaskan kait kapasitor, dan "musik" akan meledak. (tepuk tangan)

Kemudian saya membangun simulator untuk komputer desimal yang sangat sederhana, memiliki 1000 lokasi memori, masing-masing memegang angka desimal 4 digit yang ditandatangani. Itu opcodes yang sangat sederhana seperti "tambahkan ke akumulator", "lompat jika negatif", dan sebagainya. Saya ingin mereka menulis program kecil dalam "bahasa mesin" ini, seperti menambahkan dua angka, atau menambahkan daftar angka. Kemudian mereka bisa menontonnya bekerja dengan satu langkah, atau menekan tombol Enter untuk menontonnya berjalan "cepat".

Inti dari ini adalah untuk meletakkan konsep bahwa komputer hanya dapat melakukan sejumlah kecil operasi dasar yang berbeda, dan mereka melakukannya satu per satu. Ini untuk melawan kesan bahwa mereka memiliki komputer yang rumit, dan bahwa mereka melakukan semuanya sekaligus, dan membaca pikiran Anda dengan murah.

Dari sana kami melanjutkan ke pemrograman dalam bahasa "nyata" (BASIC :), dimulai dengan program yang sangat sederhana namun menarik, bekerja melalui persyaratan, loop, array, file, penggabungan, dan sebagainya. Tujuannya adalah menempatkan seperangkat keterampilan yang cukup sehingga mereka dapat mengambil proyek yang mereka pilih sendiri, karena itulah satu-satunya hal yang membuat pemrograman menarik - penggunaan yang dapat Anda gunakan. Saya akan membuang beberapa ide untuk proyek, dan kemudian mereka akan mengambilnya dari sana. Saya akan meminta ide-ide tertulis, dan kemudian membuat laporan, agar mereka tidak menundanya hingga menit terakhir dan kemudian panik. Saya pikir proyek adalah bagian terbaik, karena mereka belajar di bawah kekuatan mereka sendiri.

Landasan awal itu dalam pemahaman yang sangat konkret tentang apa yang dilakukan komputer membuatnya lebih mudah untuk mengajarkan konsep di kemudian hari yang akan menjadi benjolan-benjolan kecepatan nyata, seperti array atau (dalam kursus nanti) petunjuk. Kita cenderung mengagungkan konsep "abstraksi" sebagai hal yang luar biasa ini, tetapi perlu dibangun di atas fondasi beton, bukan di udara.

Seorang programmer yang belajar saself, saya percaya animasi adalah yang paling menantang dalam hal mengetahui apa yang dilakukan kode. Ketika sebuah program berisi algoritma dan transformasi matematis yang melakukan manipulasi abstrak, satu-satunya cara untuk memahami apa yang dilakukan matematika pada titik tertentu (kecuali jika Anda seorang jenius) membutuhkan pemahaman eksekusi kode itu sendiri.

Perbaiki saya jika ide naif saya salah. Yang ingin Anda lakukan adalah notmencegah siswa Anda menggunakan "pola desain", tetapi untuk menemukan cara untuk memastikan mereka memahami apa itu CnP? Kemudian tantang siswa Anda untuk memanipulasi animasi. Untuk mengubah output dalam animasi, perlu dipahami apa yang terjadi pada setiap langkah. Untuk keprihatinan Anda, saya membayangkan proyek animasi yang disusun dengan baik akan terwujud dalam cara yang jelas ketika seorang siswa "mendapatkannya" - ketika mereka telah menyadari transformasi yang tidak Anda harapkan atau men-tweak variabel terkait dan saling tergantung tertentu.

Tanpa mengetahui batasan pedagogis dan tujuan yang sedang Anda kerjakan, saya tidak bisa mengatakan animasi adalah jawaban yang lengkap. Seluruh kurikulum animasi di luar profesi animasi adalah, saya harus menebak, keluar dari pertanyaan. Beberapa proyek mungkin menghasilkan sesuatu yang indah dan indah, yang tidak buruk.

Pada catatan lain, saya membaca artikel surat kabar (ya, kertas!) Tentang Olimpiade Penyandian tingkat sekolah --wot-wot - kompetisi untuk programmer pra-perguruan tinggi. Deskripsi tantangan mereka adalah artikulasi yang paling jelas dari pengkodean murni yang saya ingat pernah membaca. Para pesaing dinilai saling bertentangan dan berdasarkan standar praktik yang baik. Untuk kompetisi ini siswa harus merencanakan solusi mereka dan kode tangan elemen "pola desain" yang masalah harus menyelesaikan dalam batas waktu. Dengan demikian, solusi untuk keprihatinan Anda mengenai pemrograman CnP adalah dengan menguji apakah para siswa dapat menulis "potongan kode" yang sama yaitu CnP'n!

Saya yakin itu di NY Times. Pencarian cepat tidak menemukannya. Contoh serupa adalah Kontes Pemrograman Collegiate Internasional ACM. Kontes ini menekankan pemrograman cepat: "Pemrograman kilat-cepat dalam kompetisi tim adalah keterampilan yang jelas unik, tidak persis satu banyak pencari kerja akan ditempatkan di bagian atas resume." Jadi saya akan merekomendasikan abstraksi dari masalah dunia nyata adalah jawabannya.

Juga,

Perang Kode HP

Ajari kelas menggunakan bahasa pemrograman yang secara teknis bagus tetapi sangat tidak jelas sehingga mereka tidak akan dapat menemukan kode yang ada untuk disalin.

Anda juga bisa memperlakukan mereka dengan cara yang sulit.

Temukan cara untuk membuat copy-paste berbahaya bagi mereka. Saya tidak memiliki contoh yang tepat, tetapi jika Anda membuat latihan pertama yang solusinya, jika disisipkan dalam latihan kedua yang serupa, bawalah siswa kultus kargo dalam bug "ketidakstabilan yang tidak stabil" yang sangat panjang dan menyakitkan atau "korupsi data diam". Sementara itu, pemikiran "non kargo-kultus" 2 akan membawa solusi yang jelas bahkan kepada siswa terburuk (seandainya ia tidak melihat solusi latihan pertama). Lalu, mungkin ada beberapa kemungkinan mereka bisa belajar pelajaran, dan berpikir dua kali sebelum menyalin kode paste ke latihan ketiga.

Saya ragu bahwa perilaku ini adalah karena keyakinan bahwa program adalah mantra ajaib - lebih cenderung kemalasan dan kurangnya motivasi.

Jadi saya pikir pekerjaan Anda sebagai guru adalah memotivasi siswa Anda - tidak ada siswa yang benar-benar termotivasi akan memotong dan menempelkan solusi (itu hanya untuk programmer yang bekerja dengan tenggat waktu dan garis bawah untuk bertemu ...)

Ajari subrutin. Mintalah mereka mengambil kode yang mereka ambil dari tugas sebelumnya dan mengubahnya menjadi subrutin. Ajari mereka tentang dokumentasi fungsi untuk membantu mereka memahami apa yang sebenarnya dilakukan subrutin.

Buat mereka mengerjakan tugas di depan Anda di ruang kelas tanpa akses internet (mintalah sekolah memotongnya, tidak mengizinkan penggunaan telepon selama kelas berlangsung). Setidaknya lakukan ini untuk tes. Tidak ada alasan sama sekali bahwa mereka harus menggunakan Internet untuk pengalaman pemrograman dasar. Buku ini harus menjadi sumber yang cukup untuk latihan intro. Izinkan penggunaan Internet begitu Anda berada di kelas lanjutan dan mereka sudah belajar cara berpikir.

Jangan pernah memberi mereka tugas yang terdengar serupa.

Atau, lebih gila, pelajari mereka TDD dari awal. Ini mendorong untuk menulis (bukan menyalin, menulis) banyak kode (yaitu tes) yang sebenarnya membantu merumuskan masalah yang sedang dipecahkan.

Sesuatu yang menurut saya sangat membantu bagi orang-orang di kelas saya adalah menulis proyek kecil tentang mereka, dengan subjek yang dapat mereka pilih sendiri.

Ketika saya mulai pemrograman, sulit bagi saya juga, dan saya memang banyak menyalin di kelas. Kemudian di rumah, saya mulai membuat game kecil, karena saya ingin menjadi programmer game, dan saya menemukan mereka lebih mudah dibuat. Meskipun mereka jauh lebih sulit daripada yang kami lihat di kelas. Hanya karena itu membuatku tertarik.

Beberapa orang lain di kelas saya naik dari 40-50% pada ujian mereka menjadi 90-100%, karena mereka melakukan hal yang sama persis.

Ketika saya berada dalam kursus pemrograman pengantar, instruktur meminta semua orang untuk menulis algoritma dalam bahasa Inggris dan mencetaknya dan mengubahnya sebelum kami mulai menulis kode. Kemudian kita harus memberikan banyak komentar seperti Buat variabel, Dapatkan Input dari pengguna, Lakukan kalkulasi, hasil cetak, dll. Saya berlabuh beberapa kali karena tidak memiliki cukup komentar ketika saya pikir ada banyak, jadi saya mulai menambahkan lebih. Ini memaksa saya untuk berpikir tentang apa yang saya lakukan dan menulis solusi dan terus menerjemahkan bolak-balik antara bahasa Inggris dan Jawa.