I believe that it is better to be looked over than it is to be overlooked (Mae West, Belle of the Nineties, 1934)

Kita bisa belajar dari kutipan di atas. Bukan hanya apa yang kita pikirkan, tapi bagaimana cara kita mengemasnya. Memiliki ide-ide terbaik, code dengan pendekatan terbaik, atau pemikiran paling pragmatis sekalipun pada akhirnya akan menguap, kecuali kita dapat menyampaikannya kepada orang lain. Ide yang cemerlang akan sia-sia jika tanpa komunikasi yang efektif.

Sebagai developer, kita juga berkomunikasi di berbagai jenjang. Kita menghabiskan berjam-jam dalam rapat, mendengarkan, dan berbicara. Kita juga bertemu dengan end user, mencoba memahami apa yang mereka butuhkan. Kita juga menulis kode, secara tidak langsung kita juga berkomunikasi dengan mesin dan menuangkan pemikiran kita ke dalam baris kode. Kita juga menulis SAD (service architecture diagram) atau memo untuk melaporkan status pekerjaan, atau mungkin memberikan saran kepada atasan jika kita menemukan pendekatan yang baru. Dan tidak lupa, kita juga bekerja dalam tim. Sebagian besar hari kita habiskan untuk berkomunikasi di berbagai jenjang dan dengan berbagai bentuk. Jadi, kita perlu melakukannya dengan baik.

Perlakukan “bahasa indonesia” (atau apapun bahasa yang kita pakai) selayaknya bahasa pemrograman lain. Tulis percakapan kita sebagai mana kita menulis kode: hormati prinsip DRY (don’t repeat yourself), ETC (easier to change).

English is just another programming language

Know your audience

Kita berkomunikasi hanya jika kita ada informasi yang perlu disampaikan. Untuk melakukan itu, kita perlu memahami kebutuhan, minat, dan kemampuan lawan bicara kita. Bayangkan kita sedang rapat dimana tim product engineer sedang menatap dengan tatapan tajam ke arah VP of Marketing dengan monolog panjang mengenai manfaat dari penggunaan microservice. Situasi tersebut bukan komunikasi. Itu hanya ceramah, dan itu sangat membosankan.

Katakanlah kita ingin menyarankan penggunaan microservice tersebut untuk campaign harbolnas tahun depan. Kita dapat memaparkan sistem dari microservice tersebut dalam beberapa bentuk yang berbeda, tergantung dari audiens yang kita ajak bicara. Paparkan bahwa dengan memakai pendekatan tersebut, pelanggan akan lebih mudah menemukan banner campaign, cukup dari homepage aplikasi atau website kita. Tim marketing juga akan lebih mudah mengunggah banner campaign sesuai dengan target market yang diincar. Para manager di divisi marketing setidaknya memiliki dua alasan positif untuk menggunakan microservice tersebut: tim marketing dapat dengan mudah menjalankan campaign mereka dan target market yang tepat sasaran. Akhirnya, ide yang tim product engineer usulkan dapat terlihat manfaatnya bahkan oleh orang non-tech sekalipun. Dan peserta rapat juga akan bersemangat untuk mengeksekusi proyek tersebut.

Know what you want to say

Mungkin bagian tersulit dari gaya komunikasi yang lebih formal adalah mengetahu apa yang ingin kita tulis. Para penulis novel fiksi sering merencanakan buku-buku mereka secara terperinci sebelum mereka mulai menulis. Tetapi orang-orang yang menulis dokumen teknis sering duduk di depan keyboard, dan menulis:

1. Pendahuluan

Rencanakan apa yang ingin kita katakan. Tulis garis besarnya. Lalu tanyakan pada diri kita sendiri, “does this communicate what I want to express to my audience in a way that works for them?”. Sempurnakan tulisan tersebut hingga menurut kita sudah jelas.

Pendekatan ini tidak hanya berlaku untuk penulisan dokumen. Saat kita dihadapkan dengan rapat penting atau panggilan telepon, catat ide-ide yang ingin kita komunikasikan, dan rencanakan beberapa strategi untuk menyampaikannya.

Sekarang setelah kita tahu apa yang diinginkan audiens kita, sekarang saatnya merencanakan bagaimana cara melakukannya.

Choose your moment

Bayangkan sekarang pukul enam sore di hari Jumat. Beberapa dari rekan kerja kita sudah berkemas-kemas untuk meninggalkan meja kerja mereka. Ada yang langsung pulang ke rumah, ada juga yang mampir ke kafe untuk bertemu kawan lama mereka. Mereka siap untuk menyambut weekend. Dan ini mungkin bukan saat yang tepat untuk kita meminta mereka melakukan code review untuk PR kita.

Sebagai bagian dari “know your audience”, kita perlu tahu prioritas mereka saat itu. Sekarang hari jumat dan rekan kerja kita ingin mengakhiri jam kerja mereka. Code review tentulah bukan suatu yang mendesak. Kita bisa menunda hingga hari senin untuk meminta bantuannya. Terkadang yang kita perlukan hanyalah pertanyaan sederhana, “apakah ini saat yang tepat untuk membicarakannya?”.

Choose a style

Sesuaikan gaya tulisan dengan orang yang akan membaca tulisan kita. Beberapa orang menginginkan tulisan yang to-the-point, beberapa yang lain menyukai obrolan panjang sebelum menuju ke inti pesan. Perhatikan juga tingkat keahlian dan pengalaman mereka. Apakah mereka sudah ahli, atau masih pemula?

Jika kita melihat orang yang menerima pesan kita merasa kesulitan memahami gaya bahasa kita, maka selalu terbukalah terhadap feedback. Dari masukan mereka, kita bisa menjadi lebih baik.

Make it look good

Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.

Banyak software engineer (mungkin di tingkat manager) fokus hanya pada konten saat membuat dokumentasi tertulis. Akan lebih baik jika kita juga memperhatikan bagaimana cara menyampaikan pesan, diksi yang kita pilih, hingga susunan paragraf yang membuat pembaca menjadi nyaman.

Saat ini tidak ada alasan untuk tidak menghasilkan dokumentasi yang buruk. Banyak perangkat lunak modern yang dapat menghasilkan output yang baik, terlepas apakah kita sedang menulis menggunakan markdown, atau menggunakan word processor. Kita hanya perlu mempelajari beberapa perintah dasar. Jika kita menggunakan word processor (Word misalnya), gunakan style sheet nya supaya konsisten. Pelajari cara mengatur header dan footer halaman. Lihat pula sampel dokumen (biasanya perusahaan sudah menyediakan ini sebagai acuan). Periksa ejaan kata supaya tidak ada yang miss di pembaca.

Involve your audience

Kita sering menemukan bahwa dokumen yang kita hasilkan berakhir kurang penting dibandingkan dengan proses yang kita lalui untuk menghasilkanya. Jika memungkinkan, libatkan target pembaca dokumen kita dari awal. Dapatkan feedback dari mereka. Kita bisa membangun hubungan kerja yang baik dari proses tersebut.

Be a listener

Hanya ada satu teknik yang harus kita gunakan supaya orang mau mendengarkan kita: dengarkan mereka terlebih dahulu. Ketika kita menjadi salah satu orang yang paling paham tentang sebuah konsep di sebuah forum, atau ketika kita sedang presentasi di depan puluhan orang berdasi, jika kita tidak mendengarkan mereka, merekapun juga tidak akan mendengarkan kita.

Dorong mereka untuk berbicara dengan cara menanyakan pertanyaan, atau juga bisa dengan cara meminta mereka untuk merangkum apa yang sudah kita sampaikan ke mereka. Ubah rapat yang kaku menjadi dialog.

Get back to people

Jika kita bertanya ke seseorang secara langsung, mereka akan merasa tidak sopan jika tidak menjawab pertanyaan kita. Tapi seberapa sering kita gagal mendapatkan respon dari orang lain ketika kita bertanya tentang sebuah informasi melalui email atau memo? Dalam kesibukan sehari-hari, hal tersebut sering terlupakan. Jika kita mendapatkan email dari orang lain, selalu tanggapi dengan segera, meskipun hanya dengan “saya akan menghubungimu nanti”. Tindakan seperti itu membuat mereka merasa bahwa kita tidak melupakan mereka.

Kuncinya adalah efektif. Sebisa mungkin jadikan komunikasi yang kita jalin seefektif mungkin, meskipun kegiatan komunikasi tersebut tidak terjadi secara langsung face-to-face.

Documentation

Biasanya, programmer atau software engineer tidak terlalu memperhatikan dokumentasi. Dokumentasi sering dianggap sebagai kebutuhan yang tidak menguntungkan, atau setidaknya jika kita mengerjakan dokumentasi, tugas tersebut diberikan prioritas yang paling rendah. “Iyalah. Lebih penting bikin fitur A daripada harus mengorbankan waktu untuk bikin dokumentasi”.

Seharusnya dokumentasi bisa dijadikan sebagai bagian integral dari seluruh proses development. Dengan adanya dokumentasi, pekerjaan kita akan menjadi lebih mudah karena kita tidak perlu membuang waktu ataupun “copy-paste” pekerjaan kita sebelumnya.

Sangat mudah untuk menghasilkan dokumentasi yang terlihat bagus dari comment yang kita selipkan di source code, dan disarankan juga untuk menyelipkan comment ke modul atau fungsi yang di-export supaya programmer lain dapat memahami dengan cepat.

Akan tetapi, bukan berarti menambahkan comment di setiap fungsi, data structure, deklarasi, dll itu dibenarkan. Cara seperti ini hanya cocok untuk short-term solution. Jika kita selalu menambahkan comment setiap kita menambahkan fungsi, berarti fungsi yang kita buat tidak explicit karena perlu adanya penjelasan dari luar alih-alih fungsi yang ditulis sudah menjelaskan logika yang dikerjakan.