Apakah terlalu mengandalkan alat menyiratkan bahwa Anda malas? [Tutup]

29

Saya mulai pemrograman dalam C ++ di uni dan menyukainya. Dalam istilah berikutnya kami berubah menjadi VB6 dan saya membencinya.

Saya tidak tahu apa yang sedang terjadi, Anda seret tombol ke formulir dan ide menulis kode untuk Anda.

Sementara saya benci cara VB berfungsi, saya tidak bisa membantah bahwa itu lebih cepat dan lebih mudah daripada melakukan hal yang sama di C ++ sehingga saya bisa melihat mengapa itu adalah bahasa yang populer.

Sekarang saya tidak menyebut pengembang VB malas hanya mengatakan itu lebih mudah daripada C ++ dan saya perhatikan bahwa banyak bahasa baru mengikuti tren ini seperti C #.

Ini membuat saya berpikir bahwa semakin banyak bisnis yang menginginkan hasil cepat, lebih banyak orang akan memprogram seperti ini dan cepat atau lambat tidak akan ada yang namanya pemrograman sekarang. Pemrogram yang akan datang akan memberi tahu komputer apa yang mereka inginkan dan kompiler akan menulis program untuk mereka seperti di trek bintang.

Apakah ini hanya pendapat yang kurang terinformasi dari seorang programmer junior atau apakah programmer semakin malas dan kurang kompeten secara umum?

EDIT: Banyak jawaban mengatakan mengapa menemukan kembali roda dan saya setuju dengan ini tetapi ketika ada roda tersedia orang tidak repot-repot belajar cara membuat roda. Saya bisa google cara melakukan hampir semua hal dalam bahasa apa pun dan setengah bahasa melakukan banyak hal untuk Anda ketika datang untuk debugging mereka tidak tahu apa yang ada kode bagaimana memperbaiki kesalahan.

Begitulah cara saya memahami teori bahwa pemrogram menjadi lebih malas dan kurang kompeten karena tidak ada yang peduli bagaimana hal-hal bekerja hanya jika tidak sampai tidak.

Skeith
sumber
7
"Apakah ini hanya pendapat yang kurang terinformasi dari seorang programmer junior atau apakah programmer menjadi lebih malas dan kurang kompeten secara umum?" - ini bukan salah satu atau, keduanya benar (hanya bukan karena alasan yang Anda katakan).
Jon Hopkins
15
Bagaimana orang bisa menjawab ini tanpa menyangkal gelar?
Komentator: komentar dimaksudkan untuk mencari klarifikasi, bukan untuk diskusi panjang. Jika Anda punya solusi, tinggalkan jawaban. Jika solusi Anda sudah diposting, harap perbarui. Jika Anda ingin mendiskusikan pertanyaan ini dengan orang lain, silakan gunakan obrolan . Lihat FAQ untuk informasi lebih lanjut.
8
Mengapa ini tidak ditutup sebagai "subyektif dan argumentatif" ...?
BlueRaja - Danny Pflughoeft

Jawaban:

103

Tidak, pengembang tidak lagi malas atau kurang kompeten. Ya, ada kebutuhan terus menurun untuk pengembangan yang sebenarnya, dalam arti bahwa Anda mengetahuinya. Dan ya, ini sangat banyak karena bisnis menginginkan hasil yang cepat, dan mengapa tidak?

Namun, ada titik akhir. Akan selalu ada kebutuhan untuk beberapa pengembang.

Banyak persyaratan yang sama untuk berbagai proyek. Yang Anda bicarakan adalah kode UI. Sebagian besar UI terdiri dari kumpulan bidang tertentu - kotak teks, kotak centang, radio, pilih, dll. - dan benar-benar tidak ada gunanya mengembangkannya dari awal, berulang-ulang. Jadi lapisan abstraksi dimasukkan untuk mengambil semua kode boilerplate itu.

Demikian juga lapisan data, yang biasanya tidak lain adalah Sisipkan Ini, Hapus Ini, Ganti Ini dan sejumlah besar tampilan berbeda dari data yang sama. Mengapa terus menulis itu berulang kali? Mari kita ciptakan ORM.

Satu-satunya hal yang harus Anda kembangkan adalah kode yang unik untuk bisnis yang Anda kembangkan.

Tetapi akan selalu ada keunikan itu - di mana tidak ada, ada peluang bisnis - dan akan selalu ada kebutuhan bagi orang untuk menulis kode.

Semua yang dikatakan, juga diingat bahwa ada lebih banyak untuk menjadi pengembang daripada menulis kode. Apakah Anda mengkodekan dalam perakitan murni atau menyatukan komponen Drupal untuk membuat situs berbasis konten, Anda menerjemahkan kebutuhan bisnis menjadi sesuatu yang dipahami komputer.

Bagian terpenting dari menjadi pengembang perangkat lunak adalah mampu memahami persyaratan bisnis dengan cukup baik untuk menjelaskannya kepada komputer.

Tidak masalah apa bahasa yang Anda gunakan untuk menjelaskan sesuatu ke komputer, itu hanya masalah yang Anda bisa. Dan ini kerja keras, tidak ada yang malas.

pdr
sumber
3
Ada perbedaan antara menjadi pengembang dan programmer.
Raynos
9
+1. Persis. Perangkat lunak yang berfungsi adalah apa yang Anda bayar. Kode adalah sarana untuk membuat perangkat lunak, artefak. "Pemrograman" murni adalah bagian yang mudah dan menyenangkan dalam membuat perangkat lunak.
Joonas Pulakka
+1 untuk keseluruhan. Saya tidak yakin dengan "Satu-satunya hal yang harus Anda kembangkan adalah kode yang unik untuk bisnis yang Anda kembangkan." Tetapi saya akan mengakui bahwa itu adalah strategi bisnis yang valid.
SoylentGray
@Chad - Ambil poin Anda. Terkadang saya berbicara dalam bahasa hiperbola. Akal sehat selalu mengesampingkan filsafat, ketika sampai pada kegentingan, tetapi saya pikir ini adalah posisi yang baik untuk dibicarakan dari kasus per kasus, daripada mengambil posisi default "ya, mari kita tulis sendiri." :)
pdr
Sebagai bisnis, pertanyaan terbesarnya adalah, apa pengembalian investasi pada waktu yang Anda habiskan untuk mengembangkan solusi. Bos saya sama sekali tidak peduli bahasa apa yang saya kembangkan, selama saya bisa membantu perusahaan menghasilkan lebih banyak uang daripada yang saya bayarkan. Ada hal lain dan mereka kehilangan uang pada saya.
Dan Williams
38

Apakah mekanik malas dan kurang kompeten karena dia menggunakan kunci pas hidrolik ?

Bayangkan dua orang, katakanlah Brad dan Pete. Mereka berdua bekerja di dua garasi mengganti ban setiap hari. Brad adalah pria yang cerdas, dia tahu bahwa menggunakan alat yang lebih baik bisa menyelesaikan pekerjaannya dengan lebih baik dan lebih cepat. Menggunakan kunci hidrolik membantu dia mengganti lebih banyak ban. Pelanggan menunggu dalam antrian yang lebih pendek - semua orang senang. Bard juga tahu bahwa kunci pas ini terkadang terlalu besar dan tidak dapat membantunya dengan berbagai jenis sekrup.

Di sisi lain, Pete mengatakan bahwa kunci hidrolik adalah penghujatan dan Brad bukan "mekanik nyata". Tentu saja Pete hanya bisa melakukan setengah dari apa yang dilakukan Brad, tetapi ia melakukannya dengan "cara yang benar".

Sekarang bagaimana menurut Anda, pelanggan garasi mana yang akan memilih? Yang membutuhkan waktu 20 menit atau satu dengan 40 menit menunggu.

Ini sangat mirip dengan pemrograman. C ++ adalah bahasa yang baik dan memiliki tujuan (terutama kinerja). Yang saya sukai dari bahasa seperti C # adalah saya bisa fokus pada masalah, pikirkan algoritma tanpa semua noise yang C ++ suka dengan peringatan kompiler yang ambigu, perilaku yang tidak jelas dan lain-lain. Berkembang semakin dan semakin rumit bahwa di masa lalu mainframe dan PC pertama, namun otak manusia tetap sama - cukup bodoh. Satu aplikasi dapat berjalan di cloud, mobile, desktop ada banyak dependensi, masalah keamanan dan masalah lainnya. Saya ingin memiliki alat yang lebih baik untuk fokus pada masalah yang lebih rumit dan menyelesaikannya.

Gunakan alat yang lebih baik untuk menyelesaikan pekerjaan - tidak ada yang salah dengan itu.

lukas
sumber
1
Saya tidak berpikir analoginya bekerja karena baik Brad dan Pete masih akan tahu cara melepaskan ban, dan semua yang terlibat (dara, kunci pas, dan bir).
Kristofer Hoch
3
+1 Jawaban Hebat. Saya akan menambahkan bahwa apa pun alat yang Anda gunakan, jika Anda mengerti apa fungsinya, Anda akan melakukan pekerjaan Anda dengan benar. Di sisi lain, jika Anda tidak, tidak peduli berapa banyak pekerjaan yang dilakukan oleh alat ini, pada titik tertentu Anda akan mengacaukan sesuatu.
Jacek Prucia
1
@ Kristofer: Mungkin akan lebih baik jika Pete tahu beberapa barang elektronik. Sementara Brad hanya tahu cara menggunakan komputer diagnostik dan membacakan bahwa sensor O2 telah rusak, Pete melihat bahwa kawat sensor agak terbakar, mengeluarkan meter untuk mengukurnya dan menyadari bahwa regulator tegangan sudah tidak stabil dan membakar sensor O2.
Zan Lynx
@Bisa itu bukan hal yang sama. @ Kristofer hanya karena saya menggunakan perancang untuk menyeret kontrol ke elemen formulir dengan cepat dan menyelesaikan kode boilerplate tidak berarti saya tidak tahu bagaimana cara kemudian mengubah kode itu untuk melakukan apa yang saya inginkan sesudahnya.
jcolebrand
Cara sempurna untuk menjelaskannya.
riwalk
37

Jadi, apa yang kita panggil pemrograman sekarang

Kamu bilang:

Pemrogram yang akan datang akan memberi tahu komputer apa yang mereka inginkan dan kompiler akan menulis program untuk mereka seperti di trek bintang.

lakukan saja eksperimen: tonton star trek, dan cobalah menafsirkan hal-hal yang diperintahkan komputer untuk melakukan sedikit 'tanpa rasa malu'.

  • Teh, earl grey, panas -> banyak uap.
  • Teh, earl grey, 60 derajat celsius -> genangan air dan awan uap
  • earl grey, 60 derajat celsius -> genangan air
  • earl grey, 60 derajat celsius, dalam gelas -> gelas dengan setetes di dalamnya
  • earl grey, 60 derajat celsius, 0,2 liter, dalam gelas. -> akhirnya (ok, Anda mungkin ingin tahu lebih banyak)

Ketika Anda memanggil Pemrograman: 'Mengetahui tentang penggunaan memori, pointer, dll', ya, saya kira itu akan menjadi kurang penting (seperti 'Mengetahui tentang http, openid, unicode' akan menjadi lebih penting).

Tetapi, menurut pendapat saya bahwa semua adalah 'kompleksitas tidak disengaja', dan Pekerjaan sebenarnya sebagai programmer adalah 'Membuat mesin menyelesaikan masalah, dengan memastikan seseorang cukup memahami masalah tidak disengaja untuk mencapai tugas', dan menurut definisi itu, seseorang berbicara dengan komputer star trek perlu menjadi seorang programmer (yaitu memiliki kebajikan yang sama seperti sekarang).

keppla
sumber
2
@ Raynos: soooo benar. Terutama menyedihkan ketika orang-orang ini adalah pemimpin tim, dan membuat pedoman seperti 'ketika data yang dikirim kurang dari X byte, gunakan GET, saat lebih banyak, gunakan POST'
keppla
8
@keppla - Masalah Anda bukan karena pemimpin tim Anda tidak mengerti HTTP, itu karena ia tidak mau mengubah pendapatnya dengan bukti bahwa ia salah (dengan asumsi Anda mencoba menjelaskan sesuatu kepadanya). Anda tidak dapat mengetahui lebih dari semua orang yang bekerja untuk Anda tentang segalanya - kejahatan yang sebenarnya adalah tidak menerima bahwa orang lain tahu lebih banyak tentang sesuatu daripada Anda.
Jon Hopkins
3
"Tea, Earl Grey, Hot" adalah pemrograman deklaratif. Adalah tugas komputer untuk menemukan hasil yang relevan secara kontekstual berdasarkan harapan yang masuk akal. Menghasilkan uap dari "teh panas" dalam jenis bahasa ini akan menjadi kesalahan pada bagian tim desain komputer, bukan programmer. Seharusnya menggunakan kasus yang relevan secara kontekstual kecuali jika permintaan tertentu dimasukkan.
diadem
1
@Diadem: meskipun deklaratif, Anda harus tahu apa yang harus dinyatakan, dan sebagai seorang programmer, imho, Anda tidak akan berharap bahwa komputer dapat menebak dari masa lalu apa yang akan Anda lakukan selanjutnya, karena Anda akan melakukan yang baru. Antarmuka yang menginterpretasikan keinginan Anda adalah untuk pengguna akhir.
keppla
2
@ Zan Lynx: Mungkin contoh yang lebih baik: buat komputer memperingatkan Anda, setiap kali seseorang diculik (komputer sepertinya tidak peduli dengan itu di TNG). 'Komputer: beri tahu saya, ketika seseorang diculik' 'Tolong jelaskan diculik' 'Ketika dia diambil atas kemauannya' 'Tolong jelaskan akan', dll. Untuk memunculkan solusi seperti 'Beri tahu Petugas yang Bertanggung jawab ketika seseorang mengubah lokasi dari yang diketahui menjadi tidak diketahui, dan tidak ada catatan bahwa petugas transportasi menyinari dia atau dia masuk pesawat ulang-alik, dan kapal tidak di dermaga. ' Anda tetap membutuhkan programmer Mindset.
keppla
23

Programmer tidak semakin malas. Pemrogram selalu malas. Menjadi malas adalah bagian dari sifat dasar pekerjaan. Masalahnya adalah orang menganggap bahwa malas itu negatif. Menjadi seorang programmer "malas" adalah suatu kebajikan.

Ingat pepatah lama, "Bekerja lebih cerdas, bukan lebih keras." Ini adalah dorongan mendasar dari programmer.

Orang-orang yang membuat dan memprogram komputer pertama tidak melakukannya karena mereka suka melakukan kerja keras, mereka melakukannya untuk MENGHINDARI pekerjaan yang lebih sulit. (melakukan halaman perhitungan dengan tangan)

Menjadi 'malas' adalah salah satu alasan mendasar mengapa programer memprogram. Itu sebabnya kami menulis bahasa level baru dan lebih tinggi, debugger dan IDE yang lebih baik dan lebih baik, skrip shell dan build, dll ...

Seorang programmer melihat masalah, apa pun yang dia lakukan dan pikirkan;

"Bisakah saya mengotomatisasi ini?" , "berapa lama waktu yang dibutuhkan?" , "berapa banyak waktu yang akan menyelamatkan saya?"

Kami melakukan ini karena kami malas, kami tidak ingin melakukan tugas yang berulang dan membosankan ketika kami bisa melakukan hal-hal yang jauh lebih menyenangkan.

Jika programmer tidak malas maka tidak ada programmer yang pernah melihat kebutuhan untuk menulis satu bahasa baru atau kompiler.

Sejauh gagasan bahwa seorang programmer adalah "malas" karena ia harus "mencari sesuatu", jadi apa, siapa yang peduli. Asumsi bahwa lebih banyak bekerja untuk mempelajari setiap nuansa bahasa tertentu (dan tidak pernah harus mencari sesuatu) maka itu adalah untuk menemukan dan menggunakan apa yang Anda butuhkan ketika Anda membutuhkannya adalah kekeliruan. Selain itu, proses mencari hal-hal adalah proses belajar dan alasan mengapa situs seperti ini ada.

Jika seseorang ingin kerja pemrograman yang keras, saya akan memberitahu mereka untuk pergi kode tangan beberapa kode mesin mentah dalam hex. Sudah selesai? Ingin sesuatu yang lebih sulit? Sekarang lakukan debug itu.

Justin Ohms
sumber
19

Pertama-tama memanggil orang yang menggunakan misalnya bahasa dengan pemulung sampah malas, adalah jenis memanggil orang yang mengendarai mobil dengan malas transmisi otomatis. IMO itu agak konyol.

Adapun kompetensi, pemrograman adalah pekerjaan yang jauh lebih populer dan egaliter seperti dulu. Jadi ya, ada banyak pendatang baru, yang tidak memiliki pengetahuan. Namun saya tidak bermaksud, bahwa tiba-tiba ada programmer yang kurang kompeten. Bahkan ada lebih banyak. Anda hanya melihat sisi kurva lonceng yang salah.

vartec
sumber
11
Orang-orang yang mengendarai mobil malas, tidak ada yang konyol tentang itu. Manual dengan tumit-dan-jari kaki memberikan lebih banyak kontrol dan kinerja di luar mobil, tetapi membutuhkan banyak keterampilan dan kerja ekstra.
Coder
11
@Coder: "membutuhkan kerja ekstra" - di jalan raya tidak, dalam kemacetan lalu lintas tidak, tetapi kemudian tidak memberi Anda keuntungan.
vartec
2
Transmisi manual juga memberikan penghematan bahan bakar yang lebih baik di jalan raya, meskipun hal ini kurang benar dengan pengunci torsi pengunci.
Dave Markle
4
@Dave sebenarnya elektronik modern telah membuat otomatis sebenarnya lebih efisien rata-rata. Ford Fusion saya dengan opsi yang sama dinilai hampir satu mil penuh per galon lebih sedikit. Saya yakin ada saat-saat di mana manual masih lebih baik di mikro tetapi lebih dari semua otomatis memiliki petunjuk.
SoylentGray
3
@Coder - Jika Anda pikir mengendarai manual memerlukan "banyak keahlian", Anda perlu melihat-lihat ribuan driver yang tidak kompeten di jalan dengan transmisi manual. ;)
techie007
15

Saya tergoda untuk mengatakan, "ya, programmer junior yang tidak mendapat informasi telah menjadi malas dan kurang kompeten", tetapi mari kita coba jawaban yang serius:

Banyak hal menjadi lebih mudah, tetapi lebih banyak yang diharapkan dari kita. Saat ini saya sedang membuat aplikasi web yang memiliki banyak fitur yang biasanya ditemukan di aplikasi gui yang dibuat dengan baik (tampilan tab, kisi yang dapat diedit & diurutkan, ekspor Excel dll.). Alat yang saya gunakan (ExtJS dll.) Membuatnya cukup murah untuk membuat aplikasi seperti itu.

Sepuluh tahun yang lalu, hampir mustahil, setidaknya sangat mahal, untuk membuat aplikasi semacam itu. Tetapi sepuluh tahun yang lalu, bentuk HTML sederhana dengan tabel HTML sudah cukup bagi pelanggan. Hari ini, dengan upaya yang sama, hasil yang lebih baik (setidaknya lebih indah) adalah mungkin, dan pelanggan berharap untuk mendapatkannya!

Secara umum, pengembang perangkat lunak saat ini perlu mengetahui lebih banyak bahasa daripada pengembang perangkat lunak 20 tahun yang lalu. Saat itu, sesuatu seperti C dan SQL sudah cukup. Hari ini, saya menggunakan JavaScript, HTML, Groovy, Java, SQL semuanya dalam proyek yang sama.

user281377
sumber
+1 ya, programmer junior yang tidak mendapat informasi telah menjadi malas dan kurang kompeten
SoylentGray
12

Programer menjadi kurang kompeten dan malas dalam beberapa hal, tetapi lebih kompeten dalam hal lain, meskipun pembagian C ++ / VB bukanlah alasan atau gejala dalam pikiran saya.

Menggunakan pembangun GUI tidak malas, itu hanya berbeda, ini tentang alat untuk pekerjaan di tangan. Jika programmer assembler disebut programmer C ++ malas, Anda akan menyebutnya omong kosong (benar) dan hal yang sama berlaku untuk C ++ dan VB. VB memungkinkan Anda melakukan beberapa hal dengan cepat dengan mengorbankan kontrol. Hambatan untuk memulai pengkodean di dalamnya tentu lebih rendah tapi itu hal yang sangat berbeda dengan kemalasan - Anda hanya mempelajari hal-hal yang berbeda dan menerapkannya dengan cara yang berbeda. Pemrogram VB tidak lebih malas daripada pemrogram C ++ tidak produktif, mereka hanya bekerja dan berproduksi dengan cara yang berbeda.

Pada titik yang lebih luas, secara umum pendidikan programmer lebih baik sekarang daripada sebelumnya. Gagasan tidak menggunakan kontrol sumber misalnya cukup menjijikkan bagi hampir semua orang sekarang di mana 10 atau 20 tahun yang lalu yang tidak akan begitu benar. Demikian pula mereka lebih cenderung memahami dan ingin menggunakan pengujian unit otomatis, integrasi berkelanjutan dan sebagainya, jadi dalam hal itu mereka lebih kompeten daripada mereka sebelumnya.

Tapi apa yang saya pikir telah berubah adalah bahwa orang tidak lagi tahu bagaimana memecahkan masalah seperti dulu dan itu berlaku untuk hampir semua bahasa umum. Respons instan untuk masalah apa pun sekarang adalah Google dan sementara itu hebat dan bekerja 95% dari waktu, saya melihat terlalu banyak programmer yang tidak tahu apa yang harus dilakukan ketika tidak.

Bukannya mereka tidak memahami dasar-dasarnya (mereka tidak mengerti tapi itu sebenarnya bukan masalah besar), tetapi mereka tidak dapat memecahkan masalah sedemikian rupa sehingga mereka bahkan dapat mencari tahu fundamental apa yang mereka butuhkan untuk bisa mengatasi.

Pra-Google Anda tidak punya pilihan. Sumber daya Anda adalah tim Anda, beberapa lusin buku fisik yang mungkin Anda miliki aksesnya dan otak Anda. Pengaturan itu berarti bahwa jika Anda menemukan masalah kemungkinan Anda menyelesaikannya sendiri dari sesuatu yang dekat dengan kepala sekolah pertama sehingga Anda cukup pandai dalam hal itu atau cukup cepat menganggur.

Dan ini benar terlepas dari bahasa apa yang Anda gunakan. VB adalah level tinggi dan banyak menyembunyikan tetapi itu berarti bahwa ketika datang ke pemecahan masalah yang sebenarnya berarti ada lebih banyak yang Anda butuhkan untuk bekerja. Jika sesuatu tidak berhasil, Anda harus menjadi lebih kreatif dan bekerja lebih keras karena Anda kurang memiliki kendali. Sebagai seorang programmer VB (dan saya berbicara dari pengalaman) Anda tidak tahu kurang dari C ++ guys, Anda hanya tahu hal-hal yang berbeda tetapi Anda berdua tahu bagaimana menyelesaikan masalah.

Tetapi mungkin sulit untuk melihatnya sebagai kritik yang signifikan terhadap programmer saat ini, mereka tidak mengembangkan keterampilan karena mereka tidak membutuhkannya, tetapi itu adalah kelemahan dibandingkan dengan mereka yang mengambil keterampilan dari saat mereka diperlukan.

Jon Hopkins
sumber
jadi ketika tidak ada yang tahu apa itu algoritma atau bagaimana menerapkan struktur data karena mereka semua "program" dalam drag and drop IDE apakah mereka hanya menggunakan alat yang tepat untuk pekerjaan itu?
Skeith
@Skeith - Tergantung apa pekerjaannya tetapi jika menghasilkan perangkat lunak yang menyelesaikan masalah maka ya.
Jon Hopkins
1
@ Jon-Hopkins, saya akan mengatakan bahwa peningkatan besar-besaran dalam pemrograman tergantung Google ada hubungannya dengan sejumlah besar API yang kita butuhkan saat ini. Terlalu sulit untuk melacak semuanya. (Tapi, pada intinya, Anda benar)
Jarrod Nettles
1
@Skeith - Membangun UI membutuhkan sekitar 5% dari rata-rata waktu pengembang aplikasi. Menurut Anda apa yang mereka lakukan 95% lainnya? Perancang tidak banyak membantu dengan kode backend. Anda jelas menyerang seorang pria jerami. Kebanyakan orang tahu alat yang mereka butuhkan untuk pekerjaan mereka, atau mereka tidak akan dipekerjakan.
Morgan Herlocker
@Skeith: Apakah pengguna basis data perlu peduli tentang cara mengimplementasikan basis data? Tentu saja tidak; pengguna basis data menggunakannya . Mereka mungkin perlu mengetahui beberapa perincian, sehingga mereka dapat mengoptimalkan database mereka, tetapi mereka tidak harus dapat mengimplementasikannya agar layak menggunakannya. Juga, seorang programmer mungkin tidak tahu apa arti kata "algoritma", tetapi itu tidak berarti mereka tidak menulisnya . Saya mengembangkan dan mengimplementasikan algoritma jauh sebelum saya mendengar istilah itu.
Nicol Bolas
11

Saya perhatikan dari profil Anda bahwa Anda berusia 23 tahun. Biarkan saya memasukkan gigi saya dan memberi Anda perspektif dari seseorang sekitar dua kali usia Anda yang telah melakukan ini sejak lama:

Dulu ada jauh lebih sedikit dari semuanya, dimulai dengan daya komputasi, penyimpanan dan bandwidth jaringan, jika Anda memiliki jaringan sama sekali. Kelangkaan-kelangkaan itu membatasi apa yang dapat Anda lakukan secara wajar, membuatnya lebih mudah untuk membungkus kepala Anda dengan segala sesuatu. Perangkat lunak yang kami jalankan hari ini jauh lebih mampu daripada hal-hal yang saya kerjakan 25 atau 30 tahun yang lalu, dan kemampuan itu berarti ada lebih banyak lagi. Itu membuat mengumpulkan pemahaman yang baik tentang segala sesuatu jauh lebih sulit untuk dilakukan oleh satu orang. Sebagian dari itu berkaitan dengan fakta bahwa segala sesuatu akan terus meningkat dalam kompleksitas dan sebagian lagi berkaitan dengan efek samping dari usia.

Ekosistem komputasi menjadi sangat mirip dengan sistem biologis: manusia lebih kompleks daripada organisme bersel tunggal, dan sebagian dari kita harus mengkhususkan diri jika kita ingin melakukan sesuatu dengan baik. Sel-sel otak saya sangat bagus dalam hal-hal yang cerdas, tetapi akan hilang jika dimasukkan ke dalam ginjal saya dan diharapkan untuk melakukan hal-hal ginjal. Demikian pula, orang yang pandai menulis prosesor sinyal digital mungkin tidak tahu bagaimana pengindeksan teks lengkap bekerja, karena itu bukan keahliannya. Tetapi keduanya dapat berkembang sedikit dan belajar untuk memahaminya jika mereka perlu, tetapi ada batasan seberapa jauh Anda dapat menyebar sendiri dan tetap efektif pada apa yang Anda lakukan.

... tidak ada yang peduli bagaimana hal-hal berfungsi hanya jika ia berfungsi sampai tidak.

Ketika Anda memiliki pekerjaan untuk dilakukan, Anda sering harus mengambil lompatan keyakinan bahwa alat yang Anda gunakan (perpustakaan, RDBMS, seluruh subsistem, dll.) Berfungsi sebagaimana mestinya. Salah satu hal yang dibawa pengalaman adalah kemampuan untuk memilih lubang kelinci mana yang akan Anda gunakan untuk menemukan kegagalan pada alat Anda, memperbaiki masalah dan kemudian kembali ke apa yang Anda lakukan.

Sekarang saya tidak menyebut pengembang VB malas hanya mengatakan itu lebih mudah daripada C ++ dan saya perhatikan bahwa banyak bahasa baru mengikuti tren ini seperti C #.

Itu semua masalah perspektif. Saya sekitar untuk melihat C ++ muncul, dan mengikuti tren itu juga. C ++ membuat segalanya lebih mudah daripada C, C membuat banyak hal lebih mudah daripada perakitan dan perakitan membuat segalanya lebih mudah daripada menulis opcode dengan tangan. Sebagai seseorang yang menulis banyak perakitan dan mengumpulkan beberapa hal dengan tangan dari awal, itu akan menempatkan Anda, sebagai programmer C ++, tiga langkah di jalur "lebih mudah".

Blrfl
sumber
1
+1 menunjukkan bahwa ini masalah perspektif. Saya sekitar ketika UNIX pertama kali keluar dari Bell Labs dan ada banyak 'tsk tsk'ing bahwa bahasa tingkat tinggi seperti' C 'sedang menenggelamkan seni kuno dan esoterik penulisan sistem operasi, dan ini pasti akan mengarah pada tidak baik. Seiring alat kami menjadi lebih baik dan mengurus pembukuan yang lebih tidak bijaksana bagi kami, kami dapat menggunakan waktu yang dihemat untuk mengatasi masalah yang lebih sulit, dan lebih halus.
Charles E. Grant
6

Sesuatu yang telah saya pertahankan sejak lama adalah:

Salah satu kekuatan terbesar dari Visual Basic Language adalah bahwa seorang pemula dapat belajar untuk melakukan banyak hal berguna dengan cukup cepat.

Salah satu kelemahan terbesar dari Pemrogram Visual Basic adalah bahwa mereka akan belajar untuk melakukan banyak hal berguna dengan cukup cepat, dan kemudian mereka akan berhenti belajar apa pun.

Ketika saya akan mengajarkan pemrograman latihan pertama, hari pertama kelas adalah bagaimana membangun aplikasi di NOTEPAD dan mengompilasinya menggunakan VCC atau VBC. Ya, ini adalah hal-hal yang kami (sebagai programmer) tidak lakukan setiap hari, tetapi harus memahami apa yang terjadi ketika kami menekan "F6".

Programmer tidak (umumnya) mendapatkan 'malas' sebanyak yang kami harapkan untuk mendapatkan lebih banyak dari alat kami. Saya tidak perlu mengetik "get / set" 10.000 kali sehari, saya suka Visual Studio dan alat-alat lain seperti Code Smith dan Resharper bekerja bagi saya untuk melakukan apa yang sudah saya tahu bagaimana melakukannya sehingga saya dapat menerapkan upaya saya untuk mencari tahu bagaimana melakukan hal-hal "baru". Itu tidak membuat saya malas, itu membuat saya "inovatif".

Sebagai pengembang profesional, kita tidak boleh 'membuang-buang waktu' untuk menciptakan kembali roda tetapi kita harus memahami dengan jelas apa yang membuat pembuatan roda akan kita gunakan. Ini adalah hal-hal yang 'harus' kita pelajari sebagai pengembang siswa (tapi sayangnya, seringkali tidak). Jika pengembang tidak memahami beberapa teknologi "kotak hitam" apakah itu benar-benar membuat mereka kurang "kompeten". Kebanyakan pengembang hanya 'pada dasarnya memahami' cara kerja driver ODBC, mereka hanya memahami 'apa' yang dilakukannya. Apakah saya harus tahu cara kerja transmisi untuk menjadi pengemudi yang kompeten? Saya akan mengatakan tidak. Apakah itu membuat saya pemilik mobil yang lebih kompeten untuk mengetahui hal ini, ya.

Cos Callis
sumber
4

Kebutuhan untuk Pengembangan Aplikasi yang Cepat (tautan wiki wajib: http://en.wikipedia.org/wiki/Rapid_application_development ) berarti bahwa pengembang menulis lebih sedikit kode dan pengembang baru kurang memahami, karena mereka tidak perlu memahami cara menerapkan daftar tertaut karena mereka punya sesuatu yang lebih tinggi untuk fokus

Saya tidak bisa menangkap, membunuh, menguliti, memotong daging, dan menyembuhkan daging, dan saya ragu orang di kafe di lantai bawah bisa, tetapi saya masih mendapatkan sandwich daging asap darinya, seperti halnya para pebisnis mendapatkan aplikasi mereka dari pengembang yang tidak tahu tentang pointer (seperti saya!)

StuperUser
sumber
4

Dikatakan bahwa disiplin ilmu yang hebat adalah contoh dari raksasa yang berdiri di atas bahu raksasa lain. Juga dikatakan bahwa industri perangkat lunak adalah contoh dari cebol berdiri di atas jari cebol lainnya.
- Alan Cooper

Pengembang perangkat lunak yang baik bukanlah orang yang menemukan kembali roda. Ia mampu menggunakan alat yang telah dibangun sebelumnya. Dia tidak membuang waktu untuk menulis ulang hal-hal membosankan yang sama, yang telah ditulis ratusan kali, menjadi melelahkan dengan cepat dan mungkin sudah ada dalam versi kualitas yang lebih tinggi di luar sana.
Jika Anda memberi mereka bahasa yang sudah memiliki disk bundar batu bundar, kemungkinan bagus mereka tidak menghabiskan terlalu banyak waktu untuk menciptakan kembali roda. Jika saya mendapat sen untuk setiap rutinitas penyalinan string yang pernah ditulis dalam C, saya mungkin bisa membeli seluruh industri perangkat lunak.

Sebenarnya kemalasan adalah salah satu dari tiga kebajikan utama seorang programmer. Alat yang Anda bicarakan dibangun oleh programmer yang baik untuk programmer yang baik, untuk mengurangi redundansi dan kebosanan dan dengan demikian meningkatkan produktivitas dan motivasi. Alat tersebut dapat sebenarnya memiliki efek negatif pada pemula, karena mereka menghambat pemahaman yang lebih dalam aspek pemrograman mereka menyederhanakan.

back2dos
sumber
4

Tidak. Kamu semakin tua.

Tidak bercanda, apa yang Anda alami adalah semacam hak lintas bagi pengembang. Telah sejak bahasa tingkat tinggi pertama digantikan majelis. Saat itu Anda akan mendengar semua programmer ASM mengeluh tentang hal yang sama. 5 tahun dari sekarang, semua devs Ruby on Rails akan mengeluh tentang betapa malasnya alat baru lainnya menghasilkan orang.

Pengulangan ini akan diulang sampai mesin menghancurkan kita semua: "Apakah sepertinya teknologi X membuat pengembang lebih malas dan lebih buruk daripada teknologi Z yang selalu saya gunakan?"

Kabar baiknya adalah, meskipun kompiler telah datang jauh, orang masih membutuhkan perakitan dan C dan semua pendukung lama lainnya untuk banyak hal ... hanya saja tidak mayoritas inovasi teknologi canggih. Jika Anda ingin menjadi yang terdepan, saya sarankan Anda memperbarui keahlian Anda.

DougW
sumber
+1: "Anak-anak malas hari ini dengan kereta, busur, dan panah mereka. Ketika saya masih kecil, kami berperang dengan pedang pendek, dan berjalan ke dan dari medan perang. Dan itu menanjak dua arah." - Xerxes I, Kaisar Persia, 473 SM
Bob Murphy
3

Dari pengalaman saya, ya dan tidak, tapi itu bukan kesalahan bahasa; itu kesalahan pengembang sendiri. Saya telah bekerja dengan banyak pengembang yang tidak peduli melakukan hal yang benar, meningkatkan diri, atau benar-benar melakukan apa pun selain mengaduk-aduk omong kosong yang sama yang telah mereka lakukan selama bertahun-tahun. Mencoba membuat orang-orang ini meningkat adalah seperti berbicara dengan tembok bata - separuh waktu mereka tidak tahu apa-apa yang belum pernah mereka gunakan di masa lalu atau sama sekali tidak mau "mengambil risiko" dengan sesuatu yang dapat meningkatkan produktivitas mereka .

Bahasa yang lebih maju bukanlah masalah, programmerlah yang tidak memperlakukan profesi ini sebagai keahlian yang terus berkembang. Anda tidak harus secara sadar menyadari segala sesuatu yang baru, atau melompat pada setiap kereta musik baru, tetapi Anda setidaknya harus mencoba untuk menjadi lebih baik pada apa yang Anda lakukan.

Sebagai contoh konkret: Saya seorang pengembang .NET berdasarkan perdagangan Saya mengharapkan pengembang .NET yang kompeten untuk mengetahui hal-hal seperti LINQ, Entity Framework, WPF, MVC dan sejenisnya; mereka tidak harus menggunakannya, atau mendorongnya di tempat kerja, tetapi setidaknya pemahaman yang lewat tentang "Ini ada" lebih baik daripada ketidaktahuan mutlak yang saya lihat terlalu sering.

Wayne M
sumber
2

Saya hanya mengkode selama 4 tahun dalam pekerjaan sekarang dan itu hampir seluruhnya c #. Saya memang belajar C ++ ketika di College dan Uni tetapi saya tidak akan bisa berbuat banyak dengan itu sekarang.

Jadi untuk pengembangan GUI, itu bisa dilihat sebagai malas, tetapi sekali lagi tidak dapat dilihat bahwa Anda dapat kurang fokus pada pengkodean bagian itu dan lebih pada pengembangan logika aplikasi itu sendiri.

jadi mungkin daripada menjadi kurang kompeten mereka bergerak fokus, mungkin banyak ke arah komunikasi dan sistem terdistribusi misalnya komputasi awan dan SOA. Meskipun ini bisa saja pemikiran yang sama dari programmer menengah juga.

Kioshiki
sumber
2

Mungkin benar bahwa penghalang untuk masuk dalam pekerjaan pemrograman telah semakin rendah setiap tahun. Misalnya, sekarang mungkin bagi para insinyur yang spesialisasinya bukan perangkat lunak dan artis untuk menulis kode menggunakan bahasa scripting.

Ini menyiratkan bahwa tingkat kompetensi sebenarnya telah meningkat, jika Anda mempertimbangkan luasnya. Bahwa seniman dapat memprogram juga berarti sekarang ada lebih banyak programmer dengan keterampilan artistik.

Joh
sumber
1
dengan kompetensi yang saya maksud pemrograman, semua keterampilan lain tidak relevan kecuali matematika.
Skeith
3
@Skeith - "dengan kompetensi yang saya maksud pemrograman, semua keterampilan lain tidak relevan kecuali matematika" - ini sangat salah. Salah satu peningkatan terbesar dalam industri dalam 30 tahun terakhir adalah bahwa keterampilan komunikasi sekarang dipahami sebagai kunci mutlak. Beri saya seorang programmer yang pada dasarnya kompeten dengan keterampilan matematika yang hebat atau yang memiliki keterampilan komunikasi yang hebat dan dia adalah orang dengan keterampilan berkomunikasi setiap saat.
Jon Hopkins
+1 @ Jon - Sepenuhnya setuju. Programmer yang tidak berbicara kepada pelanggan dalam hal apa pun kecuali kalkulus lambda dan sup alafabet tidak berharga pada sebagian besar porjects.
Morgan Herlocker
1
@Skeith: Jadi, Anda hanya perlu tahu pemrograman dan matematika untuk menjadi programmer yang baik? Kamu berada di dunia apa? Anda perlu tahu tentang cara menggunakan komputer, cara berkomunikasi dengan pelanggan dan programmer lain, cara menulis dokumen, dll. Apa yang tidak perlu Anda ketahui adalah matematika. Tentu, ada beberapa tumpang tindih antara matematika dan pemrograman, tetapi hanya mengetahui bagian pemrograman sudah cukup.
Martin Vilcans
Ketika saya masih kuliah saya mengambil kelas kalkulus bisnis. Pada final, saya selesai pertama dan mendapat 100 (guru menilai saya di sana - dia terkesan saya menyelesaikan dengan cepat begitu cepat). Namun sebagai pengembang perangkat lunak saya menggunakan nol matematika. Apa yang saya gunakan adalah logika untuk memahami domain bisnis, dan saya menggunakan karisma untuk berinteraksi dengan orang-orang. Bahasa pemrograman telah cukup berkembang sehingga jika Anda dapat menulis bahasa Inggris dengan baik, Anda dapat membuat kode dengan baik. Peringatan: menulis bahasa Inggris dengan baik lebih sulit daripada pemrograman, karena Anda memprogram wetware berbasis DNA ..
Christopher Mahan
2

Ada perbedaan antara "programmer" dan "programmer nyata". Tolong jangan menyebut HTML bahasa pemrograman, tetapi ada banyak "programmer HTML". Anda masing-masing (programmer / pengembang) dapat membuat pengalaman dengan kolega - cukup "matikan Internet (sebenarnya tidak mengizinkan mereka menggunakan mesin pencari)", dan Anda akan melihat bahwa beragam "programmer" akan duduk tanpa pekerjaan. Apa yang dapat mereka lakukan, mereka hanya tahu bahwa jika mereka perlu, misalnya, mencari dalam teks, mereka harus "mencari 'pencarian teks dalam% language_name%'"? Mereka tidak dapat menjawab ini - apa perbedaan dalam algoritma Boyer-Moore dan Knuth-Morris-Pratt.

Jadi, IMO, pemrograman berarti menyelesaikan masalah, mengetahui dengan sangat baik minimal satu bahasa pemrograman dengan 'STL' dan hal-hal penting lainnya. Pemrograman adalah seni, adalah semacam kehidupan, itu bukan hal yang bisa dilakukan oleh semua orang.

Maaf untuk sarkasme lebih dari yang dibutuhkan, tapi saya pikir artikel ini mengatakan lebih baik daripada saya

Apakah aku salah?

UPD: Yang utama dan penting adalah pengetahuan dasar-dasarnya, seperti algoritma, struktur data dll. Berapa banyak dari Anda yang dapat mengimplementasikan perpustakaan / fungsi standar / dll jika seandainya hari ini akan dihapus secara tidak sengaja? IMO, programmer harus menggunakan kode 'alien' yang dikembangkan / di-debug baik (libraries / frameworks / etc), tetapi harus bisa menemukan kembali roda, selalu!

Dehumanizer
sumber
6
Satu-satunya masalah saya dengan ini adalah bahwa saya telah bekerja sebagai programmer (programmer yang tepat, bukan web / HTML / script) selama 20 tahun dan tidak tahu tentang algoritma Knuth-Morris-Pratt. Bagi kebanyakan programmer, teori semacam ini tidak berdampak pada kehidupan mereka sehari-hari karena hal ini dibundel dalam perpustakaan.
Jon Hopkins
2
Perpustakaan standar tempat saya bekerja memiliki ribuan kelas dan ratusan ribu baris kode. Apakah Anda mengatakan saya harus dapat menerapkan kembali semua itu tanpa dokumentasi? Jika tidak, Anda perlu mengklarifikasi seberapa besar sesuatu yang bisa didapat sebelum berhenti menjadi roda.
Peter Taylor
6
Manusia tidak memiliki umur yang diperlukan untuk mempelajari cara menemukan kembali semua roda yang ditemukan sejauh ini, atau belajar bagaimana menciptakan kembali roda yang sedang ditemukan saat ini .
Macke
3
@Dehumanizer: Mudah-mudahan saya akan dilatih dan memiliki lebih dari satu kompiler C di tangan saya untuk menyelamatkan dunia, kalau tidak saya akan mengacaukannya. (BTW Mengapa bahkan kompiler C? Mengapa tidak hanya USB-stick, osiloskop dan baterai 9V? Serius ....)
Macke
1
Matikan kompiler mereka dan Anda akan melihat kebanyakan orang hanya duduk sambil programmer NYATA mengetikkan kode mesin langsung ke file!
Philip
1

Mengenai VB yang mudah digunakan, dan programmer malas memilih VB karena itu:

Saya pikir VB dikelilingi oleh satu mitos besar tentang mudah digunakan. Mitos ini awalnya agak benar: pada masa sekitar 1991-1994 ketika dinosaurus berjalan di bumi, hanya ada dua alat RAD nyata di sekitar, VB dan Delphi. Mereka sangat mirip, tetapi CATATAN INI: Delphi dan VB sama-sama mudah digunakan! Satu-satunya perbedaan penting di antara mereka adalah bahwa VB memiliki sintaks yang sepenuhnya tidak logis dan menghasilkan program yang sangat lamban.

C / C ++ GUI ditulis dalam MFC atau dalam Win API mentah. Jadi VB tentu lebih mudah digunakan daripada alternatif Microsoft. Kemudian rumor berjalan seperti ini:

  • VB lebih mudah digunakan daripada Microsoft C / C ++ / Win API. ->
  • VB lebih mudah digunakan. ->
  • VB mudah digunakan. ->
  • VB adalah yang termudah.

Rumor ini kemudian hidup terus, meskipun Delphi selalu sama mudahnya, jika tidak lebih mudah, karena Pascal adalah bahasa yang waras dan logis.

Kemudian pada akhir 90-an Borland merilis C ++ yang setara dengan Delphi: C ++ Builder. Sekarang ada 3 alat yang sama mudahnya. Sekitar waktu ini, beberapa argumen rasional yang tersisa untuk menggunakan VB mati. Namun mitos tetap hidup. "VB adalah yang termudah".

Kemudian Java datang dan ada beberapa alat RAD untuk itu (dan untuk versi kegagalan Microsoft yang disebut J ++). Namun mitos VB terus hidup.

Kemudian Microsoft membuat dukungan RAD untuk C ++ juga, dan juga datang dengan C #, memanggang semuanya menjadi satu goo besar yang disebut .NET. Karena mitos VB masih hidup, mereka mampu menipu pengembang VB lama untuk menggunakan VB.NET alih-alih C ++ atau C #. Meskipun VB.NET cukup tidak kompatibel dengan versi VB sebelumnya.

Saat ini, VB adalah bahasa yang sepenuhnya berlebihan. Alat RAD tidak lebih mudah daripada alat RAD lainnya. Sintaks bahasa benar-benar mengerikan, begitu buruk sehingga sebenarnya mendorong desain program yang buruk dan praktik pemrograman yang buruk.

pengguna29079
sumber
terima kasih sekarang saya bisa terdengar lebih dibenarkan dalam kebencian saya terhadap VB dengan menambahkan alasan
Skeith
1

Ada berbagai macam kegiatan yang disatukan di bawah panji "pemrograman", dan semakin banyak pekerja yang terlibat di ujung "teknisi". Anda tidak perlu bisa menulis kompiler, atau bahkan memilih dari antara serangkaian algoritma untuk memecahkan masalah tertentu untuk menyusun situs web dalam PHP. Industri / masyarakat membutuhkan banyak orang yang memproduksi situs web tersebut (tampaknya), dan juga sejumlah pemrogram yang menangani masalah yang lebih sulit. Kelompok kedua itu tidak malas atau tidak kompeten, secara keseluruhan, atau pesawat kita akan terbakar, ATM mengirimkan uang tunai dalam jumlah acak, mesin X Ray memberikan dosis radiasi yang fatal, pasar keuangan mengalami kekacauan dll. Tunggu sebentar, lupakan tentang yang terakhir :-)

Jaybee
sumber
1

Satu sisi dari hal ini yang saya pikir semua jawaban lain hanya melihat sekilas adalah bahwa ini hanyalah tren umum dari bahasa tingkat rendah ke bahasa tingkat tinggi.

Ya, industri perangkat lunak bergeser dari bahasa tingkat rendah ke bahasa tingkat tinggi, selalu ada, dan mungkin akan terus melakukannya selama kita membangun alat yang lebih baik. Ya, ini bisa dianggap malas, karena Anda harus bekerja sangat keras untuk melakukan hal-hal yang mendasar menurut standar saat ini. Tapi saya tidak akan mengatakan kurang kompeten. Kompetensi hanya bergerak dari implementasi ke desain.

Level Rendah Ini agak subyektif, tetapi pada level rendah, Anda bekerja lebih dekat dengan perangkat keras. Ada lebih sedikit pegangan tangan dan asumsi niat. Alat dasar disajikan dan menyelesaikan pekerjaan diserahkan kepada programmer. Bahasa tingkat rendah datang pertama tentu saja, dan biasanya alat penjaga lama karena bahasa tingkat yang lebih tinggi tidak ada ketika mereka mulai. Akan selalu ada pengembangan tingkat rendah. Tapi saya tidak akan membuat situs web dalam perakitan.

Tingkat tinggi Tujuan di tingkat tinggi adalah untuk mengotomatiskan fungsi dasar dan membuat pemrograman lebih sederhana. Ini menurunkan bar untuk entri untuk programmer baru, menyelesaikan pekerjaan lebih cepat, dan menstandarkan bagaimana kita merepresentasikan dan memproses data, seringkali dengan overhead. Pertimbangkan sebuah string. Pada hari-hari awal, seseorang mungkin menggunakan 1-26 untuk az, dan hanya menggunakan 5 bit dan hanya harus tahu ukuran kata-katanya. Kemudian standar ascii dikembangkan dan kami memiliki string C dengan karakter terminator. Sekarang kita memiliki objek yang menangani hal-hal untuk menghindari buffer overflows dan subtipe khusus yang melarang karakter melarikan diri. Atau satu lingkaran. Loop "untuk" adalah level yang sedikit lebih tinggi daripada loop "sementara". Dan loop "sementara" sebenarnya hanyalah representasi dari cara terstruktur memanggil GOTO.

Juga,

Pemrogram yang akan datang akan memberi tahu komputer apa yang mereka inginkan dan kompiler akan menulis program untuk mereka seperti di trek bintang.

Selamat datang di masa depan! Itulah yang dilakukan oleh kompiler. Di masa lalu orang harus menulis kode mesin dengan tangan. Sekarang kami telah mengotomasi itu dan cukup beri tahu komputer bagaimana menulis kode mesin untuk kami.

Philip
sumber
1

Saya pikir di suatu tempat di sepanjang jalan Anda lupa tentang apa yang dibayar programmer untuk dilakukan.

Hasil pengiriman kami bukan Kode, ini adalah perangkat lunak yang berfungsi.

Kami tidak membangun furnitur di mana potongan tangan entah bagaimana memberikan nilai ekstra karena semua "keahlian" manual yang masuk ke dalamnya.

Kami dibayar untuk menyelesaikan masalah bisnis di komputer). Jika Anda dapat memberikan produk yang sama dalam waktu lebih sedikit dengan lebih sedikit uang, maka saya pikir itu adalah KEWAJIBAN kami untuk membatalkan kepura-puraan bahwa program-program C ++ lebih unggul hanya karena mereka lebih kompleks untuk dibuat.

JohnFx
sumber
* itu adalah perangkat lunak bengkak, (kadang-kadang)
kagali-san
0

Rasio (pengembang program inti / jumlah pengembang) menurun karena:

  • Alat semakin mudah, ini berarti dibutuhkan talenta yang lebih kecil untuk masalah yang sama

  • Orang-orang mulai terbiasa dengan teknologi IT, ini lebih bersedia mengeluarkan uang untuk alat yang disesuaikan

  • Literatur Ilmu Komputer tumbuh secara eksponensial, spesialisasi dan pembagian kerja meningkat sehingga tidak ada lagi orang "Aristoteles" yang berbicara tentang segala sesuatu (sebenarnya mereka tidak perlu mengetahui segalanya karena lapisan abstraksi)

  • Lebih banyak pekerjaan yang ditawarkan, filter dilonggarkan

  • Lebih banyak otomatisasi diperlukan pada setiap siklus kehidupan, permintaan meningkat dan pasokan tidak cukup

  • Rasio pengembang terhadap populasi meningkat.

    Jadi orang tidak semakin malas dan kurang kompeten, rata-rata jatuh karena komputasi adalah area yang lebih terbuka sekarang.

oguzalb
sumber
0

Banyak jawaban yang mengatakan mengapa menemukan kembali roda dan saya setuju dengan ini tetapi ketika ada roda tersedia orang tidak repot-repot belajar cara membuat roda.

Anda merongrong seluruh titik Anda melalui fakta bahwa entah bagaimana, roda masih bisa dibuat. Saya mengerti maksud Anda, tetapi saya perhatikan bahwa dalam disiplin apa pun, ada cukup banyak orang yang tertarik pada hal-hal tingkat rendah untuk mempertahankannya. Misalnya, saya menggunakan Qt untuk membangun GUI. Alat itu tidak datang dengan sihir, orang-orang mengembangkan hubungan antara hal-hal tingkat rendah dan hal-hal yang saya lakukan. Apakah lebih sedikit orang yang memahami hal-hal tingkat rendah, ya. Lebih sedikit orang juga dapat membunuh makanan mereka sendiri atau memperbaiki mobil mereka sendiri, tetapi masyarakat berhasil selamat.

Kesempatan
sumber
0

Sebelum 1940-an komputer adalah sirkuit kabel keras. Kemudian Von Neuman datang dengan ide untuk lokasi memori yang tersimpan. Saya yakin para programmer di MIT itu berpikir ia akan menurunkan perdagangan mereka menjadi sesuatu yang terlalu mudah. Kemudian datang perakitan, lalu datang FORTRAN, lalu ada, lalu C, lalu c ++, lalu java dan sebagainya. Intinya adalah, titik bahasa adalah untuk memungkinkan abstraksi lebih jauh dan lebih jauh. Itu selalu menjadi tujuan dan itu adalah alasan yang membuat c ++ dan kemudian java setelah itu. Daging sapi terbesar saya adalah bahwa Universitas tidak lagi mengajarkan siswa tentang komputer. Saya tidak menyewa programmer c # jika mereka tidak tahu c ++ seperti punggung tangan mereka sendiri. Mengapa? Karena terlalu mudah untuk menjadi programmer yang buruk semakin abstrak bahasa menjadi. Mereka perlu memahami pointer, manajemen memori, pengikatan dinamis dll. . dalam dan luar sebelum mereka bisa memahami C # ke tingkat yang saya percayai mereka berkontribusi pada basis kode kami. Saya juga membuat mereka kesulitan membuat file sebelum saya mengizinkan mereka menggunakan Visual Studio. Yang mengatakan, saya suka C # dan IDE yang bagus, tetapi mereka bagus sebagai alat ketika mereka dipahami dengan benar. Menurut pendapat saya, abstraksi paling berguna ketika Anda memahami rincian yang sedang diabstraksi - itu ide yang sangat lama, lihat Thomas Aquinas tentang hubungan Abstraksi dengan rincian.

Saya pikir latihan lain yang bagus untuk pengembang entry level adalah membuat mereka menulis beberapa aplikasi menggunakan Windows API. Kemudian, setelah mereka menyelesaikannya, minta mereka membuatnya berorientasi objek di mana setiap bentuk mewarisi dari kelas jendela umum Anda. Minta mereka merangkum loop acara dan menempatkan beberapa pointer fungsi menembak kembali ke kelas bentuk mereka. Lalu katakan pekerjaan yang baik, Microsoft sudah melakukan ini untuk Anda, yang disebut System.Windows.Forms. Selamat bersenang-senang.

Jika mereka ingin menjadi pengembang web, minta mereka menulis beberapa program CGI sehingga mereka memahami POST, DAPATKAN dll ... dan kemudian menulis halaman. Itu membuat ASP.NET dan PHP jauh lebih masuk akal.

Jika mereka mengerjakan sesuatu yang levelnya lebih rendah di jaringan, buat mereka menulis beberapa aplikasi menggunakan soket sebelum memperkenalkannya ke perpustakaan yang sudah melakukannya.

Saya telah menemukan bahwa ini meningkatkan produktivitas dalam jangka panjang karena memberi mereka alat dan intuisi yang benar untuk menyelesaikan masalah mereka sendiri.

Universitas seharusnya melakukan ini, tetapi tidak demikian halnya dengan kita.

Yang mengatakan, saya setuju bahwa semakin sulit untuk menemukan programmer yang sangat berharga keluar dari perguruan tinggi, terutama karena mereka tidak disingkirkan oleh dipaksa untuk menulis algoritma rekursif dan daftar terkait. Juga, mereka biasanya hanya memiliki program Java atau .NET dan karena itu tidak mengerti apa-apa tentang cara mereka bekerja. Meski begitu, abstraksi ini cukup berguna saat digunakan dengan benar.

Jonathan Henson
sumber
0

(..) Cepat atau lambat tidak akan ada yang namanya pemrograman sekarang

Saya tidak setuju dengan hal ini.
Tanpa mengetahui apa itu kesadaran, pekerjaan programmer itu aman.

Beginilah "mesin berpikir" terlihat saat ini:

-Hentikan mengubah topik pembicaraan!
-Saya pikir cinta kami istimewa.
-Hentikan mengubah topik pembicaraan!
-Aku tidak akan mengubah topik pembicaraan.
-Kamu adalah! Saya mencoba berbicara tentang ketidakmampuan Anda untuk memahami apa yang sedang kita bicarakan.
-Tidak bahkan tidak dekat. Lagu beatles favorit saya ada di seberang jagat raya. apa milik anda?

Saya percaya bahwa hanya para programmer yang tidak mendapatkan poin ini yang akan dihukum.

Misalnya jawaban Dehumanizer`s :

Mereka tidak dapat menjawab ini - apa perbedaan dalam algoritma Boyer-Moore dan Knuth-Morris-Pratt.

Dan dengan "titik ini" yang saya maksud - salah untuk mencoba mengalahkan komputer dengan apa yang terbaik - algoritma. Sebaliknya programmer seharusnya membantu komputer dengan konteks, menceritakan tentang masalah yang kita coba selesaikan.

Alat itu sendiri tidak memperbaiki masalah, mereka hanya (kadang-kadang) membuat programmer lebih efisien.

Ini seperti dengan: "senjata tidak membunuh, manusia melakukannya".

Arnis Lapsa
sumber
1
Jika saya tidak salah, bukankah Cleverbot hanya mengulangi apa yang sudah dikatakan orang tentang itu?
Andrew Arnold
0

Benar-benar tidak. Dalam pengalaman saya, menggunakan alat pengembangan yang benar memungkinkan untuk pengembangan aplikasi yang cepat tanpa mengorbankan kualitas. Bahkan, saya berpendapat bahwa, sebagian besar, kualitas telah meningkat karena "ketergantungan yang berlebihan pada alat". Selain itu, alat pengembangan dapat mengurangi kurva belajar dan memperkenalkan lebih banyak orang ke pemrograman. Ini, tentu saja, memiliki kelemahan, karena ada lebih banyak programmer pemula, tetapi secara keseluruhan, ini membantu dalam proses kreatif dan mendorong teknologi ke depan.

Aviator berkafein
sumber
0

Apakah terlalu mengandalkan alat menyiratkan bahwa Anda malas?

Secara umum, 'Tidak'; tapi ada satu peringatan besar.

Saya mulai pemrograman dalam C ++ di uni dan menyukainya. Dalam istilah berikutnya kami berubah menjadi VB6 dan saya benci itu.

Saya tidak tahu apa yang sedang terjadi, Anda seret tombol ke formulir dan ide menulis kode untuk Anda.

Ya memang. Pengalaman Anda di uni berbicara dengan peringatan yang saya sebutkan tadi.

Jika Anda tidak tahu masalah apa yang dipecahkan oleh alat Anda, atau Anda tidak dapat memecahkan masalah saat alat Anda mengalami masalah sendiri, maka itu adalah tanda bahaya besar. Keadaan ini tidak selalu menyiratkan kemalasan, tetapi mungkin menyiratkan kurangnya pengalaman.

Jim G.
sumber
-2

Saya pikir ada 2 rasa programmer. Ada programmer yang hanya program untuk menyelesaikan pekerjaan karena mungkin tenggat waktu atau mungkin hanya untuk menjadi lebih produktif. Saya akan mengatakan mereka malas. Saya hanya percaya mereka tidak tertarik pada "bagaimana" komputer melakukan apa yang dilakukannya atau "bagaimana" suatu program melakukan apa yang dilakukannya.

Lalu ada programmer yang bersemangat, seperti saya. Pemrogram yang bergairah, seperti saya, ingin tahu persis apa yang terjadi pada CPU. Seperti halnya seorang psikolog yang baik mencoba mencari tahu apa yang terjadi di kepala manusia, ahli progchologi, seperti saya, ingin tahu apa yang sedang terjadi di dalam CPU. Jadi kami belajar, membedah dan menganalisis program dan menggunakan alat, seperti Reflektor dan pembongkar untuk mencoba mencari tahu bagaimana program bekerja.

Icemanind
sumber
Saya tidak setuju. Orang yang berbeda tertarik pada hal yang berbeda. Beberapa orang lebih tertarik pada pemrograman tingkat bawah dan ingin tahu apa yang terjadi pada perangkat keras. Orang lain lebih tingkat tinggi dan lebih mementingkan aplikasi. Apakah Anda pikir seseorang menulis kode untuk, katakanlah, facebook, memiliki masalah dengan apa yang terjadi dengan CPU atau bagaimana driver bekerja? Untuk mengatakan bahwa, secara kebetulan, orang-orang yang tertarik pada bagian pemrograman yang sama dengan Anda, adalah orang-orang yang bersemangat tidak memiliki landasan logis.
Peluang
-3

Saya memiliki harapan diam bahwa segalanya akan berubah. CPU tidak melakukan penskalaan vertikal sebanyak itu, hanya secara horizontal, dan ARM, dll. Akan dibatasi sumber daya dalam waktu dekat.

Sangat mungkin bahwa permintaan untuk pemrograman non-drag-and-drop akan menurun dan kita akan melihat beberapa pekerjaan yang lebih menarik.

Coder
sumber