Lakukan Hal yang Paling Sederhana yang Mungkin Berhasil
(seangoedecke.com)- Dalam desain perangkat lunak, memilih “hal yang paling sederhana yang mungkin berhasil” selalu merupakan nasihat yang efektif
- Desain sistem yang unggul tidak terlihat megah, dan pada praktiknya menyelesaikan masalah hanya dengan komponen seminimal mungkin
- Saat mengejar solusi sederhana, prinsip YAGNI (You Aren't Gonna Need It) dapat dijadikan filosofi desain inti: perluas secara bertahap hanya ketika kebutuhan baru benar-benar muncul
- Meski ada perdebatan tentang definisi “kesederhanaan”, sistem yang memiliki sedikit komponen, keterkaitan internal yang longgar, dan stabil adalah yang paling dekat dengan sederhana
- Obsesi pada skalabilitas berlebihan justru membuat codebase kurang fleksibel, sehingga desain sederhana yang setia pada kebutuhan nyata lebih menguntungkan dalam jangka panjang
Mengejar Hal yang Paling Sederhana yang Mungkin Berhasil
Saat merancang sistem perangkat lunak, penting untuk melakukan “hal yang paling sederhana yang mungkin berhasil”. Pendekatan ini bisa diterapkan di hampir semua situasi, seperti memperbaiki bug, memelihara sistem yang sudah ada, atau merancang arsitektur baru. Banyak engineer memimpikan sistem yang “ideal”: terorganisasi rapi, hampir tak terbatas skalanya, dan terdistribusi dengan bersih. Namun dalam praktiknya, lebih efektif untuk memahami sistem yang ada secara mendalam lalu memilih solusi yang paling mudah.
Kesederhanaan yang Diremehkan
- Desain sistem memerlukan kemampuan menggunakan berbagai alat seperti app server, proxy, database, cache, dan queue
- Engineer junior cenderung ingin memakai banyak teknologi untuk membangun struktur yang kompleks, tetapi keahlian sejati justru terletak pada mengurangi hal-hal yang tidak perlu
- Desain perangkat lunak yang hebat terlihat biasa saja, bahkan memberi kesan bahwa masalahnya ternyata bisa diselesaikan lebih mudah dari yang dibayangkan
- Misalnya, Unicorn dan Rails REST API memanfaatkan fungsi dasar Unix untuk mewujudkan struktur minimal sekaligus memberikan jaminan inti (isolasi, skalabilitas, pemulihan, dan lain-lain), sehingga sangat unggul dari sisi desain
Pola Pikir untuk Implementasi yang Sederhana
- Misalnya, saat menambahkan fitur rate limiting ke aplikasi Golang, kita bisa memakai penyimpanan eksternal seperti Redis, tetapi jika belum benar-benar diperlukan, kita bisa lebih dulu mencoba cara yang lebih sederhana seperti penghitungan di memori
- Jika cara sederhana sudah cukup, penambahan infrastruktur yang berat bisa ditunda
- Dengan begitu, dimungkinkan pengembangan bertahap untuk memperluas sistem hanya ketika kebutuhan baru benar-benar muncul
- Ini adalah pendekatan yang menempatkan prinsip YAGNI sebagai prioritas tertinggi dalam desain
Jebakan Kesederhanaan dan Batasan Praktis
1. Fenomena Big Ball of Mud
- Jika setiap kebutuhan langsung ditangani secara instan, ada risiko codebase berubah menjadi “gumpalan lumpur (big ball of mud)” yang kompleks dan sulit dipelihara
- Namun, perbaikan dadakan (hack) bukanlah kesederhanaan; justru menambah kompleksitas dalam pemahaman dan pemeliharaan
- Untuk menemukan solusi yang benar-benar sederhana, kita perlu membandingkan banyak pendekatan dan benar-benar melakukan engineering yang sistematis
2. Definisi Kesederhanaan
- Tidak mudah mencapai kesepakatan tentang apa yang dimaksud dengan “kesederhanaan”
- Secara umum, sistem yang sederhana memiliki sedikit bagian bergerak (elemen yang beroperasi), keterkaitan antarkomponen yang longgar, dan antarmuka yang jelas
- Contoh nyata: proses Unix dan Unicorn tidak berbagi memori, sehingga tingkat kesederhanaannya tinggi; dibandingkan Puma atau Redis, keterkaitan internalnya juga lebih rendah
- Jika pilihannya ambigu, maka yang membutuhkan lebih sedikit pemeliharaan dapat dianggap lebih sederhana
3. Kritik terhadap Obsesi Skalabilitas
- “Cara yang sederhana” mungkin tidak cocok untuk lalu lintas berskala besar
- Namun, merancang sistem menjadi kompleks sejak awal demi mengantisipasi lonjakan skala di masa depan biasanya merupakan usaha yang sia-sia
- Sebagian besar kode pada kenyataannya hanya perlu siap menghadapi peningkatan trafik sekitar 2–5 kali lipat, dan di atas itu lebih masuk akal untuk merespons saat masalah benar-benar muncul
- Desain yang terlalu berpusat pada skalabilitas merusak fleksibilitas kode; pemisahan struktur yang berlebihan justru bisa mempersulit implementasi fitur tertentu, bahkan menuntut pengelolaan transaksi yang kompleks
Kesimpulan
- Seiring waktu, orang menjadi semakin pesimistis terhadap kemampuan memprediksi kebutuhan masa depan sistem
- Dalam praktik nyata, memahami kondisi sistem saat ini dengan akurat saja sudah sangat sulit, dan inilah masalah utama yang menghambat desain yang baik
- Secara garis besar, ada dua pendekatan dalam pengembangan perangkat lunak
- Merancang dengan memprediksi kebutuhan masa depan
- Mengulangi hal yang paling sederhana yang sesuai dengan kebutuhan saat ini
- Pendekatan kedua pada kenyataannya lebih efektif, dan pola pikir yang berpusat pada YAGNI serta kesederhanaan menghasilkan desain yang baik dalam jangka panjang
Lampiran: Diskusi Hacker News dan Asal Istilah
- Menanggapi pendapat bahwa kesederhanaan arsitektur kehilangan makna ketika skala membesar, penulis justru berpendapat bahwa pada skala besar, struktur yang sederhana menjadi semakin penting (untuk menghadapi kompleksitas interaksi antarfungsi)
- Ungkapan “Do the simplest thing that could possibly work” diciptakan oleh Ward Cunningham dan Kent Beck
1 komentar
Opini Hacker News
Saya rasa pendekatan seperti ini bisa sangat cocok untuk domain yang sederhana. Namun, bahkan setelah lama bekerja di perusahaan teknologi besar, saya masih terus terkejut dengan kompleksitas yang memang dibutuhkan. Masalah bisnis yang paling sederhana pun bisa butuh lebih dari setahun untuk diselesaikan, atau sering rusak karena begitu banyak edge case dan masalah skala. Orang yang terus menyerukan kesederhanaan mungkin belum pernah punya pengalaman skala besar. Bahkan saat melihat codebase berusia 10 tahun, terlalu banyak hal yang harus dipertimbangkan sehingga rewrite pun sering gagal. Seperti analogi Chesterton's Fence, kalau kita tidak tahu alasan sesuatu ada, kita perlu punya kebijaksanaan untuk tidak gegabah menghapusnya
Menurut saya ini adalah kesalahpahaman klasik yang muncul karena para software engineer kurang pandai berkomunikasi satu sama lain. Maksudnya, seperti judul artikelnya, lakukanlah "hal yang paling sederhana yang mungkin". Pada masalah yang kompleks, kompleksitas memang tak terhindarkan, tetapi maknanya adalah kita harus waspada agar tidak membuatnya lebih rumit dari yang perlu. Bukan berarti kompleksitas harus dihindari sepenuhnya, melainkan kita harus menjaga diri dari kebiasaan membuat sesuatu terlalu rumit
Seperti yang sudah ditunjukkan, bisa saja kompleksitas itu bukan berasal dari domainnya sendiri. Bisa jadi itu masalah yang lahir dari desain perangkat lunak yang buruk. Jika penuh dengan dependency dan side effect, berarti pemisahan concern dan pengelolaan coupling tidak tertangani dengan baik. Refactoring pun menjadi nyaris mustahil, dan jika budaya organisasi tidak membaik, selama refactor hanya akan terus ditempeli masalah baru. Meski begitu, dengan pemisahan concern dan komposisi yang sederhana saja, masalah yang kompleks tetap bisa diselesaikan. Memang sulit, tetapi peluang berhasil jauh lebih tinggi jika para developer senior memegang sudut pandang ini dengan kuat
Saya juga merasa orang ini pasti punya cukup pengalaman sistem skala besar, mengingat penulisnya disebut sebagai staff engineer di GitHub
Sistem legacy hidup di edge. Bahkan di sistem nyata, seperti titik-titik di ruang multidimensi yang makin berkumpul di permukaan batas saat dimensinya bertambah, pengguna nyata juga kebanyakan bekerja di dekat batas sistem. Sistem lama yang sudah ada pada akhirnya adalah sistem yang menampung semua edge itu secara optimal
Di tempat kerja saya sebelumnya, sebagian besar kompleksitas datang dari upaya refactor atau perbaikan yang gagal, dihentikan di tengah jalan, atau tidak pernah selesai. Saya sering bertanya-tanya, andai hal seperti itu dicegah sejak awal, apakah kami akan mewarisi sistem yang lebih sederhana. Bukan berarti refactor dan perbaikan tidak boleh dilakukan sama sekali, tetapi menurut saya itu harus direncanakan agar benar-benar mencakup 100% use case, dengan anggaran dan milestone yang jelas, lalu dijamin membaik secara bertahap
Saya berharap asal-usul ungkapan "hal yang paling sederhana yang mungkin" dijelaskan dengan jelas. Frasa ini adalah prinsip yang sering dipakai pada akhir 1980-an saat Ward Cunningham, penemu wiki, bekerja bersama Kent Beck. Saat mereka berdua menulis kode, mereka terus saling mengingatkan prinsip ini, dan setelah itu tema ini menjadi topik penting dalam presentasi dan tulisan mereka. Seperti contoh pintu tertutup, artikel ini juga menyinggung bahwa sesuatu yang tampak sederhana bisa berarti berbeda tergantung situasinya. Artinya, menemukan solusi yang sederhana tidak selalu sederhana. Ada kesadaran bahwa cara ini bisa meninggalkan technical debt, tetapi prioritas utamanya saat itu adalah membuat kode berjalan lebih dulu. Secara pribadi, saya merasa aspek technical debt seharusnya sedikit lebih banyak dibahas juga dalam tulisan ini
Kent Beck kemudian meresmikan Extreme Programming. Metodologi ini adalah kumpulan praktik yang membantu sistem sederhana berkembang secara alami setiap kali requirement berubah
Saya tahu ungkapan ini dari rekan kerja dan melihatnya dipakai seperti motto hidup, tetapi saya tidak tahu kalau Ward Cunningham adalah asalnya. Karena ungkapan ini dipakai begitu luas, mungkin penghormatan tertinggi justru ketika tidak ada lagi yang tahu siapa pencipta aslinya
Menarik juga bahwa Wiki disebut. Di tempat kerja lama saya, kami mengelola proyek dengan Lotus Notes, dan sangat berguna karena secara default menyorot kapan sebuah dokumen berubah. Di proyek berikutnya kami hanya memakai Wiki, tetapi karena saya tidak bisa langsung melihat dokumen mana yang berubah, alat itu praktis jadi tidak berguna. Memang sederhana, tetapi terlalu sederhana sehingga malah kurang praktis
Sepanjang karier saya, salah satu perdebatan terbesar selalu soal definisi "berjalan". Kalimat "berjalan bukan berarti tidak rusak" terasa sangat intuitif bagi orang-orang yang pernah benar-benar memperbaiki sesuatu dengan tangan mereka sendiri. Para tukang sering menambal dengan alat yang rusak lalu akhirnya sadar harus menggantinya, sementara developer tampaknya tidak terlalu kuat merasakan kebutuhan bahwa sesuatu itu memang harus diperbaiki
Masa tersulit dalam karier saya adalah saat saya bekerja di perusahaan yang punya tim penggemar prototipe. Tim itu cepat sekali membuat proof of concept, mendemokannya ke eksekutif, lalu langsung mengirimkannya ke produksi. Akibatnya para eksekutif salah paham dan mengira, "kalau bisa selesai secepat ini, berarti bisa langsung dirilis." Ketika tim pelaksana membuka kodenya, ternyata semua hal penting seperti keamanan end-to-end, validasi, dan penanganan error sama sekali belum ada. Akhirnya semuanya harus dibuat ulang dari nol, dan para eksekutif salah mengira bahwa tim deployment-lah yang sedang membuat semuanya tidak perlu jadi rumit
Saya pernah membaca kutipan yang sangat berkesan: "Tidak cukup jika program hanya berjalan. Program itu harus berjalan karena alasan yang benar." Pada dasarnya pesannya sama
Percakapan seperti ini adalah bagian penting dari pekerjaan profesional. Sebuah sistem bisa disebut "berjalan" dalam arti mampu menghasilkan output yang diinginkan, tetapi dari sisi keandalan atau biaya, tetap saja bisa dianggap gagal
Definisi "berjalan" dalam pekerjaan saya bergantung pada ke mana pemberi kerja ingin mengalokasikan sumber daya, yaitu waktu saya. Kalau ada ruang untuk memakai waktu demi meningkatkan kualitas, saya akan berusaha sebaik mungkin. Sebaliknya, jika yang diinginkan hanya tercapainya target atau checklist, saya akan bekerja sesuai itu. Saya percaya hasil akan mengikuti apa yang diukur, jadi saya bisa memberi saran, tetapi keputusan akhir bukan di tangan saya
Ironi dari nasihat seperti ini adalah, orang yang benar-benar bisa menerapkannya dengan baik biasanya justru para ahli yang sudah sangat berpengalaman. Misalnya, bagaimana kita tahu mana "hal yang paling sederhana", atau bagaimana menilai apakah itu benar-benar akan berhasil. Baru-baru ini saya mengalami kesalahan penanganan XML namespace di XLSX importer buatan saya sendiri, dan masalahnya muncul karena saya berasumsi Excel selalu memakai default namespace. Begitu nanti Anda menerima file dengan namespace yang berbeda, semuanya langsung rusak. Memang lebih sederhana jika saya sekadar menghapus prefix lalu memprosesnya, tetapi demi diri saya di masa depan, saya meluangkan 4 jam untuk mendesain ulang seluruh parser agar ramah namespace. Menjalankan "hal yang paling sederhana" ternyata tidak sesederhana itu, dan memang semakin banyak pengalaman, semakin baik penilaiannya. Tapi saat sudah punya pengalaman sebanyak itu, saya juga merasa nasihat seperti ini sendiri mungkin sudah tidak terlalu diperlukan
Saya rasa artikel utama juga sudah menyinggung kenapa nasihat seperti ini sulit diterapkan. Intinya ada pada kalimat bahwa "untuk menemukan solusi paling sederhana, kita harus mempertimbangkan banyak pendekatan, dan pada akhirnya dibutuhkan pemikiran engineering"
Di perusahaan kami ada prinsip: "jangan menambahkan kode ke arah yang salah." Walaupun implementasinya baru sebagian, kami tetap menulis kode hanya ke arah yang bagus untuk dikembangkan nanti. Ini KISS, tetapi kami sama sekali tidak membiarkan shortcut
Saya menilai kesederhanaan dari "mana yang paling mudah dialihkan". Sebuah layanan tunggal yang tidak bergantung pada abstraksi atau infrastruktur yang rumit pada akhirnya paling mudah dialihkan. Orang yang membacanya bisa langsung paham, dan handover maupun debugging juga jauh lebih mudah. Namun, kalau abstraksi memang dibutuhkan, saya pasti menambahkannya, dan kalau infrastruktur memang perlu, saya juga akan menambahkannya. Yang penting, saya selalu memikirkan apakah struktur ini yang paling mudah dijelaskan saat kodenya diserahkan ke orang lain. Dulu saya berusaha mengabstraksikan semuanya semaksimal mungkin/memisahkan per layanan/serba berbasis konfigurasi supaya hampir tidak ada kode, tetapi dalam praktiknya transisi dan handover justru gagal total. Sekarang saya hanya membuat strukturnya lebih kompleks saat benar-benar perlu, dan selebihnya mempertahankan kesederhanaan yang intuitif. Pada akhirnya ini membantu onboarding anggota baru, perbaikan bug, dan transisi nyata
AI vibecoding juga mirip. Semakin banyak pengalaman dan pengetahuan praktis, semakin mudah memilih task yang tepat dan mengelola agent
Saya rasa banyak orang melewatkan bahwa "hal yang paling sederhana" bukan berarti shortcut atau tambalan darurat. Semakin sederhana metodenya, justru biasanya semakin banyak pemikiran dan pemahaman sistem yang dibutuhkan, dan itu juga yang disampaikan di awal tulisan. Sepertinya banyak orang hanya membaca judul lalu meluapkan kekesalan mereka sendiri
Secara umum, setiap kali saya mendengar prinsip seperti ini atau klaim yang terlalu kuat, saya langsung waspada. Kalau seseorang bicara seolah ada jawaban universal untuk software development, biasanya mereka sebenarnya tidak terlalu tahu. Kesimpulan dari developer yang benar-benar berpengalaman adalah bahwa software itu sulit dan butuh kehati-hatian. Tidak ada jawaban sakti. Yang dibutuhkan adalah pikiran terbuka dan kepedulian
Kesederhanaan, yaitu sisi berlawanan dari kompleksitas, hampir selalu menjadi kriteria teratas saat membandingkan alternatif desain perangkat lunak. Alasannya pada akhirnya karena manusialah yang harus merancang, menyepakati, mengimplementasikan, dan memeliharanya. Namun menilai kesederhanaan itu sangat sulit, dan engineer rata-rata di industri ini tidak cukup dapat dipercaya dalam penilaian seperti itu. Selain itu, klaim "kesederhanaan" sendiri sudah menyebar seperti buzzword yang nyaris kosong makna, sehingga sering dipakai hanya untuk membantah argumen yang benar dengan berkata "ini lebih sederhana". Pemimpin tim seharusnya pandai menangkap isu seperti ini, tetapi kemampuannya makin sering jatuh ke tingkat yang sulit dipercaya, jadi masalahnya terasa makin berat
Ada kalimat yang mengesankan di artikel itu juga. Master sejati tahu bagaimana "mengurangi", bukan "menambahkan"; seperti adegan ketika pemula bergerak ramai dan penuh gaya, sementara sang master bergerak sedikit saja lalu memberi satu serangan penentu
Saat membaca artikel ini saya sempat agak kesal di awal, tetapi saya rasa pembahasannya tepat soal bagaimana "shortcut" hanya menambah kompleksitas lain. Masalahnya muncul saat prinsip seperti ini diterapkan berlebihan seperti perintah manajemen, sehingga masalah yang kompleks diperlakukan terlalu sederhana, transfer pengetahuan jadi sulit, dan yang tersisa nanti hanya penanganan yang lebih rumit. Sebaliknya, alasan lain kenapa sesuatu jadi terlalu rumit adalah karena orang sudah jenuh dengan improvisasi/shortcut yang terus-menerus, lalu ketika akhirnya ingin membereskan semuanya sekaligus, hasilnya malah berlebihan ke arah lain. Pada akhirnya developer harus aktif terlibat dalam diskusi agar keputusan yang bijak bisa diarahkan sejak awal
Saya tidak merasa ini sampai level lampu peringatan. Kompleksitas yang tidak perlu bertambah setiap hari, jadi memang perlu ada orang yang terus menyerukan pentingnya menjaga kesederhanaan. Desainer, product manager, bahkan pelanggan dan arsitek pun secara naluriah cenderung menambah kompleksitas
Saya juga setuju dengan pendapat Anda, tetapi saya juga ingin menyoroti bahwa pada akhirnya semuanya selalu bermuara pada "semua hal adalah trade-off" atau "tidak ada makan siang gratis". Setiap generalisasi lahir dari akumulasi pengalaman lapangan, jadi tidak mungkin dihapus sepenuhnya. Masalahnya adalah ketika konsep yang praktis pada awalnya berubah menjadi rumor berlebihan atau semacam agama, lalu yang tersisa hanya perdebatan soal nama folder
Ada prinsip yang saya serap setelah membangun beberapa sistem 0-1 di startup (Seed sampai Series C): "kesederhanaan adalah ketangguhan". Dalam desain awal maupun saat memperbaiki sistem yang sudah ada, sangat mudah untuk over-engineer. Kebutuhan pelanggan terus berkembang, dan seakurat apa pun kita mencoba memprediksi kebutuhan masa depan, pada akhirnya tetap saja akan meleset. Kesederhanaan menurut saya bukan hanya mengurangi error, tetapi juga menjadi fondasi agar struktur bisa diubah dengan mudah. Siapkan kemungkinan X, Y, Z semampunya, tetapi tetap arahkan untuk membuat "hal yang paling sederhana" demi memberi ruang dan fleksibilitas ekspansi di masa depan. Kompleksitas pada akhirnya pasti menambah batasan, dan semakin lama menumpuk, semakin rapuh stack yang kita miliki
Saya rasa kita perlu mencoba sampai batas tertentu untuk merancang "sistem ideal" sebelum akhirnya bisa sampai ke "hal yang paling sederhana". Dibutuhkan banyak know-how untuk membuat sistem yang mudah dibaca dan mudah diubah. Perbaikan yang benar-benar "sederhana" juga pada akhirnya lahir dari pengalaman dan pemahaman yang mendalam
Ini sejalan dengan Gall's law. Menurut teori itu, sistem kompleks yang benar-benar bekerja selalu bermula dari sistem sederhana lalu bertahap ditambah kompleksitas. Sistem yang dibuat kompleks sejak awal biasanya tidak berhasil. Karena itu, kita harus membuat sistem paling sederhana terlebih dahulu, lalu menambah kompleksitas sedikit demi sedikit sesuai kebutuhan
Saya setuju dengan maksud tulisannya, tetapi menurut saya definisi "kesederhanaan" berubah dengan hadirnya infrastruktur cloud. Dulu posisinya adalah "sederhana tapi tidak scalable" versus "rumit tapi scalable", tetapi sekarang tidak lagi seperti itu. Solusi rate limiting in-memory mungkin sederhana di satu server, tetapi begitu servernya jadi dua saja, masalah distributed state langsung muncul. Sebaliknya, managed service seperti DynamoDB atau ElastiCache menjadi single source of truth baik untuk satu node maupun 1000 node, sehingga sangat mengurangi kompleksitas. Jika dilihat dari sudut pandang "sistem sederhana itu tangguh", memakai managed service justru bisa dianggap lebih sederhana secara mendasar. Layanan seperti itu menghilangkan masalah berulang seperti kehilangan data dan pengelolaan state terdistribusi. Sekarang definisi "hal yang paling sederhana" tampaknya bergeser menjadi kemampuan memanfaatkan managed service yang tidak perlu dikelola sendiri. Saat ini, alih-alih menghindari dependency eksternal, memanfaatkan sistem terisolasi yang sudah tervalidasi untuk meminimalkan kompleksitas justru sering menghemat waktu dan biaya
Saya setuju dengan kutipan, "Buatlah sesederhana mungkin, tetapi jangan lebih sederhana dari itu." Saya selalu berusaha mengikuti prinsip ini, tetapi saya sering bertanya-tanya apakah saya melewatkan kompleksitas yang sebenarnya tidak perlu hanya karena saya belum cukup paham teknologi terbaru, atau justru semua orang sedang terjebak dalam kompleksitas yang tak perlu. Sulit belajar apakah sesuatu benar-benar berguna tanpa memakainya langsung di proyek nyata, tetapi sebaliknya saya juga pernah melihat orang memaksakan tool terbaru ke proyek nyata hanya demi pembelajaran pribadi, dan itu malah merugikan tim
Saya sedang mengalami mimpi buruk yang mirip. Karena atasan saya selalu tertarik pada software terbaru, saya harus terus mengevaluasi tool yang entah akan berguna atau tidak di lingkungan produksi. Meski tidak berhubungan dengan hasil kerja, saya tetap dituntut melakukan eksplorasi seperti itu tiap minggu, dan itu terasa membebani
Dalam praktiknya, saya rasa yang benar adalah membuatnya berjalan dulu dengan cara paling sederhana yang ada, bahkan kalau perlu secara manual, lalu menambahkan fungsi penuh hanya saat momen itu benar-benar datang. Bahkan kalau di awal kita membuang waktu karena mengotomatiskan atau membuat tooling terlalu cepat, pengalaman memahami kenapa itu sebenarnya dibutuhkan nanti tetap lebih berharga
Perasaan ini sangat akrab bagi saya. Saya juga selalu setuju dengan tulisan seperti ini dan berusaha mempraktikkan kesederhanaan, tetapi saya terus bingung apakah itu benar-benar kebijaksanaan dan pragmatisme, atau cuma karena pengalaman dan kemampuan saya masih kurang
Karena itulah saya sangat berusaha hati-hati agar tidak jatuh ke "resume-driven development"