Bagaimana Anda membagikan kerajinan Anda dengan yang bukan programmer?

Terkadang saya merasa seperti seorang musisi yang tidak bisa memainkan pertunjukan langsung. Pemrograman adalah keterampilan yang sangat keren, dan dunia yang sangat luas, tetapi banyak yang terjadi "di luar kamera" - di kepala Anda, di kantor Anda, jauh dari penonton.

Anda tentu saja dapat berbicara tentang pemrograman dengan programmer lain, dan ada pemrograman peer, dan Anda dapat membuat sesuatu yang dapat Anda tunjukkan kepada orang-orang, tetapi ketika datang untuk menjelaskan kepada non programmer apa yang Anda lakukan, atau bagaimana itu hari Anda di tempat kerja, agak sulit.

Bagaimana Anda membuat non-programmer dalam hidup Anda untuk memahami apa yang Anda lakukan?

CATATAN: ini bukan pengulangan Mendapatkan non-programmer untuk memahami proses pengembangan , karena pertanyaan itu adalah tentang mengelola harapan klien.

Tiga kata:

dumb it down

Pemrogramannya kompleks. Butuh banyak kerja keras untuk memahaminya. Dan kegembiraan pemrograman bahkan lebih halus.

Bagi saya untuk mengomunikasikan keberhasilan saya dan hal itu kepada orang lain (yaitu keluarga) saya harus berkomunikasi pada tingkat yang lebih umum. Bandingkan pemrograman dengan hal-hal dunia nyata yang normal.

(Yaitu objek ke mobil dengan papan dasbor dan kursi dan ....)

Bahkan lebih baik jika Anda tahu sesuatu tentang audiens Anda karena Anda dapat menggunakan hal-hal yang mereka pahami yang lebih kompleks daripada konsep sehari-hari normal.

Sebagai contoh, istri saya adalah seorang guru sekolah, jadi saya dapat membandingkan beberapa proses pengembangan perangkat lunak saya dengan proses pengajaran yang harus ia gunakan. Ini sangat membantu.

Tetapi pada akhirnya Anda harus menyederhanakan, menyederhanakan dan menyederhanakan lagi. Dan bahkan kemudian, sulit untuk membuat seseorang mengerti betapa kerennya kelas yang dikerjakan dengan baik dengan unit test yang baik. :)

Saya bahkan tidak mencoba. Jika mereka tidak cukup berorientasi teknologi untuk memiliki setidaknya pemahaman dasar pemrograman, saya hanya akan membuat mereka bosan dengan detailnya. Biasanya saya hanya pergi dengan sesuatu yang sangat tinggi seperti "Saya membuat situs web" atau "Saya menulis program komputer untuk melakukan X"

Saya mencoba menjelaskannya dalam hal memecahkan masalah. Saya hanya memilih menggunakan program komputer untuk menyelesaikan masalah. Dengan begitu Anda dapat mendiskusikan apa yang telah Anda lakukan dalam hal masalah yang Anda coba selesaikan. Begitu mereka memahami hal itu, lompatan untuk menyelesaikannya melalui pemrograman tidak terlalu jauh dan biasanya dapat dibuat oleh tipe non techie.

Kakak saya, Rob, bertanya tentang hal itu. (Dia seorang seniman dan ilustrator, seperti buku anak-anak, interior museum, hal-hal seperti itu.)

Saya mencoba menjelaskannya dengan memperlihatkan kepadanya Harry Porter's Relay Computer , karena saya pikir itu menangkap esensi komputer dan pemrograman dengan cara yang terasa seperti usus.

Itu bukan yang dia inginkan, dan aku agak bingung.

Baru kemudian saya menyadari apa masalah sebenarnya. Saya teringat akan kutipan Oscar Wilde ini:

Faktanya, peradaban itu membutuhkan budak. Orang-orang Yunani ada di sana. Kecuali ada budak untuk melakukan pekerjaan yang buruk, mengerikan, tidak menarik, budaya dan kontemplasi menjadi hampir mustahil. Perbudakan manusia salah, tidak aman, dan melemahkan moral. Pada perbudakan mekanis, pada perbudakan mesin, masa depan dunia tergantung.

Yang menggairahkan saya sebagai seorang insinyur adalah saya membangun budak mekanik. Sebagai seorang anak saya ingin meletakkan bendungan di sungai, dan memiliki roda air membuat listrik, sehingga bisa melakukan sesuatu untuk saya , sementara saya hanya menonton. Di mesin di mobil, ada camshaft. Ini sebenarnya adalah program primitif. Membuka dan menutup katup ketika saya menginginkannya, jadi saya tidak perlu melakukannya.

Dunia seorang seniman sangat berbeda. Jika Anda mendengarkan, dengan mata terpejam, untuk membawakan simfoni ke-9 Beethoven, Anda dipindahkan. Anda harus memberikan perhatian penuh Anda, dan ketika selesai, Anda merindukannya. Jika Anda mengunjungi rumah karya Frank LLoyd Wright, Falling Water, Anda diangkut. Jujur saya tidak tahu bagaimana orang bisa hidup di dalamnya. Di mana Anda bisa membuat kekacauan? Ini menangkap Anda sepenuhnya. Ini adalah simfoni arsitektur.

Seni tidak melakukan sesuatu untuk Anda, itu melakukan sesuatu untuk Anda.

Saya telah mencoba menemukan seni dalam apa yang saya lakukan. Ada keindahan di dalamnya, jika Anda melihat, tetapi Anda harus melihatnya. Itu yang akan menghubungkan kita.

Bercerita. Jangan fokus pada apa yang Anda lakukan, tetapi pada perasaan Anda ketika melakukannya, bagaimana Anda bersemangat atau bosan tentang hal itu, pada hubungan dengan rekan kerja Anda.

Dua analogi saya untuk tujuan ini adalah: resep, dan birokrasi besar-besaran. Itulah yang saya jelaskan dalam QA ini: 30 menit untuk menjelaskan pemrograman ke anak berusia 15 tahun

Saya telah menggunakan analogi resep berkali-kali untuk menjelaskan bagaimana pemrograman tentang penulisan serangkaian instruksi yang keras yang memiliki hasil yang nyata dan dapat diprediksi ketika diikuti.

Saya hanya menggunakan analogi birokrasi beberapa kali sebenarnya, karena kebanyakan orang tidak benar-benar perlu memahami di luar analogi resep, tetapi kedua kali sangat mencerahkan bagi orang tersebut. Mereka tampaknya berpikir pemrograman berarti penarikan total setiap baris kode (mis. "Tetapi jika Anda memiliki memori yang jelek, lalu bagaimana Anda dapat memprogram komputer?") Tetapi sebenarnya ini tentang membangun banyak modul mandiri yang bekerja bersama untuk mencapai tujuan yang lebih besar. Modul-modul suatu program seperti departemen dalam perusahaan besar: unit mandiri yang sebagian besar berurusan dengan bagian mereka sendiri secara keseluruhan dan berkomunikasi dengan departemen lain melalui memo.

Saya pikir saya mendapatkan respons paling banyak ketika saya menjelaskan sesuatu dalam hal ide di balik kode, bukan kode itu sendiri. Saya hanya menghapus semua jargon teknis, hindari menyebutkan istilah pemrograman terkait dan hanya berbicara tentang ide dan apa yang sebenarnya sedang dilakukan .

Misalnya, saya baru-baru ini mencoba menjelaskan cara kerja filter spam. Saya hanya mengatakan itu menyimpan catatan dari kata-kata yang biasanya ditemukan dalam spam dan yang tidak ditemukan dalam spam. Catatan ini dibangun menggunakan spam yang dikenal dan email non-spam. Setelah itu, setiap kali email baru tiba, kami hanya memeriksa berapa banyak kata di sana yang tampak seperti spam (misalnya, ada dalam catatan kata-kata yang mengandung spam) dan berapa banyak yang terlihat bukan spam. Jika ada terlalu banyak kata-kata spam, itu mungkin spam dan dikirim ke tempat sampah. Orang-orang non-teknologi yang saya ajak bicara mengikuti ide dengan cukup baik.

Metafora

Sering kali, saya tidak menggambarkannya sebagai program sama sekali, saya mencoba untuk menggambarkannya sebagai konsep yang sama sekali berbeda dengan hubungan timbal balik yang serupa.

Itu membuat memvisualisasikan program jauh lebih menarik dan kadang-kadang itu membantu saya melihatnya dengan cara baru.

Anda tidak menggambarkan listrik kepada seseorang yang belum pernah bekerja dengannya dengan membicarakan arus dan voltase, bukan? Plus, menyenangkan untuk menggambarkan beberapa konsep seolah-olah beberapa proses komputer yang sangat sadar membuat mereka terjadi seolah-olah dengan sihir. Sebuah imajinasi cerita kecil tidak melukai mereka sebagai kenyataan betapa dingin dan rasionalnya komputer sebenarnya.

Saya telah menjawab pertanyaan serupa dengan lebih terperinci , tetapi intinya adalah, "Pemrograman seperti membangun pabrik atau jalur perakitan."

Banyak orang yang belum memprogram tampaknya percaya bahwa seorang programmer menghabiskan banyak waktu dengan memburu bug, secara visual mencari ribuan baris kode untuk koma yang salah. Jadi saya pertama-tama meyakinkan mereka bahwa ini bukan masalahnya, dan jika ya, saya akan benar-benar putus asa.

Saya sering membandingkan pemrograman komputer dengan menulis buku resep. Buku masak adalah sekumpulan instruksi untuk orang, sedangkan program komputer adalah sekumpulan instruksi untuk sebuah komputer. Beberapa program jauh lebih kompleks daripada buku masak, dan program dimodifikasi lebih sering, tetapi ada beberapa kesamaan dalam struktur. Jika sebuah buku masak berisi tujuh salinan instruksi untuk membuat saus, dan resepnya harus diubah, seseorang harus menemukan semua salinan itu dan memperbaiki semuanya.

Saya pikir analogi yang baik adalah membangun pabrik. Sebagian besar orang telah melihat sesuatu seperti "How it Made" di mana Anda melihat beberapa item dikocok melalui berbagai ban berjalan dan mesin dengan mudah-mudahan produk jadi keluar di akhir. Saya memberi tahu orang-orang bahwa saya membangun hal-hal seperti itu, tetapi alih-alih menjadi pabrik fisik yang mengerjakan barang fisik, mereka adalah virtual dan mereka mengerjakan data. Tentu saja ini bukan analogi yang baik untuk semua jenis pemrograman, tapi saya pikir jika memberikan ide yang bagus tentang kompleksitas dan melakukan paralel berbagai macam aplikasi.

Anda sepertinya tidak bisa membagikan kerajinan Anda - hanya berita utama tentang pekerjaan Anda dengan orang lain

Namun, yang dapat Anda lakukan adalah alih-alih membagikan kerajinan Anda, adalah membagikan hidup Anda dengan orang-orang yang berada di kerajinan yang sama dengan Anda (:

Saya biasanya tidak berbicara tentang bagaimana hal itu dilakukan, tetapi lebih pada fitur pekerjaan .

Saya biasanya menekankan bahwa ini sangat rumit, sangat rumit sehingga tidak ada orang yang bisa berharap untuk mulai memahami dengan detail sempurna apa yang sedang terjadi. Mungkin perlu 30 tahun mempelajari berbagai bagian yang berinteraksi (elektronik melalui kerangka kerja), ditambah sekitar satu jam per baris kode aktif, dan pada saat itu Anda harus kembali untuk belajar karena perangkat keras akan berubah begitu banyak sehingga itu 10 tahun lagi grokking versi terbaru.

Bagian penting lainnya adalah betapa berharganya bisa menciptakan sesuatu yang begitu fleksibel sehingga ribuan, mungkin jutaan orang dapat menggunakannya untuk memperkaya kehidupan mereka, sesuatu yang unik (setidaknya secara detail), dan sesuatu yang telah Anda pelajari banyak dari hal itu.

Jika tidak ada yang menjejali mulut saya dengan kaus kaki pada saat ini, saya akan dengan senang hati mendemonstrasikan aplikasi, menunjukkan sedikit kerumitan yang terlibat dan fleksibilitas yang mungkin.

Saya mengatakan kepada mereka bahwa di luar penulisan simfoni dan tesis matematika dan novel, pemrograman adalah satu-satunya kesempatan Anda akan terlibat dengan tugas / struktur dengan tingkat kompleksitas dan kerumitan ini. Tentu saja, tidak mengatakan bahwa aplikasi web yang layak adalah mahakarya bersejarah, tetapi begitu orang-orang menyadari bahwa Anda dapat menggunakan pikiran Anda pada level semacam ini setiap hari, maka mereka 'mengerti.' Banyak pekerjaan yang layak dan bergaji tinggi, namun turun ke tugas prosedural yang cukup sederhana yang diulang-ulang.

Setidaknya, begitulah cara saya melihatnya. Saya bisa saja salah.

Sebagai jawaban berbeda dari 15 jawaban lainnya ...

Alih-alih menjelaskan rincian pekerjaan saya (pemrograman), saya mencoba untuk fokus pada solusi yang diselesaikan oleh pekerjaan tersebut, yaitu masalah apa yang sebenarnya diselesaikan oleh sistem / perangkat lunak yang saya buat untuk pengguna. Itu biasanya domain non-pemrograman, kecuali Anda menulis kompiler atau sesuatu, dalam hal ini Anda harus menjelaskan mengapa itu berguna.

Dengan begitu, hal ini memudahkan orang untuk memahami bahwa itu sifat yang kompleks dan bagaimana hubungannya dengan "dunia nyata".

Sebagai analogi, sebagai pandai besi abad pertengahan, saya mungkin akan menjelaskan (kepada wanita di kedai lokal) bahwa saya membuat pedang untuk meretas musuh menjadi potongan-potongan, bukan bagaimana saya melunakkan baja dan palu di atasnya dengan sudut dan kekuatan tertentu (kecuali mereka bertanya). Mudah-mudahan, dia akan mengerti bahwa meretas musuh menjadi beberapa bagian berguna (...) dan bisa sulit dilakukan (kekurangan baja, musuh lapis baja, tempat kerja yang berasap, dll) dan dengan demikian Anda mendapatkan apresiasi untuk melakukan tugas yang kompleks.

(Jadi, casting landasan akan sama dengan membuat kompiler, dan Anda harus menjelaskan untuk apa mereka digunakan ...)

Saya membandingkannya dengan membangun rumah, jika kita hidup di alam semesta yang aneh dengan partikel eksotis dan anti waktu:

Anda punya ide untuk rumah yang benar-benar keren, jadi Anda membuat sketsa kasar seperti apa bentuknya, dan memiliki rencana umum tentang bagaimana melanjutkannya. Anda pergi ke toko perangkat keras dan membeli kayu untuk membangun dinding, tetapi mereka jatuh karena tanahnya tidak rata. Jadi Anda pergi dan membeli semen untuk membuat fondasi, tetapi semen tidak akan mengering dan Anda tidak tahu mengapa. Anda kembali ke toko perangkat keras dan bertanya mengapa, tetapi karyawan pergi katatonik. Anda pergi ke 8 toko perangkat keras yang berbeda sampai ada yang memberi tahu Anda bahwa semen yang Anda gunakan dikembangkan pada musim gugur 1989, tetapi Anda membeli properti Anda pada musim dingin 1989, sehingga mereka tidak kompatibel, dan dia menjual semen 2013.1.1 yang paling baru kepada Anda. Anda kembali untuk meletakkan fondasi dan segera setelah Anda melakukannya, semen menghilang. Kali ini semua karyawan menggunakan katatonik, jadi Anda google rumah Anda dan menemukan bahwa itu pernah menjadi situs pengujian nuklir. Kemudian Anda google efek pengujian nuklir di tanah dan menemukan bahwa itu menyebabkan radikal bebas. Anda google itu dan mulai meneliti radiasi elektromagnetik, kemudian fermion, kemudian boson, kemudian teori string, dan sesuatu tentang kucing. Anda tidak ingin menyerah karena Anda telah membuang banyak waktu, sehingga Anda memukul botol dengan keras. Kamu pulang terlambat dan melampiaskan amarahmu pada istrimu, mengklaim bahwa dia adalah alasan kamu tidak bisa membangun rumah karena dia dan anak-anak menghabiskan seluruh waktumu ... Kira-kira 3 bulan kamu sadar kamu pergi dari dan sesuatu tentang kucing. Anda tidak ingin menyerah karena Anda telah membuang banyak waktu, sehingga Anda memukul botol dengan keras. Kamu pulang terlambat dan melampiaskan amarahmu pada istrimu, mengklaim bahwa dia adalah alasan kamu tidak bisa membangun rumah karena dia dan anak-anak menghabiskan seluruh waktumu ... Kira-kira 3 bulan kamu sadar kamu pergi dari dan sesuatu tentang kucing. Anda tidak ingin menyerah karena Anda telah membuang banyak waktu, sehingga Anda memukul botol dengan keras. Kamu pulang terlambat dan melampiaskan amarahmu pada istrimu, mengklaim bahwa dia adalah alasan kamu tidak bisa membangun rumah karena dia dan anak-anak menghabiskan seluruh waktumu ... Kira-kira 3 bulan kamu sadar kamu pergi darihampir menyelesaikan rumah, bahkan tidak tahu mengapa Anda ingin membangun rumah di tempat pertama.

Saya hanya memberi tahu mereka bahwa yang saya lakukan adalah melihat apa yang mereka lakukan untuk pekerjaan mereka dan membuat perangkat lunak komputer yang akan membuat pekerjaan mereka lebih mudah.

Seperti yang Anda katakan, gunakan analogi, itu masuk akal bagi mereka. Saya selalu mencoba membawa Google, entah bagaimana, jika kode saya melakukan sesuatu seperti google, atau menunjukkan manfaat finansial, atau bagaimana ini membantu orang dengan cara tertentu ...

Saya terkadang menyerah dan hanya mengatakan saya menghabiskan hari saya mengedit file teks. Yang biasanya benar kalau bukan cerita lengkap.