Practical Developer vs Perfectionist Developer
Pernah ga sih dapet kerjaan suruh kerjain sesuatu terus setelah sekian lama akhirnya keluarlah hasil yang memang jalan sesuai kebutuhan?
Tapi apakah “sesuai kebutuhan” aja cukup buat kalian?
Coba kalian tanya deh pada diri kalian masing-masing penting ga sih jadi master both di teori dan implementasi di suatu hal yang sudah kalian kerjakan.
Jika jawabannya “Ya”, maka kalian adalah Perfectionist Developer, dan jika “Tidak” artinya kalian adalah Practical Developer.
Sedikit disclaimer, tulisan ini mostly opini saya berdasarkan pengalaman pribadi. Jadi jika ada perbedaan pendapat atau kesamaan kita bisa diskusikan biar seru.
Practical Developer
Saya sendiri sih mengakui bahwa saya adalah practical developer, dimana sesuatu yang saya kerjakan itu kebanyakan based on use case dan scope yang sudah ditentukan. Saya sering beranggapan “ah udah jalan ini kok, udah sesuai, butuh apa lagi sih? yaudah jalanin aja dulu, tunggu nanti ada issue baru research lagi”.
Sebenarnya ini ada baiknya dan buruknya.
Baiknya itu sering kali deadline dari strategi bisnis tabrakan dengan required time dari developmentnya, jadi practical developer sangat menguntungkan bagi perusahaan karena akan cepat menghasilkan revenue.
Juga ada kaitannya dengan konsep sprint yang ngerjain sedikit demi sedikit lama-lama jadi bukit.
Cumaa…
Biasanya develop secara practical itu berakibat buruk kedepannya, kalo bahasa gaulnya sih “ngga future-proof”.
Pribadi saya seringkali mengalami hal ini, ketika pekerjaan yang saya kerjakan “sesuai scope” itu akibatnya ada beberapa hal yang kurang efisien. Masalah akan timbul ketika ada feature baru dan kita belum persiapkan dari awal untuk expand, sedangkan timeline yang dikasih sangat terbatas. Ini kalo sedikit demi sedikit lama-lama jadi bukit sih iya, tapi bukitnya bukit sampah kaya di TPS, kesannya kaya “tambalan”, banyak tambalan sana-sini sehingga code pun jadi berantakan.
Betul kalian bisa refactor, cuma jujur deh, refactor itu suatu hal yang membosankan IMO, sering kepikiran “ini rombak ulang bikin dari awal aja gitu ya?” karena udah males liat code-nya juga. Dan refactor itu butuh waktu, seakan-akan kalian jadi kerja 2 kali, kalo gitu segi positifnya yang sejalur sama strategi bisnis gimana dong?
Ya begitu aja terus endless cycle jadinya, develop practical > code berantakan > ga ada waktu buat refactor. Sampe-sampe orang yang baru masuk kaget liat code-nya “Lah ini code atau sampah?”, akibatnya orang baru tersebut susah dan lama untuk adaptasi, sedangkan orang lama yang ngerjain udah resign karena udah ga sanggup handle.
Bisa dibilang develop secara practical ini enak di awal ngga enak di akhir. Macem hubungan yang progress-nya kelewat cepet, putusnya juga cepet, mau cari yang baru tapi susah move on (eh kok jadi curhat).
Perfectionist Developer
Ada salah satu teman saya, sebut saja Ujang. Beliau ini kalo research sesuatu itu dari hulu ke hilir, kalo di tengah-tengah ada cabang ke daerah unknown dia berani jamah. Alhasil baru beberapa bulan di tempat dia kerja langsung naik jadi senior and nge lead timnya sendiri.
Kok bisa? katanya practical developer lebih disukai company?
This my friend, tergantung situasi dan kondisi perusahaan, di tempat beliau developernya banyak, otomatis ada lebih banyak waktu untuk research bahkan refactor.
Beda halnya kalau perusahaan startup yang masih belajar merangkak, waktu itu sangat berharga karena ngejar investor dan developer-nya pun masih sedikit. Kalau jadi perfectionist developer di sikon seperti ini sih mungkin untuk personal development bagus banget, tapi kontribusi kalian di perusahaan akan kurang keliatan impactnya karena bakal ada orang-orang yang berpikiran “Ih, itu si Ujang kerjaannya apa sih? dikasih kerjaan gini doang lama banget”.
Maybe tergantung perusahaannya ya, apakah mau investasi di tech atau ngga? Dan kalau menurut pengalaman saya tetap perusahaan itu target utamanya adalah revenue. Sedangkan riset itu sangat riskan, bisa jadi sukses, bisa cuma bakar-bakar resource doang.
Kita juga harus sadar bahwa tidak semua orang di perusahaan itu orang tech yang bisa estimasi waktu pengerjaan, biasanya peran tech lead disini sering dibutuhkan untuk kasih pengarahan. Cuma kalo kalian pengen ngerjain kerjaan itu sampai 100% dan perusahaan ngasih quota waktu yang cuma cukup sampai 75% gimana dong?
Ya kalau sudah tidak sejalan dengan perusahaan dan ngerasa potensinya kurang keluar akhir-akhirnya resign deh.
Memang ada orang yang super genius bisa research dan implement dengan timeline yang diluar nalar manusia normal, dan Ujang kalo menurut saya termasuk di kategori ini, tapi yang seperti ini sangatlah langka. Jadi kalo di perusahaan ada orang seperti ini tolong lah, kasih imbalan yang sepadan, kalo ilang nanti nangis berjamaah.
Kesimpulan
Jadi Developer Pragmatis atau Developer Perfeksionis itu ga salah dan ga bener, dua-duanya punya pro and cons-nya masing-masing.
Kalau menurut saya, solusi idealnya adalah mempunyai 2 orang dengan role yang berbeda, ada orang yang fokus di implementasi dan ada orang yang fokus di riset, dengan begitu kedua orang ini bisa saling jaga. Seperti apa yang dikatakan bang Thanos;
Cuma kalau balik lagi kita mengacu ke startup yang orangnya masih sedikit gimana? ya berlatihlah untuk menjadi orang yang balance antara practical dan perfectionist.
Pengalaman saya, striking balance ini penting ketika kita bisa membagi mana yang memang harus diriset secara intensif dan mana yang nggak perlu.
Contoh kasusnya ketika membuat sebuah ERP yang kompleks.
Riset secara intense dibagian yang dirasa memang akan jadi masalah ketika ada perubahan, semisal seperti struktur datanya dan flow aplikasi yang akan digunakan. Dan akan lebih baik jika practical dibagian paling akhir, paling akhir itu semisal frontendnya, karena jika ada perubahan di frontend itu ga akan merambat seperti wildfire ke bagian lain, mungkin ada sedikit tapi tidak akan bisa menghabiskan satu pulau borneo. Bayangkan ketika sudah salah dari awal dan data yang masuk sudah ratusan bahkan ribuan.
Kira-kira seperti itulah yang akan terjadi nantinya. Yang tadinya niatan untuk cut time pada akhirnya malah lebih makan waktu lama, belum lagi ada task-task baru yang ga ada kaitannya sama refactor. Task banyak, waktu sempit, motivasi turun, performa menurun, revenue ga lancar, karyawan ga kebayar, perusahaan tutup. Ya itu terlalu extreme sih kalo cuma pointing finger ke developernya hahaha, cuma bisa jadi salah satu dari sekian banyak alasan kenapa perusahaan tutup.
Research diluar jam kerja juga sangat membantu, untuk sekedar baca hal-hal berbau tech yang mungkin akan jadi informasi penting buat apa yang lagi kalian kerjakan atau yang akan dikerjakan.
Dan selalu ingat ini:
That’s it from me, I hope it helps.
Any comments or suggestions are greatly appreciated, Thank you.