Kode lebih sering dijalankan daripada dibaca

• Prinsip “kode lebih sering dibaca daripada ditulis” berangkat dari gagasan untuk memprioritaskan maintainer di atas penulis, lalu meluas menjadi model pengambilan keputusan yang juga mempertimbangkan pengguna, operasi, dan bisnis
• Nilai kode tidak terletak pada kecanggihannya sendiri, melainkan pada apakah ia memenuhi tujuan pengguna, dan karena itu penting untuk menunjukkannya kepada pengguna lebih awal dan sesering mungkin lalu memasukkan umpan balik mereka
• “Menjalankan” kode di produksi mencakup bukan hanya deployment, tetapi juga upgrade, observasi, audit, monitoring, perbaikan, hingga pensiun, dan biaya operasi jangka panjang bisa jauh lebih besar daripada ketidaknyamanan selama pengembangan
• KISS tidak berhenti pada penyederhanaan kode, tetapi meluas menjadi prinsip operasional untuk mengurangi bagian yang bergerak dan memahami mode kegagalan agar sistem tetap bekerja bahkan saat gagal
• Karena anggaran, pemasaran, tenggat, pemangku kepentingan, investor, dan kepentingan politik ikut campur dalam pengambilan keputusan, kita perlu mengakui bahwa menyenangkan pengguna dan menghasilkan pendapatan tidak selalu sejalan

---

Perluasan model prioritas

• Ungkapan “kode lebih sering dibaca daripada ditulis” berarti orang yang pertama kali menulis kode tidak boleh mengabaikan biaya yang akan ditanggung oleh orang yang membacanya dan mengubahnya di masa depan
• Prinsip ini menjadi dasar untuk berinvestasi pada kemudahan pemeliharaan seperti kesederhanaan, pengujian, dan dokumentasi
• Jika dipadatkan, ini bisa dilihat sebagai model maintainer > author

Pengguna berada di depan pengembang

• Kode adalah sarana untuk mencapai tujuan, dan perangkat lunak harus melayani pengguna tertentu
• Sebagus apa pun kode yang ditulis atau secanggih apa pun teknologinya, nilainya berkurang jika tidak memenuhi tujuan dan tidak memberikan pengalaman pengguna yang baik
• Prioritasnya meluas menjadi user > maintainer > author, dan jika peran pengembang tidak dibedakan maka menjadi user > dev
• Daripada hanya menebak atau bertanya apa yang diinginkan pengguna, lebih baik menaruh program di hadapan pengguna lebih awal dan sesering mungkin lalu menerapkan apa yang dipelajari dari umpan balik

Menjalankan mencakup operasi di produksi

• “Menjalankan” bukan sekadar menyalakan program, tetapi mencakup seluruh proses mengoperasikannya di produksi
  • deployment
  • upgrade
  • observasi
  • audit
  • monitoring
  • perbaikan
  • pensiun
• Dan McKinley dalam Choose Boring Technology berpendapat bahwa biaya jangka panjang untuk menjaga sistem tetap berjalan stabil hampir selalu jauh lebih besar daripada ketidaknyamanan saat membangunnya
• Dengan memasukkan sudut pandang ini, modelnya menjadi user > ops > dev
• Banyak perangkat lunak tidak pernah mencapai produksi pada skala yang berarti, dan dibangun di atas asumsi yang belum tervalidasi
• Saat kode dijalankan di produksi, KISS menjadi persoalan yang melampaui kode, yaitu mengurangi bagian yang bergerak dan memahami mode kegagalan
• Hal yang penting adalah mengirim sesuatu ke produksi dan memastikan ia tetap berfungsi bahkan ketika gagal

Bisnis adalah sumbu tersendiri

• Mengembangkan dengan memikirkan pengguna bisa membawa kita jauh, tetapi asumsi bahwa “perangkat lunak yang bernilai bagi pengguna juga bernilai bagi organisasi” adalah abstraksi yang disederhanakan
• Dari sudut pandang pengembang, mudah untuk memisahkan antara membuat perangkat lunak yang baik dan membiarkan bisnis mengubahnya menjadi uang, tetapi pada akhirnya akan ada saat ketika sudut pandang bisnis perlu dimasukkan ke dalam proses kerja
• Pembedaan ini umumnya berlaku pada perangkat lunak konsumen maupun perangkat lunak enterprise
• Modelnya meluas menjadi biz > user > ops > dev
• Anggaran adalah contoh yang paling jelas, karena sumber daya untuk memenuhi kebutuhan pengguna tidaklah tak terbatas sehingga biaya dan manfaat harus diukur
• Pemasaran, tenggat, pemangku kepentingan, investor, kepentingan pribadi, dan politik juga memengaruhi pengambilan keputusan
• Keputusan yang benar jika hanya melihat perangkat lunak, tim, dan pengguna bisa jadi tidak benar jika mempertimbangkan organisasi secara keseluruhan
• Kadang kita harus melakukan hal yang menghasilkan pendapatan alih-alih hal yang menyenangkan pengguna

Bau organisasi pengembangan yang terlihat dari model ini

• Kode yang mustahil dipelihara: author > maintainer

  • Kode yang cerdas tetapi malas berubah menjadi spaghetti dan “hutan hantu”
  • Ini mencakup masalah seperti optimisasi prematur dan modul yang hanya bisa disentuh oleh orang tertentu

• Perangkat lunak yang tidak bisa digunakan: dev > user

  • Ini lahir dari tim yang tidak belajar dari pengguna atau tim yang memprioritaskan teknologi
  • Contohnya adalah program yang direkayasa berlebihan, “modernisasi” yang memperburuk pengalaman pengguna, dan web app yang merusak fitur browser

• “Di komputer saya jalan kok”: dev > ops

  • Ini adalah perangkat lunak yang tidak dirancang dengan operasi dalam pikiran
  • Ini mencakup kompleksitas berlebihan seperti memakai database mewah untuk beban data kecil, atau satu tim kecil mengoperasikan ekosistem microservices
  • Perangkat lunak yang orang perancangnya berbeda dari orang yang dibangunkan tengah malam saat insiden terjadi juga termasuk di sini

• “Hal yang benar”: dev > biz

  • Ini adalah kasus ketika kode diperlakukan seolah-olah ia adalah tujuan itu sendiri
  • Contohnya adalah perajin yang sok, para musisi Titanic, dan Lisp Hackers

• Pengembangan yang didorong resume: dev > *

  • Ini adalah perangkat lunak yang dibuat ketika tidak ada taruhan nyata dan pengembang bisa melakukan apa pun yang mereka mau

• Perangkat lunak khayalan: biz > user > ops > dev

  • Ini adalah perangkat lunak yang sudah dibuat tetapi hampir tidak pernah, atau sama sekali tidak pernah, masuk ke produksi
  • Charity Majors menyebutnya living a lie
  • Perangkat lunak tanpa pengguna juga termasuk perangkat lunak khayalan, yaitu saat ia tidak menyelesaikan masalah, menyelesaikan masalah yang salah, atau menyelesaikan masalah yang tidak pernah dimiliki siapa pun
  • Ini juga mencakup situasi ketika teknologi yang dibesar-besarkan dipakai untuk memukul semua hal sampai keluar sesuatu yang tampak seperti use case yang samar

• “Kapitalisme tahap akhir”

  • Ini adalah kasus ketika perangkat lunak berbasis investasi ventura tidak punya model bisnis, atau baru punya model bisnis setelah tumbuh menjadi monopoli lalu mengeksploitasi pengguna

Ketegangan antara pengguna dan bisnis

• biz > user membawa dampak lanjutan yang sulit diterima
• Cara kita belajar perangkat lunak adalah dengan menyelesaikan masalah pengguna akhir, dan salah satu tip terakhir dalam The Pragmatic Programmer diringkas sebagai tujuan untuk bukan sekadar mengirimkan kode, tetapi menyenangkan pengguna
• Seiring perangkat lunak menjadi makin umum, semakin sulit mempertahankan asumsi ini
• Banyak perangkat lunak tidak peduli pada pengguna, memanipulasi mereka, atau menjadikan mereka sebagai produk
• Masalah ini tidak terbatas pada media sosial saja
  • Saat memesan kamar, memesan makanan, atau mengklik tombol Start Windows, muncul popup yang mencoba merebut perhatian pengguna
  • Google Search digambarkan memberikan hasil yang seperti tumpukan sampah
• Ketidakselarasan antara keyakinan bahwa kita sedang melakukan hal yang baik dan apa yang dianggap menguntungkan oleh sebagian besar industri menjelaskan rasa tidak nyaman banyak profesional perangkat lunak
• Kita tidak bisa kembali ke masa lalu yang mengabaikan realitas ekonomi, tetapi kita membutuhkan sikap etis yang lebih kuat agar tidak merugikan pengguna
• Pengguna tidak selalu bisa berada di depan bisnis, tetapi bisnis juga tidak boleh selalu didahulukan
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

Opini Hacker News

• Ada pengguna yang memakai sebuah sistem bukan karena menyukainya, melainkan karena perusahaannya sudah membelinya.
  Dalam situasi seperti ini, secara definisi bisnis didahulukan daripada pengguna, dan pengembang akan menyesuaikan diri dengan kebutuhan manajer menengah di pihak pelanggan, bukan pengguna sebenarnya. Kalau tidak begitu, mereka tidak akan mendapatkan kontrak. Pada akhirnya pengguna terikat pada fitur yang diberikan seadanya, sementara tim pengembang sibuk membuat fitur baru yang akan disukai manajer menengah.
  Memang agak sinis, tetapi sebagai engineer, mengetahui apakah pada dasarnya Anda berada di perusahaan semacam itu bisa membantu. Misalnya, peritel online sangat peka terhadap pengguna, sampai-sampai mereka bisa memiliki versi situs web yang berbeda untuk tiap negara karena orang Jerman menyukai X dan orang Amerika menyukai Y. Perubahan kecil bisa membuat perbedaan besar pada penjualan.
  Sebaliknya, ada perusahaan yang hampir tidak peka terhadap usability karena orang yang membeli produk bukanlah pengguna sebenarnya.

  • Saya pernah bekerja di perusahaan yang menjual SaaS ke perusahaan besar.
    Untuk memenangkan kontrak, kami harus memenuhi checklist pelanggan, tetapi kami juga memperhatikan pengalaman pengguna. Pengalaman pengguna yang baik hampir tidak pernah menjadi persyaratan ketat dari pelanggan.
    Perangkat lunak pesaing sangat menyakitkan untuk digunakan, jadi kami ingin membedakan diri di aspek itu. Berkat itu, pelatihan menjadi lebih mudah, pengguna lebih puas, dan jika memungkinkan mereka juga merekomendasikan kepada manajer mereka agar membeli lebih banyak produk kami.
    Pada akhirnya, 80% dari upaya itu berasal dari rasa bangga dan empati bahwa “software kami tidak payah”, tetapi dalam jangka panjang itu juga menguntungkan kami karena membangun brand.
  • Saya pernah bekerja di perusahaan pada pasar dengan struktur pembelian serupa, tetapi kami hanya berfokus pada pengguna.
    Kami memilih strategi product-led growth, tidak memiliki tenaga penjualan, dan tim produk sepenuhnya berfokus pada pengalaman pengguna. Masalahnya, kami tidak menjual kepada pengguna. Orang yang membeli software adalah orang lain di dalam organisasi pengguna, dan mereka bahkan tidak punya pengalaman memakai produk secara langsung.
    Itu adalah pendekatan yang pasti gagal. Kami membutuhkan tenaga penjualan yang memahami isi kepala pembeli, menjelaskan manfaatnya kepada mereka, dan melatih pengguna agar dapat menjelaskan manfaat tersebut kepada orang lain di dalam organisasi. Kami harus menjembatani kesenjangan antara pengguna dan pembeli.
  • Biasanya manajer menengah juga pengguna, tetapi jumlah mereka sedikit dalam basis pengguna, dan fitur yang mereka pakai juga berbeda, seperti laporan.
    Jadi ini menjadi persoalan pengguna mana yang harus diprioritaskan, dan perlu mencari keseimbangan antara memprioritaskan pengalaman segelintir orang yang punya pengaruh terhadap pengguna lain, dengan menjaga agar pengguna lain tetap bisa memakai produk sampai mampu memberi data yang bermakna kepada manajemen.
  • Saya mengalami hal seperti ini di perusahaan yang menjual software ke pemerintah kota.
    Yang penting hanyalah pendapat wali kota, town manager, dan dewan kota. Kalau laporannya tampak bagus dan harganya sesuai, mereka memperpanjang kontrak.
    Saya ingat dalam rapat lapangan, orang-orang yang memakainya setiap hari mengatakan langsung di depan kami betapa mengerikannya produk itu. Tetap saja, tanpa pengecualian, dengan janji memperbaiki beberapa bug tertentu dan kenaikan harga minimal, pelanggan itu memperpanjang kontrak.
  • Fakta bahwa pengembang menyesuaikan diri dengan kebutuhan manajer menengah di pihak pelanggan, bukan pengguna sebenarnya, adalah alasan mengapa semua enterprise software terasa buruk.

• Hari ini saya mengetahui simbol ≹. Katanya, simbol ini “menunjukkan hubungan ketika dari dua objek yang dibandingkan, tidak ada yang lebih besar atau lebih kecil dari yang lain, tetapi juga belum tentu dapat dikatakan sama. Ini adalah nuansa penting dalam domain yang memiliki cara perbandingan yang tidak sepenuhnya numerik” (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • Contoh yang memakai z_1 ≹ z_2 untuk bilangan kompleks z_1, z_2 terasa aneh.
    Rasanya akan lebih jelas jika ditulis |z_1| = |z_2|, yaitu kedua bilangan kompleks memiliki nilai mutlak yang sama.
    Di sana tertulis, “Sebagai kesimpulan, simbol ≹ memainkan peran penting dalam menyediakan wilayah tengah di antara operator relasional tradisional,” tetapi sebagai mahasiswa doktoral matematika, saya belum pernah melihatnya sekali pun. Sulit percaya bahwa simbol ini memainkan peran penting.
  • Sepertinya glyph ini seharusnya merupakan hasil gabungan emoji apel dan emoji jeruk.
  • Saya jadi teringat konsep game dalam teori permainan kombinatorial.
    Game adalah superset dari surreal number, dan surreal number adalah superset dari bilangan real; definisi surreal number dilonggarkan sehingga sifat urutan totalnya hilang.
    Akibatnya muncul bilangan-bilangan aneh yang “dapat tertukar” atau “fuzzy” dengan bilangan lain. Contoh paling sederhana adalah * (star), yang tidak lebih besar maupun lebih kecil dari 0 sehingga tertukar dengan 0. Ia seperti awan fuzzy di sekitar 0, dan ditulis 0║*.
    Switch, game yang lebih kompleks, dapat tertukar dengan rentang bilangan yang lebih besar dan dianggap “hot”. Jika membuat bilangan dengan switch, Anda bisa membuat game hot yang lebih menarik.
  • Saya melihat konsep ini penting untuk memahami urutan kausal dalam sistem terdistribusi. Misalnya dalam konteks CRDT.
    Event yang dibuat di satu perangkat selalu memiliki urutan lengkap. Namun jika dua perangkat yang sedang offline membuat event, kita tidak bisa mengatakan mana yang lebih dulu, dan terbentuk relasi ≹ di antara kedua event itu. Dengan kata lain, event tersebut dianggap bersamaan.
    Jadi dapat muncul urutan “d > b > a” dan “d > c > a”, tetapi menjadi “c ≹ b”.
    Mendefinisikan cara menangani tie seperti ini secara deterministik adalah bagian besar dari masalah yang diselesaikan CRDT.
  • Pada “Contoh 1: konteks numerik” di tautan itu, disebutkan dua bilangan real a dan b; jika a tidak lebih besar maupun lebih kecil dari b, tetapi juga tidak secara eksplisit sama, maka relasinya adalah ≹.
    Bagaimana itu mungkin?

• Bagi cukup banyak dari kita, biaya untuk menjalankan kode 1 miliar kali bisa lebih murah daripada beberapa menit waktu developer
  Jika menghabiskan 200 dolar untuk biaya server bulanan di AWS, saya bisa menjalankan sebagian besar kode Web API saya bahkan 100 miliar kali
  Jadi optimasi untuk pembaca manusia selalu lebih baik, dan optimasi lain baru perlu dilakukan jika terbukti lambat sampai tidak layak secara ekonomi

  • Penulisnya juga tampaknya berpikiran sama, hanya saja judulnya mungkin dipilih dengan membingungkan
    Tulisannya berakhir dengan rumus berikut:
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    Kesimpulannya tampak lebih dekat pada bahwa kode ada untuk pengguna akhir dan bisnis. Rumus terakhir, ≹, dengan rapi mengekspresikan bahwa kebutuhan pengguna akhir dan bisnis tidak sama, tetapi keduanya sama-sama penting bagi keberadaan kode
  • Masalah dari perhitungan “biayanya lebih kecil daripada waktu developer” biasanya adalah bahwa yang membayar biaya itu bukan dirinya sendiri
    Pengguna membayarnya dengan cara yang kurang jelas, seperti tagihan listrik yang lebih tinggi, masa pakai yang berkurang[0], peluang yang hilang, frustrasi yang lebih besar, dan upgrade hardware yang lebih sering
    Selain itu, sebagian besar pengguna tidak punya gaji atau kualitas hidup seperti developer, sehingga dampaknya terasa berlipat ganda
    [0] Membuang-buang waktu orang lain berarti mengurangi QALY
  • Dalam tulisan itu, “eksekusi” tidak dipakai hanya dalam arti menjalankan program
    Katanya itu mencakup semua hal dalam mengoperasikannya di produksi: deployment, upgrade, observasi, audit, monitoring, perbaikan, penghentian, dan sebagainya
  • Dari pengalaman saya, latensi perlu diperhatikan. Karena itu memengaruhi pengalaman pengguna. Membeli latensi yang lebih baik dengan uang cukup sulit
  • Reaksi yang saya kira akan saya baca adalah yang ini. Tapi tulisan ini adalah tulisan yang berbeda. Layak dibaca sekali

• Jika konsekuensi dari judulnya dikembalikan kepada penulis, ini lebih dekat ke kode yang tidak bisa dibaca tidak akan berjalan lama, bukan “kode lebih sering dibaca daripada ditulis”
  Namun, saya adalah admin sistem berpengalaman yang sedang mencoba beralih jalur ke development, dan dalam arti itu saya benar-benar pemula

  • Ada banyak kode yang sudah membatu yang orang takut sentuh karena tidak memahaminya, tetapi bisnis bergantung di atasnya
  • Software proprietari tanpa source, misalnya library pihak ketiga atau hampir semua sistem black box, adalah contoh tandingan dari konsekuensi itu
  • Seluruh industri keuangan tampaknya tidak akan setuju. Dan tidak berminat kembali sebentar dari masa pensiun untuk menjelaskan kode COBOL Anda kepada developer lain?
  • Menurut saya, dengan infrastruktur yang tepat, kode itu bisa terus berjalan
    Lebih tepatnya, “kode yang tidak bisa dibaca tidak akan lama bisa dimodifikasi”
  • Bukan poin yang buruk, tetapi lebih terasa sebagai topik terpisah
    Jika bukan membahas obfuscation yang disengaja, sebagian besar kode bisa dibaca oleh orang yang mau berusaha, dan jika perlu ada juga code formatter

• Ada konsekuensi tambahan yang bisa ditambahkan di sini. Di antara tiap tahap berikut, jumlah penggunaan meningkat secara eksponensial

  1. Perancang bahasa dan developer standard library
  2. Developer modul atau library bersama
  3. Developer umum
  4. Pengguna akhir
     Dalam banyak bahasa, rasio di tiap tahap kira-kira sekitar 1000 kali, sehingga untuk setiap 1 perancang bahasa bisa ada 1000 orang yang merancang dan mendistribusikan modul, 1 juta developer, dan 1 miliar pengguna. Angkanya bisa sangat berbeda tergantung situasi konkret, tetapi untuk diskusi kualitatif, skala kasarnya cukup tepat
     Intinya, kemalasan yang sangat kecil pada tahap pertama atau kedua akan berlipat ganda secara dramatis di hilir. Hack kotor yang dibuat di tahap 1 untuk menghemat 1 menit demi “kenyamanan sendiri” bisa secara harfiah membuang jutaan jam dari hidup berharga orang lain. Entah dengan membuat mereka menunggu software yang lambat, membuat mereka frustrasi karena crash, atau membuat mereka menunggu karena pengembangan fitur di tahap 2 dan 3 menjadi terlambat
     Untuk mempertahankan tingkat kualitas yang diperlukan pada dua tahap pertama, dibutuhkan disiplin diri dan etika pribadi yang luar biasa. Sebaliknya, setiap kali mendengar orang membela posisi yang tidak dapat dibenarkan terkait desain bahasa inti atau standard library, saya merasa sangat sedih
     Saya sering mendengar ucapan seperti, “Tidak apa-apa asalkan tahu seluruh sejarah mengapa bagian tajam ini muncul! Ini bukan masalah kalau terus waspada selamanya. Ia tidak tidak aman, tidak berisiko dari sisi keamanan, tidak lambat, dan tidak bermasalah selama tidak dipakai dengan salah,” karena saya tahu hal-hal seperti itu akan menjegal para developer selama puluhan tahun ke depan dan memperlambat software bagi jutaan hingga miliaran orang

• Sepertinya penulis mengambil aturan praktis yang cukup bagus lalu mencoba membuat teori segala sesuatu darinya
  Terlihat rapi dan bijak, tetapi jika ekspresi yang dipaksakan disingkirkan, ini lebih dekat ke mengunyah ulang klise yang sudah dikenal luas

  • theory > /dev/null
  • Saya menyebutnya “ekspresi yang dipaksakan”, tetapi kita perlu sering mengingat bahwa di industri ini ada banyak orang yang bukan penutur asli bahasa Inggris dan tidak tinggal di negara berbahasa Inggris, tetapi berusaha menulis dalam bahasa Inggris
    Jadi ungkapannya bisa terasa canggung
    Dan meskipun itu “klise yang sudah dikenal luas”, tulisan ini merangkainya dengan cara yang sangat konsisten sehingga menjadi referensi yang berguna
  • Menurut saya, ada nilai juga dalam memvariasikan aturan praktis, lalu lewat variasi itu melihat kembali dan memberi konteks pada hal-hal yang kita kira sudah kita tahu
    Bagi seseorang, semuanya bisa jadi baru, dan meskipun bagi saya hanya mengonfirmasi bias saya, itu tetap merupakan sudut pandang yang menarik
  • Lebih tepatnya, ini adalah teori segala sesuatu tentang semua hal yang bisa salah dalam pengembangan software. Tetap saja menarik untuk dibaca
  • Sudah baca sampai akhir? Sisanya semua hanya cerita latar

• Pembingkaian penulis bisa disalahpahami dengan terlalu banyak cara sehingga sulit menjadi ungkapan ringkas yang berguna. Tidak mungkin ada peringkat mutlak di antara token-token ini
  Pertama, di sini “dev” bukan satu orang, melainkan kumpulan orang dengan beragam keahlian dan tingkat senioritas di berbagai organisasi produk, engineering, dan desain dalam banyak organisasi
  “ops” juga bukan satu hal, dan tidak hanya berarti operasi engineering. Ini bisa mencakup operasi bisnis, dukungan pelanggan, dan sebagainya
  “biz” pun bukan satu hal. Ada branding, marketing, sales, legal dan jajaran eksekutif, dewan direksi, regulator, pemberi pinjaman, investor, dan lainnya
  Semua orang ini memengaruhi kode apa yang ditulis, bagaimana kode itu ditulis, serta kapan dan bagaimana kode itu didistribusikan kepada pengguna. Semuanya harus memecahkan masalah yang sama
  Banyak orang di dalam organisasi sering kali ada untuk membuat semua orang memahami dan melihat masalah yang sama serta bekerja menuju tujuan yang sama
  Namun pemahaman itu terus berevolusi, dan ada jeda dalam penyebarannya ke seluruh organisasi. Karena itu, bahkan saat tujuan itu sendiri sedang berubah, ada jeda juga dalam membuat semua orang bekerja menuju tujuan yang sama
  Terakhir, “user” juga bukan satu hal, dan tidak ada kelompok pengguna yang statis. Ada beragam kelompok pengguna, dan perilaku mereka mungkin tidak stabil dalam jangka panjang
  Jadi akan membantu jika kita memahami dan mengakui bagaimana semua variabel di sekitar berubah, lalu menafsirkan dunia yang tidak sempurna dan rusak dalam konteks itu. Kalau tidak, kita mudah jatuh pada kesimpulan bahwa semua orang lain buruk, semuanya rusak, dan kita ingin membangun ulang semuanya dari awal

• Senang melihat hal yang dekat dengan etika ikut dibahas
  Pada bagian tulisan yang mengatakan, “saya pikir ada ketidaksesuaian antara apa yang kita kira sebagai melakukan hal baik dan apa yang sebagian besar industri anggap menguntungkan, dan inilah alasan meningkatnya ketidaknyamanan banyak profesional software,” kata ketidaknyamanan terasa cukup lemah. Banyak hal masih tidak terucapkan
  Saya ingin menambahkan beberapa pertanyaan. Apa yang terjadi ketika pengguna bukan pelanggan, yaitu bukan orang yang membayar? Apakah bisnis punya kewajiban etis kepada semua pengguna, termasuk pengguna yang tidak membayar? Apa yang terjadi jika pelanggan berbayar ingin menggunakan bisnis Anda dengan cara yang menimbulkan dampak hilir negatif bagi pengguna?
  Misalnya, bagaimana jika sebuah platform membuat penipuan lebih mudah dibanding alternatif yang ada, atau membuat penyebaran disinformasi lebih mudah, atau membuatnya lebih mudah untuk membentuk opini pengguna dengan cara yang merusak dalam jangka panjang tetapi menarik dan membentuk kebiasaan? Semua ini pernah terbukti menjadi model bisnis yang sukses selama periode tertentu
  Jika dinamika seperti ini nyata, apakah bisnis seharusnya mengejar model yang eksploitatif semacam itu? Jika mengejarnya, bisakah dilakukan dengan lebih bertanggung jawab? Bisakah versi bisnis yang lebih etis meredam kecenderungan terburuk para pesaing, atau pada akhirnya justru menjadi bagian dari masalah?
  Kesimpulan utamanya jelas. Ada jenis-jenis masalah tertentu yang lebih besar dan lebih penting daripada model bisnis. Ada masalah yang dapat dirumuskan sebagai “norma dan aturan apa yang diperlukan agar perusahaan beroperasi dalam batas kewajaran tertentu”
  Terakhir, saya ingin memperjelas. Bisnis pada dasarnya menyampaikan serangkaian nilai, dan ini tidak bisa dihindari. Bahkan sekadar mengambil posisi “yang populer menang” pun merupakan pilihan yang punya implikasi mendalam terhadap nilai. Ilmuwan politik dan sejarawan sudah lama mengetahui persoalan tirani mayoritas. Apa pun filsafat politik Anda, ini layak dipikirkan
  Saya tidak tahu sistem etika “terbaik” itu apa, tetapi saya tahu bahwa sebagian etika lebih baik daripada yang lain. Dan saya berharap kita terus menyempurnakan etika kita, alih-alih membiarkannya tanpa ditinjau

  • Menurut saya ini masalah yang berbeda dari masalah yang dibahas tulisan tersebut
    Kita bisa memilih masalah dan ranah mana yang sesuai dengan etika kita sendiri. Tulisan ini membahas bagaimana membangun sistem dan bagaimana menentukan prioritas kerja

• Bisnis sebenarnya tidak ada; ia adalah konstruksi imajiner yang kita ciptakan untuk mengorganisasi sumber daya agar bisa bekerja bersama
  Bisnis bukanlah hal yang paling penting. Pengguna itu banyak, dan kadang kepentingan mereka saling bertentangan. Kita tidak bisa ada di mana-mana dan menjadi segalanya, jadi harus menentukan prioritas. Mengejar pengguna yang lebih menguntungkan atau pengguna yang sesuai dengan strategi jangka panjang bisa terlihat “baik untuk bisnis”, tetapi sebenarnya tujuannya adalah melayani pengguna. Hanya saja melalui beberapa tahap tambahan
  Jika politik internal sudah kusut sampai keputusan diambil hanya demi kepentingan bisnis tanpa mempertimbangkan bagaimana itu bermuara pada kebahagiaan pengguna, organisasi itu sudah menjadi toksik. Ia seharusnya tidak lagi ada. Mungkin bisa terhuyung-huyung seperti zombi untuk sementara, tetapi sedang menurun, dan semua orang baik akan pergi

  • Mengatakan bahwa bisnis tidak benar-benar ada mirip dengan mengatakan bahwa emosi tidak ada
    Bisa saja dikatakan bahwa emosi juga hanyalah konstruksi yang dibuat untuk menjelaskan respons terhadap situasi, tetapi hanya karena ia tidak tersusun dari atom bukan berarti ia tidak “nyata”
    Bisnis ada sejauh ia menjadi faktor utama yang menentukan hidup kebanyakan orang. Ia membentuk kota, media, hukum, politik, kebijakan luar negeri, dan memberi pengaruh besar pada hampir semua hal penting. Nyata atau tidak, ia memberi dampak nyata di sekitar kita
    Di luar open source, cukup jelas bahwa pihak yang membayar menentukan bagaimana sesuatu dibuat. Bahkan jika keputusan itu buruk bagi pihak tersebut, buruk bagi pengguna, dan buruk bagi publik umum atau lingkungan. Tentu ada regulasi industri dan pemerintah, tetapi pada umumnya perusahaanlah yang memegang hak menentukan
  • Ini tidak benar. Bisnis ada sebagai konstruksi hukum, dan ada banyak hal yang baik untuk bisnis tetapi buruk bagi hampir semua orang. Selain itu, bisnis tidak ada untuk melayani pengguna
    Sayangnya, bisnis ada untuk melayani pemiliknya. Dalam kebanyakan kasus, terutama pada perusahaan besar yang bukan usaha mikro dengan kurang dari 5 orang, pemilik menginginkan uang, sehingga semua orang di perusahaan ada untuk menghasilkan lebih banyak uang bagi pemilik. Kebahagiaan orang lain, bahkan kebahagiaan pengguna, sama sekali tidak relevan kecuali ketika berkorelasi dengan pendapatan
    Insentif umum lain di dalam perusahaan adalah mempertahankan diri. Karena itu, selain menghasilkan uang, para pengambil keputusan juga mempertimbangkan keamanan pekerjaan mereka sendiri
    Karyawan tidak pergi. Karena perusahaan membuat mereka cukup puas. Dengan membayar dengan baik dan membuat mereka merasa menjadi bagian dari “komunitas”, ternyata sangat mudah membuat orang terus bekerja untuk organisasi yang jahat atau tanpa wajah. Jika melihat kantor FAANG, Anda bisa melihat daftar terperinci trik HR semacam ini
    Saya setuju bahwa perusahaan seperti ini toksik dan seharusnya tidak ada, tetapi beginilah perusahaan bekerja dalam kenyataan. Ini bukan tanda kemunduran, melainkan bentuk bisnis yang matang dan sehat yang bisa bertahan selama puluhan tahun. Eksekutif, produk, dan pemilik berganti, tetapi bisnis tetap ada
  • Awalnya saya juga bereaksi sama. Kalau melihat tulisan yang bisa diringkas sebagai uang > manusia, rasanya keliru
    Namun, kepentingan itu subjektif. Jika itu kode pribadi untuk kesenangan sendiri, bisnis tidak penting. Jika ingin mengubahnya menjadi sumber penghasilan utama, bisnis menjadi yang paling penting. Karena jika perangkat lunak tidak bisa melayani siapa pun, sebanyak apa pun pengguna menyukainya, itu tidak akan berubah menjadi pendapatan nyata
  • Mari kita tafsirkan “bisnis” di sini secara murah hati sebagai model pendanaan berkelanjutan yang dapat menopang pemeliharaan, dukungan, dan pengembangan di masa depan
    Tanpa model bisnis, perangkat lunak hebat yang disukai pengguna, bisa didistribusikan, dan dapat dipelihara pun bisa meredup

• Awalnya saya skeptis, tetapi saya menyukai model berpikir ini
  Tentu saja, jangan mengikutinya secara membabi buta. Ada pengecualian dev > biz, seperti kasus OpenAI, dan ada juga pengecualian dev > ops. Di startup tahap awal, karena harus bergerak cepat, khususnya demi bisnis, dev > ops bisa terjadi