Skip to content

ANS

Menjadi Effective Engineer

developer, pemula2 min read

Kalau ada satu buku yang perlu saya rekomendasikan ke seorang engineer/developer, niscaya akan saya sebut The Effective Engineer. Memang berbayar, karena ini hasil pengalaman dan pemikiran orang yang harus kita hargai lah. Tulisan ini setidaknya sedikit bagian untuk bisa menggambarkan hikmah-hikmah apa yang bisa kita dapat dari itu. Seringkali seorang engineer berfokus pada hal-hal teknis tapi tidak menyadari ada aspek-aspek mindset atau pola pikir penting untuk meningkatkan kemampuannya.

Bentar-bentar, efektif itu apa dulu sih? Prinsipnya, segala yang kamu lakukan, selalu menjadi hasil. Itulah efektif. Tetapi apa yang segala kamu lakukan itu efektif? Mengukur kamu efektif itu apakah dari jumlah fitur yang kamu selesaikan? Berapa lama kamu begadang dan ngoding? Atau seberapa sering kamu membereskan masalah? Buku ini membuka mata kamu mengenai efektivitas, dengan menawarkan istilah "Leverage" dan rumusnya:

./rumus-leverage.png

Seorang yang efektif itu pasti menghasilkan sesuatu, tinggal berapa lama waktu yang dibutuhkan. Leverage membantu kita memikirkan hal tersebut. Bayangkan sebuah hasil yang besar, tapi waktunya lama, lalu ada hasil yang kecil, tapi waktunya pendek. Tentu lebih mudah memikirkan hasil yang besar kan? Kita cenderung terlalu melihat dampak/hasil, bila dibandingkan waktu. Tapi kadang kita terjebak memikirkan/mengerjakan yang cepat dahulu. Sebaiknya kita tengah-tengah, melihat mana yang pas antara waktu dan hasil. Lalu makin lama makin mempercepat mengerjakan sesuatu, sambil melatih prioritas. Coba ingat-ingat lagi Eisenhower Matrix. Agar semakin efektif, kamu juga harus memiliki pola pikir "Growth Mindset". Selalu menyisihkan waktu untuk belajar, perbaiki kecepatan dan prioritas yang akan dikerjakan. Karena sekali mengerjakan, pantang mundur dengan hasil setengah-setengah, berhenti dan tukar atau selesaikan dengan benar.

Dengan semakin pintarnya kamu mengatur prioritas dan belajar, kamu akan semakin baik dalam kecepatan menyelesaikan sesuatu. Sebagai engineer, kamu harus mempersiapkan hal-hal yang membantu kamu lebih cepat. Pelajari cara kerja yang baik, toolings/libraries/aplikasi yang membantu kecepatan kerja kamu, belajar berkomunikasi untuk lebih cepat merespons dan berpendapat. Kamu tak perlu menunggu terlalu ideal, ide utama kecepatan itu adalah bagaimana kamu bisa mendapatkan feedback lebih cepat dan berkembang iteratif secara cepat. Mempersingkat waktu kamu mendapat feedback, akan mempercepat juga kamu memperoleh hasil yang maksimal. Semakin sering mempraktikkan kamu pun akan bisa mengestimasi kecepatan pengerjaan kamu ataupun beban pekerjaan kamu. Ohya sedikit tentang estimasi, disini bukan angka mutlak, saran saya bila kamu estimasi kerjaan selesai 5 hari, sebenarnya kamu butuh 7 hari. Bahasa lainnya, bila kamu punya waktu 10 hari, biasanya waktu kerja inti hanya 6-8 hari. Kamu butuh 1-2 hari untuk berfikir dan mendetailkan beberapa hal, lalu 1-2 hari untuk membereskan bila ada optimasi atau bug. Seringkali apabil kita estimasi pekerjaan tidak memikirkan detail sebelum atau sesudah kerjaan intinya.

Ada hal lain untuk menjadi makin efektif dan cepat, kamu harus siap dengan membuat banyak otomasi. Otomasi dari sisi deployment, testing, maupun kerjaan repetitif. Sebisa mungkin hal-hal repetitif itu kamu pikirkan cara malas ataupun otomasinya. Hal yang menghambat kecepatan itu pun biasanya idealisme, kamu merasa harus sempurna, kode harus bagus, hasil harus mantap. Padahal di awal apapun itu selalu ada ruang untuk kritik dan pertumbuhan hal tak terduga. Jadi yang disiapkan paling penting adalah kemudahan untuk iterasi dan abstraksi secukupnya. Kamu tidak akan mengetahui banyak hal di depan, tetapi cepat melakukan perubahan dalam perjalanan akan membantu kamu memperjelas hal-hal tersebut. Kembali lagi, otomasi dan mempercepat mendapatkan feedback. Dalam jangka panjang, yang penting bagi kamu adalah bukan membuat sesuatu yang tahan dari segalanya, tapi membuat sesuatu yang mudah diperbaiki/ditambahkan segalanya.

Kalau masih kurang puas dengan tulisan ini, bisa cek slides.

ps: saya juga memakai cerita ini bagi semua on boarding tim saya yang baru :)