Programmer memiliki ucapan berbeda tentang masalah yang sulit. Mungkin opsi favorit saya : "Ada dua masalah sulit dalam ilmu komputer: pembatalan cache, penamaan dan kesalahan per unit."

Saya telah menulis perangkat lunak cukup lama untuk menghadapi masing-masing masalah ini. Pada saat yang sama, saya berbicara dari sisi bisnis dan menjelaskan kepada pelanggan bagian teknis dari produk kami, oleh karena itu saya selalu bertemu dengan yang bukan programmer. Yang paling penting adalah menyampaikan ide atau konsep dengan benar sehingga orang lain memahaminya.

Dan ini sangat sulit.

Seperti dalam semua bidang profesional, programmer telah mengembangkan jargon mereka sendiri untuk mentransfer konsep dengan cepat.

Technolepet

Jargon sangat penting. Jika kolega saya dan saya memilih algoritme untuk menyelesaikan masalah tertentu, kita dapat mengatakan bahwa "opsi pertama O(n^2)dengan overhead minimal dari awal, dan yang kedua didepresiasi O(n log n), tetapi dengan instalasi dan konfigurasi yang mahal . "

Kalimat tunggal ini mengatakan banyak, untuk skenario mana algoritma harus digunakan dan bagaimana mereka diimplementasikan di bawah tenda:

Opsi A sangat bagus untuk sistem dengan sedikit input.
Opsi B bagus untuk bekerja dengan jumlah data input yang sangat besar, di mana biaya pemasangan dan konfigurasi sistem yang tinggi akan diimbangi dengan kinerja yang lebih baik dalam proses.
Jika Anda bermaksud menggunakan algoritme dalam satu lingkaran, Anda harus memilih opsi pertama untuk menghindari pemasangan yang mahal dan kode konfigurasi.
Mungkin kita dapat mengurangi biaya pemasangan opsi B menggunakan caching.
Mungkin, dalam opsi A, setiap elemen dari data input dibandingkan dengan yang lainnya (misalnya, for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Mungkin, opsi B pertama membuat pohon, kemudian melakukan pencarian linear, diikuti oleh pencarian di pohon ini.

Seperti yang Anda lihat, kami dapat menyampaikan beberapa paragraf informasi dalam satu kalimat, cukup menggunakan istilah yang benar.

Dalam hal ini, saya maksudkan algoritma untuk mendeteksi tabrakan, yaitu persimpangan antara dua atau lebih objek. Yang pertama memeriksa semua kemungkinan kombinasi data input, sedangkan yang kedua menggunakan kuadran pohon atau partisi ruang biner untuk memeriksa hanya elemen yang dekat.

Tetapi jika Anda memiliki pertemuan dengan orang-orang dari luar dunia pemrograman (misalnya, insinyur mekanik atau listrik, manajer, pemasar), jargon teknis ini hanya akan menghina dan membingungkan orang, tanpa mengirimkan hampir semua informasi berharga.

Inilah yang saya sebut technoleth, gumam seorang programmer.

Terus terang, biasanya detail dan istilah ini tidak diperlukan oleh orang-orang dari daerah lain, dan mereka benar-benar tidak peduli.

Misalnya, Anda menjelaskan fungsi baru yang luar biasa yang menemukan jalur terpendek dari A ke B, menghasilkan kotak navigasi dan menerapkan pencarian A * .

Dalam kasus apa pun Anda tidak perlu menggambarkan fungsi baru seperti pada kalimat sebelumnya. Sebaliknya, katakan sesuatu seperti ini:"Kami menghitung banyak jalur yang mungkin, dan kemudian menerapkan algoritma pintar yang digunakan dalam industri game untuk menemukan rute terbaik . "

Tidak masalah bahwa kami menggunakan pencarian A * di sini (tidak seperti algoritma Dijkstra atau pencarian lebar). Tidak masalah bahwa dalam game, pencarian A * digunakan tidak hanya untuk memindahkan karakter. Sudah cukup bagi teman bicara untuk mengetahui bahwa Anda dapat menemukan cara yang baik dari A ke B dan bahwa kami menggunakan alat yang andal yang telah diuji di area lain.

Tidak ada salahnya untuk menunjukkan ilustrasi apa yang Anda maksud ...

Saya kebetulan menyaksikan bagaimana programmer yang lebih berpengalaman menggunakan teknologi-jargon untuk menunjukkan keunggulan, untuk menunjukkan kecerdasan luar biasa mereka dan membangun dominasi. Ini sangat menjengkelkan.

Jangan salah, kadang-kadang ada situasi ketika lawan bicara yang cukup kompeten bertanya: "Ini sangat sulit, mengapa tidak membuat X?" - dan Anda harus menunjukkan bahwa Anda adalah seorang ahli di sini, tetapi dia tidak tahu apa yang dia bicarakan ... tetapi Anda masih bisa melakukannya dengan cara yang berbeda.

Jangan mencoba menggunakan technolepet untuk memuaskan ego Anda, itu mengasingkan orang dan memalukan profesi kita.

Menghormati

Jadi kita secara bertahap beralih ke poin berikutnya ... jangan lupa tentang rasa hormat.

Banyak orang yang bekerja dengan saya benar-benar pintar dan ahli di bidangnya, tetapi tidak harus mereka memiliki pengetahuan dan pengalaman yang cukup dalam menciptakan sistem informasi.

Ketika menjelaskan masalah yang kompleks, seringkali lebih baik untuk menyederhanakan konsep. Tetapi cobalah untuk tidak merendahkan.

Insinyur perangkat lunak yang saya sebutkan sering menjawab: "Ini ... rumit" ketika orang "normal" bertanya bagaimana fungsi ini atau itu bekerja. Seolah-olah kodenya begitu canggih sehingga tanpa 20 tahun pengalaman pemrograman Anda tidak dapat memahaminya.

Jangan lakukan seperti ini.

Jawaban terbaik:"Jika Anda menyederhanakan banyak hal, maka pertama kita lakukan X, lalu kita lakukan Y, dan akhirnya kita lakukan Z, tetapi Anda perlu mengingat selusin situasi perbatasan (mungkin menjelaskan satu atau dua), tetapi intinya adalah ini . " Kolega Anda cerdas dan tanpa techno-jargon cukup mampu memahami Anda.

Trik lain yang sangat berguna adalah menggunakan non-programmer sebagai deck, seperti bebek karet. Jika Anda sedang mengerjakan masalah yang rumit, jelaskan kepadanya dengan kata-kata sederhana solusi Anda dan tanyakan apakah Anda dapat menemukan pilihan yang lebih baik.

Perusahaan kami bekerja di bidang CNC, yaitu, ada hubungannya dengan dunia nyata (misalnya, ketika Anda mencoba menerapkan kompensasi untuk lebar potongan ). Insinyur sangat pandai menganalisis masalah yang berkaitan dengan fisika dan geometri.

Personifikasi, berlebihan dan analogi

Manusia adalah makhluk sosial. Kami diprogram untuk memahami hubungan dan menyukai analogi untuk menghubungkan konsep baru dengan yang sudah ada. Saat Anda berbicara dengan seseorang, Anda dapat menggunakan trik ini untuk membantu Anda memahami topik yang rumit.

Katakanlah perusahaan Anda memiliki sistem pengadaan online. Pemasar ingin memahami seluruh rantai mulai dari pesanan online hingga pengiriman paket untuk menjawab pertanyaan pelanggan dengan lebih baik. Saya bisa mengatakan sesuatu seperti ini:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

Semua ini terdengar agak lucu, dan contohnya lebih dari dibuat-buat, tetapi saya dapat menjamin bahwa ini adalah penjelasan yang lebih dimengerti daripada diagram jaringan besar dengan istilah "server web", "arsitektur acara", dan "Apache Kafka" (lihat bagian tentang teknolepte) )

Contoh lain. Jika Anda mencoba menjelaskan kepada orang luar bagaimana algoritma pencarian jalur bekerja, Anda tidak mengatakan "jalur yang dikunjungi diberi bobot lebih", Anda mengatakan "algoritma tersebut benar-benar tidak ingin mengikuti jalur yang sudah dilaluinya."

Ini adalah perbedaan yang halus, tetapi kami melakukan personifikasi algoritma. Kami mengatakan bahwa ia "sangat ingin membuat X" atau "berusaha sangat keras untuk menghindari Y". Seringkali ini membantu orang untuk mengerti .

Analogi yang berguna dengan contoh-contoh (jika perlu). Anda mungkin sudah memperhatikan bahwa artikel ini penuh dengan contoh. Alih-alih penjelasan abstrak, saya menceritakan kisah-kisah spesifik yang membantu menjelaskan tesis. Ini bukan sebuah kecelakaan.

Buat gambar yang indah

Kedengarannya klise, tetapi terkadang sebuah gambar benar-benar bernilai ribuan kata.

Beberapa bulan yang lalu saya membaca sebuah kursus di radio, dan gadis di dekatnya tidak dapat mengingat tombol mana yang harus ditekan pada menu LCD 16 × 2 kecil ini.

Saya bertanya apakah dia bisa menggambar diagram.

Dia mengira aku orang yang cerdas dan mengejeknya.

Tapi saya tidak bercanda.

Sebagai gantinya, saya menemukan selembar kertas, dan bersama-sama kami membuat sesuatu seperti ini:

Pemrogram segera mengenali diagram keadaan dari teori automata. Tanpa diketahui seorang gadis, saya memperkenalkan teknik dasar ilmu komputer ke dalam otaknya dan bagaimana antarmuka radio ini diprogram di bawah tenda.

Tapi dia (dan semua orang pada tahap ini) tidak peduli tentang sains. Mereka mendapat peta yang bisa mereka gunakan untuk menavigasi antarmuka pengguna.

Ada beberapa kesenangan aneh dalam mengadaptasi konsep kompleks untuk seseorang dari daerah lain. Terutama ketika mereka dapat menentukan bahwa peta itu benar-benar bug: Anda perlu menekan dan menahan tombol Batal untuk kembali ke status siaga, karena menekan tombol ini biasanya mengembalikan Anda ke "Menu Utama".

Saya selalu punya notebook besar dengan seprai kosong di meja saya. Biasanya saya menulis daftar yang harus dilakukan atau beberapa gambar selama refleksi, tetapi sering membantu menjelaskan. Kemampuan untuk menggambar sesuatu selama percakapan membantu untuk memverifikasi kursus dan memastikan bahwa Anda berada pada gelombang yang sama (maksud kata) bahwa Anda memiliki ide yang sama.

Saya mempercepat $ FITUR sepuluh kali lipat

Misalkan Anda membuat beberapa penyesuaian kinerja, dan sekarang sepotong kode bekerja lebih cepat. Bagaimana menjelaskan ini kepada non-programmer atau seseorang yang tidak melihat kode sumber?

Di satu sisi, untuk pertanyaan tentang apa yang Anda lakukan minggu lalu, Anda dapat mengatakan yang sebenarnya kepada orang itu: "Saya menambahkan caching lookup_something ()untuk mempercepat pencarian umum dan menerjemahkan algoritma dari detect_collisions()c O(n^2)ke O(n log n)" , tetapi dengan probabilitas tinggi mereka tidak akan mengerti apa-apa (lihat technolept ) .

Anda juga dapat mengatakan bahwa Anda "mengoptimalkan produktivitas" , tetapi itu kedengarannya seperti alasan, dan manajer akan memikirkan mengapa ia mempekerjakan Anda.

Seringkali, pengembang mengatakan, "Saya mempercepat $ FITUR sepuluh kali lipat."(atau nomor sewenang-wenang lainnya) dan ini terbatas. Ungkapan seperti itu memungkinkan Anda untuk menikmati banyak ucapan selamat dari penduduk kota, tetapi seringkali itu sedikit ... menyesatkan.

Dalam kebanyakan kasus, Anda benar-benar meningkatkan kinerja beberapa fungsi, tetapi jika fungsi-fungsi ini bukan hambatan kinerja, maka dengan probabilitas tinggi tidak ada yang akan melihat perbedaan.

Catatan. Jika Anda terbiasa dengan hukum Amdahl, maka meningkatkan kinerja fungsi yang tidak menjadi hambatan sama seperti menggunakan lebih banyak inti CPU untuk tugas yang pada dasarnya konsisten.

Pertanyaannya juga memohon: apa yang telah Anda lakukan untuk meningkatkan produktivitas sepuluh kali lipat? Apakah ini angka yang sangat spesifik, sudahkah kode sumber Anda mengulangi satu pekerjaan beberapa kali? Atau apakah dia meminta data (misalnya, dari perangkat keras atau situs pihak ketiga) sepuluh kali lebih lambat dari yang seharusnya? Bahkan ini membuat saya meragukan kemampuan Anda, karena Anda menebak (dengan buruk) kecepatan polling awal, atau Anda masih mengorbankan kinerja dengan menggunakan polling alih-alih arsitektur acara yang lebih efisien.

Bagi saya, lebih baik mencoba menemukan jalan tengah antara akurasi dan kelayakan. Jika Anda membuat perubahan yang meningkatkan kompleksitas algoritme dari fragmen kode (misalnya, fungsi detect_collisions()dialihkan dari O(n^2)ke O(n log n)), maka Anda dapat mengatakan:"Fungsi X sekarang dapat skala ke sejumlah besar input dalam jumlah waktu yang wajar, tetapi tidak bisa sebelumnya . "

Itu normal untuk mengatakan "Saya tidak tahu" ...

... dan lanjutkan seperti ini: "... tetapi jika Anda memberi saya lima menit, saya dapat memberi tahu Anda" .

Saya sering melihat ini. Orang takut untuk menunjukkan ketidaktahuan mereka, oleh karena itu mereka diam, tersiksa atau menciptakan sesuatu.

Misalnya, jika seorang manajer mendatangi Anda dan bertanya: “Klien meminta fungsi X, apakah ini mungkin? Dan berapa lama? ”

Dalam sembilan dari sepuluh kasus, jawaban jujurnya adalah "Saya tidak tahu," tetapi itu tidak benar-benar membantu manajer memutuskan waktunya. Dia menoleh kepada Anda karena Anda adalah seorang ahli di bidang yang relevan dan paling siap untuk memberikan jawaban.

Beberapa mencoba menebak atau menipu (misalnya, "Ya, kami akan melakukannya dalam dua hingga tiga minggu"), tetapi pendekatan ini biasanya tidak berhasil dalam jangka panjang. Dalam kasus terbaik, Anda akan ditunda selama beberapa minggu, dan dalam kasus terburuk, menghabiskan waktu berbulan-bulan hanya untuk mengetahui bahwa fungsi ini tidak dapat bekerja dengan arsitektur aplikasi saat ini.

Ini adalah cara yang bagus untuk kehilangan rasa hormat dari kolega dan atasan.

Di sisi lain, kata-kata "Tidak yakin, tetapi berikan 5-10 menit, dan saya akan punya jawaban" menunjukkan beberapa hal sekaligus:

Anda siap mengakui bahwa Anda tidak tahu segalanya (yaitu, bukan egois narsis).
Anda bertanggung jawab atas kata-kata Anda dan tidak ingin memberikan jawaban yang tidak akurat.
Anda cukup menghormati orang itu untuk menghabiskan sebagian dari waktu Anda membantu menjawab pertanyaannya.
Anda pria yang baik :).

(Dan Anda punya cukup waktu untuk mencari tahu).

Itu menyerupai perumpamaan lama :

Orang lain (biasanya) tidak berharap Anda tahu segalanya di bidangnya. Alih-alih, mereka mengharapkan Anda memiliki alat untuk meneliti pertanyaan dan menerjemahkan jawabannya ke dalam istilah yang dapat mereka pahami.

Insinyur lama pensiun, dan setelah beberapa minggu Mesin Besar mogok, yang sangat penting bagi pendapatan perusahaan. Manajer tidak dapat membuat mesin bekerja lagi, sehingga perusahaan mengundang insinyur lama sebagai konsultan independen.

Dia setuju. Sesampainya di pabrik, dia melihat Mesin Besar, mengambil palu dan memukulnya sekali. Setelah itu, mobil mulai bekerja. Insinyur tua itu pergi, dan perusahaan mulai menghasilkan uang lagi.

Hari berikutnya, manajer menerima faktur dari insinyur lama sebesar $ 5.000. Manajer itu sangat marah dan menolak untuk membayar. Insinyur lama memastikan bahwa ini adalah harga yang wajar. Manajer menjawab bahwa jika ini adalah harga yang wajar, maka Anda dapat meminta detail akun.

Akun baru yang terperinci terlihat seperti ini ...

Palu: $ 5

Ketahui di mana mobil menabrak palu: $ 4995

Siapa pun dapat mengajukan pertanyaan kepada Google. Tetapi hanya seorang insinyur perangkat lunak yang tahu kata kunci mana yang digunakan dan bagaimana menginterpretasikan hasil.

temuan

Biasanya di blog saya, saya menerbitkan artikel yang sepenuhnya teknis dengan banyak kode, tetapi terkadang berguna untuk mengingat bahwa ada hal lain di dunia ini selain kode.

Programmer (bukan tanpa alasan) dianggap sebagai orang dengan keterampilan sosial dan komunikasi yang lemah. Tetapi bagian penting dari pekerjaan kami membutuhkan komunikasi yang efektif. Saya harap pengalaman saya akan membantu Anda dengan sesuatu.

Beberapa orang mungkin menganggap ini sebagai "politik kantor" dan manipulasi pendapat orang lain. Inilah yang akan saya jawab:

Baiklah. Tetapi apakah ini tidak berlaku untuk sebagian besar interaksi interpersonal?

Psikologi hanya membantu programmer berbicara dengan bahasa yang sama dengan non-programmer dan bekerja bersama untuk mencapai tujuan bersama.

Berbicara itu sulit. Esai tentang Berkomunikasi dengan Non-Programmer