Saya Bukan Seorang Software Engineer

• Penolakan terhadap identitas sebagai software engineer bermula 23 tahun lalu dari penilaian bahwa dirinya “peretas yang baik, tetapi bukan engineer”
• Paradigma agen terasa seperti cara membuat program yang seharusnya deterministik dengan program yang tidak deterministik
• Keyakinan terhadap kode bertumpu pada keterbacaan, kemudahan dipahami, efisiensi, kemudahan ditalar, dan reproduksibilitas yang menghasilkan keluaran sama untuk masukan yang sama
• Agentic user flows di tempat kerja dan KPI penggunaan AI dipandang sebagai pendekatan yang mengutamakan metrik dan masukan bahasa alami ketimbang kode yang baik
• Gambaran masa depan industri AI tampak bukan sekadar menggantikan pengembangan perangkat lunak, tetapi membayangkan pembangunan parit perlindungan di sekeliling pemikiran itu sendiri

---

Rekayasa Perangkat Lunak dan Paradigma Agen

• Sikap mengecualikan diri dari identitas sebagai software engineer berawal dari pengalaman 23 tahun lalu ketika seorang rekan mengatakan bahwa dirinya “peretas yang baik” tetapi bukan engineer
• Belakangan ini, “paradigma agen baru” tampak seperti cara meminta mesin seperti Waylon Smithers untuk tidak melakukan kesalahan, lalu membungkus hasilnya sebagai rekayasa perangkat lunak tingkat ahli
• Cara menulis program yang seharusnya deterministik dengan program yang menghasilkan keluaran non-deterministik sedang dipromosikan sebagai masa depan rekayasa perangkat lunak
• Keyakinan dasar terhadap kode tetap bertumpu pada keterbacaan, kemudahan dipahami, efisiensi, tingkat keterjelasan penalaran yang memadai, dan reproduksibilitas yang menghasilkan keluaran sama untuk masukan yang sama
• Karena reproduksibilitas dalam sistem nyata saja sudah sulit dicapai, penulisan kode itu sendiri tidak seharusnya dibangun di atas “pasir yang bergerak”
• Detail seperti dampak kinerja kueri dari view yang terdiri atas subkueri terhubung dan ekspresi agregasi, inversion of control, serta desain yang memisahkan fungsi dari metode agar bisa diuji secara independen, tetap penting

Ketidakpercayaan terhadap Alur Pengembangan yang Berpusat pada AI

• Agentic user flows yang dituntut di tempat kerja tidak jelas maknanya, dan juga sulit diyakini lebih baik daripada memilih dari sekumpulan opsi kecil melalui kotak teks masukan bahasa alami
• Ada dorongan untuk memakai agen di setiap tahap siklus hidup pengembangan perangkat lunak, dan bahkan dikatakan bahwa menulis kode dengan tangan akan diperlakukan seperti menggunakan COBOL
• Agen tampak seperti pembungkus prompt LLM yang menilai keluaran berdasarkan konteks, dan hasil nyatanya sering terasa kurang memadai
• Penggunaan AI dilacak sebagai KPI, tetapi selama 23 tahun terakhir, menulis kode yang baik selalu lebih penting daripada KPI
• Kode yang pernah ditulis di masa lalu dinilai “terlihat seperti ditulis oleh lulusan matematika”, dan itu diterima sebagai pujian yang tinggi
• Implementasi seorang staff software engineer di tempat kerja yang sama tidak memiliki antarmuka eksplisit, mengekspos kontainer DI sebagai anggota public static, dan menggunakan konfigurasi CSV bukan karena cocok untuk data tabular, melainkan karena “mudah dipakai oleh pengguna bisnis”
• Menyebut implementasi itu sangat buruk sempat menimbulkan masalah, dan peristiwa ini berujung pada kesimpulan ironis bahwa dirinya memang bukan seorang software engineer
• Dua kali ia mendengar saran dari orang yang dianggap cerdas bahwa AI adalah masa depan penulisan perangkat lunak dan industri ini, jadi harus diterima, tetapi sikap itu tampak ceroboh
• Perangkat lunak AI yang pernah digunakan terasa bukan membantu proses berpikir, melainkan mengganggu atau bahkan secara aktif mengambil alihnya, dan bentuk pengambilalihan seperti itu mengkhawatirkan
• Para pemimpin perusahaan AI besar berbicara dengan gembira tentang masa depan industri pengembangan perangkat lunak, mengumumkan bahwa produk mereka akan menimbulkan devastating effects terhadap lapangan kerja, dan memakai ungkapan “intelligence too cheap to meter”
• Masa depan itu terasa mengerikan bukan karena mesin akan mengubah semua orang menjadi paperclip, tetapi karena mereka membayangkan membangun parit perlindungan di sekeliling pemikiran itu sendiri

[GN⁺]

Opini Lobste.rs

• Ada anekdot seperti ini dalam buku Mary Walton tentang W. Edwards Deming. Seorang pekerja pabrik mendapati mesin rusak sehingga hanya menghasilkan produk cacat, lalu melaporkannya, tetapi perbaikan terlambat, jadi ia mencoba memperbaikinya sendiri dan kemudian supervisornya datang dan menyuruhnya tetap menjalankannya
  Pada akhirnya itu berarti perintah untuk “membuat produk cacat”, dan ia berkata, “Di mana kebanggaan saya sebagai pekerja? Akan lebih baik kalau supervisor setidaknya menghormati saya seperti ia menghormati mesin.” Ia tidak ingin membuat produk cacat lalu dibayar untuk itu

  • Buku ini? https://deming.org/the-deming-management-method-by-mary-walton/
    Layak dibaca?

• Pengalaman saya jauh lebih pendek daripada penulisnya, tetapi di awal karier saya, karena berbagai masalah dengan CSV, saya pernah mencoba memindahkan sebagian alur kerja agar tidak lagi bergantung pada CSV, dan saat itu saya mendapat jawaban, “Untuk alur kerja bisnis, CSV lebih mudah”
  Saat itu, seperti penulis, saya merasa jawaban itu sangat buruk, tetapi seiring waktu saya jadi berpikir bahwa penilaian itu lebih mendekati benar

• Jika Anda masih tersiksa oleh pendapat bodoh seperti “ada orang 23 tahun lalu yang bilang saya bukan software engineer”, menurut saya solusinya adalah tidak terlalu memedulikan pendapat orang lain
  Jika kebijakan bodoh perusahaan atau kurangnya kesungguhan rekan kerja membuat frustrasi, ya cari perusahaan lain. Ada 8 miliar orang di dunia, banyak di antaranya ingin komputer melakukan sesuatu untuk mereka, dan banyak di antaranya juga membayar biaya pemrograman
  Kedengarannya seperti, “Waktu pertama kali bekerja di toko roti, seorang rekan bilang croissant adalah konspirasi Big Dairy untuk menjual lebih banyak mentega, lalu saya menjadikannya dasar pandangan hidup dan menyimpulkan saya tak akan pernah bisa bekerja di toko roti lagi.” Kalau usia penulis tidak disebutkan, saya akan mengira dia siswa SMA, tetapi kalau dia bicara soal kejadian 23 tahun lalu, menurut saya dia sudah jauh melewati usia itu

  • Saya hanya bisa menebak kenapa tulisan ini di-flag, tetapi saya cukup yakin dengan tebakan itu. Namun masalah utamanya bukan sekadar nadanya yang tidak ramah, melainkan bahwa tulisan itu meleset dari argumen inti
    Intinya bukan bahwa penulis benar-benar bukan software engineer; kemungkinan besar ia sudah lama bekerja dengan jabatan itu. Intinya lebih dekat pada bahwa sikap menjauhkan diri dari jabatan itu merupakan reaksi terhadap perubahan wujud industri ini
    Seolah ia berkata, “Ini bukan engineering, ini omong kosong. Kalau menjadi software engineer berarti seperti ini, maka saya bukan itu”
    Secara pribadi saya bersimpati dengan perasaan itu. Sudah sering saya merasa bahwa menyebut apa yang kita lakukan sebagai pengembang perangkat lunak sebagai “engineering” itu seperti penghinaan terhadap bidang teknik lain. Terutama karena sambil menyebutnya begitu, kita justru tidak terlalu peduli pada apa yang kita buat
    Insinyur sipil benar-benar memandang serius jembatan yang runtuh, dan ketika terjadi keruntuhan besar, seluruh industri bereaksi dan belajar agar hal seperti itu tidak terulang lagi. Sebaliknya, apa yang disebut “engineer” perangkat lunak bisa berkali-kali menjatuhkan lingkungan produksi karena alasan yang sepenuhnya bisa dicegah, lalu tetap menuliskannya di resume seolah kisah sukses
    Anda mungkin juga bisa menebak pendapat saya tentang arus software engineering saat ini, yaitu kecenderungan untuk tidak peduli pada kode yang benar-benar dikirim ke produksi dan mendelegasikan penulisannya kepada “kecerdasan” lain
    Saya tidak ingin mengaku memahami sepenuhnya kenapa ini terjadi atau punya semua jawaban tentang apa yang harus dilakukan. Tetapi jangan berpura-pura bahwa ini pekerjaan yang serius, yaitu “engineering”