Apa perbedaan utama antara insinyur perangkat lunak dan pemrogram? [Tutup]


103

Apa perbedaan utama antara insinyur perangkat lunak dan pemrogram?


1
Joel sudah mengajukan pertanyaan ini. Ini bukan pertanyaan yang mudah dijawab dan saya tidak yakin apakah ada jawaban yang jelas. Tetapi saya tahu bahwa Joel telah mengajukan pertanyaan itu.
Denaem

Jawaban:


80

Saat merekrut, kami mencari perbedaan antara seseorang yang akan dapat membantu kami merancang sistem kami, menentukan proses, membuat spesifikasi teknis, menerapkan refactoring lanjutan, dll. Dan seseorang yang akan membantu kami menyelesaikan tugas pemrograman dari daftar periksa . Saya percaya Anda bisa menyebut mantan Insinyur Perangkat Lunak dan yang terakhir Programmer .


10
Bisakah Anda menjelaskan, apakah Anda mempekerjakan keduanya (untuk pekerjaan yang berbeda) atau hanya insinyur perangkat lunak?
Jaap

2
Anda bisa memanggil mantan Insinyur Perangkat Lunak, tetapi saya tidak mau. Seperti yang dihindari oleh Brendan, itu biasanya pekerjaan arsitek perangkat lunak.
JᴀʏMᴇᴇ

131

Terserah perusahaan sebenarnya, karena saya tidak berpikir ada kerangka hukum untuk menegakkan denominasi atau yang lain, atau setidaknya tidak saya sadari dan ini mungkin berbeda dari satu negara ke negara lain (misalnya, penggunaan istilah "Insinyur" sebenarnya cukup diatur di Perancis, tetapi ada varian yang diperbolehkan untuk kasus "kasar").

Yang mengatakan tren umum seperti ini:

  • Sebuah programmer posisi biasanya yang dari seorang profesional disewa untuk menghasilkan kode program komputer . Ini akan menyiratkan bahwa Anda tahu cara menulis kode , dapat memahami suatu algoritma dan mengikuti spesifikasi . Namun, biasanya berhenti di sana dalam hal tanggung jawab.

  • Sebuah pengembang posisi biasanya dianggap a-jenis super dari posisi programmer . Ini meliputi tanggung jawab yang sama, ditambah dengan kemampuan untuk merancang dan arsitek komponen perangkat lunak , dan untuk menulis dokumentasi teknis untuk itu (termasuk spesifikasi). Anda dapat - setidaknya secara teknis - memimpin orang lain (jadi, programmer), tetapi belum tentu tim (ada fuzz ...)

  • Sebuah insinyur posisi biasanya akan berarti bahwa Anda adalah seorang pengembang yang memiliki jenis tertentu dari tingkat , beberapa pengetahuan tentang teknik , dan mampu merancang sebuah sistem (seperti dalam: kombinasi dari komponen software / modul yang bersama-sama membentuk badan seluruh perangkat lunak) . Pada dasarnya, Anda melihat gambar yang lebih luas , dan Anda mampu merancang dan menjelaskan dan memisahkannya menjadi modul yang lebih kecil .

Namun, semua ini bisa diperdebatkan , dan seperti yang saya katakan, tidak ada persyaratan hukum yang saya ketahui di negara-negara AS / Inggris . Yang sedang berkata, di Perancis Anda hanya dapat menyebut diri Anda seorang "insinyur" jika Anda berasal dari sekolah teknik (diakui oleh Komisi des Titres d'Ingenieurs atau sesuatu seperti itu). Anda tidak dapat mengatakan bahwa Anda memiliki "Gelar Insinyur", tetapi Anda dapat mengatakan bahwa Anda memiliki "Sarjana Teknik" jika Anda telah mempelajari disiplin yang berada di bawah portemanteau teknik dan teknologi.

Mungkin beberapa negara memiliki perbedaan yang sama, saya hanya tidak benar-benar tahu.

Kembali ke judul insinyur perangkat lunak ... Suatu kali, salah satu guru saya memberi tahu kelas kami - dan memang benar - bahwa tidak ada hal seperti itu, sampai hari ini, yang disebut "rekayasa perangkat lunak" . Karena merekayasa sesuatu (baik itu bangunan, kendaraan, perangkat keras ...) berarti Anda mampu membayangkan desain dan semua fase produksinya, dan untuk memprediksi dengan akurat sumber daya yang Anda perlukan, dan dengan demikian biaya produksi.

Ini berlaku untuk sebagian besar disiplin ilmu teknik "benar". Ada fluktuasi, tentu saja (harga bahan akan bervariasi dari waktu ke waktu, misalnya), tetapi ada model teoritis yang sangat terbatas (untuk desain dan perencanaan) dan model empiris (untuk menjaga sebagian besar yang sebelumnya dalam kendala yang dapat diakses) yang memungkinkan Anda untuk memprediksi tanggal berakhirnya suatu proyek dan penggunaan sumber dayanya.

Masalah utama dengan perangkat lunak adalah bahwa itu belum ada di sana. Kami ingin membidik rekayasa perangkat lunak, tetapi sebenarnya kami belum ada di sana. Karena kami memiliki lingkungan yang sangat lancar dan dinamis, kendala yang sangat bervariasi untuk proyek, dan masih kurang matang dalam retrospeksi dalam proses kami. Tentu kita dapat mengatakan bahwa kita menjadi lebih baik (sangat bisa diperdebatkan dengan data keras), tetapi kita hanya melakukannya sejak tahun 60an (proyek sebelumnya sebenarnya lebih dekat dengan komputer yang hanya menggunakan perangkat keras, sehingga lebih dekat dengan rekayasa nyata, ironisnya ). Padahal kami telah membangun kendaraan bermotor selama lebih dari seabad, kendaraan secara umum selama beberapa millennias, dan bahkan membangun lebih banyak millennias (dan sudah sangat bagus dalam hal itu sebenarnya di beberapa bagian dunia, membuat Anda merasa seperti kami '

Kami gagal untuk secara sistematis memprediksi tenggat waktu secara akurat , kami gagal untuk secara sistematis memprediksi biaya secara akurat , kami gagal mengidentifikasi dan memitigasi risiko yang melekat dan eksternal secara sistematis secara efisien dan deterministik . Yang terbaik yang dapat kami lakukan adalah menghasilkan perkiraan waktu yang cukup baik , dan mengakomodasi beberapa penyangga, sambil mencoba yang terbaik untuk mengoptimalkan proses untuk mengurangi siklus dan overhead.

Tapi begini, mungkin itulah rekayasa. Dan itulah yang, ketika seseorang berbicara tentang "insinyur perangkat lunak", mereka harus memikirkan dan membidik.

Sehingga tampaknya tidak dapat dipertukarkan dengan tindakan sederhana dari rutinitas pemrograman, atau tindakan yang lebih maju dalam mengembangkan aplikasi.

Namun, semuanya adalah masalah tren. Akhir-akhir ini cukup umum untuk memiliki tim pengembang horizontal di mana semua orang di tim adalah Pengembang Perangkat Lunak Senior (ya, huruf kapital, karena itu membuat kita merasa istimewa, bukan?), Tanpa perbedaan usia yang nyata (cukup adil, dalam pendapat) dan tidak begitu banyak perbedaan keterampilan (uh-oh ...) dan tanggung jawab (sekarang itu tidak baik, selain murni untuk buzz PR).

Ini juga kadang-kadang hanya kekuatan kebiasaan dan spesifik untuk budaya dan jargon industri. Lebih banyak posisi untuk produksi perangkat lunak tertanam menggunakan judul untuk insinyur perangkat lunak. Sebagian besar karena itu mungkin akan menyiratkan bahwa Anda akan selalu harus berurusan dengan tingkat tertentu dengan perangkat keras di bidang ini, sehingga Anda jelas berurusan dengan aspek-aspek lain dari produksi dan seluruh "sistem" yang Anda hasilkan. Bukan hanya bit yang menjadi gila di dalamnya. Di sisi lain spektrum, Anda tidak benar-benar melihat istilah insinyur yang digunakan dalam posisi produksi perangkat lunak keuangan. Ini karena evolusi mimetik dari industri ini dari salah satu pendahulunya (katakanlah, embedded engineering menemukan akarnya dalam rekayasa mobil, misalnya), atau karena mereka hanya ingin memberikan kredit / bobot lebih atau kurang untuk suatu posisi.

Dan untuk memastikan kehilangan semua orang dalam kabut, Anda akan menemukan judul-judul lain yang mencampurkan keduanya (seperti "Insinyur Pengembangan Perangkat Lunak" atau "Insinyur Perangkat Lunak dalam Uji"!), Dan kemudian yang lainnya menekankan jembatan yang lebih gila dengan domain lain ( pikirkan "Arsitek Perangkat Lunak" dan bagaimana "arsitektur perangkat lunak" mungkin merupakan pencurian kosa kata yang tidak tahu malu). Dan teruskan mereka: Release Engineer, Change Development Manager, Build Engineer (yang itu juga ffaaarrrrrr di luar sana). Dan terkadang hanya "insinyur".

Harapan itu membantu, meskipun itu bukan jawaban.

Oh, dan itu berarti perusahaan baru Anda mencoba memikat Anda dengan judul baru atau mereka tidak terlalu peduli dengan judul, atau bahwa Anda benar-benar akan memiliki posisi tingkat yang lebih tinggi. Satu-satunya cara untuk mengetahui adalah membaca spec pekerjaan Anda, berbicara dengan mereka dan akhirnya mencobanya dan menilai sendiri. Saya harap ini opsi terakhir dan Anda senang dengannya (dan berpotensi menghasilkan lebih banyak uang). ;)


12
Buku "Programmer pragmatis" juga mengatakan bahwa perangkat lunak tidak seperti teknik. Meskipun Anda dapat merencanakan rumah atau gedung pencakar langit, seperti analogi untuk rekayasa perangkat lunak hampir tidak dapat digunakan. Mereka menyatakan: Perangkat lunak lebih seperti berkebun. Rencanakan kebun, tanam tanaman. Kemudian lihat apa yang tumbuh, singkirkan gulma dan tanam tanaman baru.
Falcon

6
"Dulu guru saya memberi tahu kelas kami bahwa tidak ada hal seperti itu, seperti hari ini, yang disebut" rekayasa perangkat lunak ". Karena rekayasa sesuatu berarti Anda mampu membayangkan desainnya dan semua fase produksinya, dan untuk memprediksi dengan akurat. sumber daya yang Anda butuhkan ". Itu mungkin tidak benar pada saat ini ditulis. Seperti arsitektur, kami tidak dapat memprediksi biaya tanpa mengetahui persyaratan (berapa biaya pencakar langit? Saya tidak akan memberi tahu Anda berapa tinggi sebelum Anda mulai membangun ...). Tetapi kami dapat memperkirakan biaya setelahnya, mengingat kelompok pengembangan perangkat lunak yang matang.
MSalters

1
@MSalters: Tentu, Anda dapat membalikkan ini: seperti architeture, kami tidak dapat memprediksi biaya tanpa persyaratan. Tetapi tidak seperti arsitektur , bahkan dengan persyaratan yang jelas (meskipun persyaratan kami sering berubah-ubah karena lebih sulit diramalkan atau kami memiliki kecenderungan untuk memungkinkannya berubah), kami tidak dapat memperkirakan biayanya. Anda dapat melakukan ini dalam rekayasa normal hingga tingkat presisi yang sangat akurat, DAN saat ini kami lebih mampu mengidentifikasi biaya untuk keadaan luar biasa daripada di SE. Kami hanya melakukan perkiraan waktu (cukup kasar). Kita menjadi lebih baik dalam membuatnya, tapi itu masih banyak tebakan.
haylem

3
@Haylem: Itulah norma dalam pengembangan perangkat lunak. Tetapi jika Anda telah bekerja di perusahaan CMM level 4/5, Anda akan melihat bahwa mereka dapat memprediksi biaya, dan sering kali memasang tingkat kepercayaan 95% pada mereka. Mereka memahami basis perangkat lunak mereka dengan cukup baik, dan memiliki persyaratan yang cukup baik, sehingga hambatan jarang terjadi. Dan biaya hambatan lebih rendah ketika Anda punya pengalaman untuk menghadapinya.
MSalters

1
@ pcurry: perhatikan Saya tidak mengklaim ini sebagai "taksonomi saya". Itu hanya cukup umum dianggap seperti ini oleh perekrut dan penggajian perusahaan, dan juga bagaimana itu sering dianggap dalam CS kursus IT TI. Mereka cenderung saling menembak. Jadi saya kira saya mencantumkan pandangan yang diadopsi oleh (yang disebut) Insinyur Perangkat Lunak lebih dari oleh pemrogram (dijelaskan sendiri), jelas. Tidak masalah apa yang Anda sebut diri Anda sendiri, lebih penting apa yang orang anggap penting bagi Anda. Dan itu hanya masalah jika Anda peduli tentang hal-hal semacam itu. Jujur, secara pribadi saya tidak peduli menjadi satu atau yang lain, tidak mengubah saya.
haylem

81

Insinyur perangkat lunak adalah orang yang bekerja di perusahaan yang menyebut orang yang menulis perangkat lunak untuk mereka "insinyur perangkat lunak."

Pemrogram adalah orang yang bekerja di perusahaan yang menyebut orang yang menulis perangkat lunak untuk mereka "pemrogram."

Ada juga pengembang , atau pengembang perangkat lunak . Mereka adalah orang-orang yang bekerja di perusahaan yang menyebut orang-orang yang menulis perangkat lunak untuk mereka masing-masing "pengembang" atau "pengembang perangkat lunak,".


26
Saya harus mencatat bahwa jawaban ini tidak dimaksudkan untuk menjadi lucu.
Yer

15

Jadi ada "Software Engineer", "Programmer", dan juga "Developer", "Coder" dan Anda tidak akan pernah melupakan "pakar SOA"

Ini semua adalah istilah pemasaran untuk orang-orang yang tidak bisa mengatakan sesuatu yang berarti dalam CV mereka, seperti peran mereka yang sebenarnya (bukan hanya jabatan-pekerjaan) di posisi sebelumnya.

Pada iklan pekerjaan, perbedaannya tergantung pada orang SDM.

Intinya: setiap orang memiliki pandangan sendiri tentang "apa yang membuat karyawan yang baik-yang-bekerja-dengan-kode", dan beberapa suka mengasosiasikan keterampilan ini dan itu dengan judul ini dan itu.

apa yang kamu butuhkan? Iklan pekerjaan harus deskriptif tentang keterampilan yang diperlukan, dan CV harus menjelaskan detail pengalaman kandidat.


10

Tidak ada perbedaan. Mereka adalah hal yang sama. Perusahaan, meskipun, mungkin memiliki deskripsi pekerjaan formal menggunakan istilah, dan kemudian mungkin ada beberapa makna spesifik perusahaan untuk istilah tersebut.


8

Pemrograman adalah tentang kode. Rekayasa perangkat lunak adalah tentang produk akhir.


3

Itu sangat tergantung pada bagaimana perusahaan mendefinisikan posisi. Mungkin sebagai insinyur perangkat lunak Anda akan memiliki lebih banyak peluang keputusan desain, sedangkan sebagai pengembang mereka akan memberi Anda diagram UML dan Anda akan menulis program.

Tapi, tidak ada definisi yang nyata sehingga berdasarkan judul akan orang tahu apa yang Anda lakukan, atau seberapa berpengalaman Anda.

Ketika saya seorang arsitek / pengembang, gelar saya adalah ilmuwan komputer, tetapi saya hanya akan memberi tahu orang-orang bahwa saya adalah seorang programmer, karena dua yang pertama tidak mudah didefinisikan, tetapi kebanyakan orang tahu apa yang dilakukan seorang programmer.

Jika sebuah judul penting bagi Anda, maka terimalah yang baru, karena insinyur terdengar lebih tinggi dari pengembang.


3

Saya tidak berpikir ada "perbedaan resmi", untuk pengalaman saya itu bisa berarti:

  • Beberapa perusahaan menggunakan insinyur perangkat lunak dan pengembang perangkat lunak untuk merujuk pada hal yang sama. Mereka hanya menggunakan istilah favorit mereka.
  • Lainnya menggunakan kedua istilah untuk posisi dalam yang berbeda, tetapi perannya berbeda dari perusahaan ke perusahaan! Dalam beberapa bisa hanya perbedaan pada fungsi (insinyur lunak. Akan bekerja pada pemeliharaan dan peningkatan sistem sementara pengembang akan bekerja pada produk perusahaan), atau bisa hirarkis (insinyur di atas pengembang), atau bahkan sang insinyur benar-benar bergantung pada T&J!

Selain itu, ada juga istilah mode yang berubah ... Pertama istilahnya adalah "programmer", kemudian "insinyur perangkat lunak" dan sekarang tampaknya "pengembang" ...

Lebih baik membaca deskripsi pekerjaan atau kepada seseorang di perusahaan tertentu


3

Dalam beberapa yurisdiksi, "Insinyur" disertai dengan persyaratan menjadi insinyur profesional, yaitu memiliki P.Eng. desigasi di antara kredensial seseorang. Namun, di daerah lain mungkin tidak ada perbedaan seperti saya adalah "Softwere Design Engineer" yang bekerja di negara bagian Washington beberapa tahun yang lalu.


2

Insinyur Perangkat Lunak cenderung bekerja pada sistem yang sangat besar, membutuhkan waktu bertahun-tahun untuk dikembangkan, misalnya 5 hingga 16 tahun misalnya. Programmer cenderung memiliki stereotip ini hanya coding dan tidak ada yang lain. Tetapi itu benar-benar tergantung pada organisasi tempat Anda bekerja dan bagaimana SDM memasarkan peran seperti yang dijelaskan di atas. Mereka pada dasarnya adalah hal yang sama. Hanya saja, jangan terlalu terikat pada judul karena itu identik.

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.