Kesederhanaan Tidak Membuat Anda Dipromosikan

• Dalam budaya software engineering, orang yang membangun sistem kompleks cenderung lebih diakui, sementara mereka yang memilih solusi sederhana sering tidak mendapat penilaian setimpal
• Dalam evaluasi promosi, wawancara, dan design review, kompleksitas kerap disalahartikan sebagai “dampak”, sehingga kecenderungan menambahkan abstraksi dan skalabilitas yang tidak perlu menjadi makin kuat
• Implementasi sederhana sering menjadi “hasil yang tak terlihat”, sedangkan struktur kompleks mudah memenuhi dokumen promosi dengan narasi dan dokumentasi yang tampak mengesankan
• Keahlian sejati bukan soal memakai lebih banyak alat, melainkan penilaian dan kepercayaan diri untuk tahu kapan kompleksitas harus disingkirkan
• Baik engineer maupun leader perlu membuat kesederhanaan menjadi terlihat, lalu membangun sistem evaluasi dan penghargaan yang secara resmi mengakuinya

---

Kesederhanaan vs Kompleksitas: Asimetri dalam Narasi Promosi

• Contoh dua engineer dalam tim yang sama: Engineer A merilis fitur dalam beberapa hari dengan 50 baris kode yang ringkas, sementara Engineer B menyelesaikannya dalam 3 minggu dengan memperkenalkan abstraction layer baru, sistem pub/sub, dan framework konfigurasi
• Pekerjaan Engineer B dapat ditulis di paket promosi sebagai "merancang arsitektur event-driven yang scalable, memperkenalkan abstraction layer yang dapat digunakan ulang, membangun framework konfigurasi"
• Pekerjaan Engineer A hanya bisa dijelaskan dengan tiga kata: "mengimplementasikan fitur X"
  • Padahal itu pekerjaan yang lebih baik, tetapi karena dibuat agar terlihat sederhana, kontribusinya menjadi tak kasatmata
• Tidak ada yang dipromosikan karena “kompleksitas yang berhasil dihindari” — kompleksitas terlihat pintar karena sistem evaluasi memang disusun untuk memberinya imbalan

Struktur yang Memperkuat Kompleksitas dalam Wawancara dan Design Review

• Dalam wawancara system design, ketika seseorang mengusulkan solusi sederhana (satu database, API yang lugas, caching layer), pewawancara akan menekan dengan pertanyaan "bagaimana kalau ada 10 juta pengguna?"
  • Semakin banyak service, queue, dan sharding yang ditambahkan, semakin pewawancara tampak puas
  • Pelajaran yang dibawa kandidat: "jawaban sederhana ternyata tidak cukup"
• Mungkin ada alasan yang masuk akal bagi pewawancara untuk menekan seperti itu (menguji cara berpikir di bawah tekanan, memeriksa pemahaman distributed systems), tetapi pesan yang sampai ke kandidat adalah bahwa "kompleksitas itu mengesankan"
• Dalam design review juga berulang pola pertanyaan seperti "bukankah ini perlu future-proof?" yang mendorong penambahan layer dan abstraksi yang tidak perlu
  • Ditambahkan bukan karena masalahnya menuntut itu, melainkan karena ruang rapat mengharapkannya
• Banyak pengalaman di mana abstraksi yang dibuat demi menghindari sedikit duplikasi kode justru membuat sistem lebih sulit dipahami dan dipelihara
  • Kodenya memang terlihat lebih "profesional", tetapi pengguna tidak menerima fitur lebih cepat, dan engineer berikutnya menghabiskan setengah hari hanya untuk memahami abstraksinya sebelum membuat perubahan

Kompleksitas yang Tepat vs Kompleksitas yang Tidak Pantas (Unearned Complexity)

• Kompleksitas itu sendiri bukan masalah — untuk memproses jutaan transaksi dibutuhkan distributed systems, dan ketika 10 tim membangun produk yang sama maka service boundary diperlukan
• Masalahnya adalah kompleksitas yang tidak perlu: ada perbedaan antara "database sudah mencapai batasnya jadi kita perlu sharding" dan "mungkin 3 tahun lagi database akan mencapai batasnya, jadi mari lakukan sharding sekarang"
• Kode dan arsitektur dari engineer yang memahami hal ini terasa seperti "ya memang seharusnya begitu"; tidak terasa magis, tidak terasa sok cerdas, dan tidak membuat orang lain merasa bodoh karena tidak paham
• Jalur nyata menuju senior bukan mempelajari lebih banyak alat dan pola, tetapi mengetahui kapan tidak memakainya — siapa pun bisa menambahkan kompleksitas, tetapi menguranginya membutuhkan pengalaman dan kepercayaan diri

Langkah Praktis untuk Engineer

• Kesederhanaan perlu dibuat terlihat — pekerjaan itu tidak akan berbicara sendiri, karena sistem evaluasi tidak dirancang untuk bisa mendengarnya
• Daripada menulis "mengimplementasikan fitur X", tulislah "setelah mengevaluasi tiga pendekatan termasuk arsitektur event-driven dan custom abstraction layer, diputuskan bahwa implementasi sederhana sudah memenuhi kebutuhan saat ini dan yang diperkirakan, dirilis dalam 2 hari dan berjalan 6 bulan tanpa gangguan"
  • Keputusan untuk tidak membangun sesuatu juga merupakan keputusan, dan keputusan yang penting — maka itu juga perlu didokumentasikan
• Dalam design review, jangan langsung menyerah pada pertanyaan "bukankah ini harus future-proof?", tetapi jelaskan: "kalau ditambahkan nanti, biayanya sekian; kalau ditambahkan sekarang, biayanya sekian; lebih baik menunggu"
  • Ini bukan bantahan, melainkan menunjukkan bahwa peninjauan sudah dilakukan dengan matang
• Bicaralah langsung dengan manajer: "saya ingin cara saya mendokumentasikan pekerjaan mencerminkan bukan hanya kode, tetapi juga keputusan yang saya ambil" — dari sisi manajer, ini juga memberi bahasa yang bisa mereka gunakan untuk membela kontribusi Anda
• Jika setelah semua usaha itu tim Anda tetap hanya mempromosikan orang yang membangun sistem paling rumit, itu juga informasi yang berguna — sebagian organisasi benar-benar menghargai kesederhanaan, sementara yang lain hanya mengatakannya tetapi memberi imbalan pada kebalikannya

Langkah Praktis untuk Engineering Leader

• Menetapkan insentif adalah tanggung jawab leader — kebanyakan kriteria promosi dirancang untuk memberi imbalan pada kompleksitas, dan “dampak” cenderung diukur dari skala dan cakupan hal yang dibangun
  • Bukan hanya apa yang dibangun, tetapi juga apa yang berhasil dihindari perlu masuk dalam penilaian
• Dalam design review, ubah pertanyaan dari "apakah skalabilitas sudah dipertimbangkan?" menjadi "apa versi paling sederhana yang bisa dirilis, dan sinyal konkret apa yang menunjukkan bahwa kita benar-benar membutuhkan sesuatu yang lebih kompleks?"
  • Satu pertanyaan ini mengubah permainan: kesederhanaan menjadi default, dan beban pembuktian ada pada kompleksitas
• Dalam diskusi promosi, ketika melihat paket yang berisi daftar sistem yang tampak mengesankan, perlu ada pertanyaan balik: "apakah semuanya memang perlu? apakah sistem pub/sub itu benar-benar dibutuhkan, atau hanya terlihat bagus di dokumen?"
• Ketika anggota tim merilis sesuatu yang bersih dan sederhana, bantu mereka menulis narasinya — "mengevaluasi beberapa pendekatan lalu memilih yang paling sederhana yang tetap menyelesaikan masalah" hanya akan menjadi contoh promosi yang meyakinkan jika leader benar-benar memperlakukannya demikian
• Perhatikan siapa yang Anda rayakan secara terbuka di kanal tim — jika hanya proyek besar dan kompleks yang dipuji, orang akan mengoptimalkan diri ke sana
  • Engineer yang menghapus kode, atau engineer yang berkata "kita belum membutuhkannya" dan ternyata benar, juga harus diakui

[goathead]

desain yang digerakkan oleh resume...

[roxie]

Saya tidak berpikir saran-saran dalam tulisan ini tidak berarti, tetapi saya rasa terlalu sulit untuk mengalahkan "desain besar". Soalnya, yang itu terlalu, terlalu mudah dijelaskan :(

[GN⁺]

Komentar Hacker News

• Dalam sebuah pertanyaan wawancara, saya diberi skenario dua orang saling mengirim spreadsheet lewat email
  Saya menjawab bahwa saya akan memindahkannya ke Google Sheets, tetapi pewawancara tampaknya ingin saya merancang alatnya sendiri
  Saat itu terasa canggung, dan sampai sekarang saya masih tidak yakin pelajaran apa yang seharusnya saya ambil

  • Menurut saya situasi seperti ini adalah kegagalan melatih pewawancara
    Mereka seharusnya mengakui jawaban yang baik, lalu mengarahkan dengan, “ini adalah situasi hipotetis untuk evaluasi desain teknis, jadi mari kita rancang sistem baru”
    Jika kandidat tidak bisa menerima premis itu, maka itu bisa dinilai sebagai sinyal lain
    Kalau saya, saya akan bertanya, “apakah kita berasumsi solusi yang sudah ada tidak tersedia, lalu merancang dari nol?”
    Ini seperti versi desain sistem dari perdebatan algoritma di mana pewawancara hanya ingin mendengar jawaban yang dia inginkan
  • Co-founder saya pernah menjalani wawancara desain sistem saat ada pembicaraan akuisisi oleh Stripe, dan setelah mendengar requirement dia menjawab, “saya akan taruh saja di Postgres”
    Secara praktik itu memang keputusan yang benar, tetapi Patrick Collison menelepon langsung dan berkata, “kamu tidak lolos wawancara, tetapi paham maksudnya tidak?”
    Pada akhirnya dia diwawancarai lagi dan lolos
    Ini menunjukkan pentingnya memahami tujuan wawancara
  • Saya pernah mendiskusikan topik ini dengan seorang teman
    Sebuah perusahaan feri besar mengelola posisi kapal dan penugasan pegawai dengan Google Sheets, dan teman saya berkata, “ini bukan cara kerja perusahaan besar”
    Tetapi saya justru menganggap itu hebat karena mereka menyelesaikan masalah dengan alat yang sudah terbukti
    Berkat itu mereka bisa beroperasi tanpa tim pengembang internal atau outsourcing mahal
    Itu adalah pengalaman yang membuat saya mengubur rasa pongah saya dalam-dalam
  • Untuk pertanyaan wawancara seperti ini, menurut saya lebih baik mulai dengan bertanya, “kenapa ini menjadi masalah?”
    Biarkan lawan bicara menjelaskan secara spesifik bagian mana yang tidak cocok, baru setelah itu mulai masuk ke desain teknis
  • Jawaban yang benar adalah bertanya, “kenapa tidak memakai Google Sheets dan malah saling mengirim lewat email?”
    Ada banyak alasan kenapa Sheets tidak bisa dipakai — keterbatasan fitur, pembatasan akses di Tiongkok, kebijakan perusahaan, masalah jaringan, dan lain-lain
    Bisa jadi klien memang sudah menginginkan solusi kustom karena alasan-alasan itu
    Jadi peran developer bukan sekadar berkata “pakai Google Sheets saja”, melainkan memahami konteks pelanggan

• Alat coding AI memperburuk masalah ini dengan cara yang lebih halus
  Sekarang kita bisa menghasilkan arsitektur yang kompleks dalam 5 menit, tetapi biaya pemeliharaannya tetap sama
  Akibatnya struktur yang lebih mewah bisa dibuat dengan cepat, dan dokumen untuk promosi pun cepat selesai
  Namun pada kenyataannya tidak ada yang benar-benar memahami kode itu sepenuhnya
  Tolok ukur kesederhanaan yang sesungguhnya adalah “apakah orang berikutnya bisa memahaminya tanpa bertanya”, dan kode hasil AI belum benar-benar lulus ujian itu

  • Sebenarnya bahkan sebelum era LLM pun petugas on-call yang dipanggil jam 3 pagi sering kali tidak terlalu memahami sistem
    Sekarang itu hanya akan menjadi lebih buruk
    Karena itu saya menjadikan budaya pemahaman kode di organisasi sebagai kriteria dalam memilih karier
    Saya tidak ingin lagi mengalami situasi di mana tidak ada yang memahami sistem
  • Karena alasan ini, ke depan nilai produk perangkat lunak itu sendiri kemungkinan akan menurun
    Jika tujuannya menyelesaikan masalah, maka baik alat buatan AI maupun alat yang dibeli pada akhirnya harus benar-benar menyelesaikan masalah itu
    Tetapi jika produk jadi tidak cocok, pada akhirnya solusi kustom yang dihasilkan sendiri akan makin banyak
    Hanya saja, jika tidak ada yang memahaminya, orang berikutnya akan membuat ulang dari awal
    Meski begitu, dari sisi mendekatkan pengguna dan pembuatnya, ini mungkin merupakan perbaikan
  • Saat memakai alat AI, penting untuk mendokumentasikan prinsip maintainability
    Misalnya, akan membantu jika di AGENTS.md dituliskan panduan seperti “KISS” dan “YAGNI”
  • Saya juga berusaha menjaga kesederhanaan saat coding dengan AI
    Masalahnya, “orang berikutnya” pada akhirnya adalah diri saya sendiri 6 bulan kemudian
    AI juga mengalami masalah yang sama karena batasan context window
  • Biaya operasional dari kode yang dibuat AI juga tidak bisa diabaikan
    Banyak developer hanya mengejar stack yang populer tanpa memikirkan kemudahan operasional
    AI juga tidak akan berkata, “ini overengineering”
    Jika Anda ingin Kubernetes dan ElasticSearch, AI akan membuatkannya begitu saja

• Dari pengalaman di FAANG maupun startup, kuncinya adalah keseimbangan antara kompleksitas dan kesederhanaan
  Di perusahaan besar, hack sementara bisa merusak produktivitas ribuan orang,
  sementara di startup, infrastruktur yang berlebihan bisa menghancurkan perusahaan
  Engineer yang benar-benar terampil adalah orang yang bisa membedakan dua situasi itu dan memilih trade-off yang tepat berdasarkan pengalaman

  • Tingkat munculnya cacat saat ukuran tim 5 orang dan 500 orang itu benar-benar berbeda
  • Kemampuan mengelola proyek secara mandiri adalah keterampilan yang sangat sulit dipelajari

• Saat bekerja di Amazon (2005~2008), ada dua penghargaan yang menjadi simbol budaya perusahaan
  Penghargaan “Just Do It” melambangkan penyelesaian masalah secara proaktif, dan penghargaan “Door Desk” melambangkan penghematan dan kesederhanaan
  Pernah ada kisah seorang pegawai mendapat penghargaan karena menyingkirkan TV yang tidak berguna, dan sebagai hadiah justru diberikan TV itu

  • Tetapi meja dari daun pintu itu sebenarnya lebih mahal daripada Ikea dan juga lebih sulit dirakit
    Kesederhanaan sebagai metafora pada praktiknya agak ambigu
  • Sampai sekarang penghargaan “Just Do It” masih tetap diberikan

• Jika ingin mengadvokasi kesederhanaan, kita harus mengungkapkannya dalam bahasa bisnis
  Misalnya seperti “insiden turun 80%”, “biaya turun 40%”, atau “performa naik 33%”
  Kesederhanaan itu sendiri tidak dihargai, tetapi hasilnya sangat dihargai

  • Namun dampak dari “karena tidak membangun sesuatu yang kompleks” sulit diukur
  • Bahkan jika Anda merancang sistem yang cepat sejak awal, Anda akan kurang diakui dibanding orang yang membuat sistem lambat lalu memperbaikinya 80%
  • Kesederhanaan sulit berujung pada promosi karena tidak terlihat di P&L
    Saya mengubah refactoring menjadi model biaya, mengukur KPI, dan menurunkan MTTR sebesar 60%
    Angka-angka seperti inilah yang harus ditunjukkan secara langsung agar diakui
  • Kebanyakan eksekutif akan memilih “lebih cepat”, dan hampir tidak pernah memilih “lebih sederhana”

• Sebagai manajer, saya lebih menyukai kode yang sederhana
  Namun itu karena tim saya terdiri dari orang-orang yang sudah berpengalaman
  Dalam tim yang kurang berpengalaman, hal seperti The Parable of The Toaster bisa saja terjadi

• Semakin bertambah usia, saya semakin menolak kompleksitas
  Namun kepemimpinan sering salah paham dan mengira saya menentangnya karena tidak mengerti
  Proyek yang paling lama bertahan justru yang sederhana dan mudah diganti
  Alat AI membuat pendekatan seperti ini lebih mudah — bereksperimen dengan komponen melalui sample project yang terpisah, lalu mengintegrasikan kode yang sudah tervalidasi ke proyek utama
  Dalam lingkungan intranet saya tidak menghubungkan AI secara langsung, tetapi pendekatan ini sangat berguna

  • Pihak kepemimpinan sering salah menganggap pendekatan sederhana sebagai kemalasan
    Karena itu saya biasanya mengusulkan, “kita bisa membuat versi yang kompleks juga, tetapi mari mulai dari versi yang sederhana dulu”
    Dalam banyak kasus, versi sederhana itu justru menjadi kode produksi yang berjalan selama bertahun-tahun
  • Pelajaran seperti ini pada akhirnya hanya bisa dipahami dengan mengalaminya sendiri

• Developer yang cepat merilis solusi sederhana bisa memakai sisa waktunya untuk membangun lebih banyak fitur
  Sebaliknya, orang yang terpaku pada solusi kompleks bisa menghabiskan berminggu-minggu untuk satu fitur
  Pada akhirnya, dalam metrik produktivitas, pendekatan sederhana terlihat lebih menarik
  Saya juga membangun karier sebagai orang yang konsisten menghasilkan hasil, bukan orang dengan “ide besar”

  • Tetapi jika terlalu sederhana, ada risiko terlihat seperti “orang yang hanya mengerjakan fitur kecil”
  • Ada juga yang mempersoalkan “ungkapan yang berpusat pada laki-laki”, tetapi intinya adalah budaya yang berorientasi pada hasil

• Salah satu wawancara di perusahaan kami adalah soal desain sistem perpustakaan umum
  Awalnya dimulai dari perpustakaan kota kecil, lalu berkembang ke skenario skala nasional
  Jawaban terbaik adalah, “bahkan pada skala maksimum, server kelas menengah dan Postgres sudah cukup”

  • Tetapi ada pewawancara yang meminta skala tidak realistis seperti “10.000 request per detik”
    Dalam kenyataannya, 10 atau 10.000 sering kali tidak terlalu berbeda, dan pewawancara yang kurang berpengalaman sering hanya membacakan prompt
  • Kita tidak boleh lupa bahwa tidak semua perusahaan merancang sistem setingkat Spotify
  • Web awal dulu bisa menangani ratusan request hanya dengan perangkat di sudut ruang server
    Setelah itu masalah justru membesar karena infrastruktur berlebihan dan pengembangan demi CV

• Pada akhirnya saya menganggap AI hanyalah alat yang memperkuat kemampuan pengguna
  Bagi developer berpengalaman, AI meningkatkan produktivitas, tetapi bagi orang yang belum matang, AI menjadi alat untuk menyebarkan kekacauan dengan cepat

  • Saya adalah engineer yang menyukai kesederhanaan, tetapi AI belum bisa membuat kode menjadi lebih sederhana
    Sebaliknya, AI cenderung menambahkan wrapper function dan konversi tipe yang tidak perlu
    Rasanya AI lebih condong ke arah “menambah lebih banyak kode”
  • Tetapi bahkan dengan pengalaman yang masih kurang, jika AI digunakan dengan sikap belajar yang kritis, itu bisa membantu memperbaiki kode sendiri sebelum membuka PR
  • Saya juga pernah terbantu oleh ChatGPT Codex untuk mulai mengerjakan tugas yang sulit dimulai
    Namun saya tetap khawatir dengan meningkatnya “vibe coding” yang dangkal

[yangeok]

Para pewawancara yang saya temui juga tampaknya lebih menyukai kompleksitas.

[botplaysdice]

Saya bahkan tidak berharap kesederhanaan akan dinilai baik. Kenyataannya, ada juga yang dipromosikan karena membereskan kekacauan yang muncul setelah mereka membuat segalanya jadi rumit.

[beoks]

Alih-alih merancang untuk layanan, overengineering demi membesar-besarkan kemampuan sudah merajalela.

[shakespeares]

Saya pikir penilai perlu memiliki pemahaman yang baik.
Dan memang benar bahwa mereka juga perlu mendengarkan penjelasan yang memadai.

[botplaysdice]

Kalau ada orang di posisi atas yang mampu menilai hal seperti itu, semuanya akan baik-baik saja, tapi sejak awal itu tidak berjalan, jadi hal-hal seperti ini tidak bisa dinilai secara adil, dan karena itu orang-orang seperti itu tidak bisa naik ke atas...

Ini lingkaran setan...

Dari sudut pandang perusahaan, sepertinya hanya jika seseorang berhasil sebagai engineer yang seimbang lalu naik ke posisi atas, barulah prinsip engineer/engineering yang baik juga bisa dijaga.

[aa1567]

Bukankah kebanyakan realitanya adalah sekadar bisa mengimplementasikan fungsi vs mampu merancang dengan skalabilitas sambil juga memahami trade-off dengan baik?

[devsepnine]

Meski dikerjakan dengan rumit, pada akhirnya itu tetap bisa disebut sebagai implementasi fitur X.
Perbedaannya ada pada bagaimana Anda menyampaikan hal tersebut kepada penilai.