Bagaimana Anda menjelaskan bahwa rekayasa perangkat lunak lebih terspesialisasi daripada bidang teknik lainnya? [Tutup]

9

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?

engineering

— Spencer Kormos
sumber

7

Jika Anda akan downvote, bisakah Anda setidaknya berkomentar mengapa? Terutama karena masukan Anda dapat membantu pengulangan kata / fokus kembali pertanyaan.

— Spencer Kormos

11

pertama ini kata-kata kasar dan bukan pertanyaan, dan kedua itu kata-kata kasar cacat, ini perlu ditolak dan ditutup.

6

@JarrodRoberson Ada pertanyaan yang sah di sini. Ia meminta penjelasan yang baik yang meminta penjelasan mengapa beberapa orang memandang rekayasa perangkat lunak lebih atau kurang terspesialisasi daripada bidang teknik lainnya.

— maple_shaft

7

@SpencerK Pertanyaan Anda adalah "beberapa pria acak membuat analogi yang buruk, bagaimana saya merespons", dan yah, itu bukan pertanyaan. Hanya meminta bukti kuat dan / atau referensi yang mendukung posisinya, Anda bukan orang yang perlu membuktikan diri di sini.

— yannis

5

-1 karena saya tidak setuju dengan premis Anda. Rekayasa Perangkat Lunak tidak lebih khusus dari bidang teknik lainnya. Keduanya bisa sangat terspesialisasi dan digeneralisasi. Insinyur elektro-mekanis yang baik mungkin bukan insinyur biomedis yang baik. Di sisi lain, seorang tukang listrik yang baik mungkin bekerja pada rumah dan mobil.

— zzzzBov

23

tetapi dengan cara itu juga meremehkan profesi, seperti dalam "Codemonkey, go sling code".

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.

— maple_shaft
sumber

8

Saya juga akan menekankan pentingnya memahami konsep dan prinsip dibandingkan bahasa dan alat.

— Oded

+1 Salah satu kencing hewan peliharaan saya adalah orang-orang yang mengatakan "Saya seorang pengembang C # ...". Dan kemudian hanya minum kool-aid dan menerima apa pun dari MS sebagai Injil. 10 tahun pemrograman Saya telah belajar lebih dari 11 bahasa pemrograman, dan masing-masing telah membuat peningkatan besar dalam bagaimana saya memprogram dalam bahasa lain. Pelajari rekayasa perangkat lunak! Bukan platform yang akan hilang dalam 2 tahun.

— Timothy Baldridge

+1 untuk referensi Ford Engineer. Saya belum berpikir tentang Software Engineers vs Programmer dengan cara seperti itu sebelumnya.

— Dalin Seivewright

Seorang programmer adalah subset dari seorang insinyur, bukan sebaliknya.

— Spencer Rathbun

11

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.

— JeremyP
sumber

"Seorang insinyur perangkat lunak yang baik berurusan dengan prinsip-prinsip umum desain dan produksi perangkat lunak." Memproduksi sistem kontrol tertanam dan aplikasi web hampir persis sama , bukan?

— Marcin

@ Marsin: Beberapa prinsipnya, ya. Yang saya maksudkan adalah bahwa (misalnya) merancang sistem tertanam di C atau assembler menggunakan prinsip-prinsip yang sama meskipun alat-alatnya berbeda.

— JeremyP

Alat-alat itu tidak jauh berbeda, dan mereka mengatasi domain masalah yang sangat mirip. Inilah sebabnya mengapa ini sama sekali tidak membantu.

— Marcin

1

@ Marsin: Anda jelas tidak diprogram dalam assembler atau tidak diprogram dalam C. Saya jamin bahwa meskipun mitos umum, C tidak assembler dan pemrograman dalam alat-alat itu berbeda seperti (katakanlah) pemrograman di C dan Ruby.

— JeremyP

1

@ Marsin, tentu, dan bowling hanya masalah merobohkan semua pin. Sepotong kue benar-benar. Sementara pemrograman web dan pemrograman tertanam dapat berbagi beberapa prinsip tingkat tinggi dan praktik terbaik, yang benar-benar mengatur pekerjaan sehari-hari adalah kendala yang mengatur pelaksanaan praktik-praktik tersebut. Meskipun pada akhirnya Anda mungkin dapat melatih ulang programmer web sebagai insinyur yang disematkan dan sebaliknya, mereka tidak sepadan.

— Charles E. Grant

5

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.

— Michael Brown
sumber

5

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.

— Thomas Owens
sumber

Prinsip-prinsip yang mendasarinya dapat sangat bervariasi.

— Marcin

1

@ Marsin Tidak, mereka tidak. Ilmu komputer tidak berubah jika teknologi berubah. Matematika tidak berubah. Statistik tidak berubah. Juga tidak melakukan analisis persyaratan, desain sistem, praktik manajemen konfigurasi, strategi verifikasi dan validasi, prinsip kualitas ...

— Thomas Owens

Sebenarnya, "analisis persyaratan, desain sistem, praktik manajemen konfigurasi, strategi verifikasi dan validasi, prinsip kualitas" melakukan semua perubahan di antara domain masalah. Jika Anda tidak menyadarinya, maka Anda cenderung melakukan pekerjaan yang sangat, sangat buruk, bekerja di domain yang tidak Anda ketahui, karena Anda terlalu sombong untuk menyadari apa yang tidak Anda ketahui. Juga, matematika yang berlaku agak banyak berubah, tetapi saya yakin Anda bayangkan Anda tahu segalanya tentang matematika juga.

— Marcin

@ Marscin Saya sudah bekerja di segala hal mulai dari sistem tertanam hingga aplikasi web. Mereka tidak banyak berubah. Kualitas persyaratan yang baik tidak berubah berdasarkan domain. Alat yang digunakan untuk merancang sistem tidak berubah. Bagaimana Anda mengukur dan mencapai sistem berkualitas tinggi tidak berubah.

— Thomas Owens

1

Ya, Anda benar, setiap proyek perangkat lunak di dunia adalah sama, dan Anda telah menemukan cara mengelola setiap proyek. Anda mungkin harus menulis buku yang menjelaskan One True Way untuk menulis dan mengelola semua perangkat lunak.

— Marcin

4

Analoginya adalah bahwa Anda tidak perlu memiliki pengetahuan tentang produk yang sedang dibangun untuk mengetahui cara membangun jalur perakitan yang memproduksi produk tersebut.

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.

— Marcin
sumber

1

konstruksi perangkat lunak pada tingkat yang sama adalah sama terlepas dari produk perangkat lunak. Kami hanya menyebutnya sebagai metodologi alih-alih jalur perakitan , tetapi keduanya secara konseptual adalah hal yang sama.

1

@JarrodRoberson No. Jalur perakitan tidak seragam, dan metodologi umumnya tidak berlaku.

— Marcin

2

Saya setuju dengan Marcin, Anda harus memiliki pengetahuan tentang suatu produk untuk mengumpulkan jalur perakitan untuk produk tersebut. Anda harus dapat secara akurat memilih alat yang akan digunakan untuk mendapatkan hasil akhir yang benar. Dalam perangkat lunak suatu metodologi akan menjadi alat atau tugas tertentu. Jika satu tugas Anda adalah menyelesaikan tugas tertentu, Anda mungkin tidak perlu pengetahuan tentang keseluruhan. Tapi kemudian Anda seorang operator dan bukan seorang insinyur. Memilih set metodologi yang tepat untuk membentuk jalur perakitan membuat Anda seorang insinyur seperti halnya teknik lainnya. Tidak ada yang lebih khusus atau berbeda.

— RJay75

2

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.

— Atif
sumber

1

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 #.

— ozz
sumber

Saya pikir ini sudah pasti, tapi ini benar-benar tentang ROI. Saya tidak akan menyewa seorang insinyur dengan pengalaman Java utama, jika saya ingin mendapatkan proyek C ++ di 6 mos. Padahal, jika Anda memiliki proyek Swing yang perlu keluar dalam 6 mos, seorang insinyur sisi server utama mungkin masih memenuhi syarat.

— Spencer Kormos

@SpencerK sangat setuju. Itu tergantung seberapa cepat Anda membutuhkan ROI Anda. Jika Anda memiliki waktu yang lebih lama untuk menunggu, maka insinyur perangkat lunak yang lebih baik harus "menang".

— ozz

Juga, minus keras jika itu kamu!

— ozz

1

Tidak, bukan aku. Saya tidak mengundurkan diri tanpa komentar mengapa. Saya memiliki perilaku yang lebih baik dari itu!

— Spencer Kormos

1

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.

— Karl Bielefeldt
sumber

2

Betulkah? Saya kira Anda akan mengharapkan seorang insinyur keamanan untuk membuat dan mengkodekan game dalam 6 bulan, dan tidak dapat dibedakan dari spesialis yang berpengalaman.

— Marcin

Saya setuju dengan Marcin, bukan hanya pengetahuan tentang bahasa pemrograman atau platform. Saya telah bekerja di dua bidang berbeda dan menghabiskan beberapa tahun di masing-masing bidang: perlu waktu hingga Anda cukup akrab untuk benar-benar profesional dan produktif di satu bidang. Tentu saja, menjadi spesialis perangkat lunak yang berpengalaman mempercepat, tetapi saya rasa 2, 3 tahun daripada 6 bulan.

— Giorgio

1

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.

— Jaydee
sumber

1

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:

Bentuk tubuh dan teori warna: Patung, komik, dan lukisan
Komunikasi tekstual: Novel dan komik

... 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:

Algoritma: OS / sistem terintegrasi, permainan, dan tempat-tempat lain yang sering Anda butuhkan untuk mengoptimalkan kecepatan atau memori. Jarang sekali masalah besar dalam pengembangan web
Desain: Di mana-mana dalam pengembangan web, tetapi tidak terlalu penting dalam sistem terintegrasi tanpa UI.
Perangkat lunak klien / server: Mentalitas "jangan percayai klien", yang tidak selalu ada di beberapa domain (permainan pemain tunggal dan perangkat lunak desktop mandiri lainnya, yang saya akui lebih jarang belakangan ini).

— Izkata
sumber

Saya selalu berargumen bahwa pemrograman dan desain perangkat lunak adalah seni sama halnya dengan sains atau teknik. Saya kira ini adalah contoh lain bagaimana mereka mirip.

— Izkata

Oh, dan sebelum seseorang menggigit saya untuk itu, oleh "Algoritma", saya berbicara tentang CS-y tingkat tinggi. Tumpukan Fibonacci dan Timsort adalah dua yang muncul dalam pikiran. (Saya hampir tidak pernah bekerja pada tingkat kompleksitas algoritmik itu, jadi saya tahu sedikit tentang topik itu sama sekali)

— Izkata

0

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.

— Colin D
sumber

2

Ini analogi yang buruk, mereka berbicara tentang teknik, bukan pekerja konstruksi, meskipun mereka mencampur metafora dalam pertanyaan. Untuk itu semua insinyur sipil yang membangun jalan diharapkan dapat membangun segala jenis jalan! Seperti halnya setiap pengemudi truk pengangkut yang mengangkut aspal ke lokasi pembangunan tersebut harus dapat mengendarai truk jenis apa pun.

1

@JarrodRoberson Saya setuju bahwa ini analogi yang buruk, tapi saya tidak yakin pernyataan insinyur sipil Anda lebih baik. Tentu, setiap insinyur sipil harus dapat membaca rencana untuk jalan apa pun. Tetapi jika Anda membangun landasan pacu atau jalan es, apakah Anda ingin mempekerjakan seseorang yang menghabiskan waktu bertahun-tahun membangun jalan raya, atau apakah Anda ingin seseorang yang memiliki pengalaman khusus dengan landasan pacu atau jalan es?

— Caleb

0

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.

— Ruben Mallaby
sumber