Kita Telah Menggunakan Terlalu Banyak Tingkat Abstraksi

• Di industri teknologi, semakin banyak orang yang hanya mempelajari cara memakai alat dan otomatisasi, sehingga kedalaman teknis untuk memahami cara kerja lapisan di bawahnya melemah
• Abstraksi membuat pekerjaan lebih mudah seperti setir atau power steering, tetapi saat terjadi kerusakan atau gangguan, jika tidak ada yang memahami bagian dalamnya maka kemampuan pemulihan akan menurun
• Tekanan untuk rilis cepat dan penghematan biaya mendorong banyak peran ditumpuk pada satu orang seperti dalam DevOps·DevSecOps, yang berujung pada lebih banyak otomatisasi dan lebih sedikit pemahaman mendalam
• Di bidang keamanan, orang bisa terlalu percaya pada lampu hijau dari alat uji penetrasi berbasis GUI, sementara pelanggaran nyata bisa tidak terdeteksi dalam waktu lama
• Orang yang mempelajari teknologi perlu tidak sekadar mengikuti tren, tetapi juga mencoba sendiri pekerjaan yang biasanya digantikan alat, serta mempertahankan sikap seorang engineer yang menelusuri kode dan lapisan bawah

---

Kekosongan Pemahaman Teknis yang Tertutup oleh Abstraksi

• Saat ini ada masalah bahwa banyak “ahli” tahu cara mengatur alat, tetapi tidak memahami bagaimana teknologi bekerja di lapisan yang lebih dalam
• Abstraksi itu sendiri memang diperlukan
  • Setir adalah abstraksi yang memudahkan mengemudikan mobil
  • Power steering adalah abstraksi lain yang semakin meningkatkan pengalaman berkendara
• Masalahnya muncul ketika abstraksi itu rusak
  • Jika tidak ada yang memahami teknologi internalnya, akan sulit memperbaiki lapisan yang rusak
  • Meski alat terlihat normal, orang bisa gagal menilai kondisi sistem yang sebenarnya
• Industri teknologi bergerak di bawah tekanan kuat dari keuntungan dan kecepatan rilis
  • Akibatnya, semakin banyak abstraksi dan otomatisasi yang diadopsi
  • Lebih sedikit orang menangani lebih banyak pekerjaan
  • Cara memakai alat tertentu lebih ditekankan daripada pemahaman mendalam
• Peran programmer dan administrator sistem yang dulu terpisah kini berubah ke arah memasukkan pengembangan, keamanan, dan operasi ke dalam pekerjaan satu individu seperti DevOps, DevSecOps
  • Karena sulit bagi satu orang untuk benar-benar menguasai pengembangan, keamanan, dan administrasi sistem sekaligus, sebanyak mungkin pekerjaan lalu diotomatisasi
  • Akibatnya, tenaga teknis modern bisa jadi belajar memakai alat tertentu, tetapi hampir tidak memahami teknologi internalnya

Sikap yang Diperlukan bagi Orang yang Mempelajari Teknologi

• Kehidupan modern sangat bergantung pada teknologi, tetapi teknologi itu sendiri semakin sulit dipahami
• Bahkan di bidang keamanan pun ada kritik bahwa banyak orang hanya tahu cara memakai alat uji penetrasi yang sudah jadi, tetapi tidak benar-benar memahami keamanan itu sendiri
  • Jika lampu hijau muncul di web GUI alat tersebut, orang bisa berasumsi semuanya baik-baik saja
  • Bahkan jika penyerang nyata sudah menembus sistem dan menjual data di darknet, kebocoran atau pelanggaran itu bisa saja tidak terdeteksi
• Sebuah artikel Slashdot ditautkan sebagai contoh kasus sebagian mahasiswa bahkan tidak memahami konsep file dan folder
• Praktik yang diperlukan bagi orang yang mempelajari teknologi adalah sebagai berikut
  • Jangan hanya mengikuti mode atau tren
  • Jangan hanya belajar alat, tetapi pahami bagaimana teknologi dasarnya bekerja
  • Jika memungkinkan, cobalah setidaknya sekali melakukan secara manual pekerjaan yang biasanya digantikan alat konfigurasi
  • Jika memungkinkan, lihat kode dari alat tersebut
  • Terus belajar dan bereksperimen, serta gali lebih dalam teknologi yang diminati
  • Jika memungkinkan, buat homelab dan gunakan sebagai taman bermain untuk belajar dan merusakkannya
  • Tanyakan hal-hal yang tidak dipahami, dan jangan menganggap sebagai default bahwa orang lain pasti lebih tahu
• Ini bukan berarti semua orang harus memahami segalanya dari prinsip pertama atau tidak boleh memakai alat
  • Abstraksi memang diperlukan
  • Seperti sopir truk mengemudi dan mekanik memperbaiki truk, bidang spesialisasi itu memang ada
• Masalah intinya adalah melemahnya sikap engineering yang seharusnya dimiliki orang yang bekerja dengan teknologi
  • Dalam pengembangan perangkat lunak, terlalu banyak peran profesional digantikan oleh alat dan otomatisasi
  • Semakin banyak orang bahkan tidak memahami lapisan tepat di bawah lapisan tempat mereka bekerja
  • Jika pengembang web membangun situs hanya dengan alat atau framework siap pakai tanpa pengetahuan TCP/IP, DNS, HTTP, TLS, dan keamanan, maka kegunaannya akan sangat menurun ketika masalah muncul

[GN⁺]

Komentar Hacker News

• Dalam sejarah penerbangan pun pernah ada masa ketika orang yang bisa menerbangkan pesawat juga bisa merancang dan membuatnya, dan saya penasaran apakah saat itu mereka juga mengkhawatirkan masa depan ketika orang yang tidak benar-benar memahami prinsip pertama mesin akan duduk di kokpit
  Sekarang kita sudah terbiasa dengan gagasan bahwa menerbangkan dan membuat pesawat adalah keterampilan serta profesi yang berbeda, dan kita juga menerima dengan wajar bahwa insinyur penerbangan tidak perlu tahu soal penambangan bauksit atau peleburan aluminium
  Memang menenangkan kalau bisa menelusuri seluruh jalur dari gerbang logika sampai permintaan web, tetapi itu bukan keharusan. Berkurangnya insinyur yang punya gambaran menyeluruh seperti itu lebih merupakan tanda kematangan industri teknologi dan spesialisasi bidang daripada sinyal bahaya

  • Masalahnya, butuh waktu sangat lama sampai teknologi menjadi cukup baik dan dapat dipercaya sehingga benar-benar boleh dioperasikan tanpa pemahaman
    Misalnya dalam pembicaraan seperti “ayo semua kembali ke assembly”, bahkan setelah bahasa tingkat tinggi menjadi arus utama, programmer masih harus memahami assembly untuk waktu yang cukup lama. Sebab sekalipun sebagian besar pekerjaan dilakukan dengan C atau Pascal, abstraksi compiler dan alat debugging masih bocor
    Masalah hari ini adalah kita menumpuk lapis demi lapis abstraksi yang bocor tanpa memberi waktu untuk matang. Semuanya dirancang untuk mengurangi waktu kerja dengan asumsi keliru bahwa developer akan selalu berada di jalur mulus, padahal sebagian besar waktu sebenarnya dipakai untuk men-debug situasi yang tidak berjalan sesuai rancangan. Jika kita membuat jalur mulus lebih cepat tetapi membuat jalur bermasalah lebih lambat, biasanya hasil bersihnya adalah kerugian
  • “Suatu hari nanti bintang-bintang akan menjadi seakrab penanda, tikungan, dan bukit di jalan menuju rumah masing-masing orang, dan suatu hari nanti itulah yang akan menjadi kehidupan di udara. Namun pada saat itu manusia sudah lupa cara terbang. Mereka akan menjadi penumpang dalam mesin yang dikemudikan oleh sopir yang dengan hati-hati dipromosikan agar terbiasa dengan tombol-tombol berlabel, dan di dalam kepala mereka pengetahuan tentang langit, angin, serta jalur cuaca akan menjadi sama tidak perlunya seperti fiksi yang berlalu.” — Beryl Markham, West with the Night, 1942
  • Kopilot Air France 447 tampaknya cocok dengan gambaran seperti itu. Ia secepat mungkin menerbangkan tipe Airbus yang sangat terotomatisasi, dan pengalamannya dengan tipe lain hanya 250 jam
    Karena otomatisasi Airbus membuat stall hampir mustahil kecuali ada sesuatu yang sangat salah hingga sistem kembali ke hukum manual, ia tidak benar-benar memahami cara kerja stall. Dalam penerbangan itu persis hal tersebut terjadi, dan ketika kapten kembali ke kokpit ia langsung mengenali stall yang dalam, tetapi sudah terlambat
    Video Mentour Pilot terkait: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
  • Menurut saya ada beberapa masalah dengan analogi ini. Tidak jelas apakah tulisan aslinya benar-benar menuntut pemahaman pada level prinsip pertama, tidak semua orang di universitas perlu punya pengetahuan penerbangan atau kemampuan menerbangkan sendiri, dan untuk terbang pun ada alternatif
    Proses terbang sejak awal punya batasan fisik, tetapi komputasi dan kerangka untuk memikirkannya berubah tanpa henti dan cakupan penerapannya pun luas. Kalau omong kosong yang dijual sekarang dipindahkan ke analogi penerbangan, itu lebih mirip menjual naik keledai sebagai penerbangan. Banyak pelanggan tidak punya pengetahuan untuk membedakannya
    Bahan penting bagi kemajuan adalah bahwa kita baru bisa melompat jauh di atas suatu fondasi ketika kita sudah tahu cara menyederhanakan sesuatu. Jika terlalu rumit, ada batas pada seberapa jauh dan seberapa tinggi kita bisa pergi. Mirip seperti memperbesar technical debt ke skala umat manusia
    Sayangnya, dalam sejarah kita tidak pandai mengenali momen ketika sesuatu menjadi satu tingkat lebih sederhana. Karena ketika melihat ke belakang, hal itu terasa wajar dan sudah semestinya
  • Kalau jabatan dan deskripsi pekerjaan pilot, teknisi perawatan pesawat, dan insinyur penerbangan terlalu mirip sampai sulit dibedakan, itu baru layak dikhawatirkan

• Anak-anak zaman sekarang rasanya kurang mendapat pengakuan. Beberapa minggu lalu anak teman saya dengan sangat antusias menunjukkan game Roblox yang sedang ia buat bersama teman-temannya
  Karena saat itu Thanksgiving Kanada, ada banyak keluarga dan kenalan, dan ia sudah memilih bagian yang kira-kira akan diminati masing-masing orang; saya adalah “orang yang akan ditunjukkan Lua”
  Orang-orang mengira karena ponsel atau laptop terkunci dan tidak memancing rasa ingin tahu, anak-anak juga akan begitu, tetapi menurut saya justru orang dewasalah yang menjadi kurang penasaran
  Tentu saja itu dibangun di atas abstraksi, tetapi di antara pegunungan abstraksi tinggi selalu ada lembah yang dimasuki segelintir orang yang penasaran. C64 BASIC memang memungkinkan POKE ke alamat memori mana pun, tetapi mendengar anak 10 tahun menjelaskan game koleksi 3D yang kompleks dengan elemen FPS juga cukup keren

  • Membuat game menurut saya adalah pintu masuk yang kurang dihargai menuju pemrograman dan pengembangan perangkat lunak secara umum. Itu berhasil untuk saya juga
  • Roblox memang ekosistem tertutup yang dikendalikan perusahaan, tetapi karena bisa diprogram dan cukup terbuka untuk melakukan permintaan HTTP, sulit menyebutnya contoh yang buruk

• Nuansanya seperti orang tua yang berteriak ke awan
  Tidak ada yang baru dari fakta bahwa sebagian orang adalah ahli dan sebagian lainnya sekadar lumayan. Tidak semua orang bisa menjadi penyelamat seperti penulis yang memakai separuh tulisan pendek ini untuk membanggakan diri
  Tulisan ini hampir tidak ada hubungannya dengan abstraksi. Setelah dua paragraf pertama, penulis kehilangan minat pada tesisnya sendiri

  • Tulisan-tulisan di situs itu umumnya begitu dan sesekali naik ke halaman utama. Ada banyak bagian yang secara emosional terasa relatable, tetapi penulisnya hampir selalu gagal menyusun argumen yang melampaui “saya yang paling pintar, dan menurut saya ini tidak baik”
  • Setidaknya saya mengharapkan contoh konkret atau kasus tertentu, tetapi tidak ada apa-apa. Tulisan “orang tua berteriak ke awan” pun masih oke kalau ada contoh atau isi substansial karena kita bisa belajar sesuatu, tetapi dalam kasus ini seluruh tulisannya terdengar seperti komentar HN yang buruk
  • Saya merasakan hal yang sama. Saya tidak tahu bagaimana tulisan ini bisa naik ke atas
    Contohnya juga buruk sekali. Katanya “seseorang memakai framework modern lalu diretas, tetapi masalah performanya bukan karena peretasan melainkan karena framework-nya sangat lambat”, tetapi tidak jelas framework apa, bagaimana ia tahu framework itu lambat hanya dari diff, dan apa hubungannya ketidakmampuan menyetel alat agar sesuai performa dengan abstraksi

• Masalah lain adalah bahwa kita berkali-kali mengadopsi abstraksi yang keliru. Di industri perangkat lunak saat ini ada monokultur arogan yang percaya bahwa kita sudah sampai di titik akhir sejarah dan sudah memahami semuanya.
  Kenyataannya, menurut saya dalam banyak teknologi terbaru kita sudah menempuh jalan yang salah. Sampai sekitar 2014, semuanya tampak bergerak ke arah yang benar, tetapi setelah itu rasanya kemajuan justru mundur dan semua orang mulai memakai framework yang sama-sama dilebih-lebihkan. Karena perusahaan memaksakan framework seperti ini kepada semua orang, pengembangan perangkat lunak menjadi tidak efisien dan melemahkan semangat.
  Saya membuat SDK untuk proyek pribadi, dan itu setidaknya 10 kali lebih produktif daripada framework arus utama yang saya pakai di pekerjaan perusahaan, serta kodenya jauh lebih mudah dibaca dan dirawat. Bahkan ketika saya menunjukkannya kepada junior yang tidak tahu framework tersebut, mereka bisa bekerja secara produktif. Dengan SDK ini saya membuat platform BaaS no-code dalam 2 bulan secara paruh waktu; dengan tool dan framework arus utama, saya rasa saya atau siapa pun sulit melakukannya dalam 12 bulan penuh waktu.

  • Mungkin alasan framework itu produktif bukan karena ia framework terbaik yang tersedia, melainkan karena Anda membuatnya sendiri, memahami seluk-beluk internalnya, dan cocok dengan cara berpikir Anda.
    Tentu saja mungkin ada hal-hal yang lebih baik dibanding framework lain, tetapi keakraban melahirkan keahlian, dan keahlian melahirkan produktivitas.
    Sebelum sekrup drywall populer, banyak pekerja terampil yakin bahwa sekrup lebih lambat dan lebih buruk, tetapi ahli memaku maupun ahli memasang sekrup sama-sama menyelesaikan pekerjaan dengan cepat dan baik.
  • Soal pernyataan “perusahaan memaksakan framework ini kepada semua orang”, perusahaan terdiri dari orang-orang, dan kita berharap para pengambil keputusan membuat keputusan yang tepat dengan konteks dan pengetahuan yang mereka miliki.
    Baik frontend maupun backend, ada alasan mengapa kita memakai “framework-framework ini”. Anda mungkin tidak menyukai alasannya, tetapi dalam pemrograman perusahaan yang penting bukan hanya kemurnian bahasa, melainkan juga faktor-faktor yang menghasilkan uang seperti kemudahan perekrutan, kemudahan pemeliharaan, dan kesinambungan.
    Apa yang terjadi jika perusahaan memakai SDK kustom Anda lalu Anda pergi? Anda mungkin berpikir itu mudah diajarkan kepada orang lain, tetapi keputusan teknologi perusahaan melibatkan jauh lebih banyak faktor daripada itu.
  • Saya penasaran dengan SDK itu. Apakah di-host secara publik? Kalau tidak, setidaknya bisakah Anda menjelaskan perbedaan antara pendekatan Anda dan framework arus utama?

• Kalimat “banyak yang disebut pakar saat ini hanya tahu cara mengatur tool yang sedang tren, tetapi sama sekali tidak memahami bagaimana sesuatu bekerja pada tingkat yang lebih dalam” sangat mengena.
  Semua orang tahu prosedur hafalan seperti “untuk melakukan X, tambahkan baris ini ke file konfigurasi”, tetapi ketika harus melakukan sesuatu yang sedikit berbeda dari X atau variasi dari X, mereka tidak tahu cara keluar dari skrip. Lebih buruk lagi, mereka membuat orang membuang waktu untuk mengarahkan percakapan dari not-quite-X kembali ke X. Ini mengingatkan pada analogi mencari dompet yang hilang hanya di bawah lampu jalan.

• Saya pikir bagus bahwa kita menciptakan ekosistem teknologi, semacam “techosystem”, tempat orang bisa berkontribusi hanya dengan pengetahuan yang sangat sempit. Dalam versi yang kurang positif, ini juga berarti perusahaan bisa mempekerjakan tenaga kerja yang lebih murah dengan kebutuhan keterampilan teknis yang lebih sedikit.
  Dalam banyak kasus, saya percaya solusi biasa-biasa saja lebih baik daripada tidak ada solusi sama sekali. Internet tahun 1995–2005 dibangun di atas solusi biasa-biasa saja, dan itu benar-benar menyenangkan.
  Para ahli yang menggali dalam bukan spesies yang menghilang, dan bukan pula sumber daya terbatas yang memiliki pengetahuan rahasia dari era sebelum abstraksi. Justru sekarang jumlahnya lebih banyak daripada sebelumnya. Mereka tidak didefinisikan oleh apakah mereka pernah mengerjakan seluruh stack dari atas sampai bawah, melainkan oleh rasa ingin tahu untuk melihat ke tempat yang bukan lapisan mereka sendiri.
  Sebab bukan hanya lapisan abstraksi di atas yang bertambah; lapisan di bawah juga berubah, seperti NVMe, WebGPU, WebAssembly, QUIC, dan AVX512.
  Namun, ahli yang menggali dalam adalah kemewahan yang tidak dibutuhkan oleh sebagian besar tim, dan menurut saya salah satu kemampuan terpenting seorang manajer teknologi adalah mengetahui kapan benar-benar harus merekrut orang seperti itu.

• Peningkatan tingkat abstraksi itu diperlukan. Otak manusia tidak menjadi jauh lebih mampu dari tahun ke tahun, tetapi jumlah tool yang tersedia terus bertambah, jadi abstraksi diperlukan agar kita bisa fokus.
  Menurut saya ini tidak serta-merta berarti masa depan suram. Programmer yang menangani masalah bisnis bisa sangat produktif dalam bahasa tingkat tinggi tanpa mengetahui EUV, compiler, assembly, instruction set, kernel, protokol USB, HTTP, die, substrate, dan sebagainya. Pilot juga tidak perlu mengetahui semua tentang aerodinamika, kekuatan tarik, aluminium, karet, GPS, dan seterusnya.
  Namun ketidakselarasan insentif dalam masyarakat modern memang layak dibahas. Secara umum saya lebih percaya pilot dibanding pengembang perangkat lunak bisnis, peneliti, atau bankir. Karena jika pesawat jatuh, pilotlah yang tiba lebih dulu.

• Perangkat lunak untuk ketapel membutuhkan pendekatan yang berbeda dari aplikasi CRUD yang terlalu generik yang mengekspos hal-hal seperti berapa banyak rumah mewah yang Anda miliki.
  Ada banyak perangkat lunak bodoh di dunia, dan itu tidak apa-apa. Banyak “masalah nyata” juga cukup bodoh dan tidak menuntut rekayasa heroik.
  Dalam jumlah kasus yang menakutkan, perangkat lunak asal tempel yang buruk saja sudah cukup.
  Saya juga tidak menyukainya, tetapi akhirnya saya merasa pilihannya hanya membangun bisnis sendiri dengan rekayasa saya yang lebih unggul untuk mengalahkan mereka dan membuktikan bahwa mereka salah, atau menerima bahwa saya hanya sedang berteriak ke awan.

  • Sebagian besar perangkat lunak untuk ketapel juga dibuat asal-asalan seperti yang disebutkan tadi, tanpa source control atau unit test.
    Saat mengambil keputusan pembelian, rumah sakit tidak memeriksa kualitas perangkat lunak lebih dari sedikit di atas level “tombol ini tidak bisa ditekan”.

• Agak pas secara aneh bahwa tulisan yang mengkritik abstraksi menautkan kalimat “di antara mahasiswa sekarang, ada yang bahkan tidak tahu apa itu file dan folder” sebagai hyperlink.
  Tautan itu menuju thread Slashdot, lalu dari sana berlanjut ke artikel PC Gamer, artikel itu menulis ulang dan menautkan artikel Verge, dan artikel Verge berlanjut ke pertanyaan Stack Exchange.

• Dengan kata lain, ini adalah cargo cult programming. Saya menulis tentang ini dua tahun lalu [1], dan reaksinya terpolarisasi sepenuhnya antara setuju total atau menyerang kerasnya sebagai gatekeeping
  Saya berharap ada cara yang lebih baik untuk menyembuhkan penyakit ini tanpa menyentuh sistem imun profesional para engineer yang sudah berinvestasi sangat dalam pada teknologi favorit mereka
  [1] https://medium.com/the-engineering-manager-guide/cargo-cult-...

  • Menurut saya itu sudah terlihat dari caranya menaruh istilah seperti “react expert” dan “node expert” dalam tanda kutip. Cukup jelas bahwa ia memandang perannya sebagai orang yang membongkar bahwa mereka bukan ahli sungguhan
    Keduanya tidak memahami pertanyaannya, tetapi ia bahkan tidak memperjelas pertanyaan itu atau mempertimbangkan kemungkinan bahwa masalahnya ada pada pertanyaannya
    Kalimat “saya meminta seorang pakar React.js membandingkan berbagai pendekatan SPA seperti manipulasi DOM langsung, templating sisi klien berbasis MVC, manipulasi DOM berbasis komponen, dan cara mengompilasi ke vanilla JS” pun, jujur saja, saya juga tidak mengerti maksudnya
    Saya tidak tahu apakah “mengompilasi ke vanilla JS” berarti mengompilasi TypeScript ke JavaScript, atau apa hubungannya dengan DOM. “manipulasi DOM berbasis komponen berbasis MVC” juga terdengar aneh. Rasanya seperti orang yang membaca buku design pattern lalu mengurangi nilai orang yang tidak memakai istilah yang sama dengannya, bukan seperti orang yang memahami pengembangan secara lebih mendalam
  • Pertanyaan-pertanyaan yang diajukan dalam tulisan itu bagus. Namun saya merasa sedih, jangan-jangan kita telah kehilangan sesuatu yang mendasar seiring makin jarangnya orang bangga pada kemampuan, pekerjaan, dan pencapaian mereka
    Menurut saya, orang yang benar-benar menikmati kepuasan saat pekerjaan dilakukan dengan baik umumnya menghabiskan lebih banyak waktu untuk sungguh-sungguh memahami sesuatu dibanding orang yang sekadar ingin menyelesaikan pekerjaan
    Namun apa yang rasa ingin tahu itu berikan kepada kita? Saya teringat anekdot dari fortune(6) ini, dan penasaran berapa banyak orang yang tidak punya rasa ingin tahu akan memahaminya
    Seorang pemula mencoba memperbaiki mesin Lisp yang rusak dengan mematikan lalu menyalakannya kembali. Knight melihatnya dan berkata dengan tegas. “Kamu tidak bisa memperbaiki mesin hanya dengan mematikan dan menyalakannya kembali tanpa memahami apa yang salah.” Knight mematikan lalu menyalakan mesin itu. Mesin tersebut berfungsi
  • Menurut saya konsep gatekeeping benar-benar berbahaya. Hampir setiap kali tuduhan itu dipakai, selalu ada asumsi tersirat bahwa gatekeeping jelas buruk
    Itu dipakai sebagai langkah penentu semacam “kamu melakukan gatekeeping, jadi aku menang”, padahal itu gagasan yang konyol. Tidak ada yang salah dengan membela standar keahlian yang tinggi, dan itu pada dasarnya memang gatekeeping. Saat pergi ke dokter, saya merasa sangat bersyukur bahwa kedokteran adalah profesi yang di-gatekeep
  • Saya membaca tulisan blog itu untuk mencoba memahami mengapa muncul reaksi negatif, dan kesannya terasa agresif serta arogan. Rasanya seperti ia menguji orang dengan detail-detail kecil untuk menunjukkan bahwa ia tahu lebih banyak