Catatan Buku The Effective Engineer

Focus on High-Leverage Activities

Penulis berpendapat bahwa engineer yang efektif adalah ia yang selalu berkomitmen untuk melakukan aktifitas yang memiliki high leverage. Apa itu leverage?

$$Leverage = {ImpactProduced \over TimeInvested}$$

Artinya, engineer yang efektif melakukan hal-hal yang berdampak tinggi dalam yang waktu yang sesingkat-singkatnya.

Berbeda dengan resource lain, waktu adalah sesuatu yang tak dapat disimpan, tak dapat diulang, dan tak dapat digunakan lagi. Jadi gunakan sebaik-baiknya!

Salah satu contoh aktifitas dengan high leverage adalah mentoring karena keberhasilan suatu product ialah keberhasilan tim, bukan individual. Di Quora, engineer baru didampingi mentor selama 2-3 bulan awal. Aktifitasnya macam-macam; review code, membahas skill apa aja yang harus dipelajari, pair programming, diskusi engineering trade-off, gimana caranya kolaborasi dengan tim lain, dan lain sebagainya. Hasilnya dalam seminggu saja, mereka langsung bisa fix bug atau rilis fitur kecil baru.

1% investasi saja bisa meningkatkan produktifitas aktifitas 99% sisanya. Belajar UNIX command bisa memangkas waktu sekian menit task, belajar menggunakan debugging tools bisa menghemat beberapa jam waktu development, dll.

Usahakan tanyakan selalu 3 hal berikut:

• Apa yang bisa gue lakuin agar task yang sedang dikerjaan ber-impact tinggi?
• Gimana caranya gue bisa menyelesaikan task dengan waktu yang sesingkat-singkatnya?
• Ada task lain ber-impact tinggi yang bisa gue kerjain?

Contoh lain aktifitas yang memiliki impact tinggi:

• Automasi proses/tools/testing saat development
• Ngobrol sama Customer Support soal apa yang paling dibutuhkan user
• Buat skala prioritas task-task dengan impact tinggi

Contoh real life dari Bill Gates: sebagai seorang filantropis, beliau berinvestasi di vaksin campak dan malaria. Alasannya?

• Murah. Cuman $0.25 per vaksin
• Bisa menyelamatkan jutaan nyawa manusia

Optimize for Learning

Adopsi mindset growth. Apaan tuh? Mindset dimana kita melihat tantangan sebagai suatu kesempatan untuk belajar.

• Mindset ini sangat berpengaruh terhadap output
• Gimana caranya? Own your stories. Buat dinasti sendiri. Jangan ngikutin resume orang. Be genuine

Selalu investasikan waktu untuk belajar. Karena ilmu itu sifatnya eksponensial, seperti bunga:

• 5% bunga bakal menghasilkan output 49% lebih banyak setelah 40 tahun dan 82% setelah 60 dibandingkan dengan bunga 4%
• Karena sifatnya yang eksponensial, delta kecil saja bisa menghasilkan perbedaan yang sangat besar dalam jangka waktu yang lama.

Tapi sayangnya, kita sering meremehkan improvement 1% ini karena terlihat sangat kecil dan tak berarti. Padahal kalo dihitung-hitung, jika kita bisa konsisten improve diri kita 1% saja setiap hari, di akhir tahun kita akan menjadi pribadi yang 37x lebih baik, bukan 3.65x.

Sibukkan dengan proyek-proyek yang menantang. Gak menantang = menyia-nyiakan waktu untuk belajar. Perlu diingat lagi bahwa improvement itu sifatnya eksponensial (kayak analogi bunga tadi).

Cari tempat kerja yang kondusif untuk belajar. Coba liat profil perusahaan apakah mereka:

• Fast growth? Kalau kita diminta naik roket, kita gak akan tanya-tanya tempat duduknya seperti apa, nyaman apa enggak
• Ada training? Program mentoring?
• Open untuk menerima feedback?
• Berlaju cepat? Cepat beriterasi -> cepat dapat feedback -> cepat pula kita belajar
• Banyak orang pinter? Liat apakah si interviewer itu terlihat lebih pintar dari kita
• Autonomous? Kita bisa pick up task yang ingin kita kerjakan dan cari tahu sendiri gimana cara menyelesaikannya

Dedikasikan 20% saja dari waktu kerja untuk belajar hal baru. Google menerapkan ini. Walau awalnya banyak yang meragukan, namun ternyata habbit ini membuahkan hasil. Gmail, Google News, dan AdSense lahir dari ide “20% waktu” ini.

Kalau ukurannya per pekan, jangan diambil semua dalam satu hari, tapi sebar; 1-2 jam sehari. Hitung-hitung sekalian membentuk kebiasaan self-improvement setiap hari.

Harus ngapain aja selama waktu 20% ini? Kita bisa ambil beberapa contoh:

• Pelajari code abstraction di codebase. Pahami konteks mengapa ada abstraksi ini. Tanyakan pada diri sendiri: jika diminta menulis kembali abstraksi tersebut, apakah ada hal yang mau diubah?
• Jangan takut nyemplung untuk memahami code yang dianggap susah/legacy
• Kuasai bahasa pemrograman yang sedang digunakan
• Baca wiki/dokumentasi tim
• Ikut serta dalam diskusi proyek yang berhubungan sama kerjaan kita sehari-hari. Kalau kita gak termasuk dalam anggota proyek, bisa ijin jadi “kuping” aja
• Coba buka diskusi dengan engineer senior. Kalau gak ada, mending pindah tim :)
• Kerjakan proyek-proyek yang berbeda, yang di luar batas nyaman kita

Teruslah belajar:

• Kerjakan side projects. Ide-ide brilian sering muncul dari side project
• Baca buku. Penulis bisa membaca 1-2 buku dalam seminggu
• Bikin tulisan :)
• Follow orang-orang yang knowledgeable, baca blog mereka, dengerin podcast-nya, dll
• Ikut meetup, conference
• Networking!

Prioritize Regularly

Dalam satu tahun, tim si Penulis dulu ketika bekerja di Quora bisa memperbanyak jumlah user aktif bulanan dan harian sebanyak 3x lipat. Kuncinya? Terus menerus membuat skala prioritas pekerjaan.

Kenyataannya, task yang dapat dikerjaan akan selalu lebih banyak dibanding ketersediaan resource yang ada. Inilah mengapa membuat prioritas secara berkala itu perlu dan ini merupakan salah satu aktifitas yang high leverage.

Caranya gimana?

1. Langkah pertama dalam membuat prioritas adalah menuliskan semua task yang akan dikerjakan. List ini harus mudah diakses: terserah mau pake apa aja: Github, Gitlab, Notion, pensil dan kertas.

    

   Kenapa harus ditulis? Karena otak manusia itu gak didesain untuk mengingat-ingat, tapi untuk memproses.

    

   Kalo terus-menerus digunakan untuk mengingat-ingat, banyak research membuktikan bahwa hal ini dapat mengurangi kemampuan berkonsentrasi dan menurunkan kecakapan dalam mengambil keputusan. Jadi lebih baik otak kita digunakan untuk memecahkan masalah-masalah engineering aja dibanding mengingat-ingat apa yang harus dikerjakan.

2. Buat prioritas berdasarkan impact-nya. Kalo bingung, dibuat kira-kira aja berdasarkan informasi yang kita punya saat itu. Kerjakan. Setelah selesai, tanya pada diri sendiri: Ada lagi gak task dengan leverage yang tinggi yang bisa gue kerjain?

Tapi pertanyaan terbesarnya adalah: bagaimana kita bisa tahu task mana yang punya leverage lebih tinggi dibanding yang sedang kita kerjakan?

Cara yang mudah: kalau aktifitas tersebut termasuk ke dalam hal-hal seperti

• Membuat laporan
• Meeting
• Membalas email yang gak urgent

lebih baik di-skip dulu. Cari aktifitas yang berkaitan dengan

• Rilis produk/fitur
• Peningkatan user acquisition
• Berjalannya metrik
• Conversion
• Dan segala macam aktifitas yang bisa kita banggakan pas presentasi

Kalau hasil nyatanya keliatan, bakal sedikit kok yang komplain karena kita gak hadir di meeting atau lama bales email. Kalau kita banyak mengerjakan hal-hal yang penting, yang kecil-kecil jadi terlihat tak berarti.

Ibarat kita mau nabung lebih banyak dengan pergi ke supermarket yang lebih murah. Paling sekali belanja banyak cuman hemat €3-5. Tapi kalau kita banyak fokuskan waktu untuk dapat gaji yang lebih baik dengan belajar negosiasi gaji, meningkatkan kapasitas diri, dan lain sebagainya, kita bisa dapat bayaran yang jauh lebih besar dan penghematan €3-5 tadi jadi gak ada apa-apanya.

Gak bilang kalau kita gak bisa berhemat ya :) Cuman pastikan effort yang kita keluarkan proporsional dengan impact yang diharapkan.

Belajar untuk bilang “Tidak”: ketika diajak meeting, diajak ngobrol sama product owner soal ide baru, di-assign untuk fix bug yang kecil. Gak semuanya harus jadi kewajiban kita. Kadang mereka gak paham betapa berharganya waktu kita sendiri.

Fokus terhadap hal yang important and non urgent.

Jangan biarkan aktifitas di Quadrant [1] dan [3] mendikte schedule kita. Contoh lain dari aktifitas Quadrant [2] adalah:

• Merencanakan target karir kita kedepannya
• Membaca buku dan artikel tentang professional development
• Mentoring kolega
• Memastikan infrastruktur scalable

Intinya Quadrant [2] itu investasi tanpa deadline jadi gak ada urjensinya sama sekali. Melakukannya pun jadi enak, enjoy, dan relaks karena gak dikejar waktu.

Nimrod Hoofien, engineering director di Facebook (ex-Amazon juga) memberi label 1-4 di setiap item TODO list-nya.

Hati-hati kalau kita terlalu banyak mengerjakan aktifitas Quadrant [1]. Karena bisa jadi disebabkan karena kurangnya dedikasi waktu kita di Quadrant [2]. Misal:

• Banyaknya alert di production mungkin bisa jadi indikator perlunya recovery automation
• Banyaknya bug mungkin karena kita kurang menulis test
• Deadline yang tak henti-henti mungkin disebabkan karena planning dan estimasi yang kurang matang

Lebih banyak berinvestasi di Quadrant [2] dapat membantu mengurangi beban dan urjensi di Quadrant [1].

Kalau sudah tahu apa yang harus dikerjakan, protect your time. Programmer, layaknya penulis, punya unit waktunya sendiri: bukan per jam, tapi per setengah hari. Kita tidak bisa menulis program hanya dalam waktu satu jam. Satu jam itu ibarat baru pemanasan, belum kick-off.

Cara melindungi waktu kerja kita bagaimana?

• Bisa jadwalkan meeting hanya di akhir waktu kerja. Atau kalau bisa yang runtut, jangan berjeda
• Block kalendar
• Jika ada yang meminta bantuan, bisa dibalas dengan: “Gue pengen banget bantu, tapi sekarang gue lagi fokus nih. Mungkin nanti ya (misal setengah jam lagi)?”

Batasi jumlah pekerjaan yang sedang dikerjakan. Kayak nonton aksi di panggung, kalau kebanyak aktor yang masuk dan keluar panggung, kita jadi fokus ke mereka bukan ke performance-nya. Pekerjaan juga sama.

Increasing work linearly increases the likelihood of failure exponentially.
— Barry and Benson di bukunya Personal Kanban

Kapasitas tiap orang berbeda-beda. Trial and error aja berapa banyak proyek yang bisa kita kerjaan dalam satu waktu.

Lawan kemalasan dengan rencana if-then-else. Misal, “kalau masih ada sisa waktu 20 menit sebelum aktifitas selanjutnya, gue akan ngerjain ____”. Bisa diisi dengan code review, membalas email, cari tau penyebab bug kecil, menulis unit test. Jangan yang berat-berat.

Buat kebiasaan membuat prioritas. Gak ada workflow yang spesifik sih, kita musti cari tau sendiri karena beda-beda tiap orang. Yang penting itu kebiasan memprioritaskan pekerjaannya, bukan teknisnya.

Setiap kali ada task yang gak selesai, bisa tanyakan pada diri sendiri: kenapa gak selesai? Apakah ada sesuatu lain yang lebih penting? Salah prioritas? Atau karena leyeh-leyeh aja?

Membuat prioritas itu memang sulit, dan kita tidak selalu harus melakukannya (mungkin lagi capek atau butuh relaks sebentar). Tapi kalau kita punya target personal maupun profesional, memprioritaskan pekerjaan termasuk salah satu aktifitas yang high leverage.

Invest in Iteration Speed

Tim penulis dulu di Quora sehari bisa rilis versi baru sebanyak 40-50 kali sehari. Rahasianya? Continuous deployment (CD). CD memungkinkan engineer untuk membuat dan men-deploy perubahan-perubahan kecil.

Beriterasilah dengan cepat: karena kita bisa membuat hal lebih banyak dan belajar lebih cepat. Ingin tau behaviour user? Tinggal setup tracking, deploy, lalu lihat hasilnya dalam hitungan menit.

Moto facebok: “Move fast and break things”. Walaupun mereka tidak menggunakan CD, namun beriterasi cepat dan fokus pada impact menjadi budaya kerja mereka, alih-alih jadi konservatif dan terlalu berhati-hati membuat kesalahan. Walhasil mereka bisa rilis code ke production dua kali sehari.

Lebih cepat beriterasi, lebih cepat juga kita tahu mana yang berhasil dan mana yang tidak. “If you never break anything, you’re probably not moving fast enough.”

Menurut Pascal-Louis Perez, mantan CTO Wealthfront, keuntungan utama CD terletak pada pengurangan resiko karena tim bisa fokus pada perubahan-perubahan kecil sehingga bisa lebih cepat menemukan masalah ketika terjadi.

Menurut Bobby Johnson, mantan Director of Infrastructure Engineering di Facebook, bahwa hampir semua orang yang sukses itu suka membuat tools. Raffi Krikorian, mantan VP of Platform Engineering di Twitter juga sering berpesan ke timnya, “kalau kamu harus melakukan hal yang sama lebih dari dua kali, buatlah sebuah tool untuk yang ketiga kalinya.”

Tool yang bisa menghemat waktu, walaupun sedikit, dampaknya bisa besar. Pertama, ia akan lebih sering dipakai. Kalau jadwal kereta lama, ya kita juga bakal jarang pake kereta. Kalau semakin sering, makin banyak dan sering juga yang memakainya. Kedua, ia akan membuka workflow baru yang sebelumnya tak terpikirkan. Misal kita buat tools yang mempercepat compile time: kita jadi bisa test code lebih cepat, gak takut jalanin unit/e2e test secara terus menerus -> lebih produktif

Jangan pernah remehkan tools. Tools yang, misal, menghemat waktu satu jam, ketika digunakan oleh 10 orang, akan menghemat 10 jam kerja.

Mulailah dari yang kecil. Cari area yang bisa dibuat lebih singkat oleh sebuah tool, buat, lalu demonstrasikan kepada tim. Jangan biarkan aktifitas Quadrant [1] menghambat kita membuatnya (Quadrant [2]).

Contoh tools:

• Konfigurasi hot-reload sehingga kita tak perlu reload page di browser ketika ada perubahan di code
• REPL. Sehingga tak perlu compile untuk menjalankan suatu expression
• Auto format code
• Reminder bot
• Atau sesederhana setup/menguasai shortcut-shortcut IDE atau editor yang digunakan

Namun hal-hal yang bisa menghambat iterasi cepat ini terkadang datang bukan dari engineering tools, namun dari proses (yang melibatkan orang lain). Misal proses code review yang lama.

Mau jadi engineer yang efektif? Cari tahu hambatan-hambatan terbesar yang menghalangi kita dari beriterasi cepat, entah itu engineering tools, dependesi antar tim, atau approval dari atasan. Langsung optimize.

Measure What You Want to Improve

Tentukan metrik:

• Ia membantu kita untuk fokus kepada tujuan, gak sekedar mengandalkan intuisi kita saja
• Bisa menangkap terjadinya regresi ketika metrik divisualisasikan dengan baik (chart, dll)
• Metrik yang bagus bikin maju. Di Box, mereka menggunakan metrik sebagai performance ratchet; ketika ada perubahan yang berhasil meningkatkan performance, mereka jadikan angka tersebut sebagai patokan baru
• Metrik yang bagus dapat mengukur seberapa efektif usaha kita. Nantinya bisa dijadikan poin retrospektif untuk terus mengerjakan hal-hal yang high leverage

Terus gimana caranya menentukan metrik? Ada 3:

1. Yang bisa memaksimalkan impact
2. Actionable: yang pergerakannya dapat “dipertanggungjawabkan” lewat usaha tim
3. Responsif dan robust. Responsif agar kita bisa tahu dengan cepat apakah metriknya bergerak naik atau turun supaya tim bisa belajar. Misal metrik yang mengukur user aktif seminggu terakhir itu lebih responsif dibanding yang sebulan terakhir. Tapi harus diimbangi dengan robustness. Misal avg response times jika diukur per menit akan lebih banyak naik turunnya (banyak noise) dibanding jika diukur per jam atau per hari

“Measure anything, measure everything”, seperti filosofi tim engineering Etsy. Tujuannya agar kita tahu kalau-kalau ada bug yang nyelip ke production. Makanya penting untuk membuat tools yang fleksibel untuk mengukur metrik lainnya.

Harus tau standar operasi untuk dijadikan patokan. Misal:

• Berapa sih standar clickthrough rates email marketing?
• Seberapa cepat sih seharusnya operasi read di MySQL?
• Berapa standar load time sebuah halaman?
• Seberapa lama baca 1MB data dari network?

Jadi ketika ada masalah, setidaknya kita tahu dimana letak penyebabnya.

Bersikaplah skeptis terhadap integritas data. Data dapat diinterpretasikan sesuka yang menginterpretasikannya. Salah satu caranya, menurut Schillache, adalah dengan melihat suatu metrik dari dua sumber/arah/properti yang berbeda untuk memastikan datanya konsisten.

Nah karena metrik ini sangat penting dan high leverage, sebagai engineer kita harus:

• Memastikan data yang kita ukur dikirim dengan benar. Unit test behavior penting, launch projek sesuai deadline penting, tapi jangan lupakan juga integritas data
• Tidak meremehkan metrik-metrik yang terlihat mudah dan pasti benar, seperti page load. Siapa tahu angkanya terkirim dua kali?
• Log data sebanyak mungkin, siapa tahu berguna nantinya
• Buat tools yang bisa meningkatkan dan memastikan akurasi data sedini atau secepat mungkin
• Periksa data sedini mungkin. Meskipun harus menunggu satu minggu atau satu bulan agar datanya bermakna, langung periksa data yang dikumpulkan begitu “jatuh tempo”
• Kalau ada angka yang terlihat aneh, langsung investigasi; bisa jadi ada bug atau misinterpretasi

Validate Your Ideas Early and Often

Jangan sampai kayak Cuil, search engine yang digadang-gadang bakal menyingkirkan Google. Sudah menghabiskan dana lebih dari 33 juta USD tapi gagal total:

• Hasil pencarian yang gak bagus
• Lambat
• Penuh bug
• dsb

Kenapa? Levy, salah satu orang yang mengembangkan Cuil berefleksi bahwasanya memvalidasi ide produk itu harus dilakukan sedini mungkin, bukan malah sembunyi-sembunyi lalu buat kejutan. Mereka bahkan tidak menggunakan alpha tester untuk mengumpulkan feedback.

Don’t delay … Get feedback. Figure out what’s working. That’s by far better than trying to … build something and then trust that you got everything right—because you can’t get everything right

Gunakan pendekatan iteratif agar terhindar dari kesalahan-kesalahan fatal dan langsung dapat feedback untuk kembali on track. Semakin pendek siklus iterasinya semakin baik.

Engineering manager Square, Zach Brock berpesan ke timnya, “Yang paling ditakutkan di dalam sebuah proyek itu kan area yang paling tidak diketahui dan yang paling banyak resikonya. Lakukan itu dulu.” Cari tahu area yang paling beresiko yang berpotensi membuat usaha tim nantinya sia-sia.

Contoh Dropbox, dimana MVP-nya adalah sebuah video berdurasi 4 menit. Dalam semalam saja, mailing list beta Dropbox bertambah dari 5 ribu ke 75 ribu user. Dari situ Drew Houston tahu bahwa produknya banyak diminati orang.

Jadi untuk membuat MVP, fokus ke aktifitas ber-leverage tinggi yang dapat memvalidasi hipotesis kita semudah dan sebanyak mungkin.

Contoh lain 42Floor, sebuah layanan yang menampilkan daftar kantor untuk disewakan menggunakan Google Map. Sayangnya website-nya akan sangat lamban (bisa 12 detik) bila menampilkan data yang terlalu banyak. Tiga bulan mereka redesign UI: infinite scrolling, mini map, dll. Tapi gagal. Akhirnya mereka menyewa agensi untuk membuat 8 mockup Photoshop dan buat versi HTML-nya beserta data daftar-daftar kantor yang disewakan, hardcoded. Lalu mereka sebar “fake pages” ini lewat Google AdWords. Variasi yang menang diimplementasikan, dan mereka berhasil mencapai target conversion rate yang diinginkan.

Atau Asana, yang menampilkan pesan “Thanks for your interest—the feature is coming soon” ketika tombol “Google Signup” diklik. Alasannya mereka ingin tahu apakah cukup banyak user yang ingin sign up lewat Google sebelum membuatnya.

Gunakan AB test untuk memvalidasi hipotesis dan beriterasi berdasarkan apa yang dipelajari. Hasilnya pun dapat diukur (quantifiable).

Seperti kampanye Obama. Mereka menulis 17 versi email yang berbeda dan mengirimkannya ke sebagian kecil subscriber di maling list mereka. Ternyata ada satu versi yang sukses mengumpulkan dana 6x lebih banyak dibanding versi lainnya. Ketika versi yang menang ini dikirim ke 4,4 juta subscriber sisanya, mereka berhasil mendapatkan dana sebanyak 2,6 juta USD.

Buat feedback loop dalam mengambil keputusan. Buat eksperimen. Validasi hipotesis. Belajar dari hasil. Lalu buat eksperimen-eksperimen lain dari hasil pembelajaran tadi.

Improve Your Project Estimation Skills

Untuk membuat estimasi yang lebih akurat namun tetap fleksible, bisa gunakan beberapa tips berikut:

• Pecah proyek ke task-task yang lebih kecil lalu masing-masing buatkan estimasinya. Jika ternyata lebih dari dua hari, pecah lagi. Kita juga jadi bisa lebih membantengi diri dari deadline yang kurang realistis
• Anggap estimasi itu sebagai distribusi probabilitas, bukan best-case scenario. Lebih ke, “kemungkinan kita rilis fitur ini dalam 4 minggu itu 50%, dan 90% dalam waktu 8 minggu”
• Hati-hati dengan anchoring bias. Ada suatu eksperimen dimana murid-murid diminta menebak harga sebuah botol anggur. Mereka terlebih dahulu diminta menuliskan dua digit terakhir nomor KTP mereka. Murid dengan digit tinggi menebak harga yang lebih tinggi dibanding mereka dengan digit rendah. Dari eksperimen ini, kita bisa menarik pelajaran untuk tidak memberikan estimasi sebelum benar-benar di-outline apa yang harus dikerjakan
• Waspada terhadap man-month—jumlah jam, hari, minggu, atau bulan suatu tim dapat menyelesaikan suatu proyek, dimana semakin banyak orang semakin cepat pula proyek tersebut terselesaikan. Padahal, makin banyak orang semakin tinggi juga overhead di komunikasi, diskusi, meeting, dll.
• Buat catatan estimasi kita sendiri. Jika kita tahu ternyata kita cenderung overestimate 20%, mungkin lebih baik jika kita naikkan estimasi awal kita sebesar 25%
• Buat alokasikan waktu (time box) untuk aktifitas-aktifitas yang open-ended (gak berujung), seperti mencari library Javascript yang optimal untuk fitur baru
• Ajak yang lain untuk menantang estimasi kita. Kadang ada beberapa edge case yang kita tak tahu namun mereka tahu

Buat budget untuk hal-hal yang belum diketahui, seperti:

• Menulis unit test tapi malah makan waktu yang lama karena ternyata ada service yang sulit di-mock
• Refactor code di luar lingkup proyek. Awalnya keliahatan kecil tapi bisa jadi malah besar
• Kolega ambil cuti

Biasanya ketika kita sebagai engineer membuat estimasi, maksud estimasi kita lebih ke waktu pengerjaannya, bukan dalam waktu kalendar. Namun stakeholder lain bisa jadi salah menangkap maksud kita. Dua minggunya kita itu (ideal engineering day) bukan dua minggu waktu kelander. Karena seringkali dalam satu minggu (kalendar) sendiri, waktu kita untuk bisa benar-benar mengerjakan proyek tersebut hanyalah 2 hari. Jadi seharusnya kita jangan bilang 2 minggu, tapi 7 minggu (14 hari / 2 hari).

Catat seberapa lama task-task yang tidak ada di estimasi awal bisa dikerjakan. Gunanya lebih untuk meningkatkan kesadaran diri akan adanya distraksi-distraksi semacam ini yang bisa membuat proyek molor.

Buat tujuan yang jelas dan milestone yang bisa diukur. Seperti, “Masalah kita adalah database yang sudah gak kuat melayani traffic. Dan tujuan kita adalah untuk migrasi ke sharded architecture tanpa downtime.” Keuntungannya dua:

• Bisa jadi filter task/fitur mana saja yang harus dikerjakan, dan mana yang hanya sekedar nice-to-have.
• Kejelasan dengan stakeholder penting lain agar mereka paham tujuan, batasan, dan asumsi-asumsi yang kita buat.

Punya milestone yang bisa diukur juga penting agar ketika ditanya progress kita gak jawab, “hapir jadi”, “udah 90%”. Akan jauh lebih mantap kalau bisa kita beri jawaban, “Fitur X dan Y sudah jadi. Tinggal Z, seminggu lagi”. Contoh milestone:

1. Refaktor kode untuk memudahkan proses migrasi dari library A ke B
2. Ganti kode di home page dan profile page dari library A ke B
3. Buat deprecation warning penggunaan library A
4. Rilis
5. Cleanup

Cari tahu area yang paling beresiko terlebih dahulu dan selesaikan, seperti yang dibahas di bab sebelumnya. Jangan “bohongi” diri kita sendiri lewat kemajuan semu dengan mengerjakan hal-hal yang mudah dulu. Langsung beri tahu ke tim jika ada kemungkinan molor, jangan malah gak enakan :)

Hindari rewrite. “Trying to rewrite stuff from scratch—that’s the cardinal sin”, kata Sam Schillache yang sempat ngurusin Gmail dan Google Apps selama empat tahun. Kenapa?

• Kita lebih familiar dengan versi original dan biasanya kita underestimate saat rewrite
• Kita sering ingin sekalian menambah fitur baru
• Kita tahu semua edge case-nya? Belum tentu

Kalaupun harus rewrite, lakukan dengan bertahap sembari menjaga behaviour aplikasi agar terhindar dari kesalahan-kesalahan.

You also avoid having the system broken while you are carrying out the restructuring—which allows you graually refactor a system over an extended period of time
— Martin Fowler

Misal saat ingin migrasi API dari PHP ke Nodejs, alih-alih rewrite, buat sebuah proxy server yang melayani beberapa endpoint lama ke Nodejs. Lakukan secara bertahap sampa semua endpoint berhasil diporting ke Nodejs.

Atau saat Google mengakuisisi Writely (nantinya jadi Google Doc) yang harus menulis ulang dari C# ke Java karena C# gak jalan di data center Google. Strategi mereka itu tulis ulang dulu ke Java, jangan tambah, kurangi, atau ubah fungsionalitas. Setelah selesai semua, baru refactor. Walhasil, mereka berhasil menyelesaikan proses rewrite dalam waktu 12 minggu, yang tercepat sepanjang sejarah Google dari segi porting aplikasi ke infrastruktur Google.

Tahu kapan harus overtime. Harus sangat hati-hati dengan menambah jam kerja saat tahu deadline sudah dekat:

• Menurunkan produktifitas. Sudah banyak studinya
• Meningkatkan potensi burn out. Dengan menambah jam kerja, ada hal lain yang harus dikorbankan seperti rekreasi dengan keluarga, waktu istirahat, dll
• Mempermudah munculnya technical debt demi mengejar milestone

Kalaupun harus overtime, pastikan benar-benar diperlukan:

• Komunikasikan alasan utama kenapa molor
• Buat rencana proyek dan deadline yang lebih realistis
• Harus siap meninggalkan sprint/overtime kalau ternyata masih belum saja bisa selesai dengan rencana yang diperbarui. Terima saja kenyataannya karena bisa jadi garis finish-nya masih sangat jauh. Don’t sprint in the middle of a marathon

Belance Quality with Pragmatism

Kualitas kode di Google itu tinggi, namun di saat yang bersamaan Google juga punya banyak produk, yang berarti saat suatu eksperimen gagal, semua kodenya harus dihapus. Bukan hanya kode, tapi juga usaha dan waktu yang telah dikorbankan. Kan sayang. “Instead of right or wrong, I prefer to look at things in terms of works and doesn’t work. It brings more clarity and is more effective for making decisions”, begitu kata Engineering Director Facebook, Bobby Johnson. Inilah yang disebut pragmatisme.

Lalu bagaimana cara menyeimbanhkan kualitas kode dengan beriterasai cepat?

Pertama bisa dengan budaya code review. Tujuannya:

• Menangkap bug dan kesalahan desain lebih dini
• Berbagi tanggungjawab. Gak bakal dong kita nulis kode asal-asalan kalau ada orang lain yang review kode kita
• Berbagi ilmu. Code review bisa jadi ajang belajar trik-trik atau “best practices” baru
• Menjaga kualitas kode

Fun fact: Selama empat tahun pertama semenjak didirikan, Dropbox tidak menerapkan code review. Katanya waktu yang dihabiskan lebih baik digunakan untuk hal lain 😅.

Cara kedua bisa dengan menulis automated tests, bisa unit, integrated, dan/atau end to end. Manfaatnya bukan hanya untuk menangkap regresi produk, tapi juga menghemat waktu manual testing yang harus dilakukan berulang-ulang. Gak harus dapet 100% code overage. Bisa dimulai dengan high-leverage test—yaitu yang waktu penulisannya sebentar tapi menghemat banyak waktu manual testing.

Cara selanjutnya adalah membayar technical debt secara berkala. Quora memiliki satu hari khusus untuk “bersih-bersih” setelah seminggu hackathon. Google punya Fixit Days seperti Docs Fixit, Customer Happiness Fixit, atau Internationalization Fixit dimana para engineer fokus bersih-bersih sesuai tema Fixit. Namun kadang-kadang technical debt ini sulit dikuantifikasi, namun yang pasti semakin lama kita menundanya, semakin besar juga bunganya. Jadi dedikasikanlah waktu sesekali untuk membayar hutang ini. Lagi, bisa dimulai dengan fitur/kode yang paling sering digunakan user namun butuh sedikit usaha saja untuk memperbaikinya.

Minimize Operational Burden

Salah satu kunci kesusksesan Instagram sebelum dibeli oleh facebook adalah mereka menyadari pntingnya meminimalisir beban operasional. Engineer-nya cuman lima orang. Mike Krieger, co-counder Instagram, bilang bahwa di balik sebuah fitur dibutuhkan juga resource tambahan untuk maintenance. Beban ini baru mulai terakumulasi saat peluncuran, terus menggunung seiring waktu.

Maka kalau kita ingin mencicipi framework atau library baru, mending dipikir-pikir dulu: seberapa lama nantinya kita akan menghabiskan waktu untuk maintain dan bug fix sistem ini, alih-alih membuat hal yang memang dibutuhkan user?

Krieger lanjut menjelaskan proses pengembangan Instagram saat itu. Ia selalu menanyakan kepada timnya, “apa ini hal yang paling sederhana yang bisa kita lakukan?” Kalau jawabannya tidak, maka mereka akan mempertimbangkan kembali solusinya.

Steve Jobs juga pernah menyatakan hal yang sama, “saat pertama kita mencoba mencari solusi terhadap suatu masalah, biasanya solusi awal yang didapat itu kompleks, dan kebanyakan orang berhenti pada tahap ini. Namun kalau kita terus memahami masalahnya, kita akan sampai pada solusi yang cukup sederhana kok. Kebanyakan dari kita ini cuman gak mau berusaha lebih untuk mencapai titik ini.”

Buat sistem yang gagal lebih awal. Gunanya untuk menangkap kesalahan lebih mudah dan cepat. Contoh:

• Crash saat pertama kali salah baca file konfigurasi
• Validasi input, terlebih kalau ia akan jauh digunakan nanti
• Buat eksplisit error dari layanan eksternal, jangan ditelan aja

Kisah lucu dari penulis. Ia pernah mengubah waktu cache Memchached dari 10 hari menjadi 40 hari untuk query-query tertentu. Begitu masuk ke production, langsung terlihat banyak error. Setelah di-roll back dan diinvestigasi, usut punya usut waktu cache Memchached itu diekspresikan dengan detik tapi hanya boleh sampai 30 hari, selebihnya dianggap sebagai UNIX timestamp. Jadi si Memchached ini malah menganggap 40 hari tadi sebagai timestamp di tahun 1970. Walhasil nilai yang masuk ke cache tadi langsung terinvalidasi. Kalau saja Memchached langsung kasih peringatan atau kasih error saat input > 30 hari, penulis bisa menghemat banyak waktu development dan gak perlu pusing cari akar permasalahan.

Buat automasi. Seperti script untuk deployment, membuat database snapshot, restart web service, atau bahkan sesederhana membuat alias 12 commands. Saat membuat automasi, penting untuk diingat bahwa idempotancy (tetap menghasilkan output yang sama jika dijalankan berulang-ulang) itu penting. Jika tak memungkinkan, setidaknya buat ia retryable, tidak meninggalkan efek samping (misal counter-nya gak ke-reset jadi 0 lagi) saat dijalankan ulang. Buat proses automasi ini sukses sepenuhnya atau gagal sepenuhnya.

Asah kemampuan untuk recover dengan cepat. Netlflix punya sistem yang namanya Chaos Monkey yang secara acak mematikan sebuah service di infrastruktur mereka sendiri, tujuannya untuk membuat infrastruktur lebih robust karena mereka bisa melihat bagian mana yang lemah dan mempersiapkan diri saat terjadi.

Bill Walsh, mantan pelatih San Francisco 49ers sering membuat “script” strategi jauh sebelum pertandingan. Kalau A terjadi, maka jalankan B. Kalau X terjadi, maka Y, dsb. Dengan cara seperti ini ia tetap bisa fokus ke jalannya pertandingan tanpa dipengaruhi naik turunnya emosi di lapangan dan hiruk pikuk di stadion. Kita pun sebagai engineer bisa ambil contoh dari Bill: punya proses dan tahu apa yang harus dilakukan saat terjadi kesalahan sistem di production.

Google punya DiRT (Disaster Recovery Testing) yang dijalankan setiap tahun, untuk mensimulasi bencana alam seperti gempa bumi dan badai yang dapat mematikan data center mereka.

Buat daftar pertanyaan “gimana kalo”:

• Gimana kalo ada kolega yang sakit? Bisa ambil alih tugasnya?
• Gimana kalo database mati?
• Gimana kalo ada bug saat rilis fitur? Bisa roll back?
• Gimana kalo projeknya molor? Apa rencana selanjutnya?

Invest in Your Teams’ Growth

Berinvestasi di tim akan memberikan dampak yang saaangat besar terhadap efektifitas kita. Misal dengan memiliki program onboarding: lebih cepat engineer baru familiar dengan infrastruktur kita, lebih cepat pula kita bisa bekerja dengannya. Kita juga bisa fokus ke pekerjaan sendiri dengan lebih cepat pula.

Makin tinggi naik ke tangga engineering, kesusksesan kita akan lebih sering diukur dengan pencapaian tim, bukan pencapaian individu.

Manfaat lain dari berinvestasi ke pertumbuhan tim adalah kita bisa ikut terseret ke yang baik-baik. Misal semua orang di sekitarmu mencapai 120% dari target awal, sekalipun kita gak ngelakuin apa-apa, kita juga tetep kecipratan suksesnya.

Buat hiring tanggung jawab bersama (tim). Karena orang baru ini nantinya akan kerja sama kita. Kalau satu visi kan akan lebih mudah kerjanya. 40 jam yang kita keluarkan untuk hiring akan terbayarkan kok dengan output 2000+ jam outputnya. Berikut beberapa tips:

• Sisihkan waktu untuk mencari tahu kualitas apa yang diharapkan dari si kandidat yang kita bersama hargai. Kualitas kode? Algoritma? Struktur data? Skill komunikasi? Culture fit?
• Beri tantangan interview dengan beberapa layer. Misal kandidat diminta untuk membuat suatu UI. Layernya bisa: loading time, performace, responsiveness, dll. Dimana layer-layer ini bisa kita tambahkan atau hilangkan agar kita bisa dengan cepat dan mudah melihat kemampuan kandidat
• Cari red flag dengan menanyakan pertanyaan-pertanyaan tricky dengan cepat (gimana cara kerja paramater passing sebuah function di Javascript?). Kandidat yang bagus gak akan menjawab terlalu lama

Buat proses onboarding yang bagus. Akan sulit bagi kolega baru untuk mencari tahu sesuatu tanpa arahan apapun terlebih dahulu. Kesan pertama juga penting lho, karena bisa mengubah persepsi kolega baru ini terhadap kultur engineering kita, juga dapat membentuk kapasitasnya untuk deliver further impact. Menghabiskan satu atau dua jam setiap hari selama sebulan awal itu lebih baik dibanding langsung membiarkannya terjun bebas develop product. Lagi, kesuksesan tim lebih utama dibanding kesuksesan individu.

Konsekuensi kalau proses onboarding-nya jelek: kita akan lebih sulit untuk mengidentifikasi bad performer. Apa orang baru ini gak bisa deliver karena kurang berkualitas atau memang karena hanya butuh waktu penyesuaian lebih saja?

Kalau kamu adalah orang baru, kamu bisa kasih feedback soal proses onboarding yang kamu terima, apa yang menurutmu jalan, apa yang enggak. Kalau kamu yang kasih onboarding, kamu bisa meminta feedback ke orang baru tersebut apa sudah efektif prosesnya.

Lalu gimana caranya membuat proses onboarding yang bagus? Pertama, sebagai tim kita harus mengidentifikasi apa saja yang mau dicapai. Kedua, buatlah rencana dan mekanisme untuk mencapai hal tersebut. Contoh di Quora, ada empat hal yang harus dicapai saat onboarding:

1. Ramp up orang baru secepat mungkin. Produktifitas akan menurun pada awalnya, tapi gak sebanding dengan output yang dihasilkan nantinya
2. Beri tahu kultur dan nilai-nilai tim. Seperti getting things done, data-driven, gimana cara kerja yang bagus di tim, dan lain-lain
3. Sampaikan materi-materi fundamenatal yang harus diketahui
4. Integrasikan orang baru ke tim secara sosial. Maksudnya kasih ia waktu dan kesempatan untuk membuat hubungan yang baik dengan rekan tim

Bagi kepemilikan kode. Jangan biarkan hanya satu orang yang tahu akan suatu area kode. Begitu kita yang jadi bottleneck, kita akan kesulitan untuk jadi fleksible karena tanggungjawab kita tidak bisa dibagi. Kalau ada bug dengan prioritas tinggi, malah kita yang selalu harus memperbaikinya. Padahal kita bisa saja menggunakan waktu yang ada untuk belajar dan membuat hal baru.

Selalu lakukan retrospektif saat setelah terjadi insiden atau bug yang kritikal. Tujuannya bukan untuk saling menyalahkan, namun untuk berbagi pelajaran bersama. Bahkan bila insiden ini terjadi di level projek, kita tetap bisa membagikan hasil retrospektif ini ke tim-tim lainnya. Collective wisdom.

Seperti NASSA yang sudah mengalami banyak insiden dari tahun 1960-an, semua kesalahan dibutakan Flight Rules-nya. Dokumenasinya lengkap. Jadi jika terjadi kesalahan yang sama di waktu yang akan datang, semua udah tau harus ngapain. Nah kita juga bisa buat Flight Rules kita sendiri: Database gagal? Ada Flight Rules nya. Server kelebihan kapasitas menampung request? Ada Flight Rules-nya. Projek molor? Ada Flight Rules-nya.

Dari tulisan di atas, dengan berhasilnya kita menjadi engineer yang efektif, kita tak hanya bermanfaat bagi diri kita sendiri, tapi kita juga berkontribusi dalam membangun kultur engineering yang efektif dalam tim.

Stay well!