44 poin oleh GN⁺ 2026-01-26 | 8 komentar | Bagikan ke WhatsApp
  • Bahkan di era agentic coding, permintaan terhadap software engineer justru diperkirakan meningkat, dan kuncinya ada pada kemampuan mengoperasikan layanan, bukan menulis kode
  • Menulis kode selalu merupakan bagian yang mudah, sedangkan yang benar-benar sulit adalah menjalankan sistem secara stabil dalam jangka panjang
  • Seperti pada kasus no-code dan spreadsheet, nonspesialis pun bisa membuat alat, tetapi beban pemeliharaan dan operasional pada akhirnya tetap membutuhkan engineering profesional
  • Pengguna membeli layanan, bukan perangkat lunak, dan software yang baik harus bekerja tanpa terlihat
  • Operational excellence seperti uptime, tingkat cacat, kecepatan pemulihan, dan pembaruan keamanan adalah inti daya saing masa depan
  • Peran yang memenuhi semua tuntutan ini adalah SRE, yang kini bergerak ke pusat software engineering

SRE diperkirakan akan menjadi peran yang paling banyak direkrut

  • Saat kode menjadi murah, operational excellence menjadi penentu kemenangan
  • Demo greenfield bisa dibuat siapa saja, tetapi untuk mengoperasikan layanan secara stabil dibutuhkan kapabilitas engineering
  • "Semua orang ingin menulis demo greenfield, tetapi tidak ada yang ingin menjalankan layanan"
  • Software engineering bukan sekadar pemrograman, melainkan mengelola sistem yang berubah seiring waktu

Pelajaran dari era no-code dan spreadsheet

  • Joe, staf akuntansi, memangkas pekerjaan berulang yang sebelumnya memakan 10 jam per minggu menjadi 1 jam dengan alat no-code dan makro spreadsheet
  • Pada awalnya hasilnya jelas terlihat, tetapi seiring waktu kompleksitas meningkat dengan cepat
    • Perubahan lingkungan bisnis, perubahan aturan akuntansi, serta akumulasi masalah zona waktu dan daylight saving time
    • Setiap minggu muncul edge case baru sehingga perlu penyesuaian dan perbaikan berkelanjutan
  • Pada akhirnya Joe beralih menjadi terikat pada sistem yang ia buat sendiri
    • Bahkan saat liburan ia tetap harus memikirkan sistem itu, dan sulit menyerahkan operasionalnya ke orang lain
    • Menjalankan kode dan memeriksa hasilnya sendiri menjadi sumber kecemasan dan ketegangan

Penyakit komputer (The Computer Disease)

  • Konsep yang dinamai oleh Feynman ini menyoroti bahwa masalah komputer adalah ia membuat orang terus-menerus ingin mengutak-atiknya
  • Otomatisasi itu sendiri memang menyenangkan, tetapi ada jebakan ketika kita mengotomatisasi area yang sebenarnya tidak perlu dan justru menambah kompleksitas
  • Beban yang sebenarnya ada pada operasional layanan
    • Menjaganya tetap berjalan stabil
    • Memperluasnya tanpa masalah di lingkungan berskala besar
    • Mengelolanya secara berkelanjutan selama bertahun-tahun
  • Dalam penyediaan layanan, stabilitas, keandalan, dan keberlangsungan adalah inti

Mengapa operational excellence adalah masa depan

  • Orang tidak membeli software, melainkan mempekerjakan layanan yang menyelesaikan masalah mereka
  • Mereka tidak peduli pada cara kerja internal iCloud, tetapi berharap foto selalu tersinkron otomatis antarperangkat
  • Cara Word, Notion, atau gDocs dibuat tidak penting; yang penting adalah pengalaman menulis dan membagikan pemikiran
  • Dibanding struktur jaringan pembayaran, yang lebih penting adalah hasil berupa matcha latte 7 dolar terbayar tanpa masalah
  • Software yang baik itu tidak terlihat (berjalan secara alami tanpa terasa hadir)

Tantangan engineering yang benar-benar sulit

  • 90% pertama untuk membuat demo yang berfungsi itu mudah, tetapi 190% sisanya yang benar-benar penting
  • Pertanyaan yang harus dijawab dari sudut pandang operasional:
    • Berapa uptime-nya
    • Seberapa tinggi tingkat terjadinya cacat
    • Saat terjadi gangguan, seberapa cepat waktu pemulihannya
    • Apakah masalah bisa dideteksi sebelum pengguna menyadarinya
    • Apakah dependensi upstream bisa dikelola
    • Saat vendor bermasalah, apakah itu bisa dideteksi sebelum keluhan pengguna muncul
    • Berapa lama yang dibutuhkan untuk menerapkan ide yang diusulkan pengguna
    • Apakah ada pencegahan agar engineer tidak merusak sistem satu sama lain
    • Apakah ada sistem yang memungkinkan engineer terus maju tanpa membuat aplikasi berubah menjadi gumpalan yang kacau
    • Apakah mampu menangani software dengan skala yang tidak bisa dimuat dalam kepala satu orang
    • Jika masalah besar terjadi saat engineer tertidur di zona waktu dengan selisih 12 jam, apakah itu bisa diperbaiki sebelum pengguna menyerah
    • Apakah sistem bisa pulih dari gangguan internal maupun gangguan upstream, dan apakah data penting akan hilang
    • Apakah pembaruan keamanan diterapkan secara konsisten
    • Apakah data pengguna tidak bocor
    • Apakah sistem bisa dipercaya
    • Apakah sistem bisa diandalkan
    • Apakah ada dasar yang mendukung kepercayaan itu
    • Apakah kita bisa menandatangani jaminan yang mengikat secara hukum bahwa software akan bekerja saat dibutuhkan
  • Inilah tantangan engineering yang sesungguhnya sulit, dan menulis kode adalah bagian yang mudah

8 komentar

 
pseudojo 2026-01-27

Reaksi komentarnya wkwkwk, rasanya seperti memangkas hanya bagian yang diperlukan dari isi artikel asli~ Terima kasih, saya membacanya dengan baik.

 
bsh998 2026-01-27

Hasil pembacaan AI bip bip biiik.. dengan probabilitas 95%, ini adalah blog AI.

 
alfenmage 2026-01-27

wkwkwk 90 190 wkwkwk

 
roxie 2026-02-03

kkkkkkkkkk

 
sudosudo 2026-01-27

Apa maksudnya ini

 
[Komentar ini disembunyikan.]
 
[Komentar ini disembunyikan.]
 
skageektp 2026-01-26

Akan lebih baik jika ada penjelasan tentang apa itu SRE.