Akhirnya kelar juga part 2 lanjutan dari tulisan sebelumnnya tentang opini pribadi gw terhadap kesalahan junior software engineer🥳. Seperti yang udah gw tuliskan sebelumnya, tulisan ini dibagi 2 part karena ternyata lumayan banyak point of view gw terkait hal ini. Beberapa poin juga bagian dari kesalahan yang pernah gw lakukan dulu😅. Jadi kita saling instropeksi diri aja sama saling berbagi pengalaman. Berikut ini adalah another 10 kesalahan umum junior software engineer yang sering terjadi berdasarkan pengalaman dan opini gw pribadi:
Impostor syndrome adalah perilaku seseorang yang meragukan atau mempertanyakan kemampuannya karena standar yang ia terapkan terlalu tinggi untuk dirinya sendiri. Banyak yang merasa iri dengan raihan teman-temannya yang lain atau postingan orang lain yang pamer di sosial media yang udah bisa bikin macam-macam. Sedangkan dirinya sendiri masih belum bisa banyak hal. Padahal belum tentu juga yang suka flexing ilmu di medsos sejago itu😅. Software engineering itu scopenya sangat luas. Salah satu quotes yang katanya sih dari Albert Einstein yang gw setuju adalah:
I don't need to know everything, I just need to know where to find it, when I need it.
Albert Einstein
Hampir mustahil kita bisa jadi master di semua hal dalam waktu singkat. Yang penting kita harus tahu kapan kita akan mempelajarinya, kapan kita menggunakannya, dan kasus yang seperti apa yang cocok ditangani menggunakan itu. Apalagi kalau masih junior. Jalannya masih panjang, nikmati aja prosesnya. Cepat atau lambat kalian akan sampai di titik itu. Senior yang master di banyak hal itu juga ga sebentar belajarnya, butuh 5-10 tahun, atau bahkan lebih. Dibandingin junior yang baru bekerja kurang lebih 2 tahun, ya masih jauhlah. Tapi bukan berarti jadi alasan untuk bermalas-malasan. Standarnya yang realistis aja, misalnya tahun ini fokus belajar Java & Spring Boot, tahun depan akan fokus mendalami database Sql & NoSql, tahun depannya lagi mulai memperdalam system architecture, dan seterusnya secara bertahap. Atau apapun itu, yang penting realistis aja. Kita hanya perlu tahu bahwa untuk membuat aplikasi berjalan di semua jenis system menggunakan Docker. Jadi suatu saat kita membutuhkan itu, kita tahu bahwa kita harus mempelajari Docker. Kita hanya perlu tahu bahwa untuk mempercepat pembacaan data yang sering diakses dan jarang diubah menggunakan Redis. Jadi suatu saat kita membutuhkan itu kita tahu bahwa kita harus belajar Redis. Kita hanya perlu tahu bahwa untuk menghandle pencarian data yang banyak dan kompleks menggunakan search engine seperti Elastic Search. Jadi suatu saat kita membutuhkan itu kita tahu bahwa kita harus belajar Elastic Search. Begitu juga untuk hal lainnya.
Overengineering adalah menyelesaikan suatu masalah sederhana secara berlebihan. Biasanya ini dilakukan setelah mempelajari sesuatu dan ngebet ingin mengimplementasikannya di project yang dikerjakan, padahal belum tentu sesuai kebutuhan. Bukannya mempermudah, malah bikin code jadi kompleks dan rumit, atau bahkan bisa memperlambat development atau performa aplikasi. Misalnya setelah belajar design pattern, langsung diaplikasikan secara membabi-buta tanpa melihat kondisinya. Semua object dijadikan Singleton tanpa melihat konteksnya. Semua object ada Buildernya tanpa tahu kekurangannya. Atau setelah belajar search engine seperti Elastic Search, langsung diaplikasikan pada fitur pencarian, padahal datanya ga terlalu banyak dan masih bisa diakali dengan cara lain seperti restructuring query atau apply index. Atau setelah belajar Data Isolation, semua transaksi diganti menjadi Serializable, padahal ga ada urgency memblok transaksi lain. Atau setelah belajar NoSql, databasenya diganti dari Sql ke NoSql tanpa pertimbangan yang matang. Dan masih banyak contoh lain yang ditemukan. Semuanya ga bisa diaplikasikan untuk semua kasus. Masing-masing pendekatan dilakukan berdasarkan jenis permasalahan yang dihadapi. Ga ada yang namanya silver bullet, satu solusi untuk semua masalah dalam pemrograman.
Banyak juga yang gw liat ketika mengerjakan suatu task hanya fokus pada task itu saja. Edge cases-nya diabaikan. Padahal inilah saatnya critical thinking kita diasah. Selain mengerjakan task sesuai requirement, kita juga harus aware terhadap edge cases yang mungkin akan dihadapi. Jika di suatu algoritma itu ada “if” logic, maka kita juga harus aware “else” logic-nya bakal gimana. Kalau perlu tanyakan pada tim Product atau Managernya jika bingung “else”-nya gimana. Misalkan pada algoritma konfirmasi penjualan, statusnya harus “open” saat diproses. Kita juga harus aware kalau statusnya bukan “open” handlenya gimana. Jangan hanya dibiarkan begitu saja mentang-mentang ga ada di requirement. Apalagi kalau sampai berasumsi sendiri tanpa klarifikasi dan handle sesuka hati. Malah dilaporin sebagai bugs ntar😅. Kita harus raise up ke tim Product atau Manager untuk klarifikasi ketika menemukan edge cases yang belum didefinisikan pada requirement.
Unit test adalah proses membuat testing secara otomatis pada bagian suatu algoritma yang kita develop. Unit test ini membantu kita agar aware terhadap perubahan-perubahan apa yang dapat menyebabkan algoritmanya jadi bugs. Jadi kita akan tahu lebih awal ketika melakukan kesalahan saat melakukan perubahan. Kadang selesai develop sesuatu, banyak juga yang malah mengabaikan unit test. Apalagi kalau unit test sebelumnya jadi error setelah di-develop. Bahkan ada juga yang sampai disable unit test tersebut😤. Ini justru akan mempersulit engineer selanjutnya yang akan develop pada class yang sama. Unit test itu ditambahin saat development dan diperbaiki kalau error, bukan malah dihindari apalagi sampai disabled.
Ini juga cukup banyak junior yang ga peduli teori. Taunya hanya code dan code saja. Mempelajari teori itu bukan berarti harus menghafal semua function pada bahasa. Yang expert pun juga belum tentu hafal semua function. Teori yang penting dipelajari itu seperti programming principle dan best practice dari suatu kasus. Jadi kita tahu kapan menggunakan pendekatan “ABC”, dan kapan menggunakan pendekatan “XYZ”. Itu bagus untuk mengasah decision making. Dalam pemrograman praktek dan teori itu harus sejalan. Hanya melakukan praktek saja tanpa mempelajari teorinya hanya akan menghasilkan program yang asal-asalan. Code readability akan memburuk dan akan susah dimaintain oleh orang lain. Pada intinya tugas software engineer bukan ngetik code doang, tapi mencari solusi dari suatu permasalahan menggunakan teknologi. Lewat teori itulah kita akan paham konsep sebuah teknologi dan gimana best practicenya dalam mencari solusi sehingga praktek pun akan jadi lebih gampang dilakukan dan dikembangkan kalau paham teorinya.
Sebagian junior dalam melakukan coding masih sering seenaknya saja. Kalau codingnya untuk project sendiri sih ga masalah karena hanya akan dibaca dan dimaintain oleh dirinya sendiri. Tapi kalau codingnya bersama tim tentu akan menimbulkan miskomunikasi. Penamaan yang tidak seragam dapat menyebabkan konflik dan miskomunikasi. Contohnya, kita menggunakan suffix “Request” pada setiap class di domain request API. Maka semua class yang berisi request dari sebuah API juga harus menggunakan suffix “Request”, seperti “OrderCreationRequest”, “OrderConfirmationRequest”, “OrderDeliveryRequest”, dll. Jangan sampai dibikin belang-belang jadi “OrderCreationRequest”, “OrderConfirmationDto”, “OrderDeliveryEntity”, dll. Harus pilih salah satu terminologi, suffix “Request”, “Dto”, atau “Entity”. Kalau misalkan udah sepakat menggunakan suffix “Request” pada setiap class yang berisi request dari sebuah API, maka ikuti satu terminologi itu aja, ga usah diganti. Begitu juga misalnya untuk class pada domain database misalnya menggunakan suffix “Entity”, maka semua class yang berisi data yang diproses oleh database juga harus menggunakan suffix “Entity” seperti “OrderEntity”, “InvoiceEntity”, “UserEntity”, dll. Jangan pula dicampur-adukkan suffix antar domain seperti “OrderRequest” pada domain database atau “OrderCreationEntity” pada domain request API. Masing-masing domain harus ada suffix penamaannya dan harus konsisten. Jadi orang lain akan paham kalau suffix “Request” berarti untuk request sebuah API, kalau suffix “Entity” berarti untuk data yang diproses database. Apapun itu penamaan yang dipilih, semuanya harus disepakati bersama dan konsisten digunakan. Ini dapat mempermudah komunikasi nantinya.
Kalau tadi terkait penamaan, kali ini terkait code style. Sebenarnya hampir sama sih, sama-sama karena tidak konsisten terhadap sesuatu. Contohnya pada Javascript, ada orang yang ngodingnya pakai ;, ada juga yang nggak. Ada orang yang menggunakan indentasi 2 spasi, ada juga yang 4 spasi, dan ada juga yang 8 spasi. Ada yang menggunakan spasi, ada juga yang menggunakan tab. Ini juga harus disepakati bersama. Kalau code style-nya belang-belang maka akan mudah terjadi konflik saat development nantinya😒. Salah satu best practicenya adalah menggunakan library development seperti Prettier biar code style-nya ga belang-belang.
Privilege di sini bisa bermacam hal, seperti wifi kantor, atau sharing session dari senior. Banyak juga junior yang tidak memanfaatkan ini ketika task lagi sepi. Padahal itu bisa dimanfaatkan untuk memperdalam pengetahuannya seperti dengan belajar memanfaatkan wifi kantor. Lumayan kan buat anak kosan yang ga punya wifi di kosannya😁. Atau belajar langsung dengan senior di waktu luangnya. Kadang di perusahaan itu ada namanya sharing session atau transfer knowledge untuk membagikan kisah mereka dalam menghadapi jenis permasalahan. Manfaatkan sesi ini sebaik-baiknya untuk mencuri ilmu.
Ini biasanya karena overconfidence saat sebelum mengerjakan task. Jadinya menganggap remeh task. Merasa bahwa task tersebut bisa dikerjakan dalam waktu semalam. Ketika deadline udah dekat, baru panik dan keteteran. Hasilnya malah ga bisa mengerjakannya tepat waktu. Untuk itu hindari pengerjan yang mepet waktu, karena kita ga pernah tahu bakal ada blocker apa ke depannya yang bisa menghambat development. Tapi dari sisi tim Product atau Manager kadang juga ngasih task dengan deadline yang mepet. Jadi ini perlu kesadaran dari masing-masing tim sih.
Ketika diberikan task dengan requirement yang ga masuk akal atau deadline yang ga ngotak, ada juga yang langsung bilang “iya”. Padahal dia tahu di awal bahwa itu ga realistis. Mungkin karena masih junior jadi agak segan buat ngebantah. Atau orangnya emang suka ga enakan sama orang😳. Itu justru akan mempersulit diri sendiri. Kalau emang ngerasa ga masuk akal atau ga realistis, raise up aja. Pasti akan dicari jalan keluarnya bareng-bareng. Misalkan butuh waktu untuk experiment task yang susah, tinggal bilang aja. Harusnya atasannya juga ngerti kok. Kecuali kalau atasannya asshole, ya susah juga🤣. Yang penting raise up-nya jangan mepet-mepet, seawal mungkin lebih baik biar jalan keluarnya cepat ditemukan. Daripada dipendam sendiri, malah pusing sendiri. Lebih baik pusingnya bareng-bareng😂. Tapi harus realistis juga, jangan sesuatu yang gampang malah bilangnya susah, nanti kita malah dianggap memiliki skill issue.