Saya bekerja dengan seseorang yang bersikeras bahwa setiap insinyur perangkat lunak yang baik dapat berkembang dalam teknologi perangkat lunak apa pun, dan pengalaman dalam teknologi tertentu tidak masalah untuk membangun perangkat lunak yang baik. Analoginya adalah bahwa Anda tidak perlu memiliki pengetahuan tentang produk yang sedang dibangun untuk mengetahui cara membangun jalur perakitan yang memproduksi produk tersebut.
Di satu sisi itu adalah pujian untuk dilihat dengan mata sedemikian rupa sehingga "jika kamu bagus, kamu bagus dalam segala hal", tetapi dengan cara itu juga meremehkan profesi, seperti dalam "Codemonkey, go sling code". Tanpa pengalaman dalam kerangka kerja perangkat lunak tertentu, Anda bisa mendapat masalah dengan cepat, dan itu penting.
Saya mencoba menjelaskan ini, tetapi dia tidak membelinya. Adakah perbedaan pandangan atau pemikiran tentang hal ini untuk membantu menjelaskan bahwa pengalaman saya dalam satu hal, tidak berarti semua hal?
sumber
Jawaban:
Saya berpendapat sebaliknya. Seorang insinyur perangkat lunak yang baik akan memiliki kemampuan untuk membuat konsep, arsitek, dan merancang perangkat lunak agnostik teknologi berkualitas. Ujung yang berlawanan dari spektrum ini adalah .NET atau Java atau PHP hanya "codemonkey" yang bagus diberikan arahan atau spesifikasi dan menggunakan alat untuk mengimplementasikan perangkat lunak.
Seorang insinyur perangkat lunak tidak perlu menjadi ahli semua alat, tetapi harus memiliki pemahaman tingkat tinggi yang cukup baik tentang apa mayoritas dari mereka, apa yang mereka bawa ke meja, dan apa yang mungkin paling sesuai untuk proyek yang diberikan . Saya berharap monyet kode hanya menjadi master dari keahlian mereka yang dinyatakan dalam alat tertentu.
Saya tidak akan mempercayai insinyur Ford yang tidak tahu bagaimana melakukan pekerjaan Mekanik.
Meski begitu, rekayasa perangkat lunak adalah salah satu bidang ini di mana dalam banyak kasus kita diharapkan menjadi Insinyur, Pembuat, dan Mekanik pada saat bersamaan.
sumber
Saya setuju sampai batas tertentu dengan orang yang bekerja dengan Anda. Seorang insinyur perangkat lunak yang baik berurusan dengan prinsip-prinsip umum desain dan produksi perangkat lunak. Bahasa dan kerangka kerja yang sebenarnya adalah detail.
Itu bukan untuk meremehkan kemudahan yang Anda dapat mengambil bahasa dan kerangka kerja baru. Selalu ada kurva belajar yang terkait dengan mereka tetapi intinya adalah kurva, bukan dinding vertikal untuk insinyur perangkat lunak yang baik.
Seorang insinyur perangkat lunak yang baik memiliki berbagai pengalaman dalam sejumlah alat dan teknologi yang berbeda. Jika tidak, bagaimana dia bisa memilih alat terbaik untuk pekerjaan itu? Untuk mengusir klise lama, untuk seorang pria yang tahu bagaimana menggunakan palu, setiap masalah tampak seperti paku. Sekalipun Anda bukan ahli dengan obeng, Anda harus memiliki pemahaman yang mendalam tentang mereka sehingga Anda dapat mengenali sekrup bukan hanya kuku yang terlihat lucu.
sumber
Versi TLDR: Disiplin teknik lainnya membutuhkan pengetahuan tentang bahan yang mereka gunakan (mis. Arsitek perlu tahu berapa banyak muatan bahan yang mereka gunakan dalam desain mereka dapat menanggung ). Bahasa dan kerangka kerja yang kami gunakan untuk rekayasa perangkat lunak memiliki batasan tertentu dan kami harus terbiasa dengan mereka untuk merancang dan mengembangkan secara efektif terhadap mereka.
Ada dua fase berbeda dari apa yang kita lakukan. Yang pertama adalah desain konseptual. Itu adalah desain sistem level tinggi dan level rendah (misalnya menggunakan UML). Desain tingkat tinggi secara teoritis dapat menjadi implementasi agnostik (walaupun terkadang desain tingkat tinggi harus mempertimbangkan spesifik akun, platform database, middleware rak, dll.). Desain tingkat rendah agak sulit. Anda dapat mendesain spesifik logika bisnis tanpa memasukkan rincian infrastruktur ke dalamnya dan sekali lagi, ini secara teoritis bisa menjadi platform agnostik.
Fase kedua adalah pemrograman aktual. Sementara beberapa melihat pemrograman sebagai konstruksi, yang lain (termasuk saya) berpendapat bahwa pengkodean masih disiplin desain (dalam PPP , Bob Martin merujuk pada sebuah artikel di mana penulis mengajukan argumen yang sangat baik untuk efek ini, saya tidak memilikinya dengan saya sekarang, tetapi saya akan memperbarui jawaban ini dengan tautan ke artikel itu). Konstruksi sebenarnya terjadi ketika Anda menekan kompilasi dan berlaku bebas.
Sama seperti seorang arsitek harus memperhitungkan hal-hal seperti kekuatan tarik dan tekan bahan bangunan yang ia gunakan, demikian juga seorang insinyur perangkat lunak harus mengetahui kemampuan platform yang mereka kembangkan saat menulis kode. Saya berpendapat bahwa desain sistem tingkat rendah tidak terlalu efektif jika tidak memperhitungkan pilihan platform juga.
sumber
Sebagai seseorang yang lulus dari program sarjana Rekayasa Perangkat Lunak, saya dapat mengatakan bahwa rekan kerja Anda sebagian benar. Seorang insinyur perangkat lunak yang baik berfokus pada penerapan matematika, statistik, ilmu komputer, dan pengalaman domain untuk membangun suatu sistem. Metode yang digunakan oleh seorang insinyur perangkat lunak biasanya adalah teknologi dan agnostik bahasa - alat-alatnya tidak masalah sebanyak prinsip yang mendasarinya.
Yang mengatakan, analogi rekan kerja Anda cacat. Memahami masalah domain sangat penting untuk setiap disiplin ilmu teknik. Jika Anda tidak sepenuhnya memahami masalah yang Anda coba selesaikan dan orang-orang yang Anda coba puaskan, menjadi jauh lebih sulit untuk membangun solusi terbaik untuk masalah mereka.
Pada akhirnya, rekayasa perangkat lunak (dan disiplin teknik apa pun) adalah tentang menerapkan sejumlah konsep untuk menyelesaikan masalah. Jika Anda sering menggunakan alat yang sama, Anda akan menjadi lebih mahir dengan alat-alat itu. Akan lebih mudah bagi Anda untuk mengidentifikasi masalah yang dapat diselesaikan oleh alat-alat itu, risiko atau jebakan dengan menggunakan alat-alat itu, dan kemudian menggunakan alat-alat itu untuk membangun solusi.
sumber
Ini hampir pasti salah. Insinyur produksi spesialis perlu memahami cukup banyak tentang produk di bawah asuhan mereka.
Bagaimanapun, analogi yang lebih baik adalah dengan lulusan kursus teknik mesin: meskipun semua orang memulai (baik dalam mech dan perangkat lunak) dengan banyak keterampilan yang sama, tidak ada yang tetap menjadi "insinyur mesin", tetapi sebaliknya mengkhususkan diri dalam jenis hal-hal yang mereka bangun. Demikian juga, pengembangan perangkat lunak juga memiliki subbidang yang sangat berbeda.
Untuk kembali ke analogi jalur perakitan, setiap jalur perakitan berbeda untuk setiap produk, dan berbagai jenis pengembangan perangkat lunak memerlukan metodologi yang berbeda - Anda tidak akan membangun perangkat lunak keamanan dengan cara yang sama seperti saat Anda membangun sebuah game.
sumber
Ada kurva belajar yang terlibat dengan spesialisasi yang berbeda. Saya sedang berbicara tentang perbedaan antara pemrograman Embedded / Real-time, pemrograman Web-App, pemrograman Sistem / OS, pemrograman klien tebal, pengembangan ponsel, dll.
Seseorang yang ahli dalam satu jenis pemrograman mungkin tidak dapat langsung beralih ke yang lain karena persyaratan yang berbeda. Tentu, seorang insinyur perangkat lunak memiliki dasar-dasar untuk melakukannya, tetapi butuh waktu untuk berspesialisasi dalam sesuatu.
sumber
Saya setuju dengan premis yang disarankan rekan Anda meskipun saya akan menambahkan peringatan.
Seorang insinyur perangkat lunak yang baik akan dapat membangun perangkat lunak yang baik dalam teknologi apa pun ..... setelah mereka melakukan sedikit pembelajaran dalam teknologi baru.
Mungkin ada beberapa kebiasaan yang tidak jelas pada awalnya, tetapi insinyur perangkat lunak yang baik akan segera mempelajarinya.
Saya pikir apa yang sebenarnya ia maksudkan adalah hanya karena seorang pengembang memiliki 2 tahun pengalaman C # solid, itu tidak berarti seorang insinyur perangkat lunak yang lebih baik dengan latar belakang Java, yang belum pernah melakukan C # sebelum tidak dapat datang, belajar C #, dan dengan cepat menjadi pengembang C # yang lebih baik daripada orang pertama.
Dengan kata lain, Anda tidak harus mengabaikan orang Jawa untuk pekerjaan, HANYA karena dia telah "menyelesaikan waktu" dalam C #.
sumber
Contoh kasus: kerangka kerja perangkat lunak yang Anda rasa sangat penting untuk memiliki pengalaman khusus dengan kemungkinan tidak ada 10 tahun yang lalu, atau telah mengalami transformasi yang signifikan jika itu terjadi. Sifat dasar dari profesi kami membuat tidak mungkin untuk mengkhususkan diri untuk keseluruhan karir seseorang. Bergantung pada tingkat keahlian Anda masing-masing, spesialisasi Anda memberi Anda keuntungan untuk suatu tempat antara 1 dan 6 bulan dibandingkan seseorang yang belum pernah menggunakan kerangka kerja khusus Anda. Setelah itu, Anda setara.
sumber
Saya bekerja untuk sebuah perusahaan helikopter dan para insinyur penerbangan di sini berspesialisasi pada jenis-jenis pesawat yang dapat mereka gunakan. Mereka harus "tipe dinilai". Secara teknis mereka bisa mengerjakan apa saja dari Robinson R22 ke Jumbo Jet, tetapi tidak tanpa pelatihan konversi.
Saya pikir ini sangat mirip dengan rekayasa perangkat lunak kecuali bahwa "pelatihan konversi" lebih informal untuk insinyur perangkat lunak.
sumber
Ketika berbicara dengan seorang pelukis, apakah Anda akan memberitahunya bahwa ia tidak memiliki masalah dengan memahat?
Mempelajari bahasa baru atau spesifik pada domain baru mirip dengan seorang seniman yang terutama berurusan dengan pensil dan tinta, belajar cara melukis (atau sebaliknya). Inilah yang sebagian besar jawaban lain bicarakan, bagaimana teman Anda sebagian benar - banyak konsep yang sama berlaku.
Tetapi mengajar seorang pelukis bagaimana memahat objek 3D, atau menulis novel (Kedua bentuk ekspresi artistik) adalah binatang yang sama sekali berbeda. Dari sudut pandang itu Anda berasal.
Perangkat lunak berbasis web membutuhkan jenis pemikiran yang sama sekali berbeda dari perangkat lunak desktop. Keduanya sama sekali berbeda ketika diterapkan pada game versus lingkungan kerja. Saya menduga bekerja pada OS atau sistem terintegrasi juga memerlukan pemikiran dengan cara yang berbeda (tapi saya tidak punya pengalaman dengan mereka). Dan saya tidak ragu ada domain lain yang juga membutuhkan cara berpikir yang berbeda.
Ringkasan dan contoh:
"Seni" termasuk patung, novel, komik, dan lukisan. Tumpang tindih keterampilan meliputi:
... Dan seterusnya. Tapi seperti yang disebutkan di atas, seorang komikus tidak mungkin berhasil dengan baik di novel pertama mereka. Mereka perlu berpikir secara berbeda.
Demikian juga, ada tumpang tindih di berbagai bidang pemrograman / rekayasa perangkat lunak, tetapi kebanyakan dari mereka terlalu berbeda untuk bisa langsung masuk. Misalnya:
sumber
Apakah semua pekerja konstruksi jalan dapat menggunakan setiap peralatan dan mesin di lokasi kerja? Jawabannya adalah tidak. Ada potongan-potongan mesin yang mereka tahu dan kemungkinan akrab dengan yang lain. Hal yang sama harus berlaku untuk insinyur perangkat lunak, ada sejumlah bahasa dan kerangka kerja yang Anda tahu karena Anda bekerja dengan mereka setiap hari, tetapi seharusnya tidak diharapkan untuk mengetahui operasi yang tepat dari orang lain tanpa pelatihan. Ini seperti mengambil pekerja jackhammer dan menugaskannya tugas mengemudi mixer semen.
Bahasa dan kerangka kerja pemrograman hanya alat di sabuk alat insinyur perangkat lunak. Ada beberapa alat yang Anda akan tahu lebih baik daripada yang lain karena pengalaman. Pada akhirnya, alat terbaik adalah memahami konsep inti dan prinsip komputasi. Memilih bahasa dan kerangka kerja hanya memilih obeng mana yang akan digunakan pada sekrup mana.
sumber
Hal semacam ini sering terjadi di tempat saya bekerja.
Saya suka membandingkan dengan profesi paman istri saya - montir mobil.
Dia berspesialisasi dalam Mercedes, dia dapat menerapkan ilmunya ke merek mobil lain, dan dia melakukannya - beberapa di antaranya agak jarang, tetapi itu tidak berarti bahwa dia dapat segera memperbaiki merek X karena Anda mengatakan itu membuat suara.
Saya memprogram dalam beberapa bahasa, tetapi itu tidak berarti saya tahu mengapa Safari di MacBook Anda memuat ulang halaman setiap kali Anda mengubah tab (panggilan aneh hari ini). Saya akan mencoba dan mencari tahu mengapa tetapi saya tidak akan tahu dari atas kepala saya karena bidang komputasi adalah BESAR .
Dalam kedua kasus setelah menghabiskan waktu melihat bidang masing-masing, kita mungkin dapat menemukan jawabannya tetapi tidak dalam sepuluh detik yang dipikirkan orang karena "tetapi Anda bekerja dengan mobil" atau "tetapi Anda bekerja dengan komputer".
Apakah orang mengatakan hal seperti itu kepada dokter lokal mereka (seperti "Saya sakit kepala penyakit apa yang saya miliki?") - Saya yakin mereka melakukannya karena kebanyakan orang benar-benar tidak mengerti bahwa ada lebih banyak profesi dalam satu profesi daripada harapan langsung mereka dari kata profesi.
sumber