Buku Panduan CTO Startup

Buku Panduan CTO Startup

Keterampilan Esensial dan Praktik Terbaik untuk Tim Engineering Berkinerja Tinggi

Pengantar

• Selalu belajar: Penulis memiliki ketertarikan pada komputer dan pemrograman perangkat lunak sejak kecil, dan melalui hal itu menyadari pentingnya pembelajaran berkelanjutan. Untuk berhasil sebagai pemimpin teknologi, penting untuk terus belajar dan berkembang.
• Dilema pemimpin teknologi startup: Sebagian besar startup memiliki co-founder teknis, dan merekalah yang menulis codebase awal serta merekrut engineer pertama. Namun, seiring tim bertumbuh, pemimpin teknologi harus beralih ke peran manajerial, dan dalam proses ini mereka mungkin kekurangan keterampilan kepemimpinan.

Tentang penulis

• Penulis telah mengumpulkan pengalaman di berbagai startup dan menjalankan peran sebagai pemimpin teknologi. Melalui pengalaman di beragam startup, ia memahami berbagai keterampilan dan tantangan yang diperlukan dalam kepemimpinan teknologi.

Cara menggunakan buku ini

• Buku ini adalah referensi bagi pemimpin yang mengelola tim software engineering, dan membahas berbagai topik sebagai bab-bab yang berdiri sendiri. Setiap bab memperkenalkan topik, memberikan gambaran umum, dan menyajikan praktik terbaik.

Proses bisnis

• Buku ini menjelaskan proses bisnis untuk memberikan titik awal dalam pemecahan masalah. Proses tersebut perlu disesuaikan dan diskalakan menurut ukuran tim dan perusahaan.

Orang dan budaya

Prinsip dasar manajemen

• Aturan emas manajemen: Kinerja tim adalah tolok ukur untuk menilai kinerja manajer. Manajer harus mendukung anggota tim agar mereka dapat memberikan yang terbaik.
• Pohon keterampilan profesional: Untuk kepemimpinan teknologi, perlu berinvestasi bukan hanya pada keterampilan teknis tetapi juga pada keterampilan manajerial.

Perbaikan berkelanjutan

• Kaizen: Baik tim maupun individu harus mengejar perbaikan berkelanjutan. Kesalahan harus dijadikan peluang untuk melakukan perbaikan.

Coaching

• Manajer harus berperan sebagai coach yang membantu anggota tim agar dapat memberikan performa terbaik.

Mencari mentor manajemen

• Mencari mentor manajemen penting untuk transisi menuju kepemimpinan. Dengan mentor yang tepat, keterampilan kepemimpinan dapat ditingkatkan.

Pertemuan 1:1

• Pertemuan 1:1 adalah kesempatan untuk membangun hubungan dengan anggota tim, memahami kekuatan dan kelemahan mereka, serta membantu mereka memberikan yang terbaik.

Pertemuan skip-level

• Dengan secara rutin mengadakan pertemuan dengan bawahan langsung dari para manajer, kita dapat mengumpulkan berbagai sudut pandang dan menggunakannya untuk meningkatkan bisnis.

Coaching untuk manajer

• Kinerja manajer menengah sangat penting bagi kinerja organisasi. Manajer perlu dibina melalui pelatihan dan dukungan yang berkelanjutan.

Pertemuan 1:1 dengan engineer

• Pertemuan 1:1 dengan engineer adalah kesempatan untuk mendengarkan masalah yang mereka hadapi dan membantu mereka menemukan solusi. Tujuan pertemuan harus jelas, dan percakapan perlu diarahkan agar produktif.

[GN⁺]

Pendapat di Hacker News

• Saat membaca dokumen seperti ini, saya biasanya pergi dulu ke bagian yang saya pahami mendalam untuk melihat apa yang dikatakannya. Di sini disebutkan bahwa menyiapkan dan menjalani audit PCI DSS atau SOC 2 biasanya memakan waktu 6–12 bulan, jadi jangan mencoba mendapatkan sertifikasi di saat-saat terakhir. Namun untuk startup, saya cenderung memberi saran yang hampir sebaliknya
  Khususnya atestasi SOC 2 mudah didapat, dan mengeluarkan uang secara proaktif sebelum ada purchase order yang bergantung padanya adalah pemborosan. Tentu saja hal-hal yang nantinya menjadi dasar atestasi, seperti pengaturan single sign-on atau branch Git yang dilindungi, sebaiknya dilakukan sejak awal, tetapi itu lebih dekat ke praktik terbaik dasar yang memang harus dilakukan meski tidak berencana mendapatkan SOC 2. Menurut saya, jika pelanggan besar tidak memintanya, tidak perlu melakukan SOC 2. Akan bagus kalau ada yang memeriksa bagian lain dari dokumen ini juga

  • Pendekatan yang bagus. Saya mencari bagian tentang database dan secara umum terlihat baik. Namun pada 2025, startup tampaknya tidak perlu berfokus pada SQL versus NoSQL. Database SQL populer sudah mendukung JSON dengan baik, jadi gunakan PostgreSQL atau MySQL yang lebih akrab bagi para engineer, dan gunakan CloudSQL atau RDS yang akan menangani backup dan replikasi
    Dengan read replica untuk BI dan alat visualisasi yang layak, itu bisa bertahan cukup lama, dan sudah cukup sebelum menghabiskan angka 5–6 digit untuk sesuatu seperti Snowflake
  • Dalam pengalaman saya, perusahaan yang bersedia berbisnis dengan startup tahap awal sekaligus menginginkan laporan SOC 2 umumnya tidak keberatan melanjutkan dengan memasukkan perolehan SOC 2 Type 1 dalam 6 bulan ke kontrak, selama penanggung jawab teknis bisa menelepon tim IT mereka dan meyakinkan bahwa kapabilitasnya memadai
  • Saya dengan hormat tidak setuju khusus untuk kasus ketika proses akuntansi dan rantai pasok berada di dalam ERP enterprise. Membalik proses yang tidak dapat diaudit di kemudian hari memakan terlalu banyak waktu dan uang, sementara bisnis tetap harus berjalan. Untuk kasus spesifik ini, menurut saya lebih murah dan lebih baik membuatnya dapat diaudit sejak hari pertama
  • Penerapan saran ini bisa sangat berbeda tergantung industrinya. Jika menjual produk B2B yang menangani informasi identitas pribadi, SOC 2 praktis diperlukan agar tidak menjadi bahan tertawaan dalam pitch meeting
    Bergantung pada kondisi pendanaan, biaya menggunakan layanan checklist kepatuhan SOC 2 otomatis seperti Secureframe bisa berada di kisaran beberapa ribu dolar. Layanan itu bukan hanya membantu mengikuti praktik terbaik, tetapi juga menata semuanya dengan cara khas yang sesuai SOC 2 sehingga audit menjadi lebih mudah. Dibandingkan waktu pengembangan dan manajemen proyek yang dibutuhkan untuk membawa organisasi yang proses nonpatuhnya sudah tertanam dalam ke jalur SOC 2, itu bukan investasi besar
  • Saya tidak terlalu paham soal kepatuhan regulasi, tetapi ini terdengar cukup aneh. Dari membaca sekilas SOC 2, diperlukan pengumpulan bukti besar-besaran selama beberapa bulan sebelum audit. Jika tidak meluangkan waktu sebelumnya, saya tidak tahu bagaimana nantinya bisa tahu apa saja yang harus disiapkan
    Pernyataan bahwa atestasi SOC 2 mudah didapat juga bertolak belakang dengan yang saya dengar dari orang lain tentang topik ini. Biasanya saya dengar itu sangat sulit dan memakan banyak waktu, jadi saya penasaran apa yang saya lewatkan. Kalau memang benar mudah, saya berharap saya keliru

• Saya sering melihat orang mengatakan bahwa ketika menjadi VP atau CTO, Anda berhenti coding. Saya paham bahwa kemampuan manajemen bukan kemampuan coding, tetapi sulit memahami mengapa orang meletakkan keyboard dan menyia-nyiakan superpower pertama mereka
  Anda bisa tetap menjadi CTO yang teknis dari awal sampai akhir. Perlakukan tim dan perusahaan seperti layanan yang membutuhkan kontribusi aktif, pemeliharaan, dan dukungan on-call, sambil tetap ikut turun tangan membangun, baik sendiri maupun bersama tim

  • Di level VP/CTO, tidak ada waktu untuk berkontribusi pada kode dan memeliharanya. Jika ada waktu, jabatan itu kemungkinan besar hanya simbolis. Misalnya “CTO” di tim startup berisi 3 orang
    Masalah sebenarnya adalah mengambil peran yang tidak memberi waktu untuk coding terlalu awal dalam karier. Misalnya menerima peran arsitek yang hanya menggambar kotak di whiteboard dan berpindah dari rapat ke rapat, atau peran yang pada dasarnya manajerial tetapi diberi label “tech lead”. Anda menjadi terbiasa tidak menulis kode, lalu beberapa tahun kemudian saat harus mencari pekerjaan baru, Anda harus menghadapi wawancara untuk posisi coding sambil menyadari bahwa sebagian besar karier pemrograman Anda dihabiskan tanpa menulis kode. Bagi banyak orang, insting itu tidak cepat kembali
  • Dalam pengalaman saya, masalahnya adalah waktu dalam sehari memang hanya sebanyak itu. Selama 7 tahun, ada sekitar 20–25 orang yang menjadi tanggung jawab saya secara langsung maupun tidak langsung, dan benar-benar sangat sedikit waktu untuk melakukan hal yang berguna di kode
    Waktu saya jauh lebih baik digunakan untuk menyelesaikan masalah yang tidak bisa diselesaikan orang lain. Sesekali saya mengambil perubahan yang sangat sederhana untuk menjalani sendiri proses kami dan melihat bagian mana yang bisa diperbaiki. Saya tetap coding pada malam hari atau akhir pekan, tetapi rasanya tidak sama, dan seiring waktu pasti sedikit berkarat. Meski begitu, selama masa sabatikal, sangat menyenangkan bisa coding seharian penuh dan benar-benar turun tangan
  • Jika Anda bukan kontributor individu murni, prioritas lain akan muncul. Karena itu, pekerjaan kontribusi individu bisa dihentikan kapan saja. Akibatnya Anda tidak bisa mengambil pekerjaan yang dekat dengan critical path; jika mengambilnya, Anda akan menghambat orang lain atau harus menyerahkannya
    Review atau rapat desain masih bisa dilakukan, tetapi jika mengambil pekerjaan inti, pada akhirnya akan menimbulkan masalah
  • Saya tidak berpikir ada satu jawaban benar, tetapi mulai titik tertentu, merekrut engineer kunci berikutnya, membuat roadmap teknis untuk unggul dari kompetisi, atau menyelaraskan organisasi engineering dengan bagian lain perusahaan memiliki leverage yang jauh lebih besar daripada kontribusi kode dari VP/CTO
    Kode yang bisa ditulis VP/CTO juga bisa ditulis oleh orang lain di tim, dan mungkin bahkan lebih baik. Sebaliknya, hal-hal lain yang disebutkan tadi kemungkinan besar paling baik dilakukan oleh VP/CTO di perusahaan. Melepaskan sebagian besar pekerjaan teknis langsung demi hal yang lebih penting bagi tim dan perusahaan adalah keputusan yang cukup masuk akal
  • Peran CTO terakhir saya adalah untuk tim 40 orang, dan sejak hari pertama saya sudah sepenuhnya kewalahan. Padahal saya cukup baik dalam manajemen waktu. Jika memungkinkan, saya ingin memakai 50% waktu untuk programming, tetapi tidak ada waktu untuk itu dan tidak ada struktur pendukung yang bisa saya delegasikan, jadi saya harus membangunnya sendiri dengan susah payah. Itu sendiri juga menjadi alasan mengapa tidak ada waktu
    Gagasan untuk terus coding itu bagus, tetapi biasanya bukan itu alasan Anda dibayar. Saya menganggap diri saya developer yang sangat kuat, tetapi developer seperti itu bisa didapat dengan biaya lebih rendah daripada gaji CTO. Tidak efisien jika CTO yang lebih mahal mengerjakan hal itu. Sebagai catatan, beberapa tahun kemudian saya kembali menjadi kontributor individu, dan saya berencana menjalani sisa karier saya seperti itu

• Saya ingin mengatakan bahwa tidak ada yang namanya chat sinkron
  Jika sesuatu harus sinkron, jangan lakukan di jendela chat. Setidaknya kecuali sudah sepakat untuk “fokus pada chat real-time selama beberapa menit”. Jika remote, teleponlah; jika di tempat yang sama, bicaralah langsung. Jangan melempar pesan ke chat lalu mengharapkan jawaban instan

• Saya penasaran apakah ada contoh sistem “dua tim” yang tidak menimbulkan rasa kesal. Saya juga tidak tahu apakah ada kasus ketika orang secara alami tidak ingin pindah ke tim masa depan
  Di atas kertas terdengar seperti ide bagus, tetapi sulit dipercaya bahwa ini benar-benar akan berjalan baik dalam praktik. Bentuk terdekat yang pernah saya lihat adalah semacam tim library yang membuat layanan seperti design system dan komponen agar dipakai tim lain

  • Di tempat kerja sebelumnya, ada versi produk on-premise yang dukungannya diperpanjang superpanjang oleh perusahaan untuk versi yang sebenarnya sudah dijadwalkan end-of-support. Sebuah tim kecil, mungkin sekitar 3 orang, hanya bertanggung jawab memastikan versi itu tetap didukung, pipeline berjalan, dan jika perlu bisa merilis perbaikan besar
    Selama tanggung jawab itu terpenuhi, di sisa waktunya mereka bebas mengerjakan hal yang mereka anggap bernilai bagi perusahaan. Itu kesepakatan yang cukup bagus. Orang lain berterima kasih karena tim kecil itu mau menangani pekerjaan kotor, dan tim maintenance senang karena di waktu luang mereka bisa memperbaiki hal-hal yang selama ini mengganggu atau melakukan riset. Saya lupa detailnya, tetapi saya ingat ada beberapa peningkatan dan hasil riset yang cukup keren. Fakta bahwa orang-orang di tim itu sangat hebat dan mandiri juga membantu keberhasilannya, meski biayanya juga lebih besar
  • Buku ini tampaknya mengusulkan rotasi rutin sebagai solusi untuk masalah ini. Tulisan blog Microsoft menyarankan agar setiap minggu sebagian anggota tim ditukar di antara dua tim, dan mendefinisikan tim pelanggan sebagai tim sementara
    Saya pernah mengalami beberapa tempat di mana tim yang benar-benar terpisah berjalan baik. Dalam game, bayangkan tim engine dan tim game. Di salah satu peran lama saya, bahkan di dalam tim game kami mengerjakan fitur yang memakan waktu 6–12 minggu lalu merilisnya, kemudian menangani maintenance, update, dan technical debt. Hal yang baru dirilis menjadi fokus utama, tetapi masih ada waktu untuk kembali ke pekerjaan sebelumnya; tim lain juga berada dalam siklus yang sama, lalu 6–8 minggu kemudian onboarding ke fitur baru, dan begitu seterusnya
  • Dulu saya pernah bereksperimen dengan sistem dua tim. Pengembangan fitur ditangani Red Team, sedangkan stabilitas dan perbaikan bug ditangani Blue Team
    Kami tidak memperlakukannya sebagai tim tetap, melainkan sebagai alur kerja tempat orang berpindah setiap sprint, yaitu tiap 2 minggu. Selama sekitar 3 bulan berjalan baik, tetapi setelah itu tidak lagi cocok, dan sekitar saat itu organisasi membesar sehingga tim direorganisasi berdasarkan kapabilitas bisnis atau domain
  • Mirip dengan itu, saya pernah mencoba sistem giliran di mana engineer menangani support dan laporan bug masing-masing selama satu minggu. Ini cukup menghindari jebakan “dua tim” yang sepenuhnya terpisah. Saya menuliskannya sedikit lebih lanjut di https://news.ycombinator.com/item?id=43337703#43339972
  • Jika “tim pelanggan” memiliki sumber daya yang cukup dan kompensasinya juga layak, sepertinya mereka tidak harus ingin pindah ke “tim masa depan”. Namun bahkan tanpa pemisahan pun, biasanya maintenance dibiarkan kelaparan sementara fitur baru mengambil semua perhatian dan sumber daya. Kalau dibagi menjadi dua tim, kemungkinan besar justru bisa menjadi lebih buruk

• Materi seperti ini bagus bukan untuk dipakai seperti kitab suci, melainkan karena memberi gambaran luas tentang tanggung jawab dan hal-hal yang perlu diperhatikan
  Kecuali Anda punya penasihat yang hebat atau pernah bekerja di bawah orang yang benar-benar luar biasa, ketika sampai di posisi ini tidak ada orang yang duduk di samping Anda dan memberi daftar hal-hal yang harus diperhatikan. Ini membantu karena tiap bagian membuat kita bertanya, “Apa jawaban kita?”, “Apakah kita setuju?”, “Apakah proses kita lebih baik?”, “Apa yang saya lewatkan?”

• Menarik juga bahwa pemisahan “dua tim” dituliskan sejelas ini. Itu cara yang fantastis untuk terus merilis sampai biaya untuk merilis sesuatu yang layak menjadi terlalu besar
  Jika Anda memutus feedback loop yang kembali ke orang-orang yang pertama kali membuat software itu, mereka akan sedikit lebih bahagia untuk sementara, dan orang lain sedikit lebih sengsara untuk sementara. Lalu tim fitur tidak akan pernah mau diganggu lagi, dan tim pelanggan tidak akan pernah mendapat sumber daya untuk benar-benar memperbaiki apa pun
  Yang lebih buruk, tim fitur tidak belajar apa pun selain cara mengirim baris kode. Seiring waktu semuanya menjadi lebih lambat dan lebih mahal karena satu-satunya fungsi kecocokan dalam pengembangan software yang baik—yaitu mengintegrasikan kembali feedback negatif sebagai sumber pengembangan—telah dihilangkan. Handbook kepemimpinan CTO yang sungguhan seharusnya menyatakan dengan jelas: “Membantu developer menjadi lebih baik bahkan saat mereka merilis adalah tanggung jawab Anda, dan developer tidak selalu akan menyukainya”

  • Pernyataan “membuat tim fitur bisa fokus 100% pada masa depan tanpa terganggu pekerjaan dukungan pelanggan” lebih tepat berarti membiarkan tim fitur sama sekali tidak tahu kekacauan yang mereka lepaskan, lalu terus berjalan sampai kapal menabrak gunung es sepenuhnya
    Akan muncul juga konflik merge antara tim fitur yang didorong sales dan tim maintenance yang didorong pihak pelanggan. Selama “tim pelanggan” digambarkan sebagai tahap yang nantinya dilewati, sudah jelas pihak mana yang akan menang dalam perebutan prioritas. Ungkapan “jalur lain bagi engineer individu, terutama junior, untuk belajar dan berkembang” pada akhirnya terdengar seperti “senior tidak mau membersihkan kotoran, jadi diserahkan ke junior”
  • Terkait hal itu, di antara perusahaan tempat saya bekerja, yang memiliki tim platform umumnya terinfeksi over-engineering. Yang saya maksud tim platform di sini adalah semacam tim pendukung ketiga yang mengelola tool, praktik, dan kode bersama
    Tim seperti ini cenderung menarik orang-orang yang memandang rendah pekerjaan merilis fitur dan memperbaiki bug, serta ingin mengabstraksikan masalah secara berlebihan. Alih-alih memperbaiki bug, mereka membuat abstraksi yang makin rumit dengan alasan agar bug tidak muncul sejak awal, dan hasilnya mudah ditebak
  • Itu pekerjaan PM. Dibutuhkan satu orang atau beberapa orang yang bekerja dengan pelanggan dan, berdasarkan feedback, menetapkan visi tentang bagaimana semua fitur akan saling terhubung
    Pelanggan, terutama pelanggan nonteknis, tidak memiliki visi produk yang konsisten, dan sering kali hanya menginginkan perbaikan langsung tanpa memedulikan rencana lain. Pelanggan juga tidak saling berkomunikasi sehingga feedback bisa bertentangan. Jika beban ini diletakkan pada developer, developer harus mengelola semua komunikasi selain memiliki kompetensi teknis untuk memahami dan memelihara codebase dengan baik, dan semua developer harus memiliki visi konsisten yang sama agar bisa mengambil keputusan yang bijaksana. Dalam peran developer sekarang yang juga mengelola infrastruktur, itu pada dasarnya berarti satu orang melakukan dua atau tiga pekerjaan
  • Untuk melengkapinya, kami mengganti tim setiap sprint atau setiap beberapa sprint. Orang-orang mendapat pengalaman yang lebih beragam, dan jika membuat fitur yang banyak bug, pada akhirnya mereka sendiri harus memperbaikinya sehingga feedback tetap terus diterima
    Sepertinya orang-orang jauh lebih menyukai cara ini. Mereka tidak lelah karena selalu hanya memperbaiki bug, dan pemutusan feedback yang Anda sebutkan dengan tajam itu juga bisa dihindari
  • Developer harus mengoperasikan dan memelihara software yang mereka buat. Prinsipnya sesederhana itu

• Pada titik ini, saya sudah tidak bisa menghitung berapa kali melakukan wawancara, jadi agak sulit untuk sepenuhnya setuju. Salah satu kesulitannya adalah pada tahap penerimaan lamaran, jumlah pelamar bisa sangat banyak atau berpotensi sangat banyak, dan pada tahap ini biasanya tim rekrutmenlah yang berinteraksi dengan pelamar
  Menambahkan pertanyaan seperti contoh itu tidak masalah, tetapi untuk menyaring kandidat yang tidak memenuhi syarat, diperlukan pertanyaan yang bukan sekadar ya/tidak atau berbentuk skala. Saya lebih suka pertanyaan yang sangat sederhana dengan jawaban yang jelas. Ada begitu banyak orang yang menjawab “sangat nyaman” dengan JavaScript tetapi ternyata tidak tahu apa itu ===. Jadi saya menanyakan hal seperti “apa operator strict equality di JavaScript?” Programmer JavaScript mana pun akan tahu, tetapi satu pertanyaan seperti ini saja bisa menyaring 50% dari kumpulan pelamar dan menghemat sangat banyak waktu organisasi

• Ada banyak pembahasan tentang kecocokan budaya, tetapi sebagian besarnya terlihat seperti mengangkat lapisan diskriminasi terselubung yang merugikan perusahaan. Menurut saya, keterbukaan budaya adalah faktor keberhasilan, sementara diskriminasi membawa ke arah sebaliknya
  Saat membaca kalimat “Pemimpin terbaik melacak tingkat keberhasilan, tidak takut mengakui kesalahan perekrutan, serta merekrut perlahan dan memecat dengan cepat”, saya jadi ingin mengunggah gambar yang ditampilkan JWZ (Jamie Zawinski) ketika ia mendeteksi header referrer yang mengarah ke situs ini. Cari saja di Google apa yang dikatakan Jamie Zawinski tentang Y Combinator. Ia juga orang yang berjasa atas keputusan Netscape untuk merilis Netscape Navigator sebagai open source, serta sebagian besar pekerjaan yang kemudian menjadi engine rendering browser tersebut. Karena itulah Firefox ada

  • Melihat “kecocokan budaya” sebagai diskriminasi terselubung adalah interpretasi yang sinis, dan dalam kasus yang pernah saya lihat, istilah itu lebih sering dipakai untuk melindungi kandidat agar tidak diberi pekerjaan yang akan mereka benci
    Di salah satu tempat kerja awal saya, perusahaan mencoba melarang semua hal yang bisa disebut kecocokan budaya dalam kriteria perekrutan. Akibatnya, beberapa orang langsung membenci perusahaan begitu bergabung dan berhenti dalam hitungan minggu atau bulan. Seorang kandidat menekankan perencanaan dan prediktabilitas, serta mengeluhkan perusahaan-perusahaan sebelumnya yang bergerak terlalu cepat. Kami adalah startup, dan seperti yang diperkirakan, ia membenci perusahaan. Namun dalam proses pengambilan keputusan perekrutan, kekhawatiran seperti itu tidak boleh disampaikan. Alasannya, itu dianggap “kecocokan budaya” dan bisa mengarah pada diskriminasi. Setelah kejadian serupa terjadi beberapa kali lagi, kebijakan itu diam-diam menghilang, dan kami kembali bisa menilai kompatibilitas dengan budaya engineering
  • Semua proses perekrutan bersifat diskriminatif. Yang penting adalah karakteristik apa yang diuntungkan dan dirugikan, serta apa yang dikecualikan
    “Kecocokan budaya” pada dasarnya adalah pertukaran: mendapatkan efisiensi komunikasi dan kepercayaan tinggi dengan mengorbankan sebagian keberagaman pemikiran. Karena orang-orang sudah tahu bagaimana seharusnya bertindak dan apa yang harus diharapkan satu sama lain, tidak perlu membuat banyak panduan, tetapi mereka menjadi lebih rentan terhadap groupthink dan bias kognitif terkait. Kira-kira seperti “di kapal ini ada semua warna pelangi, tetapi bahkan orang Klingon kami pun berpikir bahwa Klingon itu jahat”
  • Saya mengikuti penyimpangan topik itu dan mencoba mencari, tetapi semua hasil halaman pertama hanya komentar di Hacker News yang menyebut Jamie Zawinski, jadi saya menyerah di sana. Jadi akan bagus kalau ada yang menjelaskan maksudnya

• Saya tidak yakin apakah saran “buat library video penjelasan” itu bagus. Untuk hal-hal tertentu seperti UI atau animasi, itu bisa masuk akal
  Namun secara umum, membaca teks lebih efisien daripada menonton video. Saat sedang terburu-buru, melompat ke bagian penting dalam teks juga jauh lebih mudah daripada di video

  • Ada orang yang menyukai video, ada juga yang menyukai teks. Keduanya adalah investasi yang membutuhkan usaha dan memberi manfaat. Sekarang, berkat AI generatif, keduanya menjadi lebih mudah dibuat