Latar Belakang
Semakin lama saya mengerjakan suatu proyek, semakin tidak jelas jadinya. Sepertinya saya tidak bisa memisahkan berbagai kelas / objek lagi di kepala saya. Semuanya mulai bercampur, dan sangat sulit untuk memisahkan semuanya lagi. Saya mulai meletakkan fungsi di kelas di mana mereka sebenarnya tidak termasuk, dan membuat kesalahan konyol seperti menulis kode yang kemudian saya temukan adalah 100% usang; segalanya tidak lagi jelas bisa dipetakan di kepalaku. Baru setelah saya mengambil langkah mundur selama beberapa jam (atau kadang-kadang hari!) Saya benar-benar dapat melihat apa yang terjadi lagi, dan menjadi produktif.
Saya biasanya mencoba untuk berjuang melalui ini, saya sangat bersemangat tentang pengkodean sehingga saya tidak akan seumur hidup saya tahu apa lagi yang bisa saya lakukan. Ini adalah ketika hal-hal bisa menjadi sangat aneh, saya begitu tenggelam dalam pikiran saya sehingga saya agak kehilangan kontak dengan kenyataan (sampai batas tertentu) dalam berbagai tindakan, seperti menuangkan segelas air, tidak lagi terjadi pada tingkat yang sadar. Ini terjadi pada pilot otomatis, di mana hampir semua konsentrasi saya yang sadar (apakah itu suatu hal?) Dikhususkan untuk pemecahan masalah tanpa batas (mencoba memisahkan elemen kode). Rasanya seperti kalah perang.
Jadi saya mengikuti tes IQ beberapa waktu lalu (Skala Kecerdasan Orang Dewasa Wechsler saya percaya) dan ternyata Spatial Aptitude saya cukup rendah. Saya masih mendapat skor total yang layak , tepat di atas rata-rata, jadi saya tidak perlu menyodok sesuatu dengan tongkat untuk mencari nafkah, tetapi saya sedikit khawatir bahwa ini adalah hambatan ketika menulis / merancang program komputer yang saya menangkan ' tidak pernah dapat melakukannya dengan serius atau secara profesional.
Pertanyaan
Saya sangat tertarik dengan apa yang orang lain pikirkan tentang ini ...
Mungkinkah bakat spasial rendah menjadi penyebab masalah yang dijelaskan di atas?
Bagaimana pemrograman dipengaruhi oleh kemampuan spasial?
Mungkin saya harus lebih memperhatikan garis ADD atau sesuatu yang serupa, karena saya didiagnosis dengan ADD pada usia 17 (5 tahun yang lalu) tetapi obat yang saya terima tampaknya tidak terlalu mempengaruhi saya sehingga saya tidak pernah meminumnya. semua itu serius.
Sejauh yang saya tahu orang dilahirkan dengan kemampuan spasial rendah / med / tinggi, jadi saya pikir itu menarik untuk mengetahui apakah yang lebih beruntung adalah programmer yang lebih baik dengan hak lahir.
sumber
it turned out my Spatial Aptitude was quite low. I still got a decent score, just above average,
Saya bukan seorang psikolog, tetapi jika saya membaca bahasa Inggris dengan benar dan memahami definisi rata-rata, saya tidak benar-benar mengerti bagaimana menerjemahkannya menjadiquite low
... Mungkin Anda terlalu memikirkan ini ... :)Jawaban:
Sebenarnya ada beberapa data penelitian keras tentang ini, sebagian besar dikumpulkan selama 35 tahun terakhir, dan saya juga telah mengalami beberapa fenomena serupa, meskipun tidak secara teratur. Lihat di bawah untuk lebih lanjut.
Data Penelitian
Tampaknya ada beberapa tetapi korelasi kecil berdasarkan penelitian yang dilakukan dan diringkas dalam karya-karya berikut. Seperti sering dengan penelitian, model studi berbeda antara studi dan mereka harus ditinjau dengan seksama untuk memahami mengapa hasil menyajikan perbedaan dalam kesimpulan.
Menjelajahi prediktor psikologis pencapaian pemrograman [ PDF ] (Erdogan, Aydin, Kabaca, 2008)
Sayangnya, detail ini tidak jelas. Ini menunjuk pada "dampak tinggi" dari "bakat" secara umum, tetapi kemudian hanya menunjuk pada penelitian lain tanpa memberikan hasil untuk setiap tes bakat, jadi kita tidak tahu bagaimana kemampuan spasial tarif. Ini sebagian besar tinjauan literatur lebih dari penelitian yang sebenarnya.
Kemampuan spasial dan pembelajaran ke program [ PDF ] (Jones, 2008)
Prediktor Sukses dalam Kursus Pemrograman Pertama [ PDF ] (Simon, Fincher & al., 2006)
Siapa yang cenderung memperoleh keterampilan pemrograman? (Shute, 1991)
Kemampuan lateralisasi dan Pemrograman Hemispheric , (Gasen, Morecroft, 1990)
Korelasi pemecahan masalah dalam pemrograman [ PDF ] (Choi-man, 1988)
Yang menarik ... Model penelitian yang bagus, dan hasil yang dikuantifikasi dengan beberapa kelompok belajar dan memperhitungkan keandalan faktor-faktor penelitian. Ini menghasilkan bahwa:
Pembelajaran, penelitian, dan representasi grafis dari pemrograman (Taylor, Cunniff, Uchiyama, 1986)
Persyaratan Kognitif Belajar Pemrograman Komputer dalam Pengaturan Grup dan Individu (Webb, 1985)
Korelasi kognitif tugas-tugas pemrograman pada programmer pemula (Irons, 1982)
Penelitian tentang bakat untuk belajar: Laporan kemajuan [ PDF ] (RE Snow, 1976)
Ambillah dengan sejumput garam: Beberapa relatif tua, tes IQ mungkin telah berubah sejak itu. Saya belum melakukan pencarian mendalam untuk menemukan kutipan dari setiap artikel untuk melihat apakah mereka dikonfirmasi atau ditolak di kemudian hari.
Beberapa tautan (terutama jenis [PDF]) mungkin tidak berfungsi untuk Anda jika Anda tidak memiliki afiliasi dengan perpustakaan yang memberikan akses ke konten online ini.
Opini pribadi
Peringatan dan pengungkapan: Saya TIDAK seorang psikolog NOR ahli saraf, tetapi saya telah belajar dan mengajar pemrograman untuk kedua anak-anak kecil (mulai 6) dan mahasiswa (sampai 60!).
Setelah belajar dengan DAN mengajar siswa sebagai guru universitas sendiri, termasuk beberapa siswa yang terkena masalah spasial (dan yang lainnya dengan disabilitas yang lebih kuat), saya harus mengatakan bahwa meskipun mungkin (saya tidak melacak siswa saya berdasarkan disabilitas, jelas) bahwa beberapa akan terdaftar di bagian bawah dari kurva umum, saya masih ingat dengan jelas beberapa skor tinggi (dan bahkan satu khususnya menjadi kelas utama selama minimal 2 tahun).
Maksud saya adalah, walaupun mungkin memiliki efek, dan seperti yang ditunjukkan oleh beberapa penelitian di atas, itu tidak memperhitungkan bagian terbesar dari kemampuan Anda untuk belajar memprogram dan berpikir seperti seorang programmer. Ini ngawur, dalam hal itu tidak akan menghentikan Anda untuk mengetahui apakah Anda benar-benar ingin, dan tidak akan mencegah Anda dari bekerja dalam kasus umum, meskipun itu bisa (seperti mungkin menjadi kasus Anda) membuatnya sedikit lebih keras untuk Anda.
Hampir tidak ada batasan untuk apa dan seberapa cepat Anda dapat belajar .
Lagipula, tidak ada programmer yang tidak menyukai tantangan yang bagus, bukan? (Aku melihatmu, RSI)
Pengalaman Pribadi (Mungkin Tidak Berhubungan)
Mungkin Anda terlalu bersemangat. Berapa jam Anda bekerja per hari dan per minggu? Apakah Anda beristirahat secara teratur?
Kasus Serupa?
Pada suatu masa dalam hidup saya, saya bekerja berhari-hari setidaknya 14 jam setiap hari dalam seminggu, sepanjang tahun, ke titik di mana ia memuncak untuk merekam minggu 120 jam kerja di depan layar komputer . Ya, itu hanya 48 jam tersisa per minggu untuk makan, tidur, bepergian ke dan dari tempat kerja ( tip: hindari mengemudi !! ), mandi dan fungsi vital lainnya. Pada titik ini, saya bisa tidur dengan detak jantung (walaupun biasanya memiliki masalah tidur), tetapiSaya hampir selalu terus memimpikan kode, dan saya juga akan tiba-tiba menyadari di kamar mandi atau bahkan ketika berjalan atau berlari atau melakukan tugas-tugas kasar bahwa pikiran saya kembali ke sana dengan pilot otomatis, seperti yang Anda katakan sendiri. Sayangnya, saya tidak akan secara ajaib menyelesaikan masalah dalam tidur saya; itu akan lebih dekat dengan apa yang tampaknya Anda gambarkan dan alami: pusaran raksasa pikiran-pikiran yang membingungkan berputar di kepala saya, yang akan semacam (tampaknya) masuk akal pada skala yang lebih besar, tetapi tidak dengan jelas mengekspresikan solusi apa pun dan tanpa banyak keberhasilan dalam mengambil salah satu dari pemikiran ini untuk fokus padanya, membedahnya dengan jelas dan mengubahnya menjadi sesuatu yang bermanfaat. Dan ini biasanya agak melelahkan dan menyusahkan.
Relaksasi Mungkin Membantu
Mungkin Anda perlu sedikit tenang, dan rileks dan bekerja lebih sedikit. Cobalah untuk menemukan sesuatu untuk mengalihkan pikiran Anda. Saat itu, saya akhirnya sering meninggalkan waktu tidur yang berharga untuk melakukan sesuatu yang benar-benar akan menghentikan pemikiran gila ini. Tampaknya kontraproduktif, tetapi saya sebenarnya lebih suka melakukan beberapa hal di mana saya akan benar-benar bersantai daripada tidur lebih banyak dan tidak diistirahatkan. Gangguan untuk baterai gugup, dan tidur untuk baterai fisik, dalam arti tertentu.
Identifikasi Pemicu
Jika itu bukan kasus Anda, maka mungkin ada sesuatu yang terlibat dalam memicu keadaan ini untuk Anda. Cobalah untuk mengisolasi elemen yang ada dalam situasi ini, dan lihat apakah Anda dapat mereproduksi kondisi ini di lingkungan lain, untuk melihat apakah Anda juga menemukan elemen ini. Apakah itu terjadi lebih di tempat kerja atau di rumah, dll ...
Isolasi
Juga, Anda mungkin sudah pernah mendengar dan mencoba ini, tapi saya punya teman dengan cacat spasial kecil, dan biasanya itu membantunya, jika bekerja pada komputer, berada di ruang yang lebih gelap, untuk menghindari terlalu banyak pandangan dan jendela yang rumit terbuka (untuk menghindari gangguan), dan secara umum menjaga hal-hal agak minimalis (baik dari segi desain dan warna, dan dalam hal konten dan representasi).
Cobalah juga untuk beristirahat secara teratur, dan biarkan pikiran Anda bebas untuk waktu singkat setiap 1 atau 2 jam, berdasarkan apa yang paling cocok untuk Anda. Mungkin mengadopsi teknik Pomodoro atau yang serupa (saya tidak memiliki penelitian tentang korelasinya dengan ini, tetapi bisa membantu memaksa Anda untuk beristirahat).
sumber
Ech ... ini lebih dari sekadar komentar.
Berhenti berkelahi. Anda mendapatkan hal-hal yang bengkok dan membuat kesalahan kan? Anda mungkin memiliki beberapa masalah unik tetapi cara di mana otak Anda memberontak adalah normal bagi siapa saja yang menghabiskan terlalu lama terlalu fokus pada masalah. Ketika saya masih muda, terlalu banyak dari hari saya dihabiskan untuk berpikir pada tingkat yang sangat sadar dan saya tidak melakukan kebaikan pada diri saya sendiri. Masalah Anda bukanlah Anda tidak berusaha cukup keras karena Anda tidak tahu kapan harus berhenti.
Saya akhirnya belajar menghargai nilai dari meletakkan barang-barang di pembakar belakang ketika saya tahu bahwa satu-satunya cara untuk tidur pada jam yang masuk akal adalah dengan keinginan diri saya untuk memikirkan apa-apa dan terkejut mengetahui bahwa dalam waktu 10 menit atau lebih Saya akan tertidur sedangkan biasanya saya akan berpikir-berpikir-berpikir selama setidaknya beberapa jam sebelum jatuh dari kelelahan mental.
Dari sana saya merasa lebih mudah untuk belajar mengenali ketika saya menempatkan terlalu banyak pikiran sadar ke dalam masalah dan membiarkannya pergi untuk sementara waktu. Saya terkejut menemukan berapa banyak ini sebenarnya berkontribusi untuk membantu Anda mengatasi masalah.
Saya merekomendasikan yang berikut ini:
Ketika ada sesuatu yang berputar di kepala Anda dan Anda tidak memiliki kemewahan untuk bisa istirahat dan pergi berjalan-jalan atau sesuatu, cobalah untuk berpindah persneling dan fokus pada bagian masalah yang sangat berbeda untuk sementara waktu.
Jangan pernah melewatkan makan siang dan selalu meninggalkan kantor. Berikan diri Anda sampai Anda tiba di pintu untuk sampai pada titik pemberhentian atau cukup jatuhkan. Apa pun yang berharga disimpan di kepala Anda akan ada di sana ketika Anda kembali ke sana dan semua hal yang tidak Anda butuhkan akan hilang. Semakin banyak Anda menemukan ini, semakin mudah didapat.
Secara teratur Anda sendiri tidak akan memikirkan apa pun sepanjang hari. Bahkan jika itu hanya sebentar, sementara Anda mendapatkan segelas air untuk diri sendiri.
Cobalah untuk memanfaatkan OOP atau pendekatan arsitektur masalah-domain-sentris lainnya untuk memikirkan lebih sedikit. Siapa aktor dalam kode Anda di level tertinggi? Mereka seharusnya tidak memiliki hubungan yang kompleks satu sama lain. Itu memungkinkan Anda untuk lebih fokus pada satu masalah pada satu waktu.
Beberapa Prinsip Pengkodean Yang Mungkin Membantu
KERING adalah praktik pengkodean umum karena "Mencuri itu salah" dapat diterapkan ke hampir semua etika / moralitas. Ada pengecualian yang sangat jarang. Buat mereka sangat langka.
Jika Anda terbiasa memecahkan masalah yang mungkin akan Anda hadapi di kemudian hari, hentikan itu. Tidak ada yang lebih bukti di masa depan atau "scalable" dari kode yang tidak lebih kompleks dari yang seharusnya. "Enterprise" adalah kebohongan.
Pola kompleks seringkali menjanjikan daftar poin poin panjang. Hanya ada 3 hal yang paling penting. Mudah dibaca. Mudah digunakan kembali. Sangat mudah untuk dimodifikasi. Pikirkan dalam hal penggunaan kekuatan minimum yang mungkin dilakukan oleh seorang seniman bela diri dan terapkan prinsip itu pada kompleksitas. Cukup tepat untuk menyelesaikan masalah itu ideal.
Tulis antarmuka Anda terlebih dahulu. Dan tidak, saya tidak bermaksud konstruksi C # / Java yang seharusnya hanya digunakan saat dibutuhkan, maksud saya API dari objek Anda. Apa yang perlu dilakukan oleh kelas / objek? Tulis metode kosong itu dan beri mereka nama arg. Jangan mengisi bagian yang kosong sampai Anda selesai. Tidak apa-apa untuk membuat tweak kemudian, tetapi setelah Anda menetapkan apa yang harus dapat dilakukan, Anda dapat fokus pada bagaimana setiap hal, satu per satu, perlu dilakukan. Alasan Anda mungkin berusaha mempertahankan sebanyak mungkin di kepala Anda mungkin karena Anda memiliki implementasi yang terjadi untuk masalah yang seharusnya sudah dipecahkan jauh sebelum Anda sampai pada tahap tertentu dari suatu proses. Punya banyak is dan punya metode? Itu yang saya bicarakan.
Diagnosa?
Saya pikir masalah kesadaran spasial telah tercakup dengan baik. Apa pun yang Anda putuskan di bagian depan itu, saya akan memberikan kembali hal ADD, terutama jika Anda enggan melakukannya pertama kali. Ini jelas kedengarannya sangat hiper-fokus. Pada akhirnya, biarkan kecintaan terhadap pengkodean mendorong Anda untuk menemukan cara untuk mengurangi masalah ini dan saya berharap karir Anda akan berubah dengan baik.
sumber
Berapa jam Anda bekerja sebelum mulai melihat ini kabur? Banyak rata-rata untuk programmer yang baik saya tahu pekerjaan 4, mungkin 5 jam sebelum minum kopi atau makan siang atau sesuatu. Sprint terpanjang yang pernah saya baca adalah ketika Guy L Steele dan Richard M Stallman melakukan sprint 10 jam atau lebih saat menulis Emacs. Steele melanjutkan dengan mengatakan bahwa dia tidak ingin melakukan sprint yang panjang lagi.
Jika Anda cukup baru untuk (kurang dari, katakanlah, 5000 jam (angka itu berasal dari pos Peter Norvig untuk belajar memprogram dalam sepuluh tahun, dengan membagi dua 10.000 jam yang ia rekomendasikan untuk menjadi programmer ahli)) pemrograman, ini terdengar sangat normal kecuali untuk bagian di mana Anda mengatakan Anda perlu berhari-hari istirahat. Mungkin Anda sedang kelelahan untuk membuat diri Anda membutuhkan istirahat yang lama?
sumber
Dari apa yang Anda uraikan, masalah Anda mungkin memiliki berbagai penyebab:
Kurang pengalaman
Kehilangan fokus / kelelahan
Kemampuan spasial yang rendah
Kurang pengalaman bisa diselesaikan dengan ... yah, mendapatkan lebih banyak pengalaman, pada dasarnya. Betapapun jelas kedengarannya, dengan berlatih lebih banyak Anda akan menemukan diri Anda dalam situasi pemrograman yang kompleks lebih sering dan akan semakin belajar untuk menanganinya. Saat ini Anda mungkin kekurangan skema mental dan refleks untuk membuat koneksi yang tepat, menarik kesimpulan yang benar dan membuka kunci situasi ini, yang dapat membuat Anda merasa seperti Anda lambat dan menulis "kode usang", tetapi pola pemecahan masalah ini akan semakin progresif terjadi di kepala Anda ketika Anda menjadi lebih berpengalaman (Anda hanya 22 tahun seperti yang saya mengerti, yang masih sangat muda).
Ada berbagai teknik untuk meningkatkan fokus Anda. Pomodoro dan Getting Things Done adalah dua contoh. Di bidang pemrograman, Test Driven Development juga sesuatu yang saya sangat sarankan karena memaksa Anda untuk berkonsentrasi pada satu tujuan kecil yang dapat dicapai pada suatu waktu (langkah kecil). Dengan pendekatan TDD Anda jauh lebih kecil kemungkinannya untuk "menempatkan fungsi di kelas di mana mereka sebenarnya bukan miliknya" karena Anda dipaksa untuk secara jelas mendefinisikan tanggung jawab kelas Anda dengan tes dan kemudian fokus hanya pada penerapannya ketika Anda membuat kode , Bertentangan dengan melompat antara beberapa kelas dan mengisinya secara acak sedikit demi sedikit.
Penurunan kelelahan dan perhatian dapat dihindari dengan mengadopsi ritme berkelanjutan dengan sering istirahat. Anda mungkin tertarik dengan presentasi itu oleh Linda Rising untuk menjadi lebih produktif dengan menghargai otak kita: Born to Cycle .
Adapun kemampuan spasial yang rendah, saya khawatir tidak banyak yang dapat Anda lakukan tentang hal itu. Namun, kerja keras dapat melemahkannya dan itu jauh dari keterampilan yang hanya diperlukan dalam pemrograman. Hal-hal seperti kreativitas, semangat, antusiasme, ketelitian, keterampilan analitik, ketajaman, pemahaman yang baik tentang masalah bisnis, keterampilan kolaborasi, dapat lebih dari sekadar menebus visualisasi mental yang lebih lemah dari rata-rata basis kode.
Singkatnya, yang Anda butuhkan IMO adalah:
Disiplin
Praktek
Langkah berkelanjutan
sumber