3 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jika memahami perangkat lunak secara mendalam, kita tidak akan terseret oleh alat, dan bisa memiliki kendali serta kepemilikan atas sistem yang menjadi tanggung jawab kita
  • Pencarian dan LLM memberi jawaban cepat, tetapi kebiasaan menyalin solusi yang tidak bisa dijelaskan dapat melemahkan kemampuan memperbaiki dan kompetensi inti
  • Untuk skrip sekali pakai atau UI internal berisiko rendah, membuat dengan generasi AI atau copy-paste bisa masuk akal, tetapi kode yang akan dipelihara lama harus dibuat dengan teknologi yang dipahami secara mendalam
  • Jika produktivitas hanya diukur dari output seperti jumlah baris kode atau jumlah PR, hasilnya mudah terdistorsi, sedangkan outcome seperti rilis yang stabil, penyederhanaan, otomatisasi, dan pengujian lebih dekat dengan nilai jangka panjang
  • Perangkat lunak modern telah menjadi kompleks hingga mencakup runtime, jaringan, keamanan, basis data, dan AI, tetapi jika menguasai prinsip dasar, kita bisa lebih cepat memahami alat dan pendekatan baru

Kendali dan Kesenangan yang Datang dari Pemahaman

  • Pemahaman yang mendalam adalah syarat nyata untuk memperbaiki dan mengubah kode maupun sistem
  • Sesuatu yang tidak kita pahami sulit untuk diperbaiki atau diubah, dan pada akhirnya kendali serta kepemilikan atas kode yang menjadi tanggung jawab kita juga melemah
  • Pemahaman bukan hanya membuat kita menjadi penguasa alat, tetapi juga memberi kepuasan secara psikologis
  • Wajar jika tindakan yang membuat kita lebih mampu mengendalikan lingkungan terhubung dengan emosi positif

Kemalasan Manusia dan Ketergantungan pada LLM

  • Manusia cenderung mengurangi penggunaan energi dan memaksimalkan imbal hasil atas investasi
  • Kemalasan ini menjadi motivasi untuk mengotomatisasi pekerjaan yang membosankan dan mahal, tetapi dalam pembelajaran dan penguasaan keterampilan, hal itu bisa menjadi kelemahan
  • Berkat internet dan LLM, jawaban untuk masalah serupa bisa diperoleh dengan mudah dalam bentuk yang diinginkan, sehingga proses memahami jadi mudah dilewati
  • Daripada belajar SQL secara langsung, memberi tahu tabel dan data yang diinginkan ke LLM lalu hanya menyalin hasilnya memang terasa mudah untuk saat ini, tetapi kemampuan untuk menanganinya dengan benar tidak akan terbangun
  • Meski LLM bisa menghasilkan SQL lebih cepat, kemampuan membaca dan memahami yang dulu dibangun lewat pengulangan langsung akan menurun jika tidak digunakan
  • LLM dan mesin pencari, dalam kondisi terbaiknya, adalah pengganda kemampuan (force multiplier), tetapi kita tetap perlu fondasi dasar yang kuat terlebih dahulu
  • Keterampilan dan pengetahuan inti sulit dipertahankan hanya dengan pencarian, prompt, dan verifikasi manual; kita perlu terlibat langsung dalam proses membangun dan mencipta
  • Secara berkala kita perlu melawan kecenderungan malas dengan membaca dokumentasi dan source code, memahami alasan di balik solusi serta trade-off alat, dan merancang sendiri solusi maupun algoritme

Menyeimbangkan Produktivitas Jangka Pendek dan Pemahaman Jangka Panjang

  • Tidak semua kode dan solusi harus dipahami sepenuhnya, dan standar bisa berbeda tergantung situasi
  • Skrip sekali pakai yang berisiko dan berdampak rendah boleh saja disalin atau dihasilkan otomatis
  • UI atau halaman internal yang dipakai dua atau tiga orang juga bisa ditangani dengan cara yang sama
  • Kode yang akan dimiliki, dipelihara, dan dikembangkan selama berbulan-bulan atau bertahun-tahun harus dibuat dengan bahasa dan teknologi yang benar-benar dipahami
    • Kita harus bisa memahami setiap baris, kata, karakter, dan opsi konfigurasi, atau setidaknya bergerak ke arah itu
    • Daripada mengejar banyak hasil keluaran sekarang, kita perlu mengoptimalkan pemahaman jangka panjang, maintainability, dan produktivitas
  • Jika keberhasilan masih belum pasti, seperti pada MVP atau fitur eksperimen di dalam produk yang sudah ada, standar kualitas dan pemahaman bisa sedikit diturunkan
  • Pilihan seperti ini mirip dengan mengambil utang kognitif
    • Sekarang kita bisa bergerak lebih cepat
    • Tetapi jika produk atau fitur itu berjalan, atau nanti perlu diperbaiki dan diubah, kita harus membayarnya lebih mahal
  • Meski begitu, setidaknya kita tetap harus memahami dan memverifikasinya sampai cukup yakin untuk berkata, “ini bekerja”
  • Dalam beberapa kasus, strategi menghasilkan dulu, memverifikasi, lalu menulis ulang dari awal bisa jadi masuk akal

Efek Bunga Berbunga dari Tech Stack dan Keahlian

  • Jika itu adalah bahasa pemrograman, library, atau alat yang hanya sesekali dipakai, kita tidak perlu menginvestasikan banyak waktu untuk pembelajaran mendalam dan penguasaan
  • Selama hasilnya bisa diverifikasi, menyalin atau menghasilkan sesuatu yang hanya dipahami sebagian kadang-kadang juga tidak masalah
  • Namun, jika kita melewati tahap belajar dan bersusah payah, kita sendiri mengurangi peluang untuk menjadi mahir dan produktif dengan teknologi tersebut
  • Pada tech stack inti yang digunakan secara rutin, kemahiran bisa memberikan imbal hasil ratusan hingga ribuan kali lipat
  • Pengetahuan dan keterampilan memiliki efek bunga berbunga
    • Semakin banyak yang kita tahu, semakin cepat kita bisa membangun sesuatu sendiri
    • Kita juga bisa mempelajari pengetahuan dan keterampilan baru semakin cepat
    • Semakin besar kemampuan kita, semakin banyak solusi dan ide baru yang bisa kita bayangkan

Produktivitas yang Berfokus pada Outcome, bukan Output

  • Cara memahami dan mengukur produktivitas secara umum terbagi menjadi pendekatan berpusat pada output dan berpusat pada outcome
  • Mengukur output itu mudah dan gampang dihitung dengan angka
    • Jumlah baris kode yang dihasilkan
    • Jumlah PR yang dibuka dan digabungkan
    • Jumlah fitur yang diimplementasikan
    • Jumlah bug yang ditemukan dan diperbaiki
    • Jumlah tugas yang diselesaikan
  • Metrik yang berpusat pada output mudah dimanipulasi
    • Bisa menulis kode yang bertele-tele
    • Bisa membuat banyak PR kecil
    • Bisa memecah pekerjaan secara artifisial
    • Bisa menambahkan fitur yang tidak berguna
  • Bertambahnya angka tidak menjamin bahwa kita bergerak ke arah yang benar
    • Banyak PR belum tentu lebih baik
    • Membesarnya codebase juga tidak selalu diinginkan
    • Alih-alih menambah fitur, bisa jadi lebih baik menghapus fitur yang tidak dipakai
  • Contoh pendekatan berpusat pada outcome lebih terhubung langsung dengan nilai jangka panjang
    • Rilis produksi menjadi lebih stabil berkat proses CI/CD baru
    • Refactoring dan penyederhanaan membuat pemeliharaan serta perubahan di masa depan jadi lebih mudah
    • Perancangan ulang solusi integrasi mempercepat penambahan partner baru dan menghemat sumber daya komputasi
    • Menambah pengujian untuk menangkap bug lebih awal dan mencegah regresi
    • Menambahkan metrik dan alert agar potensi masalah dan bug bisa ditemukan secara proaktif
    • Mengotomatisasi pekerjaan manual yang membosankan untuk menghemat waktu dan mengurangi kemungkinan kesalahan fatal
  • Produktivitas dan pemahaman jangka panjang lebih selaras dengan metrik berpusat pada outcome, dan lebih banyak output tidak selalu berarti lebih baik

Perangkat Lunak yang Semakin Kompleks dan Prinsip Dasar

  • Teorema dasar rekayasa perangkat lunak dapat diringkas sebagai, “Masalah apa pun dalam ilmu komputer bisa diselesaikan dengan satu lapisan abstraksi tidak langsung lagi, kecuali masalah karena terlalu banyak lapisan abstraksi tidak langsung”
  • Pengembangan perangkat lunak modern sangat kompleks karena banyaknya lapisan dan elemen
    • Runtime dan platform: browser, server, cloud, mobile, desktop, embedded
    • Jaringan: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, serta protokol basis data dan message broker
    • Keamanan, autentikasi, otorisasi
    • Sistem operasi
    • Virtualisasi, containerisasi, orkestrasi keluarga Kubernetes
    • Basis data: SQL, NoSQL, lokal, remote, terdistribusi
    • Bahasa pemrograman tingkat tinggi dan pipeline compiler, interpreter, serta transpiler
    • Library, framework, package manager
    • API dan layanan eksternal
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLM dan AI
  • Ada juga alasan mengapa kita tetap bisa menghadapi kompleksitas ini
    • Banyak sistem dirancang secara berlebihan dan sebenarnya bisa sangat disederhanakan
    • Dalam periode tertentu, biasanya kita hanya perlu menguasai secara mendalam sebagian kecil dari lanskap pengembangan perangkat lunak
    • Sisanya cukup diketahui pada tingkat pengenalan
    • Jika menguasai pola dan prinsip umum di balik alat, itu menjadi pengungkit untuk mempelajari alat, pendekatan, dan teknologi baru

Cakupan dan Dampak Prinsip Dasar

  • Prinsip dasar adalah aturan, batasan, dan mekanisme yang mendasar serta tidak banyak berubah, yang berada di bawah alat, library, framework, protokol, dan komponen yang digunakan dalam pengembangan perangkat lunak
  • Cakupan intinya mencakup berbagai bidang
    • Arsitektur komputer dan hardware: struktur CPU, eksekusi instruksi, hierarki memori, register, cache, perangkat penyimpanan
    • Bahasa mesin, assembly, dan bahasa tingkat tinggi: alasan assembler, compiler, dan interpreter dibutuhkan, serta trade-off tiap jenis bahasa
    • Sistem operasi: proses, thread, penjadwalan, lock, sinkronisasi, memori virtual, file system, IPC, system call, I/O
    • Algoritme, struktur data, analisis kompleksitas
    • Jaringan: komunikasi antar komputer, keandalan, throughput, latensi, struktur berlapis
    • Basis data dan sistem data: ACID, transaksi, isolation level, indeks, cara penyimpanan, relasi, pemodelan data
    • Desain dan arsitektur perangkat lunak: modularitas, pengelolaan dependensi dan tanggung jawab, information hiding, enkapsulasi, lapisan, client-server, event, coupling dan cohesion
    • State dan aliran data: identitas, single source of truth, penyelesaian konflik, cache dan memoization, invalidasi state, state machine, konsistensi dan sinkronisasi
    • Sistem terdistribusi: teorema CAP, replikasi, latensi, partisi, konsensus, service discovery, eventual consistency
    • Konkurensi dan paralelisme: lock, sinkronisasi, kemungkinan paralelisasi, race condition, deadlock
  • Kita tidak perlu dan mungkin juga tidak bisa menguasai semua bidang, tetapi seharusnya menargetkan untuk mengetahui sedikit tentang masing-masing dan unggul dalam beberapa yang dipilih
  • Jika berfokus pada prinsip dasar, seiring waktu akan muncul meta-skill berupa intuisi universal
  • Jika memahami secara mendalam bagaimana komputasi dan komputer bekerja, baik secara tunggal maupun dalam cluster, kita akan lebih sedikit digoyahkan oleh detail alat dan framework yang terus berubah
  • Pada tingkat ini, mempelajari alat baru yang sedang naik daun juga menjadi jauh lebih mudah

Kegembiraan dan Daya Pengaruh dari Pemahaman

  • Seperti kata Leonardo da Vinci, “kesenangan paling mulia adalah kegembiraan memahami”
  • Dalam pengembangan perangkat lunak, pemahaman bukan hanya memberi kesenangan, tetapi juga daya pengaruh dan kekuatan praktis
  • Cakupan rekayasa perangkat lunak memang sangat luas, tetapi jika berfokus pada prinsip dasar, area yang bisa kita tangani akan semakin besar
  • Sikap untuk terus mendorong batas kognitif kita saat ini akan mengarah pada kegembiraan yang teratur dan perluasan pengaruh

1 komentar

 
GN⁺ 4 jam lalu
Opini di Lobste.rs
  • Saya sangat menyukai nuansa keseluruhan tulisan blog ini
    Belakangan ini saya terlalu sering melihat tulisan bernada “saya membuat alat ini meski tidak tahu apa yang terjadi di dalamnya”, dan saya lelah dengan suasana yang menganggap itu sesuatu yang patut dibanggakan

    • Betul. Pemahaman yang mendalam benar-benar menciptakan keunggulan dan mengarah pada ide serta wawasan baru
      Selain itu, prosesnya sendiri juga sangat menyenangkan
  • Tulisan yang menarik, dan saya rasa dorongan agar orang menghasilkan sesuatu yang tidak mereka pahami sampai tingkat tertentu memang disengaja
    Dari sudut pandang lab AI, jelas ada alasan ekonominya. Mereka baru bisa mulai membenarkan valuasi jika orang harus bergantung pada produk mereka, dan melemahkan kemampuan pengguna adalah salah satu caranya
    Kebetulan hari ini saya juga menulis sesuatu yang mirip, dengan premis inti yang sama tentang kegembiraan benar-benar belajar dan menguasai sesuatu: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • Terima kasih sudah membagikan tulisannya. Poin tentang agensi dan efek bola salju terutama sangat bagus
      Kita sama sekali tidak boleh melepaskan agensi, dan semakin banyak yang kita ketahui dan bisa lakukan, semakin banyak pula yang akan bisa kita ketahui dan lakukan—terbentuk siklus kebajikan. Umpan balik positif yang benar-benar indah
  • Senang rasanya tulisan ini tidak diberi tag vibecoding yang menakutkan itu. Sebenarnya pembicaraan seperti ini sudah ada selama puluhan tahun, hanya dalam versi yang lebih singkat dan biasanya lebih banyak keluhannya
    Perangkat lunak itu sangat kompleks sampai-sampai penuh jalan pintas kognitif, dan pada titik tertentu itu memang perlu untuk bertahan. Tetapi manusia cenderung menjadi lebih malas justru saat seharusnya berhati-hati. Komputer cocok dengan modularisasi yang ketat, tetapi manusia tidak
    Saya suka karena tulisan ini menekankan bahwa pemahaman bukan sekadar “kewajiban”, melainkan betapa menyenangkannya memahami cara kerja sesuatu. Mungkin ada orang yang tidak menikmati memahami dunia, tetapi itu begitu inti bagi kepribadian saya sampai terasa hampir teoretis. Kalau tidak ada kegembiraan itu, mungkin perlu berpikir ulang sebelum memulai karier di perangkat lunak

    • Saya melihat ada tag vibecoding di tulisan ini
      Sekarang rasanya hampir semua tulisan diberi tag vibecoding, jadi mungkin lebih masuk akal membalik gagasannya dan memperkenalkan tag non-vibecoding. Jadi hanya tulisan yang bukan vibe coding, atau tulisan tentang kelebihan vibe coding, yang diberi tag seperti itu, sementara sisanya dibiarkan apa adanya. Sayangnya, ini tampak seperti standar baru
      Tulisan yang bagus, dan juga “sefrekuensi” dengan perasaan saya
  • Saya benar-benar suka belajar, dan tulisan ini membahas situasi “menghasilkan sesuatu yang hanya dipahami sebagian lalu harus menghabiskan lebih banyak waktu untuk memahaminya”, dan secara pribadi saya tidak terlalu keberatan dengan utang kognitif seperti itu
    Jika itu domain masalah yang saya minati, saya bersedia meluangkan waktu untuk melunasi utang itu dan mendapatkan pemahaman. Pada akhirnya terasa seperti jalur lain menuju pemahaman yang sama
    Ini juga mengingatkan saya pada konsep lean startup. Jika ada sesuatu yang bisa dilihat, kita bisa mulai dengan membedah sesuatu yang konkret alih-alih menebak-nebak apa yang penting dari layar kosong. Tidak tahu harus mulai dari mana itu lebih buruk, dan AI bisa membantu memulai dengan cepat
    Bagian yang masih belum benar-benar rapi dalam pikiran saya adalah bagaimana junior yang kurang berpengalaman mengembangkan intuisi untuk mendeteksi hal-hal yang terasa janggal dan membantahnya. Cara saya memakai AI sangat iteratif, dan saya memperlakukannya seperti dialog Socratic untuk perbaikan. Ini sangat berbeda dari dunia vibe coding one-shot yang dimungkinkan alat saat ini

    • Tentang bagian “bagaimana junior yang kurang berpengalaman mengembangkan intuisi untuk mendeteksi hal-hal yang terasa janggal dan membantahnya”, saya punya teman dekat dan anggota keluarga yang baru masuk industri pada akhir tahun lalu
      Secara realistis, saya rasa situasinya tidak jauh berbeda dari sebelumnya. Orang yang lebih senior akan memberi saran dan bantahan, dan di sebagian besar perusahaan teknologi juga ada peer review. Jadi junior tidak sepenuhnya sendirian. Bahkan justru ada cukup banyak waktu untuk melakukan kesalahan dan beradaptasi
  • Saya suka karena tulisan ini mencantumkan cukup banyak topik dasar
    Pembaca mudah membayangkan ini sebagai teknik retoris seperti Gish gallop atau parading of horribles, tetapi menurut saya kenyataannya memang ada puluhan teori dasar yang saling beririsan dalam setiap momen kehidupan kita
    Komputer juga tampaknya lebih dekat ke diagram inklusi-himpunan yang saling tumpang tindih daripada diprogram dengan satu teori terpadu tunggal, melainkan tersusun dari banyak teori kecil yang disambung bersama

  • Saya sangat menikmati membaca tulisan ini dengan saksama, dan juga membagikannya kepada beberapa teman
    Karena semakin sulit untuk melambat, saya juga menulis https://writing.tidefield.dev/hello-world-again/#honing-my-focus tentang berkomitmen secara terbuka pada pembelajaran dasar di tahun baru
    Menyenangkan melihat arah yang sama: “Setelah 2026, saya akan mempelajari hal-hal mendasar yang tidak cepat menjadi usang...”