Apakah pemrograman secara umum menjadi lebih mudah untuk dibaca, ditulis, dan dipahami ketika Anda memperoleh pengalaman? [Tutup]


80

Saya seorang pemula dalam pemrograman dan saya sudah membaca buku, belajar, membaca artikel, dan yang lainnya. Saya mendapatkan hasil yang luar biasa sejak saya mulai belajar pemrograman, dan ketika saya masih pemula saya dulu berpikir saya tahu segalanya tentang pemrograman, tetapi ketika saya belajar lebih banyak saya menyadari betapa sulitnya bidang ini (Faktanya semua bidang itu sulit, tapi bukan itu intinya).

Saat ini, saya telah menulis perangkat lunak fungsional dan saya telah mempelajari BASICS dari 3 bahasa dan saya menengah hanya dalam satu bahasa. Ketika saya melihat hal-hal canggih seperti MYSQL, atau pemrograman OpenGL, atau bahkan kode visual studio C ++ itu memberi saya sakit kepala, dan bahkan ketika memvisualisasikan kode sumber HTML dari banyak situs web (Sebagian besar kode sumber di situs web, dilihat oleh google chrome tampak sangat berantakan dan tidak terorganisir ) itu membuat saya bingung sampai batas otak saya. Awalnya semua tampak sederhana, tetapi ketika melihat hal-hal yang canggih ini hanya membuat saya bertanya-tanya bagaimana orang bisa belajar begitu banyak.

Singkatnya, pertanyaannya adalah apakah hal-hal ini menjadi lebih jelas bagi seorang programmer saat ia maju dalam karirnya. Apakah topik rumit seperti yang tercantum di atas (OpenGL, MySQL, situs html canggih) menjadi lebih mudah dibaca, ditulis, dan dipahami ketika Anda belajar lebih banyak, atau apakah itu semakin rumit saat Anda pergi? Bagaimana Anda bisa melawan perasaan ini bahwa Anda adalah semut di dunia pemrograman dan hal-hal ini akan menghancurkan Anda?


24
Saya sarankan Anda membaca ini: norvig.com/21-days.html
James P.

Seperti yang lainnya, ya. Sampai teknologi berubah pada Anda. :-)
MathAttack

3
Selama "pengalaman" Anda tidak membaca hal yang sama berulang kali. Regangkan diri Anda dengan hal-hal baru.
JeffO

tip kecil, untuk menganalisis halaman HTML yang kompleks, Anda ingin menggunakan Firebug Firefox atau Elemen Inspeksi Chrome.
Lie Ryan

6
"Ketika saya masih pemula, saya biasanya berpikir saya tahu segalanya tentang pemrograman." Berada di sana dan semakin banyak saya belajar, semakin saya sadar betapa sedikit yang saya tahu.
Lieven Keersmaekers

Jawaban:


134

Jawaban singkat: tidak.

Jawaban panjang:

Membaca kode orang lain menjadi lebih mudah, ya. Tapi hanya membaca. Saat Anda mendapatkan pengalaman dan keterampilan, kebutuhan pribadi Anda sebagai pengembang tumbuh.

  • Anda tidak ingin hanya menulis kode. Anda ingin menulis kode yang indah .

  • Anda tidak menganggap kode Anda berjalan dalam kondisi ideal . Anda mulai berpikir tentang semua hal buruk yang mungkin terjadi ketika menjalankan kode Anda, menangani pengecualian, memikirkan masalah perangkat keras, latensi jaringan, dan masalah tumbuh seiring dengan meningkatnya keterampilan Anda.

  • Anda tidak membaca dan menulis kode dalam satu-satunya bahasa yang Anda tahu. Sebagai pengembang yang terampil, Anda tahu bahwa untuk mengatasi masalah khusus yang Anda miliki saat ini, pemrograman fungsional adalah alternatif yang jauh lebih baik , jadi Anda sekarang harus membaca dan menulis kode dalam bahasa pemrograman fungsional.

  • Anda tidak membatasi diri hanya pada set kecil perpustakaan yang Anda kenal. Jika Anda kode dalam C #, Anda ingin tahu dan menggunakan kekuatan penuh banyak perpustakaan .NET Framework.

  • Anda tidak lagi menggunakan notepad. Anda memerlukan IDE yang kuat , dan Anda ingin tahu cara menyatukan kode tes, apa itu metrik kode, dan apa arti dari ratusan opsi dan jendela yang dapat ditunjukkan oleh IDE Anda kepada Anda.

  • Anda tidak ingin membatasi diri hanya pada seperangkat alat dasar yang diberikan bahasa kepada Anda . Dalam C #, Anda ingin menggunakan obat generik, kontrak kode, refleksi, pengembangan berbasis peristiwa, aspek fungsional dengan LINQ, ekstensi reaktif, dan banyak hal lain yang Anda pelajari, semuanya dalam satu proyek tunggal, jika hal-hal itu membantu Anda menulis lebih baik kode.

  • Anda tidak mulai menulis kode . Anda menghabiskan 80 hingga 90% dari persyaratan pengumpulan waktu Anda , membuat arsitektur aplikasi Anda, menulis unit test, menulis dokumentasi, dll., Dan hanya 10 hingga 20% dari waktu Anda menulis kode aktual .

  • Anda peduli dengan keamanan . Anda tahu masalah hukum yang mungkin timbul dengan data yang dimanipulasi oleh aplikasi Anda. Anda tahu apa itu ITIL . Anda tahu beberapa standar ISO dan Anda menerapkannya setiap hari dalam pekerjaan Anda.

Ya, Anda memperoleh pengalaman dan keterampilan, dan menjadi lebih mudah untuk memecahkan masalah yang diberikan dengan semua pengetahuan dan kemampuan intelektual yang Anda peroleh. Tetapi masalah yang harus Anda selesaikan juga tumbuh, dan Anda tidak bersemangat memecahkan masalah tingkat masalah yang telah saya selesaikan saat Anda memulai pemrograman.

Sambil mendapatkan keterampilan, Anda juga mendapatkan wawasan tentang kompleksitas pengembangan perangkat lunak, mempelajari aspek-aspek yang bahkan tidak dapat Anda bayangkan ketika mulai belajar pemrograman, dan Anda ingin dan perlu menerapkan semua hal yang Anda pelajari setiap hari.

Pendeknya:

  1. Hari pertama Anda mulai memprogram, tugas mendaftarkan semua angka dari 1 hingga 100 dapat dibagi dua adalah sangat kompleks: Anda baru belajar cara membuat loop dan menampilkan angka di layar, tetapi Anda tidak tahu cara menemukan apakah jumlahnya dapat dibagi dua.

  2. Sepuluh tahun kemudian, latihan yang sama tampaknya sangat sederhana. Tetapi juga, sepuluh tahun kemudian, Anda menulis aplikasi yang harus menggunakan transaksi, di-host di beberapa server dan harus menangani keadaan sesi dengan benar di antara server, dan menyimpan detail rekening bank pelanggan Anda, dengan semua aspek keamanan dan hukum yang dihasilkan.

  3. ... Dan Anda bertanya-tanya pada diri sendiri, "Bagaimana mungkin saya bisa melakukan itu?" dengan cara yang sama persis seperti yang Anda lakukan sepuluh tahun yang lalu ketika Anda harus menampilkan angka ke layar dengan satu lingkaran.

Ketika semuanya menjadi mudah bagi Anda dalam suatu domain, itu berarti bahwa Anda mencapai kesempurnaan dalam domain ini, atau Anda tidak peduli lagi.

Mencapai kesempurnaan dalam domain seluas pengembangan perangkat lunak tidak mungkin, tidak peduli seberapa pintar Anda.


36
Berjalan di atas air dan mengembangkan perangkat lunak dari suatu spesifikasi adalah mudah jika keduanya dibekukan (ini menunjukkan bahwa "Anda tidak mulai menulis kode. Anda menghabiskan waktu berbulan-bulan untuk mengumpulkan persyaratan" agak tidak realistis)
jfs

9
"pemrograman fungsional adalah alternatif yang jauh lebih baik " masih bisa diperdebatkan.
jfs

15
Saya tentu berharap bit "pemrograman fungsional" hanyalah sebuah contoh "gunakan alat yang tepat untuk pekerjaan itu" daripada menyiratkan bahwa pemrograman fungsional sebenarnya lebih baik untuk penggunaan umum.
Ben Brocka

7
Saya juga akan mencatat bahwa "persyaratan pengumpulan berbulan-bulan" tanpa pengembangan hanya akan terjadi pada dasarnya model Air Terjun ideal. Jika Anda tidak mengulanginya, Anda bunuh diri dan proyek itu.
Ben Brocka

8
"Itu tidak pernah menjadi lebih mudah, kamu hanya pergi lebih cepat." / Greg LeMond /
daGrevis

20

Sebagai seorang anak, Anda belajar berbicara dan kemudian membaca bahasa ibu Anda. Mekanika polosnya adalah perjuangan pada awalnya, tetapi pada beberapa titik itu lancar. Namun, Anda masih memiliki persediaan buku tanpa batas yang belum Anda baca, dan pada beberapa topik Anda harus meningkatkan kosa kata Anda terlebih dahulu hanya untuk dapat memahami buku itu.

Hal yang sama berlaku untuk pemrograman komputer. Pada titik tertentu, bahasa itu sendiri berhenti merasa seperti bahasa asing, tetapi masih ada banyak hal yang ditulis dalam bahasa itu yang belum Anda ketahui. Tetapi semuanya dapat diakses oleh Anda dengan sedikit usaha.

Beberapa pekerjaan pemrograman sangat berulang, pada dasarnya menerapkan kembali perangkat lunak yang sangat mirip untuk pelanggan yang berbeda. Dalam pekerjaan-pekerjaan itu Anda mungkin merasa seperti telah mencapai titik tertinggi dalam belajar. Pekerjaan lain Anda melakukan sesuatu yang baru dan unik setiap saat, dan tidak pernah berhenti belajar hal-hal baru.


18

Ada beberapa jawaban yang sangat bagus di sini, tetapi saya pikir saya mungkin menambahkan beberapa poin pendek lagi:

ketika saya masih pemula saya biasanya berpikir saya tahu segalanya tentang pemrograman, tetapi ketika saya belajar lebih banyak saya menyadari betapa sulitnya bidang ini

Ini disebut efek Dunning-Kruger . Ini sangat umum di antara programmer pemula, dan pada kenyataannya, pemula di banyak bidang.

Sebagian besar kode sumber di situs web, yang dilihat oleh google chrome tampak sangat berantakan dan tidak terorganisir

Apakah orang-orang yang menulis situs web itu ingin Anda bisa memahaminya? Mungkin tidak. Adalah kepentingan mereka untuk memiliki kode yang sulit dipahami.

itu hanya membuat saya bertanya-tanya bagaimana orang bisa belajar banyak.

Dengan spesialisasi . Saya seorang ahli dalam bidang yang sangat sempit: desain dan implementasi analisis semantik kompiler C #. Jika saya menghabiskan waktu lima belas tahun mempelajari OpenGL atau XML atau HTML atau apa pun, saya akan menjadi ahli dalam hal itu dan bingung oleh analis semantik. Tetapi saya tidak melakukannya, dan karena itu saya hanya memiliki pemahaman yang sangat mendasar tentang OpenGL, XML dan HTML.

Singkatnya, pertanyaannya adalah apakah hal-hal ini menjadi lebih jelas bagi seorang programmer saat ia maju dalam karirnya.

Ya, karena Anda mulai melihat pola yang lebih besar. Ambil OpenGL misalnya. Anda mungkin telah melihat banyak "pustaka API" - potongan besar kode terkait di mana cara Anda berinteraksi dengan kode adalah dengan memanggil sekelompok fungsi bernama dengan argumen tertentu. Dan Anda bisa mendapatkan pemahaman dasar tentang OpenGL hanya dari memahami bahwa itu adalah API.

Ketika Anda mendapatkan lebih banyak pengalaman dan melihat banyak teknik pemrograman yang berbeda, Anda menyadari bahwa teknologi yang tampaknya tidak terkait - katakanlah, OpenGL dan LINQ di C # - memiliki kesamaan. Keduanya adalah API tempat Anda membuat alur kerja yang mengalirkan data, dan Anda dapat menjalankan pengoptimal dan transformasi lain pada alur kerja dengan cara yang kaya dan menarik. Setelah Anda memiliki konsep itu di dalam kotak alat Anda, tiba-tiba menjadi lebih mudah untuk memanfaatkan kekuatan penuh dari API apa pun yang menggunakan pola itu.

Apakah topik rumit seperti yang tercantum di atas (OpenGL, MySQL, situs html canggih) menjadi lebih mudah dibaca, ditulis, dan dipahami ketika Anda belajar lebih banyak, atau apakah itu semakin rumit saat Anda pergi?

Mereka menjadi lebih mudah dan lebih rumit. Lebih mudah karena, seperti yang saya katakan, Anda mulai mengenali pola pemikiran yang lebih besar yang mendasari desain sistem, yang memungkinkan Anda menggunakan sistem secara lebih efektif. Lebih rumit karena sekarang Anda dapat menggunakan sistem untuk memecahkan masalah yang lebih rumit , dan Anda kemudian mulai mengalami keterbatasan sistem.

Bagaimana Anda bisa melawan perasaan ini bahwa Anda adalah semut di dunia pemrograman dan hal-hal ini akan menghancurkan Anda?

Anda adalah semut; kita semua semut. Tetapi benda itu bukan kaki yang meremas Anda; itu adalah dunia yang Anda jelajahi, tinggali, manfaatkan, dan tingkatkan. Anda, semut, hanya dapat menjelajahi bagian yang sangat kecil darinya. Pilih bagian yang Anda suka di mana Anda dapat menambahkan nilai nyata dan menjadi ahli di dalamnya.


2
Terima kasih banyak untuk jawaban ini, itu di atas yang lain karena tidak hanya menjawab pertanyaan utama saya, tetapi juga membuka mata saya pada hal-hal tertentu. +1
Bugster

@ Eric: Apa yang akan Anda katakan kepada seseorang dalam topik semacam ini di mana ia mengatakan "spesialisasi adalah untuk serangga, bukan manusia"?
Joan Venge

@ JoanVenge Apakah ada yang akan mengatakan itu? Biasanya orang adalah tentang spesialisasi dan menjadi unik, dan lebih dari itu jika mereka merasa perlu untuk membedakan diri dari binatang (atau serangga).
Matius Baca

1
Anda salah paham apa Efek Dunning-Kruger itu didefinisikan sebagai ketidakmampuan orang yang tidak terampil untuk mengenali ketidakmampuan mereka sendiri dan mengevaluasi kemampuan mereka sendiri secara akurat . Jika Anda tidak bisa mengenali Anda tidak tahu segalanya, Anda tidak akan pernah bisa mempelajari hal baru. Jika Anda bisa mengenalinya, itu bukan DKE.

+1 untuk Pilih bagian yang Anda suka di mana Anda dapat menambahkan nilai nyata dan menjadi ahli di dalamnya.
Akshay Khot

14

Jawaban singkat, Ya.

Mengingat waktu dan keterpaparan hal-hal ini menjadi lebih mudah untuk dipahami.

Ingatlah ketika Anda melihat situs-situs dari perangkat dev di browser Anda, situs-situs itu sering dihasilkan oleh suatu kerangka kerja. Biarlah itu menjadi sejumlah hal ... ASP.NET, JSP, RoR, Django, ... siapa tahu. Beberapa kerangka kerja ini menghasilkan kode yang lebih bersih daripada yang lain.

Sebagai penutup ... paparan mengarah pada kemahiran. Tidak ada cara untuk menghilangkan perasaan itu. Hanya pengalaman dan pembelajaran. Dibutuhkan waktu untuk pindah, mendapatkan pengetahuan domain, dan mempelajari keterampilan yang digunakan lingkungan Anda.


1
Ada beberapa kebenaran selama ini karena orang yang menulis kode menggunakan praktik yang baik dan idiom biasa dari bahasa khususnya dan programmer pada umumnya. Pengodean yang buruk dan / atau kebingungan yang disengaja dapat memperlambat Anda kembali ke perayapan. Coba mampir oleh CodeGolf.SE . Bahkan versi "in the clear" dapat menjadi slogging yang sulit karena praktik-praktik yang baik telah dikorbankan saat ia mengganti metrik kontes.
dmckee

@ dmckee Bahkan kode yang buruk menjadi jauh lebih mudah dibaca dengan pengalaman. Saya perhatikan ini khususnya di C ++ (dan saya harus membaca banyak kode buruk). Tentu saja ini merupakan rintangan yang ekstrim tetapi akan menjadi jauh lebih mudah setelah Anda mulai melihat pola desain yang buruk dan kesalahan umum. Ini juga membentuk semacam idiom yang akan Anda pelajari.
Konrad Rudolph

2

Saya setuju dengan beberapa jawaban yang sudah diberikan tetapi saya pikir itu juga merupakan poin mendasar yang tidak dibahas tentang membaca kode. Ketika saya pertama kali mulai melihat beberapa kode sumber terbuka, rasanya luar biasa dan besar. Tapi coba tebak? itu akan selalu menjadi besar. Pada titik tertentu Anda menyadari bahwa Anda menjadi lebih baik dalam mengekstraksi apa yang secara spesifik ingin Anda ketahui dan terus maju.

Salah satu contoh yang Anda berikan adalah melihat sekumpulan kode HTML, namun:

Mengapa Anda melihat kode HTML? Mungkin bukan karena Anda ingin mempelajari HTML seluruh situs. Mungkin ada trik khusus yang ingin Anda ambil. Dalam hal ini, cari saja HTML yang relevan dengan alat seperti pembakar.

Jika Anda benar-benar ingin mempelajari bagaimana keseluruhan situs dibuat, Anda menyadari bahwa HTML yang diberikan bukanlah cara untuk melakukannya. Anda akan lebih baik melihat proyek sumber terbuka menggunakan teknologi serupa. Namun, mencoba mempelajari seluruh kode proyek tidak sepadan kedengarannya. Membosankan, menghabiskan waktu, mudah melupakan apa yang Anda pelajari, dan Anda tidak memiliki apa-apa untuk ditunjukkan pada akhirnya. Anda akan belajar lebih sedikit dari membaca kode orang lain tanpa henti dan lebih banyak lagi dengan menggunakan potongan-potongan khusus dan menarik untuk menulis plugin, penambahan fitur, atau sebagai perancah dan saran untuk proyek Anda sendiri.

Cobalah untuk belajar minimum absolut untuk mendapatkan sesuatu dari pekerjaan Anda sendiri. Hanya kembali ke titik referensi Anda ketika Anda mengalami kesulitan atau ingin mempelajari hal baru tertentu. Ini bertentangan dengan beberapa kebijaksanaan konvensional bahwa Anda harus memahami segalanya atau Anda sedang memprogram dalam kegelapan. Tetapi pada akhirnya Anda menyadari bahwa tujuan itu tidak mungkin dan Anda belajar untuk menyeimbangkan tujuan mengetahui segala sesuatu dan tujuan untuk benar-benar menyelesaikan apa yang sedang Anda kerjakan.


2

Jawaban singkatnya adalah YA tetapi banyak tergantung pada bagaimana Anda mendefinisikan pengalaman.

Saya pikir setidaknya ada 3 bagian untuk pengembangan. Ketika Anda menjadi lebih baik di setiap segmen, hal-hal tertentu menjadi lebih jelas.

  1. Memahami persyaratan BISNIS . Ini memberi Anda pandangan mata yang lebih baik dari aplikasi. Semakin baik Anda memahami mengapa aturan bisnis itu seperti apa adanya, semakin cepat Anda memahami mengapa hal-hal tertentu dilakukan dengan cara tertentu. Misalnya, pelanggan Anda harus mematuhi peraturan pemerintah X, itulah sebabnya mereka perlu menyiapkan dokumen Y, itulah sebabnya mereka membutuhkan informasi yang tampaknya tidak berguna ini disimpan.

  2. Memahami persyaratan TEKNIS . Ini seperti # 1 kecuali lebih tentang memahami mengapa pada tingkat teknis. Beberapa alat dan teknologi memiliki kebiasaan sendiri, sampai Anda mengatasinya sebelum sulit untuk memahami mengapa hal-hal dilakukan dengan cara tertentu. Ini lebih jelas ketika Anda berurusan dengan sistem warisan. Misalnya Aplikasi menggunakan bus layanan tertentu yang hanya membutuhkan XML.

  3. Memahami persyaratan LANGUAGE . Seperti yang telah disebutkan orang lain, semakin Anda berpengalaman dengan bahasa, semakin cepat Anda dapat membaca apa yang ingin dicapai oleh pembuat kode asli. Namun tanpa # 1 dan # 2, Anda akan menemukan bahwa peningkatan kemampuan ini memuncak dengan cepat.

Cobalah untuk terlibat dalam berbagai aspek pembangunan karena itu benar-benar tidak menjadi lebih mudah sampai Anda telah melakukan semua bidang setidaknya beberapa kali.

Ingatlah bahwa kesempurnaan (dan tujuan) dalam kode orang lain selalu relatif terhadap # 1 dan # 2. Ini adalah pendorong utama mengapa kode berada di negara bagian itu. Perubahan yang sering terjadi di kedua area tersebut adalah alasan terbesar mengapa kami mendapatkan kode spageti sepanjang waktu. Jadi kecuali Anda mahir membaca persyaratan bisnis dan teknis, tugas membaca kode akan selalu menjadi PITA kerajaan.


2

Semakin mudah dan lebih rumit pada saat yang sama!

Mengenal orang lain adalah kebijaksanaan;
Mengenal diri adalah pencerahan.
Menguasai orang lain membutuhkan kekuatan;
Menguasai diri membutuhkan kekuatan;
Dia yang tahu dia sudah cukup kaya.
Ketekunan adalah tanda kekuatan keinginan.
Dia yang tinggal di mana dia bertahan.
Mati tetapi tidak binasa berarti hadir selamanya.

diterjemahkan ke Pengembangan Perangkat Lunak

Mengetahui banyak teknologi adalah kebijaksanaan. (Semuanya turun dari ALGOL)
Mengetahui apa yang tidak Anda ketahui adalah pencerahan. (LISP)
Menguasai banyak bahasa, kerangka kerja dan platform membutuhkan banyak upaya. (Java)
Menguasai hanya apa yang perlu Anda ketahui dan hanya itu yang membutuhkan kekuatan. (dan Google atau stackoverflow.com)
Mengetahui kapan harus berhenti menyandikan dan mengirim sesuatu adalah saat Anda cukup tahu. (Tanpa Analisis Kelumpuhan atau Pelapisan Emas)
Tetap bekerja pada apa yang ingin Anda capai, itu membutuhkan fokus dan kemauan. (Semuanya terus berubah, Anda tidak pernah selesai)
Tetap dengan satu atau dua teknologi dan Anda akan bertahan. (COBOL masih membayar dengan baik, seperti halnya C)
Untuk berhenti pemrograman dan pindah ke manajemen harus selalu ada. (atau tinggalkan warisan perangkat lunak FOSS yang semua orang akan terus menggunakan dengan baik setelah Anda mati).


Jadi, alih-alih menjadi semut, Anda harus menjadi seekor kecoak dan hanya bangun ketika meremukkan Anda, apakah saya benar? :-P
Bugster

"Analysis Paralysis"! = "Tahu kapan harus berhenti coding". Ini lebih "tahu kapan harus mulai coding".
Ben Voigt

0

Singkatnya, pertanyaannya adalah apakah hal-hal ini menjadi lebih jelas bagi seorang programmer saat ia maju dalam karirnya. Apakah topik rumit seperti yang tercantum di atas (OpenGL, MySQL, situs html canggih) menjadi lebih mudah dibaca, ditulis, dan dipahami ketika Anda belajar lebih banyak, atau apakah itu semakin rumit saat Anda pergi? Bagaimana Anda bisa melawan perasaan ini bahwa Anda adalah semut di dunia pemrograman dan hal-hal ini akan menghancurkan Anda?

Saya akan mengambil cara yang sedikit berbeda dari responden lain; Saya percaya bahwa membaca dan menulis kode pada kenyataannya semakin mudah ketika Anda melakukannya lebih banyak, dan saya akan menunjukkannya dengan analogi sederhana.

Pikirkan ketika Anda pertama kali mulai berolahraga. Pada awalnya dengan olahraga pertama yang Anda pelajari, koordinasi dasar untuk tugas-tugas sederhana dari satu olahraga mungkin tampak sangat sulit. Ketika Anda sedikit lebih berpengalaman, Anda mulai menguasai tugas-tugas sederhana sehingga Anda tidak perlu memikirkannya lagi, dan Anda memperhatikan bahwa ada tugas yang lebih rumit yang dapat Anda perhatikan (seperti menonton pemain lain untuk memprediksi perilaku mereka).

Kemudian, ketika Anda mencoba tangan Anda di olahraga lain, Anda mungkin menemukan Anda tidak begitu ketinggalan ketika Anda mulai. Menangkap bola basket jauh berbeda dari menangkap bola bisbol, tetapi seseorang yang menguasai salah satu dari mereka akan lebih mudah mengambil yang lain daripada orang yang belum pernah melakukan keduanya sebelumnya. Dengan pengalaman Anda berlatih olahraga kedua, Anda menemukan bahwa olahraga pertama memberi Anda keterampilan khusus dan generik . Keterampilan khusus (menangkap bola basket) hanya berguna dalam domain mereka, tetapi keterampilan generik (melacak objek yang bergerak cepat mendekati ruang tiga dimensi dan mengembangkan rencana untuk menghadapinya) membuat Anda lebih baik di semua domain terkait.


Apa hubungannya ini dengan pemrograman? Baris kode pertama yang Anda baca memperlihatkan Anda ke dunia yang dibangun berdasarkan aturan tertentu. Anda mempelajari aturan-aturan itu (sintaksis dan idiom bahasa itu) sebagai keterampilan khusus, tetapi Anda juga mempelajari beberapa keterampilan generik yang berharga: memahami bagaimana komputer beroperasi secara internal, dan bagaimana mengekspresikan niat Anda dengan cara yang dapat dipahami komputer. Setiap bahasa baru yang Anda pelajari memberi Anda beberapa keterampilan spesifik baru, tetapi itu juga memperkuat keterampilan generik Anda dan membantu Anda melihat pola-pola ditembakkan melalui semua bahasa komputer seperti deposit mineral yang dilapisi sepanjang dinding ngarai. Setelah Anda benar-benar terbiasa dengan beberapa bahasa yang berbeda, Anda mulai bisa mengenali "bentuk" dari sebagian besar kode apa pun, jika Anda akan mengampuni ketidakjelasan, bahkan jika Anda tidak tahu apa-apa tentang bahasa yang ditulisnya.

Misalnya, ketiga bahasa yang Anda sebutkan (MYSQL, OpenGL, C ++) memiliki beberapa fitur umum:

  • Dimungkinkan untuk menghitung bagian kecil dari suatu algoritma secara terpisah dan menyusunnya menjadi solusi yang lengkap nantinya
  • Komputer biasanya memerlukan sejumlah persiapan umum sebelum Anda dapat mulai mengerjakan masalah spesifik Anda (membuat tabel, menginisialisasi kanvas, atau mungkin memuat perpustakaan umum)
  • Pernyataan sebelumnya diutamakan dan mempengaruhi pernyataan kemudian, yaitu komputer mulai di bagian atas kode dan berjalan turun

Semakin banyak pemrograman yang Anda lakukan, semakin Anda akan menyadari bahwa tidak peduli seperti apa bentuk bola itu, itu tetap saja sebuah bola yang menghampiri Anda, dan Anda tahu apa yang harus dilakukan dengannya tanpa harus terlalu memikirkannya. Semua pemrograman adalah tentang upaya untuk mengungkapkan niat Anda dengan cara yang dapat dipahami komputer; cukup belajar dan Anda akan mulai bisa membaca niat alih-alih kode.

PS - Setiap saat, ketika Anda akhirnya mulai merasa seperti Anda tahu jalannya, Anda akan mengalami sesuatu yang benar-benar menghancurkan otak Anda dan membuat Anda merasa seperti pemula. Itulah yang kami sukai dari pekerjaan ini, selalu ada sesuatu yang baru untuk dipelajari.


0

Jawaban Singkat: Ya , secara umum

Namun, Anda tidak akan menjadi spesialis jika Anda menyamaratakan. Menjadi seorang spesialis juga berarti menyadari semua hal yang tidak Anda ketahui: ini adalah perasaan yang luar biasa.

Saat Anda bergerak melalui waktu, Anda mendapatkan pengalaman.

Saat Anda bergerak melalui waktu, bahasa / pola lain, dll sedang berkembang sejajar dengan perkembangan Anda.

Variabel lain untuk pertanyaan Anda, adalah jika Anda mendapatkan pengalaman yang bermakna dalam kaitannya dengan industri karena ia juga bergerak melalui waktu konstan yang sama. Industri teknologi adalah target yang bergerak dan tidak seperti kebanyakan industri lainnya.

Pertanyaan yang bagus mungkin juga, apakah Anda menyebarkan diri Anda terlalu tipis atau terlalu tebal pada bahasa tertentu.


0

Ini adalah sumber keajaiban (dan kegelisahan) yang tidak pernah berakhir berapa banyak bahasa komputer yang ada dan sejauh mana mereka terus berubah. Selain itu, jumlah kerangka kerja yang berbeda di setiap bahasa dan untuk setiap kerangka kerja, tersedia beragam pustaka dan plug-in. Tambahkan ke jumlah editor kode dan IDE.

Semua variasi ini memiliki dua dimensi kompleksitas.

  1. Kosakata dan sintaksis mereka berbeda.
  2. Abstraksi (konsep tingkat tinggi) yang didukungnya berbeda.

Mereka juga memiliki satu kesamaan. Turing kelengkapan. Dengan usaha yang cukup dari programmer, semuanya dapat digunakan untuk menyelesaikan semua masalah! Jadi, jika Anda mulai dengan bahasa seperti C (kosakata kecil, sintaksis kompleks, dan hampir tanpa abstraksi), Anda pasti mendapatkan perasaan bahwa Anda dapat melakukan apa saja (dengan benar).

Kemudian beralih ke "hal-hal mudah" seperti CSS, HTML, Javascript dan mungkin juga kerangka kerja seperti Bootstrap dan Bereaksi, dan otak Anda akan menggoreng - seperti halnya Albert Einstein. Orang-orang berpikir "Saya tahu bahasa Prancis, jadi belajar bahasa Jerman seharusnya mudah". Tidak!

Banyak abstraksi pemrograman dapat dipelajari dari pola perangkat lunak . Ada beberapa buku yang didedikasikan untuk topik ini. Pola ada di mana-mana, agnostik bahasa dan dapat dipelajari dan dipahami satu kali . Jika Anda tahu pola Anda, Anda dapat menggunakannya dalam bahasa apa pun, dan mengenalinya ketika dibangun ke dalam bahasa dan lebih sering ke berbagai kerangka kerja.

Dibutuhkan sebagian besar orang 1-2 tahun untuk menjadi fasih dalam bahasa baru dan pengusaha tahu itu. Itu sebabnya mereka tidak mempekerjakan orang yang tidak berpengalaman dalam bahasa mereka, karena karyawan baru akan menghabiskan banyak waktu bergulat dengan bahasa dan tidak cukup waktu untuk menyelesaikan masalah bisnis.

Singkatnya, prinsip / abstraksi ilmu komputer, pola perangkat lunak, dan jenis masalah bisnis yang Anda temui, semua ini berubah perlahan. Anda dapat belajar satu kali dan mengumpulkan pengetahuan baru secara bertahap. Sebaliknya, bahasa komputer, kerangka kerja, yang disebut "ekosistem" dan pustaka komponen berubah sangat cepat seperti halnya semua alat yang mengelilinginya. Di sini diharapkan langkah belajar menjadi lambat dan memakan waktu!


-1

Apakah topik rumit seperti yang tercantum di atas (OpenGL, MySQL, situs html canggih) menjadi lebih mudah dibaca, ditulis, dan dipahami ketika Anda belajar lebih banyak, atau apakah itu semakin rumit saat Anda pergi? Bagaimana Anda bisa melawan perasaan ini bahwa Anda adalah semut di dunia pemrograman dan hal-hal ini akan menghancurkan Anda?

Ketika ada kemajuan, kami melepaskan dan belajar lagi apa yang kami pikir kami tahu sebelumnya. - Henry David Thoreau

Ada kisah tentang guru Zen dan Cangkir Teh yang Meluap .

Terkadang, kita perlu melepaskan gagasan dan pendapat kita yang sudah terbentuk sebelumnya dari masa lalu sehingga kita dapat membiarkan diri kita mempelajari konsep-konsep baru.

Ingat: Jika Anda merasa kewalahan oleh konsep baru, Anda perlu mencari banyak guru.

Baru-baru ini, ketika diberi tugas memperbarui beberapa perangkat lunak internal perusahaan yang menggunakan bahasa scripting saya tidak terbiasa dengan. Awalnya itu sangat menegangkan. Namun, setelah saya mengubah sikap, saya mulai menemukan sumber daya yang menjelaskan sintaks dan konsep dasar. Saya menyelesaikan proyek dan sekarang menggunakan bahasa skrip ini sebagai salah satu alat saya untuk menyelesaikan lebih banyak hal.

Sikap Anda membuat semua perbedaan.

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.