Bintang Utara Perangkat Lunak Saya

Prioritas dalam pengembangan perangkat lunak

1. Perangkat lunak harus berguna bagi pengguna akhir, dan diarahkan untuk menjadi "perangkat lunak yang bisa dicintai"
2. Perangkat lunak harus akurat (correct). Perangkat lunak yang tidak berfungsi dengan baik menurunkan manfaat yang bisa diperoleh pengguna
3. Perangkat lunak harus mudah dipelihara dan efisien. Ini adalah standar untuk menghindari pemborosan sumber daya manusia dan komputasi ketika ingin menarik lebih banyak manfaat dari perangkat lunak

Ketidakbermaknaan saat prioritas dibalik

• Walaupun blockchain tidak memiliki bug, jika itu adalah rugpull, maka tidak ada artinya
• Walaupun bahasa yang digunakan aman terhadap memori (memory-safe), jika tidak ada desain untuk kebenaran dan proses untuk pada akhirnya terus memperbaiki semua bug, maka tidak ada artinya
• Walaupun perangkat lunak memiliki lapisan abstraksi yang indah (canopy of abstractions), jika perilakunya buruk dan tidak ada yang bisa memeliharanya atau menambahkan fitur baru, maka tidak ada artinya

Terkadang saya kehilangan semangat, terkadang saya menempuh jalan yang salah, dan terkadang saya sengaja berputar, tetapi tidak seorang pun bisa membuat saya mengira tujuan sejati saya berada di tempat yang lebih rendah.
Saya menghargai pengalaman saya sebagai pengembang, tetapi saya menganggap pengalaman itu penting hanya sejauh pengalaman tersebut membantu saya membuat lebih banyak perangkat lunak yang bisa dinikmati orang lain dan Anda.

• Tujuan akhirnya adalah memaksimalkan manfaat bagi pengguna akhir, dan segala hal lainnya hanyalah sarana untuk mencapai tujuan itu
  • Inilah prinsip paling penting dalam mengembangkan perangkat lunak

[GN⁺]

Komentar Lobste.rs

• Saya lebih menyukai pendekatan yang mirip
  Bahkan alat yang tidak “menyenangkan” seperti obeng bisa sangat andal untuk waktu yang sangat lama. Obeng plus akan selalu berkepala plus, dan tidak ada kejadian 1% saat mengambilnya dari kotak perkakas lalu ternyata berubah menjadi obeng minus sehingga harus dikembalikan dan diambil lagi. Desain pegangannya juga tidak berubah tanpa henti, dan alat yang sudah dibeli bisa dipakai begitu saja sampai rusak
  Akan bagus kalau lebih banyak perangkat lunak menjadi seperti itu

  • Saya penasaran apa yang dimaksud dengan “alat yang tidak menyenangkan seperti obeng”

• Saya menghormati dan berterima kasih kepada pengembang yang memegang prinsip bahwa “tujuan akhirnya adalah memaksimalkan utilitas bagi pengguna akhir, dan yang lain semuanya demi tujuan itu”, tetapi saya sendiri tidak selalu bisa hidup seperti itu. Saya merasa dalam perangkat lunak ada pihak lain selain pengguna akhir yang juga sah untuk dipertanggungjawabkan
  Secara profesional, saya membuat perangkat lunak untuk menafkahi keluarga, dan meskipun cukup sering berpihak pada pengguna, pada akhirnya loyalitas saya lebih besar kepada perusahaan yang membayar dan keluarga saya.
  Dalam pekerjaan pribadi, tolok ukurnya adalah “apakah pekerjaan ini bermakna bagi saya”, dan kepuasan artistik, estetis, serta intelektual itu penting. Biasanya ini sejalan dengan kepentingan pengguna, tetapi saya juga bisa salah menilai utilitas pengguna, dan misalnya sekalipun terbukti bahwa menu hamburger beranimasi memaksimalkan utilitas, saya merasa dalam karya saya sendiri saya boleh menggunakan hak pilihan estetis untuk mengorbankan utilitas itu

  • Selain itu, terlepas dari kompromi semacam ini, tidak selalu mungkin juga untuk mendefinisikan siapa pengguna akhir yang sebenarnya
    Ada juga kasus ketika sebagian perangkat lunak sengaja dibuat tidak ramah bagi pengguna agar mereka tidak bisa melakukan hal konyol yang merugikan para pengguna dari pekerjaan mereka sendiri.
    Saya pernah membahas sengaja memasang mekanisme seperti itu agar fitur pelaporan tertentu—yang sangat rentan terhadap Hukum Goodhart dan punya cakupan efek samping yang besar—tetap selamanya dalam status “belum siap”, meskipun pengguna perangkat lunak menginginkannya

• Baru setelah melihat tulisan ini saya tahu bahwa Tiger Style sekarang punya situs web

• Mereka mengatakan “tidak ada yang bisa memeliharanya, apalagi menambahkan fitur baru” sekaligus “semua bug diperbaiki”, tetapi pada akhirnya saya tidak begitu paham bagaimana mungkin memperbaiki semua bug tanpa pembekuan cakupan

• Kalimat “meskipun blockchain tidak punya bug, kalau itu rug pull tetap tidak ada artinya” bisa memuat tiga hal dalam satu kalimat
  Meningkatkan efisiensi sesuatu tidak ada artinya jika itu menciptakan bug baru, dan bahkan itu pun hanya berarti kalau itu bukan rug pull

• Yang menonjol bagi saya adalah tidak ada persyaratan bahwa perangkat lunak harus ditulis hanya oleh manusia. Ini lebih menarik karena saya tahu Kristoff adalah pengembang inti Ziglang
  Saya ingin berpikir bahwa bahkan dengan menggunakan pengembangan berbantuan AI, kita tetap bisa membuat perangkat lunak yang memenuhi persyaratan ini.
  Menulis kode langsung dengan tangan itu menyenangkan, dan menyelesaikannya juga menyenangkan, tetapi keduanya kadang bertabrakan.
  Maaf membawa-bawa topik AI, tetapi sulit memisahkannya mengingat hubungan dekat Kristoff dengan komunitas Zig, sikap tegas Zig, dan bagaimanapun juga fakta bahwa saya terus menginjili Ziglang

  • Saya justru melihat poin ketiga menyiratkan penolakan terhadap alat semacam itu. Apa yang dihasilkan alat-alat itu pada umumnya terlihat seperti kode spageti yang tidak bisa dipelihara
  • Sepertinya ada alasan mengapa tulisan ini diposting di blog pribadi Loris, bukan di ziglang.org
    Hanya karena sebuah proyek punya sikap yang jelas terhadap kode berbasis model bahasa besar, bukan berarti semua orang di proyek itu berbagi sikap yang sama untuk proyek ini atau semua proyek.
    Ini bukan hanya berlaku bagi Loris pribadi; untuk keputusan seperti ini, penilaian per kasus adalah hal yang masuk akal