Apakah pemrograman sebagai sebuah profesi berlomba ke bawah? [Tutup]

Sepertinya saya bahwa industri pemrograman sedang berlomba ke bawah. Jika kami mengambil praktik:

1. Tidak perlu waktu untuk menerapkan praktik terbaik
2. Menggunakan kode orang lain sebanyak mungkin (kode khusus sebagai kewajiban)
3. Menggunakan bahasa tingkat yang semakin tinggi untuk meningkatkan produktivitas
4. Pengembangan "alat" berbasis GUI yang sangat menyederhanakan "pemrograman" dan tidak mengharuskan orang untuk memahami pipa ledeng di balik kode

Hal-hal ini menyiratkan kepada saya bahwa kita berlomba untuk menjadi seperti pekerja kantor lainnya. Adalah kepentingan pengusaha untuk hal-hal yang tidak memerlukan keterampilan (lebih mudah untuk menggantikan), untuk hal-hal yang akan dibangun kembali (lebih sedikit waktu proyek).

Maksud saya di sini adalah bahwa a) adakah ketidaksejajaran antara keterampilan dan kepentingan ekonomi majikan? dan b) jika ada, bagaimana Anda menguranginya untuk menegakkan standar profesional?

Saya pikir Anda telah mengajukan pertanyaan yang sangat mengharukan.

Membuat alat pengkodean GUI membuat pemrogram keluar dari pekerjaan sebanyak robot membuat pekerja lini perakitan tidak bekerja. Menurut pendapat saya, sementara ada kehilangan pekerjaan, ada juga pergeseran di mana pekerjaan berikutnya.

Teknologi untuk menyelesaikan tugas berubah, tetapi tugas itu masih harus diselesaikan: Mobil-mobil masih harus dibuat / dirakit sebelum dapat dikendarai; kode / logika bisnis masih perlu disatukan agar aplikasi berfungsi.

Pergeseran teknologi menghadirkan pilihan bagi pemrogram: Pelajari pemrograman berbasis GUI atau alat program GUI ... atau ... sesuatu yang lain sama sekali.

Mungkin ada ketidaksejajaran antara keterampilan karyawan dan kepentingan majikan, tetapi tidak lama, terutama jika majikan cerdas. Oleh karena itu, demi kepentingan pemberi kerja dan karyawan, mereka mengejar apa yang saling menguntungkan. Tapi yang satu pasti akan di depan yang lain. Semoga itu adalah Anda (-:

Semoga sukses,

KM

Untuk tren yang Anda sebutkan saya akan menambahkan satu lagi, yang IMHO menjelaskannya:

Ada jauh lebih banyak programmer (dibutuhkan) dari sebelumnya.

Jumlah tugas yang memerlukan atau termasuk pemrograman semakin meningkat, dan bahkan lebih tinggi daripada jumlah programmer. Saat ini ada beberapa microchip di mobil biasa. Dalam 5 tahun mungkin ada chip di lemari es dan pemanggang roti Anda. Dalam 10 tahun, pakaian dalam Anda? ... Dan seseorang perlu membuat semua perangkat lunak itu untuk membuatnya bekerja. Jadi ada setiap upaya yang mungkin dilakukan untuk mengotomatisasi apa pun yang dapat diotomatiskan, dan untuk meningkatkan "produktivitas" (namun itu didefinisikan). Dan semakin banyak otak segar yang direkrut.

Ini menyiratkan bahwa mayoritas programmer aktif saat ini tidak berpengalaman dan / atau tidak siap untuk pekerjaan mereka. Dibutuhkan beberapa tahun untuk mencapai tingkat pengalaman yang memadai dan dibutuhkan pembelajaran terus-menerus untuk menjaga diri Anda tetap di sana. Intinya adalah, semakin banyak pekerjaan pemrograman menjadi semakin sulit. Tetapi masih ada cukup banyak tantangan bagi siapa saja yang mencari mereka .

Biarkan saya berperan sebagai penasihat iblis melawan poin Anda di atas:

Tidak perlu waktu untuk menerapkan praktik terbaik

Banyak orang tidak, banyak orang. Bertahun-tahun yang lalu ketika saya pertama kali menemukan unit testing dan pendekatan gesit, tidak ada rekan saya yang tahu sedikit pun tentang apa itu. Saat ini hampir bahan standar di universitas, sehingga banyak lulusan baru sudah memahaminya.

Menggunakan kode orang lain sebanyak mungkin (kode khusus sebagai kewajiban)

Bertentangan dengan apa? Menemukan kembali roda? Atau menggunakan kode orang lain untuk menghindarinya?

Saya pikir penting untuk dicatat bahwa kita dibayar (kebanyakan) untuk menyelesaikan masalah, dan menulis kode bukanlah akhir, hanya sarana untuk itu . Jika masalah dapat diselesaikan tanpa menulis satu baris kode, itu masih membuat klien senang. Apalagi jika dengan cara ini kami berhasil menghasilkan solusi yang lebih andal lebih cepat dan lebih murah. Saya tidak melihat masalah dengan itu.

Menggunakan bahasa tingkat yang semakin tinggi untuk meningkatkan produktivitas

Berbeda dengan pengkodean segala sesuatu dalam perakitan? ;-)

Pengembangan "alat" berbasis GUI yang sangat menyederhanakan "pemrograman" dan tidak mengharuskan orang untuk memahami pipa ledeng di balik kode

IMHO alat apa pun dapat disalahgunakan. Yang tidak mengatakan bahwa pembangun GUI tentu sempurna atau bahkan baik - sebagian besar (atau setidaknya beberapa) dari mereka dapat digunakan dalam batas mereka. Tetapi jika seseorang tidak mengetahui batasan-batasan itu, apakah itu masalah alat atau penggunanya?

Secara umum, saya percaya (walaupun tidak memiliki bukti untuk membuktikannya) bahwa kembali pada kartu punch dan kode mesin, kira-kira proporsi yang sama dari kode yang ada mengerikan seperti sekarang, hanya keduanya

• jumlah keseluruhan kode, dan
• kemungkinan orang luar melihat kode tersebut

jauh lebih sedikit.

Sekarang, dengan Internet dan WTF Harian, kita dapat melihat contoh terburuk hari demi hari. Ini seperti menonton semua berita tentang terorisme dan gempa bumi dan selebritis yang bercerai, dan berteriak betapa berbahayanya dan tidak bermoralnya dunia ini.

Anda meringkas situasi dengan benar, tetapi sepenuhnya salah mengartikan maknanya.

Sebagai perangkat lunak menjadi lebih kuat, tugas-tugas yang dibutuhkan berskala dengannya. Jadi yakin, saat ini mungkin tidak perlu menjadi pemrogram basis data untuk membuat basis data kontak telepon ketika Anda dapat menggunakan Access. Dan mungkin tidak perlu menjadi programmer web untuk membuat blog ketika Anda bisa pergi ke wordpress. Tetapi, sementara 15 tahun yang lalu perlu untuk menjadi seorang programmer untuk melakukan hal-hal itu, apa yang programmer lakukan sekarang adalah urutan besarnya lebih besar dari apa yang bisa dilakukan 15 tahun yang lalu.

Biarkan saya begini, 100 tahun dari sekarang, itu akan sepele untuk mengatur sistem serumit facebook atau google. Saya tidak berbicara halaman web mereka, maksud saya pusat data mereka. Siapa pun dapat melakukannya. Itu akan dibangun ke ponsel, dengan asumsi kita masih menggunakannya. TETAPI, masih akan ada programmer, dan sementara mereka mungkin tidak bekerja pada sistem 'sepele' seperti itu 100 tahun dari sekarang, mereka akan bekerja pada sistem yang jauh lebih kompleks dan canggih sehingga tidak seorang pun di sini bahkan dapat mulai memahami ruang lingkup dan skala. Dan sistem itu, seperti yang sekarang, akan jauh dari jangkauan pekerja kantor rata-rata karena beberapa orang, yang disebut programmer, akan memilih untuk berspesialisasi dalam mendorong teknologi era itu ke ekstremnya.

Saya telah membaca hal semacam itu selama empat puluh tahun sekarang, dan saya tidak berada di awal prediksi. Itu belum terjadi.

COBOL adalah alat pengembangan asli yang dimaksudkan untuk menghilangkan kebutuhan akan programmer bisnis, dan bahasa yang jauh lebih tinggi daripada assembler. Pustaka kode (untuk menghindari keharusan menulis kode sendiri) memiliki jaman dahulu yang serupa.

Seringkali, sesuatu muncul yang memungkinkan nonprogrammer untuk melakukan sesuatu yang lebih seperti pekerjaan pemrograman. Ada "bahasa generasi keempat" 1980-an, spreadsheet mewah seperti Excel, generator laporan, dan sejenisnya. Apa yang telah mereka lakukan secara seragam, jika berhasil, adalah menghapus beberapa scutwork dari pemrograman dan memungkinkan programmer untuk melakukan hal-hal lain yang lebih menarik.

Pola ini tidak akan bertahan selamanya, tetapi saya akan membutuhkan sesuatu lebih dari argumen teoretis dan prediksi untuk meyakinkan saya bahwa pemrograman memang menurun.

Masalah dari COBOL ke alat pengembangan modern adalah bahwa mereka tidak menggantikan kemampuan untuk mengambil spesifikasi yang tidak tepat dan mengubahnya menjadi sesuatu yang tepat dan berguna. Itu adalah kemampuan dasar programmer, dan mengapa kita tidak pergi untuk waktu yang lama.

Programer Assembly dan FORTRAN mungkin mengatakan hal yang sama ketika pemrograman terstruktur dan penerjemah yang tersebar luas muncul.

Pada akhirnya, perangkat lunak adalah kreasi yang dimaksudkan untuk mengotomatisasi sesuatu yang sebelumnya telah dilakukan dengan tangan. Sebuah departemen akuntansi dalam sebuah perusahaan moderat sebelumnya akan membutuhkan lusinan orang, sekarang semua pekerjaan itu dapat diselesaikan dengan pekerjaan satu atau dua. Akibatnya, pos tujuan telah dipindahkan dan kami sekarang mengharapkan standar kemampuan ekstra dari seorang akuntan.

Pixar membutuhkan waktu lebih lama untuk membuat film daripada sebelumnya. Terlepas dari peningkatan besar dalam kecepatan komputasi, seiring dengan itu, animator telah menuntut semakin meningkatnya kompleksitas dan detail dalam adegan mereka. Animasi kaliber Toy Story tidak dapat diterima pada tahun 2010 seperti pada tahun 1995. Karena alat mereka telah maju, begitu pula kemampuan mereka dan dengan demikian harapan.

Ketika drag and drop atau metodologi pemrograman lainnya adalah hal yang umum, dunia akan menuntut solusi untuk masalah yang lebih menantang dan kompleks, dan mereka akan membutuhkan programmer menggunakan alat-alat mewah baru untuk menyelesaikannya. Pos tujuan akan dipindahkan.

Sementara saya setuju dengan sebagian besar jawaban yang menunjukkan bahwa masih ada banyak pekerjaan yang harus dilakukan, saya akan memberikan jawaban yang berbeda untuk Anda pertimbangkan:

Ya itu, dan HARUS

Saya di sini untuk merancang solusi untuk masalah yang orang lain tidak bisa. Apa pun yang ada di toolset yang menyita waktu saya untuk menyelesaikan masalah untuk menangani semua detail kecil tentang bagaimana mengimplementasikan desain saya adalah pemborosan.

Satu-satunya alasan saya takut pergi ke bahasa tingkat yang lebih tinggi atau alat yang lebih sederhana dan lebih abstrak adalah bahwa alat-alat itu sering membuat asumsi yang menghalangi saya dan membutuhkan waktu saya untuk bekerja di sekitar asumsi untuk mendapatkan implementasi yang diinginkan.

Selalu ada lebih banyak masalah untuk dipecahkan daripada ada pemecah masalah yang baik. Bahkan jika seluruh rantai dev menjadi sangat sederhana, anak-anak prasekolah dapat menggunakannya, sebagian besar solusi yang dirancang tidak akan cukup atau tidak efisien sehingga orang akan membayar untuk solusi yang lebih baik karena kebanyakan orang hanya buruk dalam melihat solusi yang tepat untuk masalah dengan semua kasus tepi. dan bagaimana-jika yang perlu Anda pertimbangkan untuk membuat solusi yang baik.

Tugas kami adalah untuk memecahkan masalah lebih baik daripada sebagian besar sisanya, kompleksitas toolchain tidak terlalu relevan dalam tampilan gambar besar selama itu keluar dari jalan dan memungkinkan Anda membangun dan Anda membangun sesuatu yang baik.

Meskipun teknologi pemrograman dapat berubah, kompleksitas mendasar dari suatu produk perangkat lunak masih ada. Jika perangkat lunak dapat ditulis sepenuhnya menggunakan diagram atau diagram alir (atau cara 'sederhana' lainnya), semua kerumitan perangkat lunak masih perlu dipahami dan ditangani. Untuk alasan itu, penting bagi pengusaha untuk memiliki pemrogram yang mengetahui produk dalam-luar perusahaan untuk memperbaruinya atau menambahkan fitur baru. Dan itu bisa memakan waktu cukup lama bagi karyawan untuk mempelajari produk perangkat lunak.

Apa pun yang Anda bisa lakukan secara otomatis atau ditarik, sebagian besar perangkat lunak yang dikemas terbagi dalam dua kategori:

1. Ini mudah digunakan, tetapi tidak cukup cocok dengan apa yang benar-benar dibutuhkan bisnis
2. Ini sangat dapat dikustomisasi, tetapi perlu spesialis untuk memahami dan memanfaatkan kustomisasi

Saya kira saya lupa yang ketiga Ini adalah perangkat lunak produktivitas standar (email, browser, kata proc, dll. Perangkat lunak dalam kategori satu mengarah ke bisnis yang mempekerjakan pengembang perangkat lunak untuk menyesuaikan perangkat lunak yang tidak tersedia (jika memungkinkan). Perangkat lunak kategori 2, yah mereka mungkin juga menyewa pengembang karena orang yang tahu bahwa sistem yang dapat dikustomisasi luar dan dalam sangat dicari (seperti SAP, PeopleSoft, dll.) atau jenis yang sekarat (pikirkan sistem apa pun yang mirip dengan SAP dan PeopleSoft yang tidak cukup memiliki penetrasi pasar yang sama).

Akan selalu ada kebutuhan untuk pengembang. Apa yang saya lihat adalah bahwa lebih dari apa yang dulunya adalah pekerjaan manual, membosankan, berulang menjadi otomatis (pikirkan menulis kode untuk akses data dengan tangan dibandingkan menggunakan O / RM). Ini memungkinkan pengembang untuk memberikan nilai lebih kepada bisnis dengan lebih sedikit usaha.

Saya tidak mengambil argumen Anda:

1. Tidak perlu waktu untuk menerapkan praktik terbaik

kecuali itu.

1. Menggunakan kode orang lain sebanyak mungkin (kode khusus sebagai kewajiban)

Penggunaan kembali kode adalah praktik terbaik. Kode yang digunakan diuji. Tentu saja Anda harus menggunakan kode dari sumber yang baik, yang dikelola dan digunakan oleh banyak orang.

1. Menggunakan bahasa tingkat yang semakin tinggi untuk meningkatkan produktivitas

Produktivitas tidak buruk per se - bukan?

1. Pengembangan "alat" berbasis GUI yang sangat menyederhanakan "pemrograman" dan tidak mengharuskan orang untuk memahami pipa ledeng di balik kode

Jika alat melakukan pekerjaan: Gunakan itu. Jika tidak: tolaklah. Jika janji itu berlaku, dan orang-orang benar-benar tidak perlu memahami kode tersebut - dilakukan dengan baik! Anda tampaknya mengatakan bahwa ini adalah janji yang tidak berlaku?

(Angka-angka di sini secara otomatis diterjemahkan salah. :))

Pemrograman visual tidak kalah valid atau pantas dicemooh daripada pemrograman berbasis teks.

Ada defisit dan tantangan tertentu saat pemrograman visual, tetapi komponen pipa yang mendasarinya berpotensi berbahaya ketika diabaikan tidak dimonopoli oleh komponen visual dan yang lebih relevan, desainer visual. Pipa yang mendasari diabaikan adalah risiko untuk setiap perkembangan.

Jika Anda mendapat kesempatan untuk mencoba Labview, Anda mungkin melihat potensi (atau bahkan varian khusus di lingkungan Lego NXT). Meskipun bukan tanpa kekurangan atau kekurangan, ada manfaat bawaan. Melihat adalah percaya.

Praktik pemrograman tidak hanya meningkatkan produktivitas dan mengurangi biaya untuk jenis pengembangan tertentu (ras Anda ke bawah), tetapi meningkatkan kemampuan aplikasi dan harapan pelanggan (sehingga mendorong perlombaan ke atas). Saksikan bonus yang dibayarkan Goole dan Facebook untuk mendapatkan teknologi top.

Tidak ada profesi lain yang berhubungan dengan rekayasa keberadaan yang berusaha menuju perubahan sebanyak pemrograman. Segera setelah Anda menyederhanakan sesuatu, Anda hanya membuka kaleng untuk masalah baru yang melahirkan ide-ide baru.

Jadi saya tidak akan menghentikan upaya orang lain untuk berbagi kode dan solusi untuk membantu kami bergerak ke arah tantangan baru, ide, dan pengalaman pengguna dengan praktik buruk, kebiasaan buruk, dan perilaku praktisi yang tidak ada dalam kemanusiaan.

Jika kami mengambil praktik:

WTF? Apakah maksud Anda agar daftar ini tidak konsisten? Daftar harus berasal dari sisi yang sama untuk setiap elemen daripada beralih bolak-balik tanpa peringatan. Jadi daftar Anda harus dibaca:

Jika kami mengambil praktik: