Mengapa developer senior gagal menyampaikan keahliannya

• Developer senior dan non-developer menerima kalimat yang sama bahwa agen AI akan menggantikan developer, tetapi dengan standar yang berbeda: stabilitas dan pembelajaran pasar
• Organisasi bisnis ingin merilis secepat mungkin untuk mendapatkan umpan balik dan mengurangi ketidakpastian, sementara developer senior mewaspadai meningkatnya kompleksitas yang dapat merusak sistem
• Setelah pelanggan muncul, dua siklus—eksplorasi pasar dan keberlangsungan layanan—berjalan bersamaan, dan tanggung jawab inti developer senior bergeser menjadi manajemen kompleksitas
• Persuasi tidak berhenti pada mengatakan “kompleksitas adalah masalah”, tetapi baru mungkin jika keinginan lawan bicara akan kecepatan dipenuhi melalui eksperimen yang lebih cepat seperti Google Forms atau tombol pada UI yang sudah ada
• AI meningkatkan kecepatan rilis, tetapi dapat merusak kemudahan untuk dipahami, diubah, dan di-debug, serta tidak menanggung tanggung jawab, sehingga developer senior dapat memisahkan Speed dan Scale

---

Mengapa kalimat yang sama didengar dengan standar yang berbeda

• Developer senior dan non-developer menerima secara berbeda kalimat yang sama, yaitu “agen AI adalah masa depan pengembangan perangkat lunak dan developer akan tidak lagi dibutuhkan”
• Dalam copywriting, pesan harus disesuaikan dengan audiens, dan kalimat yang sama dapat bermakna berbeda tergantung audiensnya
• Alasan intuisi developer senior berbeda dari optimisme terhadap AI adalah karena definisi masalah berubah tergantung apakah fokus pekerjaannya pada pembelajaran pasar atau stabilitas layanan

Hal yang diwaspadai developer senior

• Di antara developer senior, ada tipe yang ingin mengadopsi sesuatu berdasarkan alat baru, cara kerja perusahaan lain, atau praktik terbaik di Hacker News
• Developer senior yang lebih dihargai akan lebih dulu bertanya, “Apakah ini benar-benar diperlukan?”, “Apa yang terjadi jika kita tidak melakukannya?”, “Bisakah kita bertahan sekarang dan melihatnya lagi nanti saat ini menjadi lebih penting?”
• Tipe ini berusaha sebisa mungkin menghindari pengembangan, menguranginya, dan memanfaatkan kembali yang sudah ada
• Dalam pengembangan perangkat lunak profesional, hal yang paling diwaspadai developer senior adalah kompleksitas
• Kasus khusus, percabangan kondisi, tabel database baru, dan komponen baru semuanya menambah kompleksitas pada sistem
• Developer yang bertanggung jawab atas sistem yang sedang berjalan pada akhirnya akan takut pada peningkatan kompleksitas
• Bahkan developer senior yang mahir membuat desain baru dan kreatif pun akan mewaspadai kompleksitas ketika mereka menangani sistem yang sedang berjalan

Hal yang diwaspadai organisasi bisnis

• Marketer, staf penjualan, manajer produk, dan CEO berada dalam sebuah siklus: meluncurkan sesuatu ke pasar, menerima umpan balik, dan mempelajari apakah itu bernilai
• Tujuan dari siklus ini adalah pembelajaran, dan ancaman terbesarnya adalah ketidakpastian
• Karena tidak ada strategi yang menjamin keberhasilan, ketidakpastian bekerja dengan keras dan tanpa ampun
• Ketika insentif pemasaran dan penjualan, gaji pendiri, serta data manajer produk bertemu dengan waktu, satu-satunya cara untuk mengurangi ketidakpastian sebelum tenggat terasa seperti merilis ke pasar secepat mungkin
• Semakin banyak yang dirilis ke pasar, semakin banyak umpan balik yang didapat, dan secara potensial ketidakpastian bisa semakin berkurang
• Semua perusahaan memulai dari siklus ini, dan siklus ini digerakkan oleh kecepatan murni

Siklus kedua setelah pelanggan muncul

• Saat pelanggan mulai membayar, muncul siklus kedua yang bertujuan pada keberlangsungan dan jaminan layanan
• Sistem harus terus berjalan, dapat dipahami, dapat di-debug, dapat diubah, dapat diajarkan, dan stabil
• Developer senior menganggap stabilitas penting karena mereka memikul tanggung jawab bisnis untuk terus melayani pelanggan
• Yang mengancam semua ini, sekali lagi, adalah kompleksitas
• Kompleksitas membuat sistem lebih sulit dipahami, lebih sulit di-debug, lebih sulit diubah, lebih sulit diajarkan, dan pada akhirnya kurang stabil
• Saat kompleksitas naik, stabilitas turun; developer senior gagal memenuhi tanggung jawabnya, dan masalah seperti terhentinya pembayaran bisa muncul
• Jika tujuan siklus pertama adalah mengurangi ketidakpastian, maka tujuan siklus kedua adalah manajemen kompleksitas

Titik kegagalan komunikasi

• Setelah pelanggan muncul, dua siklus—eksplorasi pasar dan keberlangsungan layanan—berjalan pada saat yang sama
• Bisnis harus mengeksplorasi kemungkinan sambil tetap memberikan layanan kepada pelanggan
• Masalah yang sama akan terlihat berbeda tergantung siklus mana yang sedang menyita waktu
• Organisasi bisnis ingin membuat dan merilis lebih cepat demi mengurangi ketidakpastian
• Developer senior, seiring bertambahnya permintaan, akan mengkhawatirkan kompleksitas, biaya pemeliharaan, kemudahan untuk dipahami, kecepatan pengembangan berkelanjutan, dan produktivitas dari waktu ke waktu
• Namun, bahasa manajemen kompleksitas saja sulit menjawab keinginan departemen lain untuk mengurangi ketidakpastian
• Untuk meyakinkan orang lain, solusi ala developer senior juga harus diungkapkan sebagai solusi terhadap masalah yang mereka hadapi
• Komunikasi gagal ketika masalah dibahas dari sudut pandang manajemen kompleksitas, tetapi solusinya tidak dibahas dari sudut pandang pengurangan ketidakpastian

Kekuatan praktis developer senior

• Kemampuan paling berguna dari developer senior adalah menemukan peluang untuk tidak membangun sesuatu yang tidak perlu, dan untuk memanfaatkan kembali apa yang sudah dibuat
• Jika perlu mengumpulkan data survei, gunakan Google Forms
• Alih-alih membuat satu fitur baru secara penuh lalu mengujinya, Anda bisa menambahkan tombol pada UI yang sudah ada dan melihat apakah orang mengkliknya
• Sebelum mengadopsi layanan analitik baru, tanyakan dulu keputusan terpenting apa yang benar-benar membutuhkan analitik, lalu mulai dari satu keputusan, satu grafik, dan satu metrik
• Pendekatan seperti menancapkan satu lilin pada sandwich alih-alih memanggang seluruh kue ulang tahun juga dimungkinkan
• Developer senior belajar bagaimana memanfaatkan perangkat lunak yang sudah ada untuk memberikan apa yang diinginkan orang
• Kalimat singkat untuk menyampaikan ini adalah “Can we try something quicker?”
• “quicker” mengakui kecepatan yang sebenarnya diinginkan lawan bicara
• “something” menyiratkan bahwa ada cara lain untuk mencapai tujuan yang sama
• “try” memuat kemungkinan bahwa sesuatu yang belum sempurna pun bisa cukup baik
• Kalimat ini mengakui kecepatan pengurangan ketidakpastian yang diinginkan perusahaan, sambil tetap memberi ruang bagi developer senior untuk menjalankan keahliannya: mengurangi, menggunakan kembali, dan jika memungkinkan menghindari pembangunan baru

Tekanan yang diubah AI dan tanggung jawab yang tetap ada

• AI dapat membuat banyak hal dalam waktu singkat, sehingga sikap mengurangi, menggunakan kembali, dan menghindari bisa terlihat tak lagi berarti
• Namun AI masih belum bisa melakukan satu hal yang dilakukan developer senior: bertanggung jawab
• Alasan developer senior menghargai kemudahan sistem untuk dipahami adalah karena ketika masalah muncul, sistem itu harus bisa diperbaiki
• Kemudahan untuk dipahami memungkinkan sistem berkembang secara cerdas saat perlu bertumbuh, dan terus melayani pelanggan berbayar dengan stabil
• AI sangat meningkatkan kecepatan untuk membawa sesuatu ke pasar, tetapi juga memengaruhi siklus stabilitas yang menjadi tanggung jawab developer senior
• Jika agen AI, developer junior, non-developer, investor, dan orang-orang di sekitar mereka semuanya menambahkan kode ke dalam sistem, sistem akan terlalu memberi imbalan pada kecepatan sambil mengorbankan stabilitas
• AI dapat memperburuk kemudahan untuk dipahami, diubah, di-debug, diajarkan, dan dijamin
• AI dapat membuat sistem tidak stabil, tetapi tidak menanggung tanggung jawabnya
• Inilah titik kekhawatiran utama developer senior

Developer senior lebih dekat ke editor daripada penulis

• Salah satu pendekatan yang bisa digunakan developer senior adalah decoupling
• Karena untuk waktu yang lama hanya developer perangkat lunak yang bisa membuat perangkat lunak, developer menanggung dua siklus sekaligus: pembelajaran pasar dan stabilitas layanan
• Satu sistem menopang kedua tujuan itu secara bersamaan
• Jika masing-masing tujuan memiliki sistem yang berbeda, maka kecepatan dan stabilitas dapat dipisahkan
• Ini mirip dengan proses ketika novelis menyelesaikan draf pertama dengan cepat, lalu kemudian melalui proses penyuntingan untuk memilih bagian yang berhasil dan membuang yang tidak berhasil
• Tugas editor adalah mengambil potongan yang bekerja dengan baik lalu membentuknya menjadi satu kesatuan yang koheren
• Versi Speed adalah sistem untuk kecepatan, tempat agen AI, kode hasil generasi yang belum ditinjau, developer junior, pemasaran, dan lainnya dapat dengan cepat mewujudkan ide
• Versi Speed tidak bertujuan pada kemudahan untuk dipahami, melainkan pada kondisi yang cukup baik untuk mendapatkan umpan balik pasar
• Versi Scale adalah sistem untuk stabilitas, yang dirancang developer senior agar stabil, mudah dipahami, dan dapat diskalakan
• Versi Speed membuat bisnis terus belajar dari pasar, dan developer senior mengikuti di belakangnya dengan membangun sistem yang ditinjau dengan baik dan dapat dipahami
• Desain versi Scale dipengaruhi oleh apa yang berhasil dan apa yang tidak berhasil pada versi Speed
• Fitur dibuat di Speed, lalu distabilkan di Scale
• Bentuk implementasi nyata mungkin belum jelas, tetapi intinya adalah memisahkan secara eksplisit pekerjaan yang mengejar kecepatan dan pekerjaan yang mengejar stabilitas karena keduanya berbeda
• Saat menerima permintaan yang ambisius, Anda bisa berkata, “Versi Speed akan siap dalam 3 hari, dan versi Scale akan siap sekitar 6 minggu kemudian”
• Pihak lain mendapatkan kecepatan dan momentum, sementara developer senior mendapatkan waktu untuk observasi dan desain
• Dalam sudut pandang ini, developer senior bisa menjadi lebih dekat dengan editor perangkat lunak senior daripada “penulis perangkat lunak senior”

[GN⁺]

Opini Hacker News

• Bagian terpenting dari keahlian berasal dari model dunia internal, dan tidak bisa dipisahkan dari itu
  Biasanya orang percaya bahwa apa pun bisa diungkapkan dengan kata-kata, dan jika kata-kata itu disampaikan maka pendengar akan memahami maksud pembicara apa adanya. Dari keyakinan inilah muncul tuntutan agar keahlian developer bisa “ditransfer” ke orang lain
  Faktanya, pengetahuan cukup bisa disampaikan lewat kata-kata, tetapi model dunia yang mengeras karena semua pengetahuan itu saling terhubung tidak demikian. AI bisa mengetahui jauh lebih banyak fakta, tetapi masih belum bisa memanfaatkan pengetahuan itu dengan cara yang menghasilkan wawasan yang sangat sering tepat
  Transfer keahlian pada praktiknya lebih mirip petunjuk tentang ke mana harus pergi dan apa yang harus dipelajari, dan penerimanya harus memperoleh keahlian yang sama lewat usaha internalisasi dan proyek yang tepat

  • Salah satu perbedaan besar antara junior yang terlihat berbakat dan cepat “ngeh” dengan yang tidak adalah kemampuan membentuk model dunia yang akurat dengan cepat
    Terlihat jelas bedanya antara orang yang memahami lalu menerapkan “hukum fisika” software, dan orang yang hanya menuliskan prosedur tanpa mencoba memahami hakikat tiap langkah
    Ini особенно menonjol saat mengajarkan functional programming kepada orang yang terbiasa dengan object-oriented: ada yang modelnya runtuh, ada juga yang cepat melihat bahwa dunia monad bisa diterjemahkan relatif mudah dari dunia variabel
  • Kebetulan kemarin saya melihat tulisan Peter Naur dari 1985 https://pages.cs.wisc.edu/~remzi/Naur.pdf dan terus memikirkannya
    Selama hampir 30 tahun saya kebanyakan bekerja di satu perusahaan besar, dan setiap minggu menghabiskan cukup banyak waktu menjawab masalah yang dihadapi orang-orang baru. Sering kali hanya dari pertanyaannya saja saya langsung tahu bahwa akar masalahnya adalah model dunia mereka, atau Theory dalam istilah Naur, tidak lengkap atau terdistorsi sehingga menyulitkan penalaran
    Tugasnya adalah mengubah teori saya menjadi representasi simbolik seperti teks dan diagram, agar orang dengan pengalaman dan kecerdasan yang cukup bisa membayangkan model mental yang serupa. Dengan kata lain, saya ingin memasang teori saya ke dalam kepala orang lain
    Teori dalam arti yang dimaksud Naur tidak bisa dipindahkan secara langsung, tetapi menurut saya pekerjaan developer senior adalah mencari cara mereproduksi teori semacam itu dengan menarik pengalaman, baik di ruang kelas maupun di lapangan. Karena itu kemampuan komunikasi penting, dan seseorang perlu berkali-kali mengalami proses menerima teori kerja dari orang lain agar naluri yang efektif bisa terbentuk
    Sekarang ini justru menjadi bagian paling memuaskan dari pekerjaan saya, dan selama saya merasa masih bisa menjalankan peran ini secara bermakna, saya tidak ingin buru-buru pensiun
  • Kalau semua orang punya model dunia internal yang sama, hampir tidak akan ada inovasi, jadi saya justru menganggap ini hal yang baik
    Saat melatih dan membimbing junior, saya mencoba menunjukkan apa yang mungkin dilakukan dan pola-pola yang berujung gagal, tetapi pelatihan itu biasanya tetap terpecah-pecah dan tidak lengkap
    Saya berusaha menjelaskan alasan di baliknya sebanyak mungkin, tetapi tidak banyak hal yang saya larang secara mutlak. Saya sering terkejut melihat cara orang yang saya ajar memecahkan masalah, dan saya juga sering belajar
    Pelatihan biasanya kurang berhasil pada orang yang tidak tertarik pada kontribusinya sendiri dan hanya melihat pekerjaan sebagai cara mendapatkan gaji. Bukan berarti cara pandang itu salah, tetapi jika pandangan dunianya dibangun dari ketidakpedulian, pelatihan jadi sulit diinternalisasi
  • Saya pernah melihat pandangan bahwa karena pengetahuan sudah dikirim lewat kata-kata maka itu berarti sudah tersampaikan disebut Transmissionism
    https://andymatuschak.org/books/
  • https://en.wikipedia.org/wiki/Tacit_knowledge

• Sebagai developer senior, saya sangat tidak suka generalisasi yang serba mutlak
  Saya sudah melihat kegagalan yang lahir dari sikap seperti “apa ini benar-benar perlu?”, “kalau tidak dilakukan apa yang terjadi?”, “bisa tidak kita tahan dulu dan kembali nanti kalau jadi lebih penting?”, sebanyak kegagalan yang datang dari para eksperimentalis
  Tiap sistem berbeda, tiap produk berbeda. Kalau Anda membuat firmware CT scanner, cara menyikapi hal baru harus berbeda dengan CRUD SaaS yang punya 100 pelanggan
  Memang ada senior yang terlalu bersemangat dan terlalu terbuka lalu mendorong sistem ke sudut yang sulit ditinggalkan, tetapi ada juga orang yang bilang PHP5 saja sudah cukup

  • Saya datang untuk mengatakan hal serupa. Ada saatnya senior yang berusaha sebisa mungkin menghindari development itu baik, dan ada saatnya yang terbaik justru aktif mendorong perbaikan
    Senior yang baik harus bisa melihat kapan momen itu terjadi
  • Ini semacam survivorship bias. Seorang VP pernah memerintahkan memakai Elasticsearch karena itu berhasil di perusahaan sebelumnya, dan ternyata memang juga cocok untuk kami
    Lalu berubah jadi semacam aturan bahwa kalau mengambil keputusan teknis, dengarkan VP dan pakai Elasticsearch
  • Ini terasa seperti membantah demi membantah, padahal inti tulisan aslinya cukup jelas dalam konteksnya
    Tentu ada saat-saat ketika tindakan memang perlu, tetapi saat ini keseimbangannya sudah terlalu condong ke arah membuat segala hal lebih rumit dari yang perlu
    Bukan berarti jangan membuat produk dan layanan baru, melainkan saat membuatnya carilah jalur dengan entropi total paling rendah. Ini juga berlaku untuk operasi dan pengurangan technical debt
    Premature optimization adalah akar dari segala kejahatan
  • Setuju. Konteks itu penting. Developer senior harus memahami kompleksitas, risiko, trade-off, dan sisi bisnis
    Penilaiannya berbeda tergantung apakah Anda startup atau perusahaan besar yang arus kasnya sudah kuat saat mengubah fitur inti produk
  • Sepertinya Anda melewatkan pesan yang ingin disampaikan penulis asli. Karakteristik yang ditekankan itu semua bisa mengarah pada stabilitas yang lebih baik

• Saya menikmati membaca tulisannya, dan setuju dengan pesan utamanya: berkomunikasilah lebih baik sesuai audiens
  Hanya saja framing-nya terasa mulai dari arah yang benar lalu sedikit berbelok ke arah lain
  Dua loop yang diajukan sama-sama diuntungkan jika lebih rapat dan lebih cepat. Salah satunya membawa sistem lebih cepat ke titik setel yang “stabil” dan mudah dipelihara, yang lain menangani ketidakpastian
  Wawasan tambahan tentang memecah sistem agar lebih cocok beradaptasi dengan AI juga adalah sesuatu yang sudah lama saya jelaskan lewat spike jauh sebelum AI menjadi arus utama

• Saya mendapati bahwa keinginan saya untuk mengomunikasikan dan membagikan keahlian biasanya tidak punya permintaan dari developer junior
  Secara umum, developer tidak terlalu tertarik mencari mentor. Mereka bahkan tidak melihat profil LinkedIn, dan tidak melihat saya sebagai kemungkinan sumber pengetahuan dan keahlian
  Bukan karena setelah 30 tahun di industri saya tidak punya sesuatu untuk dibagikan, melainkan karena tidak ada yang mau menerima

  • Inilah frustrasi saya di tempat kerja sekarang. Ada terlalu banyak hal bodoh yang dilakukan dan tidak ada yang mau menghindarinya
    Seorang developer yang kurang berpengalaman mengusulkan mengganti validator URL dengan sihir AI, dan saya menolak dengan mengusulkan solusi fuzzy matching berbasis cache yang dipraisiapkan AI, tetapi tidak ada yang peduli. Sekarang model AI-nya mendadak turun dan sistemnya rusak. Seluruh sistem harus divalidasi ulang
    Seorang developer muda yang dipromosikan lebih dulu dari saya sedang menulis dokumen tentang cara memperbaikinya lalu berkata, “Dan, bisa bantu saya soal ini?” Dia dipromosikan karena cara maju di sini bukan bekerja secara masuk akal, melainkan menulis dokumen dan rapat, dan sekarang dia ingin membuktikan kepemimpinannya dengan memanfaatkan pekerjaan saya
    Semakin baik solusi yang saya usulkan, semakin itu terasa mengancam bagi developer yang kurang berpengalaman, dan karena pada umumnya sistemnya tetap jalan, manajer juga tidak peduli. Mungkin saya juga bisa menanganinya lebih baik, tetapi melawan omong kosong itu sangat melelahkan dan saya cuma ingin menulis kode yang bagus
  • Developer senior yang pernah saya ajak kerja datang ke kantor, bekerja dekat dengan junior, dan tampak hampir alergi berbicara dengan orang lain
    Sebaliknya, para junior ingin ngobrol, makan siang, dan berbagi apa yang mereka kerjakan. Para senior menjaga jarak dan menyendiri
    Mungkin memang hanya tempat kerja kami, tetapi kantor itu penting
  • Saya berharap dulu ada orang seperti Anda saat saya mendapat pekerjaan engineering pertama di IBM
    Beberapa developer senior di sana marah kalau junior bertanya. Bahkan sekadar bertanya sesuatu kepada orang yang sudah bekerja 20 tahun butuh keberanian, dan ada peluang 50% mereka akan bersikap kasar
    Itu jadi pengalaman belajar yang baik, dan sekarang saya sengaja berusaha melakukan mentoring
  • Turut prihatin Anda mengalami itu, tetapi memang ada orang yang ingin belajar dari senior
    Selama beberapa dekade terakhir saya sesekali menjadi mentor, dan saya beruntung bertemu mentee yang hebat. Beberapa bahkan saya lihat berkembang hampir 10 tahun, dan sekarang mereka sangat baik
    Saya tidak punya saran yang lebih membantu soal cara menemukannya, tetapi orang-orang seperti itu memang ada
  • Di pekerjaan pertama, karier saya tanpa sengaja terkunci jadi system administrator di startup, dan karena tidak banyak orang untuk belajar, saya pindah ke perusahaan di negara bagian lain yang dalam wawancaranya ada system administrator luar biasa yang ingin saya jadikan tempat belajar
    Namun tak lama setelah saya tiba, dia mengajukan resign karena katanya sudah menemukan pengganti, dan hasilnya buat saya tidak terlalu baik

• Sebagian besar proof of concept yang saya lihat berubah jadi production begitu mendapatkan traction
  Semua orang pernah beberapa kali berjanji, “kalau nanti naik, kita tulis ulang dari awal,” tetapi itu tidak pernah terjadi
  Tulisan itu menyentuh soal tanggung jawab dan akuntabilitas, tetapi bagi orang yang mengambil risikonya hal-hal itu tidak ada. Mereka mendapat untung dengan buru-buru merilis ide gila lalu berharap pelanggan menggigit. Cara membuatnya bekerja, menskalakannya, dan memastikan biaya operasional tidak melebihi harga jual bukan masalah mereka
  Ada perusahaan yang membawa loop kanan itu sampai ekstrem, dan sekarang dua di antaranya sangat terkenal. Mereka meluncurkan sesuatu dengan cepat, lalu hanya bisa skala secara linear, lalu pergi menggalang dana. Perusahaannya sukses, penggunanya tak terhitung banyaknya, dan sebagian bahkan membayar. Orang yang rasional atau developer senior yang bertanya “apakah ini berkelanjutan, jalan keluarnya apa” akan dipecat, dan yang tersisa hanya orang-orang fanatik

  • Karena itu dibutuhkan kepemimpinan engineering yang benar-benar cukup senior. Termasuk kepemimpinan individual contributor maupun manajerial
    Jika engineer hanya menurut diam-diam pada apa yang diminta pemangku kepentingan nonteknis, akan muncul kekosongan tanggung jawab, dan suatu hari itu meledak seperti bencana besar lalu orang yang paling tidak mampu membela diri akan disalahkan
    Sebaliknya, jika cakrawala diperluas cukup jauh dan pertanyaan “mengapa” diajukan cukup dalam, hampir semua masalah bisnis bisa diselesaikan dengan cara yang masuk akal tanpa mendorong sistem masuk ke lorong satu arah yang mengerikan
    Memang tidak semua tempat memberi engineering wewenang itu, tetapi tempat yang tidak memberikannya juga tidak bisa mempertahankan senior yang ingin penilaiannya dihormati. Kadang technical debt memang pilihan bisnis yang benar, tetapi engineer yang cukup senior selalu bisa menyiapkan jalan keluar
    Hanya saja kemurnian sistem tidak bisa ditempatkan di atas masalah bisnis. Yang membayar biaya sistem adalah bisnis, dan kalau itu dilupakan maka dasar pengaruh kita juga hilang
  • Seperti pepatah lama, tidak ada yang lebih permanen daripada hack sementara
  • Masalah ini sudah ada jauh sebelum AI coding agent, dan AI bisa membuatnya makin buruk
    Kesimpulan tulisan itu pada dasarnya adalah nasihat lama: “buatlah satu yang memang direncanakan untuk dibuang.” Saya juga sudah membaca Mythical Man-Month, tetapi masalahnya adalah bagaimana meyakinkan para pengambil keputusan
  • Ini bisa jadi masalah budaya perusahaan. Dulu kami pernah memulai dengan solusi cepat dan kotor lalu berakhir berantakan, dan kami menetapkan kebijakan keras bahwa setiap fitur quick and dirty wajib punya story lanjutan di 1–2 sprint berikutnya
    Jika hasilnya di bawah harapan, fiturnya dinonaktifkan atau dihapus; kalau tidak, setelah review akan direfaktor dengan benar
    Otonomi tim tinggi dan hampir tidak ada keluhan soal jadwal, karena kebanyakan departemen lain justru tertinggal. Hanya marketing yang selalu punya “ide”
  • Jika “prototipe” yang berjalan mampu menangani permintaan, punya fitur yang dibutuhkan, dan tidak ada alasan membuat ulang selain memuaskan selera developer, lalu kenapa harus menghabiskan waktu dan tenaga?
    Fakta bahwa itu prototipe atau proof of concept pada dasarnya tidak penting jika Anda tidak bisa menyebutkan masalah nyata apa yang ada di sana
    Banyak tim mengeluh terjebak technical debt, itu risiko besar, dan itu memperlambat mereka, tetapi catatan insiden tidak menunjukkan banyak kejadian dan tidak ada yang bisa dikaitkan dengan kode berbahaya yang berjalan di production. Di risk register juga tidak ada entri “kode ini tua, buruk, dan punya dependensi yang sudah end-of-life”, dan tidak ada tim yang bisa menjelaskan bagaimana serta seberapa besar technical debt memperlambat mereka
    Sebaliknya, saya juga pernah melihat tim yang selama berbulan-bulan melakukan refactor sebelum rilis karena merasa bisa membuat aplikasi yang mereka tulis jadi lebih “baik”. Semua pengiriman nilai tertunda, leadership tentu marah, dan hampir tidak ada kepercayaan yang tersisa
    Harus ada percakapan yang baik antara tim dan stakeholder soal delivery agar semua puas, tetapi jika itu tidak ada maka stakeholder akan selalu menang

• Yang terlewat adalah masalah mendasarnya: insentif. Yang diinginkan “perusahaan” tidak penting; yang penting adalah apa yang diinginkan orang-orang yang mengambil keputusan tertentu
  Ada orang yang cukup menjaga pekerjaannya hanya dengan merilis fitur atau aplikasi baru yang muncul di suatu metrik perusahaan. Walaupun developer senior bilang itu ide buruk, mereka tidak akan mendengar atau tidak peduli. Taruhannya adalah pekerjaan mereka sendiri

  • Contoh khasnya adalah peneliti yang dinilai dari paper dan hal-hal baru yang mereka keluarkan
    Tetapi kalau ini soal produk, maka fitur harus disesuaikan dengan kebutuhan pelanggan, sehingga peneliti perlu diminta berhenti memaksakan dorongannya

• Senior yang benar-benar andal akan memahami budaya dominan perusahaan saat ini dan apa yang dibutuhkan lima tahun lagi, lalu beradaptasi dengan itu
  Startup berisi 5 orang mungkin tidak butuh kompleksitas tambahan yang mengurangi runway. Perusahaan berisi 500 orang mungkin justru membutuhkannya untuk meredam efek orde kedua dari setiap keputusan bisnis
  Ini bukan logika hitam-putih “selalu hindari kompleksitas”, melainkan “tambahkan kompleksitas saat memang masuk akal”, dan bahkan pertanyaan itu sendiri bisa sangat subtil ketika bisnis harus bertahan hidup beberapa bulan lagi

  • Betul. Dengan prioritas dan transparansi, orang bisa mengubah variabel yang harus mereka gunakan saat memecahkan masalah
    Kalau badai akan datang dua jam lagi, Anda tidak bertanya soal arsitektur, melainkan “apakah air akan naik terlalu banyak sampai nanti tidak bisa dipompa keluar?”
    Masalah yang saya lihat adalah eksekutif tidak mau bilang sebenarnya sisa uang ada berapa atau jadwal nyatanya seperti apa, dan malah bermain-main. Mereka takut para kontributor pergi sebelum momen penting, tetapi akibatnya orang terus mengambil keputusan bodoh dalam konteks itu dan akhirnya semua tetap mencari pekerjaan baru

• Beberapa hari ini saya mencoba menyampaikan perasaan yang hampir persis sama ke tim, bahkan sampai kalimat “apa kita benar-benar perlu membuat dan menguji satu fitur baru penuh? Sudah coba taruh satu tombol di UI yang ada dan lihat apakah orang menekannya?”
  Rasanya engineer kini sama-sama menderita setelah pihak produk memutuskan bahwa mereka tidak perlu lagi memakai fungsi mental mereka sendiri. Pokoknya bangun dulu, urusan persona pengguna dan kegunaan dicari tahu nanti, atau mungkin tidak pernah
  Dulu kami meluangkan waktu memahami domain, pengguna, dan proses tempat produk itu masuk, tetapi sekarang kami hanya merilis apa yang kami bayangkan diinginkan pengguna khayalan lalu bereksperimen sampai berhasil
  Ini menghasilkan persis masalah yang disebut tulisan aslinya. Setiap fitur acak yang dibuat lewat vibe coding menjadi sumber instabilitas dan risiko, dan karena tak seorang pun punya model mental kerja atas hal itu, pemeliharaannya pun akhirnya hanya bisa dilakukan dengan lebih banyak vibe coding

• Bahkan jika kompleksitas bisa direduksi menjadi satu dimensi pengukuran, itu tetap hanya salah satu unsur dalam ruang solusi
  Ada sifat lain seperti maintainability, scalability, reliability, resilience, antifragility, extensibility, generality, durability, composability, dan tidak semuanya selalu relevan
  Menurut saya kemampuan untuk membicarakannya bukan sebagai dimensi tunggal melainkan sebagai trade-off dalam ruang solusi adalah pembeda antara senior dan developer Staff+

  • Jika “kompleksitas” dipahami sebagai kesan pertama junior ketika melihat potongan arbitrer tertentu, maka itu akan selalu tampak buruk dan berlebihan
    Sebaliknya, jika dipahami sebagai unsur yang akan membuat pengembangan sistem ini lebih mudah dan lebih cepat selama 10 tahun-orang ke depan, maka itu berarti memilih jalan memutar di tempat pendekatan naif ingin menabrak lurus
    Seperti kisah kelinci dan kura-kura, alur yang menghabiskan dua minggu pertama dengan terburu-buru demi buah yang paling rendah, hasil yang terlihat, dan MVP, lalu makin melambat terus karena desain yang belum matang dan beban maintainability saat development, itu sulit dipahami. Selama beberapa minggu tampak “cepat”, tetapi akhirnya jadwal molor 6 bulan
  • Trade-off adalah kuncinya. Orang nonprogrammer membayangkan trade-off itu tidak ada
    Sebagai programmer, pada akhirnya kita harus sadar bahwa semua aspek yang mungkin dalam desain adalah trade-off
  • Cukup banyak dari unsur-unsur ini yang terdampak langsung oleh kompleksitas
  • Anda melewatkan satu yang paling penting: usability