3 poin oleh GN⁺ 2026-01-28 | 2 komentar | Bagikan ke WhatsApp
  • Hanya tindakan itu sendiri yang merupakan eksekusi nyata, menekankan bahwa berpikir atau bersiap bukanlah eksekusi
  • Berulang kali ditegaskan bahwa merencanakan, belajar, berdiskusi, membeli alat dan sejenisnya bukanlah ‘mengerjakan pekerjaan’
  • Hanya tindakan mencoba langsung, meski gagal atau canggung yang dianggap sebagai eksekusi yang sesungguhnya
  • Memulai walau kecil itu penting, dan persiapan sempurna atau kondisi ideal tidaklah perlu
  • Tulisan ini mengingatkan bahwa sikap menerjemahkan niat menjadi tindakan nyata adalah inti dari kreasi dan pengembangan

Membedakan eksekusi dan non-eksekusi

  • Tulisan ini merinci bahwa “berpikir, bermimpi, memvisualisasikan, mempersiapkan” semuanya bukan ‘mengerjakan pekerjaan’
    • Contoh: “berpikir”, “bermimpi”, “membayangkan kesuksesan”, “menunggu sampai siap”
  • Berbicara, menjelaskan, atau berdebat juga tidak dianggap sebagai eksekusi
    • Termasuk “menjelaskannya kepada orang lain”, “berdebat secara online”, “mengumumkan bahwa akan memulai”

Jebakan persiapan dan konsumsi

  • Mendengarkan podcast, menonton tutorial, membaca contoh kasus orang lain semuanya bukan eksekusi
  • Merancang sistem yang sempurna, membeli alat, atau merapikan ruang kerja juga tidak dipandang sebagai eksekusi
  • Sikap mencari penghiburan dalam rasa bersalah atau kesibukan juga bukan tindakan nyata

Bentuk eksekusi yang sesungguhnya

  • Melakukannya sambil gagal, melakukannya dengan canggung, melakukannya meski kecil semuanya diakui sebagai ‘mengerjakan pekerjaan’
    • Meski tidak sempurna, tindakan benar-benar menggerakkan tanganlah yang penting
  • Di bagian akhir, tulisan ini menyebut bahwa “bahkan menulis blog pun bukan berarti mengerjakan pekerjaan”, lalu menghadirkan kesimpulan yang reflektif terhadap diri sendiri

Pesan inti

  • Hanya tindakan yang merupakan eksekusi nyata, dan semua hal lain bukanlah pengganti eksekusi
  • Memulai walau kecil, menerima kemungkinan gagal, dan langsung mencobanya sendiri adalah satu-satunya bentuk kemajuan
  • Kalimat terakhir tulisan ini, “Sekarang aku harus kembali bekerja,” melambangkan sikap untuk segera bertindak

2 komentar

 
bobross0 2026-02-27

Ini ungkapan yang bagus untuk orang seperti saya yang tidak terlalu pandai mengeksekusi.

 
GN⁺ 2026-01-28
Komentar Hacker News
  • Prinsip "Doing it badly" benar-benar mengubah cara berpikir saya
    Saya pernah menghabiskan berminggu-minggu mencoba merancang arsitektur yang sempurna, tetapi pada akhirnya saya berhenti membuat rencana dan membuat versi kasar yang menyelesaikan masalah saya
    Yang mengejutkan, versi pertama itu mengajarkan hal-hal yang tidak akan pernah saya pelajari hanya dari perencanaan. Saya belajar apa yang benar-benar dianggap penting oleh pengguna, edge case yang penting di dunia nyata, dan apa arti "cukup baik"
    Bagian tersulitnya adalah mengizinkan rilis padahal saya tahu ada kekurangannya. Tetapi loop umpan balik dari penggunaan nyata jauh lebih berharga daripada berminggu-minggu diskusi hipotetis

    • Saya setuju dengan isinya, tetapi nada tulisannya terasa seperti tulisan yang dihasilkan LLM
      Sekarang subreddit produktivitas penuh dengan tulisan seperti ini. Saya ragu apakah realistis menghabiskan berminggu-minggu merencanakan arsitektur sambil membuat alat otomasi pribadi
      Jika melihat riwayat komentar penulis, gaya serupa terus berulang sehingga terasa kurang meyakinkan
    • Dulu saya pernah melihat seorang developer hebat yang bekerja dengan cara menghapus total lalu menulis ulang kode berkali-kali
      Menyaksikan proses itu benar-benar menarik
    • Sangat sulit mengajarkan intuisi ini kepada pemula
      Ada banyak hal yang bisa dipelajari tentang masalah maupun pemrograman secara umum lewat proses benar-benar mengimplementasikan lalu me-refactor
      Abstraksi awal yang dipikirkan biasanya salah. Saat implementasi berjalan, strukturnya berubah total, dan pada akhirnya keluarlah kode yang indah yang sama sekali berbeda dari titik awal
    • Ini mengingatkan saya pada esai "Plan to Throw One Away" dalam The Mythical Man-Month karya Fred Brooks
      Intinya, versi pertama dibuat dengan kesiapan untuk dibuang, tetapi kenyataannya kebanyakan tidak dibuang dan justru diperbaiki secara iteratif
      Sekarang, berkat tool dan proses yang ada, kita bisa terus iterate
    • Yang penting adalah tidak mencampuradukkan desain fitur tingkat atas dengan plumbing internal (struktur dasar)
      Struktur internal juga perlu iterasi dan prototyping, tetapi hal-hal seperti struktur data, penanganan error, logging, dan penamaan perlu diputuskan dengan hati-hati sejak awal agar nanti bisa ditingkatkan lebih cepat
  • Saya suka kalimat "Doing it badly is doing the thing"
    Ini pelajaran yang saya dapat dari HN: saat buntu, yang penting bukan memikirkan cara melakukannya dengan sempurna, tetapi mulai saja dulu
    Meski awalnya berantakan, kalau terus diperbaiki sedikit demi sedikit, tiba-tiba gambarnya jadi jelas. Rasanya seperti sihir

    • Ungkapan "Everything worth doing is worth doing badly" membantu saya melewati masa-masa sulit
    • Ada dua nasihat terkait ini yang saya suka
      Salah satunya adalah nasihat Dan Harmon tentang writer’s block,
      yang lainnya adalah "The Gap" dari Ira Glass
      Intinya, jangan menunggu sempurna; tulis saja draf yang jelek, lalu perbaiki dengan sudut pandang seorang kritikus
    • Di perusahaan, kalau pakai pendekatan seperti ini, justru kita bisa dibilang "sudah cukup, berhenti saja", lalu versi setengah jadi itu dipertahankan selamanya
      Karena itu akhir-akhir ini saya sengaja bilang "belum selesai" sampai benar-benar matang
    • Software biasanya melewati tiga tahap: alpha–beta–release
      Saya biasanya membuatnya cepat dulu, lalu merapikannya, dan pada akhirnya menulis ulang dari awal
      Yang penting adalah tidak terjebak perfeksionisme di tahap beta
    • Menarik melihat bahwa ketika manusia melakukan perbaikan bertahap seperti ini, itu dipandang positif, tetapi ketika LLM melakukannya, dipandang negatif
      Jika perbaikan bertahap memang efektif, seharusnya tidak masalah apakah itu dilakukan manusia atau AI
  • Di perusahaan lama, kami menyebut manajemen sebagai "perkumpulan pengagum masalah"
    Mereka sibuk membahas masalah, menganalisisnya, dan mencari siapa yang bertanggung jawab, tetapi tidak benar-benar menyelesaikannya
    Pada akhirnya yang penting adalah 'benar-benar melakukannya'

    • Sebaliknya, ada juga perusahaan yang terlalu terobsesi pada solusi yang sudah ada sampai enggan melihat ulang masalahnya
      Pendekatan terbaik adalah punya kepedulian terhadap masalah sekaligus kemauan untuk terus mengiterasi solusinya
      Dogfooding penggunaan internal adalah cara yang bagus untuk menjaga keseimbangan itu
    • Pada akhirnya, kalau Anda menjadi orang yang benar-benar mengerjakan sesuatu, Anda harus memanfaatkan kewenangan mengambil keputusan itu
      Penting untuk memutuskan sebisa mungkin ke arah yang menguntungkan diri sendiri
    • Menghapus manajer menengah meningkatkan produktivitas
      Koordinasi untuk pembaruan berkurang, dan organisasi yang benar-benar bekerja jadi lebih efisien
    • Setelah menganalisis masalah, jika itu memberi Anda alasan untuk langsung mulai mengerjakan hal lain sekarang juga, itu tidak apa-apa
  • Tulisan ini sangat mirip dengan esai di strangestloop.io

    • Sejujurnya rasanya hampir sampai tingkat plagiarisme
      Dari judulnya saya merasa familiar, lalu saat diklik ternyata situsnya berbeda dan waktu terbitnya juga beberapa hari lalu, jadi saya kaget
      Isinya terlalu mirip untuk dianggap kebetulan
    • Saya juga tidak ingat pernah melihat tulisan ini di mana, tetapi saya yakin pernah membaca sesuatu yang sangat mirip
  • Dulu saya menganggap persiapan itu penting, tetapi pada suatu titik saya sadar bahwa persiapan bisa menjadi loop tanpa akhir
    Tim kami menyelesaikan produk dalam empat bulan dengan spesifikasi dua halaman, sementara tim pesaing menulis dokumen selama delapan bulan lalu dibubarkan
    Perencanaan 20% saja sudah menangkap 80% masalah. Setelah itu, sisanya sering kali hanya kekakuan yang dibungkus kecemasan
    Pada akhirnya, sebagian besar pembelajaran datang dari merilis sesuatu yang memalukan lalu memperbaikinya

    • Sepertinya Anda sedikit salah memahami poin tulisannya. "Persiapan" itu sendiri sudah termasuk dalam kategori 'bukan doing the thing'
    • Tergantung timnya. Tim kami merencanakan selama berbulan-bulan dan tetap berhasil merilis dengan baik. Pada akhirnya semua tergantung situasi
    • Manfaat perencanaan memang menurun, tetapi kebanyakan proyek justru jadi lebih buruk karena kurang perencanaan
    • Ini mengingatkan saya pada adegan Rimmer di Red Dwarf yang gagal karena hanya sibuk mempersiapkan ujian
      Itu dikutip di komentar HN sebelumnya
    • Menghapus perencanaan sepenuhnya juga bermasalah. Yang dibutuhkan adalah keseimbangan
  • Analysis paralysis itu nyata
    Agar tidak berhenti total, Anda harus mulai dulu. Kerjakan happy path lebih dulu, lalu rapikan edge case belakangan
    Sekarang biaya membuat prototipe rendah, jadi jangan takut gagal dan cobalah
    Inilah juga alasan LLM sangat efektif — langsung mengeksekusi alih-alih menganalisis
    Meskipun hasilnya tidak sempurna, sering kali sudah cukup berguna, dan jika perlu bisa dioptimalkan nanti
    Sebelum membuat framework, Anda sebaiknya membangun setidaknya tiga sistem nyata terlebih dahulu. Dengan begitu Anda tahu bagian mana yang berlebihan dan mana yang kurang

    • Namun, jangan mengira prototipe sebagai produk nyata
      Ungkapan "sudah cukup oke" bisa menjadi bentuk penipuan diri
      Prototipe yang gagal bukan bukti bahwa tidak ada pasar. Itu hanya sinyal bahwa ada sesuatu yang kurang
  • Tulisan ini membawa pesan yang hampir sama persis dengan postingan sebelumnya
    Ini juga sudah dibahas dalam diskusi HN sebelumnya

    • Diskusinya terlalu mirip sampai rasanya pantas ditandai sebagai duplikat (dupe)
  • Sebaliknya, terkadang 'doing the thing' itu sendiri justru pilihan yang salah
    Itulah sebabnya saya masih tetap menekankan dokumen desain dan code review
    Di era GenAI, "coba saja tanpa rencana dan asal kerjakan" menjadi terlalu mudah, sehingga penyeimbang semakin dibutuhkan

    • Sekarang happy path memang jadi lebih mudah, tetapi jarak antara prototipe dan production justru makin lebar
      Waktu habis untuk menghadapi masalah non-determinisme dan latency, dan pada akhirnya tantangan yang sesungguhnya adalah membuat unit economics masuk akal
  • Dalam Remains of The Day, "hanya membicarakan the thing" disebut sebagai tindakan memuaskan diri sendiri
    Sering kali itu berhenti pada percakapan yang membuat kita merasa baik, padahal sebenarnya tidak menghasilkan apa-apa

  • Di sisi lain, perencanaan, persiapan, dan mise-en-place memang bisa membantu pelaksanaan nyata

    • Namun, itu hanya bermakna jika benar-benar diwujudkan dalam tindakan. Jangan sampai jatuh ke analysis paralysis
    • Orang sering salah mengira perencanaan atau diskusi sebagai 'doing the thing'. Itulah masalahnya