Melacak Waktu Build Developer untuk Memutuskan Upgrade ke M3 MacBook

• incident.io memutuskan apakah akan mengganti laptop developer ke M3 bukan berdasarkan perasaan, melainkan berdasarkan waktu build Go, dan mengumpulkan data nyata dari feedback loop pengembangan lokal
• Karena hot reloader Go yang ada sulit memberikan nilai yang dibutuhkan, mereka membuat tool sendiri dan memuat event build seperti platform, memori, status daya, tahap build, file pemicu, dan total waktu yang dibutuhkan ke data warehouse
• Dari sekitar 25 ribu build, setelah menyaring build yang gagal, dibatalkan, dan berjalan dengan daya baterai, mereka menganalisis 12.525 build sukses, serta mengonfirmasi perbedaan statistik bahwa build dengan daya AC lebih cepat daripada build dengan baterai
• Hasilnya, pengguna M1 sering harus menunggu hampir 2 menit sampai build selesai; M2 menunjukkan peningkatan besar dibanding M1, sementara M3 menunjukkan peningkatan bertahap dibanding M2
• Pada total waktu build, perbedaan memori tidak terlihat jelas, tetapi pada waktu linker, mesin 32~36GB lebih unggul, sehingga incident.io memutuskan mengganti mesin M1 dengan M3 Pro dasar 36GB

---

Kriteria penilaian upgrade adalah feedback loop pengembangan

• Semua developer di incident.io menggunakan MacBook untuk pekerjaan pengembangan
• Setelah Apple memperkenalkan M3 MacBook Pro pada Oktober 2023, CTO Pete mengatakan mereka akan menggantinya jika nilai upgrade dapat dibuktikan dengan data
• Tim menyiapkan tiga hal untuk menilai apakah perlu upgrade ke M3
  • Hot reloader Go kustom
  • Pengumpulan telemetri build dari laptop developer
  • Analisis data menggunakan model terbaru OpenAI dan code interpreter
• Produktivitas developer itu sendiri sulit dikuantifikasi, tetapi incident.io melihat feedback loop yang cepat sebagai hal penting bagi efisiensi developer
• Feedback loop yang sering berulang dalam pengembangan lokal adalah sebagai berikut
  • Mengompilasi monolith Go
  • Generasi kode seperti API client dan interface
  • Hot reload untuk frontend dan aplikasi mobile
• Developer incident.io menjalankan seluruh lingkungan incident.io secara lokal di laptop mereka, dan mempertahankan feedback loop di bawah 30 detik dari perubahan kode hingga eksekusi
• Karena codebase aplikasi Go sudah mendekati hampir 1 juta baris, kompilasi Go yang sering terjadi dan berbiaya besar dipilih sebagai metrik pembanding performa MacBook

Cara mengumpulkan telemetri build

• Sejak awal pembuatan repositori GitHub, incident.io telah menggunakan codegangsta/gin sebagai hot reloader Go
• Mereka juga meninjau hot reloader alternatif, tetapi tidak menemukan tool yang menyediakan telemetri yang dibutuhkan untuk analisis waktu build
• Data yang ingin dikumpulkan dari setiap build adalah sebagai berikut
  • Level sistem: platform M1/M2/M3, total memori, dan sebagainya
  • Metrik runtime: OS, penggunaan memori, sumber daya, sisa baterai, dan sebagainya
  • Telemetri build: total waktu yang dibutuhkan, tahap build Go, file yang memicu build, dan sebagainya
• Karena tidak ada alternatif siap pakai, mereka membuat tool sendiri yang dimulai dari main.go, lalu menjalankan dan mem-parsing output berbagai binary Mac untuk mengekstrak nilai yang dibutuhkan
  • memory_pressure
  • docker
  • sysctl
  • pmset
• Kode terkait dipublikasikan sebagai Gist
• Setelah membuat collector sistem dan runtime, mereka membungkus perintah build Go untuk mengumpulkan waktu per tahap seperti linker dan kompilasi, serta file pemicu build
• Hot reloader final dijalankan dari target make run yang sudah ada, dan perubahan ini tidak terlihat oleh tim engineering
• Setiap kali build selesai, event telemetri dikirim ke endpoint HTTP, lalu dimuat ke data warehouse melalui receiver webhook Fivetran

Alur analisis menggunakan OpenAI Assistant

• Setelah mengumpulkan dataset yang cukup selama beberapa minggu, mereka mengekspor hasil select * except(payload) from developer__build_events dari BigQuery sebagai CSV
• Mereka memberikan file CSV dan prompt yang menjelaskan tujuan ke OpenAI Assistants
• Model eksperimental gpt-4-1106-preview dan code interpreter diaktifkan untuk digunakan dalam analisis data
• Waktu build sangat bervariasi bahkan pada sistem yang sama, dan efek cache compiler Go juga besar, sehingga tidak adil jika hanya membandingkan rata-rata per platform
  • M3 Max tanpa cache bisa lebih lambat daripada Intel MacBook lama yang memiliki cache
• Analisis dilakukan bukan dengan sekadar membandingkan rata-rata, melainkan dengan merapikan kondisi build dan memisahkannya berdasarkan platform, memori, serta status daya

Pembersihan data dan kondisi perbandingan yang adil

• Seluruh dataset berisi sekitar 25 ribu build, dikumpulkan dari berbagai waktu dalam sehari, laptop, dan kondisi
• Untuk perbandingan platform yang adil, build berikut dikecualikan
  • Build yang gagal atau dibatalkan: tidak cocok untuk membandingkan kecepatan build karena pekerjaannya tidak selesai
  • Build dengan daya baterai: OS X dapat membatasi performa demi masa pakai baterai
• Setelah mengecualikan build gagal, jumlah build sukses tercatat 12.525
• Perbedaan performa build antara daya AC dan baterai dibandingkan terutama pada M1 Pro dan M2 Max
• Dalam uji statistik, rata-rata waktu build dengan daya AC lebih rendah, dengan p-value sekitar 0,0014
• Analisis selanjutnya hanya menggunakan build sukses dengan daya AC

Mengapa waktu build Go berfluktuasi

• Monolith Go incident.io adalah target yang terus dipantau performa build-nya, dan menghapus atau men-tuning proses build itu sendiri sama pentingnya dengan pembelian hardware
• Proyek Go terdiri dari banyak package, dan compiler Go menggunakan cache agar hanya mengompilasi ulang package yang dianggap mengalami perubahan
• Aplikasi incident.io dirancang dengan grafik dependensi yang lebar dan sedikit modul fondasi, sehingga sebagian besar perubahan tidak memicu kompilasi ulang seluruh grafik
• Tipe build secara garis besar terbagi menjadi empat
  • Selesai seketika, di bawah 3 detik: perubahan yang tidak berkaitan dengan compiler Go, sehingga binary yang sudah di-cache dapat digunakan
  • Build cepat, di bawah 30 detik: perubahan pada satu package dengan sedikit package dependensi, sebagian besar cache dipakai ulang, dan waktu terutama dihabiskan untuk linking
  • Build menengah, 30 detik~1 menit: package fitur yang memiliki sebagian dependensi package bawah diubah, tetapi sebagian besar masih dapat digunakan ulang
  • Build lambat, lebih dari 1 menit: penambahan type ke package dasar domain, sehingga semua package aplikasi harus dikompilasi ulang
• Perbandingan platform harus mempertimbangkan perbedaan karakter build seperti ini; jika semua build dicampur, situasinya menjadi seperti membandingkan apel dan jeruk

Hasil perbandingan M1, M2, dan M3

• Dengan hanya build sukses berdaya AC, mereka terlebih dahulu membandingkan M1 Pro dan M2 Max
• M2 Max jauh unggul dalam kecepatan build dibanding M1 Pro, tetapi kedua mesin tidak hanya berbeda chipset, melainkan juga konfigurasi memori
• Distribusi event build sukses berdasarkan platform dan memori adalah sebagai berikut
  • Apple M1 Pro 16GB: 5.235 build
  • Apple M2 Pro 16GB: 1.927 build
  • Apple M2 Max 32GB: 3.842 build
  • Apple M3 Pro 18GB: 321 build
  • Apple M3 Pro 36GB: 899 build
  • Apple M3 Max 36GB: 301 build
• Perbandingan M1 Pro 16GB dan M2 Max 32GB tidak sepenuhnya adil karena perbedaan memori
• Saat membandingkan M2 Pro 16GB dan M2 Max 32GB, dampak memori 32GB terhadap total waktu build tampak kecil
• M2 Pro dan M2 Max pada dasarnya adalah chip yang sama, dan Max memiliki tambahan 2 core efisiensi energi
  • Core tersebut dinilai berkontribusi kecil pada kompilasi program Go karena performanya sekitar 1/5 dari core performa
• Untuk mengevaluasi M3, mereka membeli tiga mesin berikut
  • M3 Pro 12-core, 6 core performa + 6 core efisiensi energi, 18GB
  • M3 Pro 12-core, 6 core performa + 6 core efisiensi energi, 36GB
  • M3 Max 14-core, 10 core performa + 4 core efisiensi energi, 36GB
• Grafik waktu build M3 Pro 18GB dan 36GB mirip, tetapi data M3 lebih sedikit dibanding platform lain
• Ketika membandingkan M3 Pro dan M3 Max setelah mengecualikan build yang sangat cepat di bawah 3 detik, M3 Max tidak menunjukkan peningkatan menonjol yang cukup untuk membenarkan harga 60% lebih tinggi dibanding M3 Pro dasar
• Penilaian keseluruhannya adalah sebagai berikut
  • Pengguna laptop M1 sering menunggu hampir 2 menit sampai build selesai
  • M2 adalah upgrade besar dibanding M1
  • M3 adalah peningkatan bertahap dibanding M2
  • Pengguna M1 akan upgrade ke M3 Pro dasar
  • Pengguna M2 tidak perlu upgrade

Memori terlihat lebih jelas pada waktu linker

• Dalam perbandingan total waktu build, peningkatan dari 16~18GB ke 32~36GB tidak menunjukkan peningkatan bermakna yang besar
• Karena efek memori tidak terlalu tampak pada grafik seperti yang diperkirakan, mereka menganalisis waktu linker secara terpisah di antara tahap build
• Event telemetri berisi waktu tahap linking dan kompilasi, dan kolom linker_time dibuat dari build_stages.link.duration_seconds untuk analisis
• Saat linker_time dibandingkan berdasarkan platform dan konfigurasi memori, muncul pola yang berbeda
  • Mesin M1, M2, dan M3 dengan memori 32~36GB hampir selalu menyelesaikan linking dalam di bawah 20 detik
  • Mesin dengan memori 18GB ke bawah sering mengalami linking yang melewati 20 detik
• Tambahan memori mungkin kurang jelas pada total waktu build, tetapi terbukti berguna pada tahap linker
• Mereka juga sedang mempertimbangkan menghapus Docker dari mesin pengembangan, yang mengarah pada interpretasi bahwa mesin bermemori rendah dapat meningkatkan waktu linking dengan menambah memori sistem yang tersedia tanpa Docker
• Dalam pengembangan aplikasi mobile, simulator menggunakan banyak memori sistem, sehingga penambahan memori juga dianggap masuk akal sebagai biaya untuk kesiapan masa depan

Keputusan akhir dan efek samping

• incident.io memutuskan untuk meng-upgrade mesin M1 ke M3 Pro dasar dengan memori 36GB
• Mesin M2 tampak sudah memiliki performa yang cukup baik, sehingga tidak akan di-upgrade untuk sementara
• Selain keputusan pembelian laptop, pemahaman terhadap lingkungan dan tool pengembangan juga meningkat
• Hasil yang diperoleh tim adalah sebagai berikut
  • Menemukan waktu build Go sebagai benchmark yang baik untuk mengukur performa mesin developer
  • Membuat hot reloader Go sendiri yang melacak metrik yang dibutuhkan, sekaligus mendapatkan peningkatan usability lain
  • Lebih memahami faktor yang membuat build Go menjadi lebih cepat atau lebih lambat
  • Mengonfirmasi bahwa OpenAI Assistants dapat menangani masalah analisis data serupa
  • Mengkuantifikasi peningkatan antar-lini chip Apple dari sudut pandang developer Go
  • Memori penting, tetapi terlihat lebih jelas pada waktu linker daripada total waktu build

[GN⁺]

Pendapat di Hacker News

• Tulisan yang bagus, dan saya suka karena cara mengumpulkan serta menganalisis datanya beragam, tetapi rasanya akan jauh lebih mudah dan akurat kalau setiap laptop diletakkan berdampingan lalu menjalankan build yang diukur waktunya dalam skenario yang sama
  Sepertinya dalam sehari bisa dibuat skrip untuk membandingkan beberapa hal seperti build penuh, build inkremental untuk perubahan terbaru, build inkremental yang perlu membangun ulang modul tertentu, atau menerapkan 100 commit Git terbaru secara berurutan sambil mengukur waktu build inkremental
  Jika mengumpulkan statistik seluruh perusahaan, biasnya bisa besar. Misalnya, karyawan baru mungkin memakai M3, sementara karyawan lama memakai M1; karyawan baru mungkin lebih sering membuat perubahan kecil, sedangkan yang berpengalaman menangani bagian kode yang lebih dalam atau area yang kompleks sehingga waktu build menjadi lebih lama
  Jadi analisisnya sendiri keren, tetapi mengingat bias yang melekat pada sampel, menurut saya sebaiknya mulai dari cara sederhana dulu, yaitu membenchmark commit-commit terbaru di masing-masing laptop, sebelum membangun arsitektur pengumpulan data untuk seluruh perusahaan

  • Saya sepenuhnya setuju dengan usulan itu, dan sebagai penulis artikel, saya lebih dulu melakukan spot check performa untuk beberapa pekerjaan umum
    Alasan mengumpulkan data ini bukan hanya untuk membandingkan antarperangkat, tetapi juga untuk membangun data historis waktu build developer dan terus mengukur performa build agar bisa menangkap regresi
    Ketika melihat waktu build meningkat, kami sering menyesuaikan struktur codebase agar build menjadi lebih cepat
  • Saya tidak melihat analisis tentang network build sebagai alternatif M3. Proyek saya sekitar 40 juta baris, dan setelah melewati ambang tertentu, mesin lokal secepat apa pun tidak bisa mengalahkan network build yang dibuat tim infrastruktur
    M3 mungkin bisa membuat build 30% lebih cepat daripada M1, tetapi network build 15 kali lebih cepat. Bisa dipertimbangkan apakah seharusnya berinvestasi pada network build, alih-alih memberi M3 kepada developer
  • Bias pada sampel adalah masalah metodologi analisis. Ini menunjukkan bahwa jika Anda sendiri tidak cukup memahami topik tersebut, Anda tidak bisa bergantung pada asisten AI
    Mereka melakukan uji-t pada data yang tidak diambil sampelnya secara independen; beberapa titik data berasal dari orang yang berbeda, dan tiap orang mengerjakan hal yang berbeda sehingga kebutuhan komputasinya bisa berbeda, sehingga muncul faktor pengganggu. Ini melanggar asumsi dasar uji-t, tetapi code interpreter tidak menyorotinya
    Sebagai gantinya, bisa digunakan model efek campuran linear dengan memasukkan faktor seperti pemilik laptop dan masa kerja sebagai efek acak
    Meski begitu, datanya sendiri menarik, terutama bagian RAM. Cache itu kuat, dan RAM yang besar memberi manfaat lebih besar daripada yang banyak orang kira. MacBook yang RAM-nya lebih banyak dari kebutuhan biasanya mengisi sebagian besar RAM tersisa sebagai cache
  • Entah kenapa, tampaknya mereka memilih cara semahal mungkin untuk menjawab pertanyaan itu. Dan mereka juga menilai M2 sudah cukup, jadi saya heran mengapa kesimpulannya adalah meng-upgrade pengguna M1 ke M3 yang lebih mahal
  • Akan lebih baik jika mereka mencatat apa yang dibuild dan bagaimana caranya, misalnya “repositori dimulai dari commit ini”, “terapkan diff ini”, “jalankan build dengan perintah ini”
    Jika dikumpulkan sekitar seminggu, mereka bisa mendapatkan irisan beban kerja nyata, menjalankan ulang build tersebut di tiap kelas hardware, dan menggunakannya kembali nanti untuk hardware baru

• Sebagai ilmuwan, saya merasa menarik melihat cara programmer komputer menangani data
  Mereka membuat grafik yang cantik, mengotomatiskan analisis dengan sangat cepat menggunakan ChatGPT, dan ChatGPT menghasilkan uji-t yang cukup meyakinkan
  Namun ada variasi berdasarkan memori dan jenis chip, tetapi mereka tidak mempertimbangkan regresi linear, dan membuat histogram yang sulit dibandingkan. Mereka bisa melengkapinya dengan rata-rata sederhana dan error bar, atau memakai fungsi distribusi kumulatif (CDF) yang memudahkan melihat tumpang tindih atau pergeseran

  • Sebagai peneliti ilmu komputer, reaksi saya juga sama. Saat S1 saya mengambil jurusan ganda biologi/ilmu komputer dan belajar statistik, tetapi seingat saya baru saat pascasarjana saya memakai fungsi distribusi kumulatif untuk analisis data
  • Biasanya itu pekerjaan data scientist, dan sebagian besar tim infrastruktur engineering tidak punya data scientist serta sebagian besar waktu memang tidak terlalu membutuhkannya
    Umumnya orang menangani data sesuai cara yang ditampilkan alat, dan ini juga cukup berkaitan dengan rangkaian produk software untuk analisis, analisis performa, dan observability
    Mengharapkan software engineer rata-rata mengetahui CDF mirip seperti mengharapkan mereka mengetahui quaternion dalam grafis 3D atau dasar-dasar penulisan shader
  • Distribusinya jelas tampaknya bukan distribusi normal, dan perbedaan median juga mungkin cukup penting. Sebagai langkah pertama, saya mungkin akan memakai uji Wilcoxon
    Atau bisa juga memakai regresi kuantil. Jika hipotesisnya M3 > M2 > M1, uji Jonckheere–Terpstra yang terkenal untuk median berurutan mungkin sangat cocok untuk pseudo-analisis seperti ini
  • Di beberapa tempat mereka menggunakan box plot yang memungkinkan perbandingan lebih jelas. Sepertinya akan lebih efektif jika semua data ditampilkan sebagai box plot
  • Untuk perbandingan seperti ini, saya ingin merekomendasikan grafik fungsi distribusi kumulatif empiris. Setiap distribusi menjadi satu kurva, dan beberapa kurva bisa diletakkan pada grafik yang sama sehingga mudah dibandingkan
    Contohnya bisa dilihat pada grafik terakhir di halaman ini: https://ggplot2.tidyverse.org/reference/stat_ecdf.html

• Analisisnya solid, tetapi dari pengalaman pribadi saya ingin memberi satu peringatan
  Di perusahaan software menengah dengan sekitar 2.000 karyawan, kami berusaha meningkatkan produktivitas pengembangan, dan menjajaki opsi memindahkan stack pengembangan ke instance AWS alih-alih membeli laptop baru
  Hasilnya, itu menjadi proyek bertahun-tahun yang melibatkan sekitar 4 developer secara full-time, dan kalau dilihat lagi, manfaatnya tidak sebanding dengan biayanya. Mereplikasi pengalaman pengembangan yang sepenuhnya lokal di cloud masih terlalu sulit
  Jadi menurut saya lebih baik upgrade laptop

  • Tim kami sudah beberapa tahun mengembangkan dengan target cluster K8s yang sepenuhnya remote, dan itu memberikan pengalaman developer yang cukup kuat
    Kode ada di laptop, tetapi tersinkronisasi real-time dengan layanan remote tanpa build Docker atau deployment K8s, sehingga benar-benar terasa seperti lokal
    Terutama karena saat coding kami bisa langsung menjalankan integration test ke atas, sehingga bisa menghindari siklus commit-push-pray
    Untuk ini kami memakai Garden(https://docs.garden.io). Baik memakai Garden maupun tidak, dengan alat yang tepat, memanfaatkan kekuatan cloud dalam loop pengembangan internal bisa menjadi sangat bagus
    Tulisan singkat tentang pengalaman itu: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
  • Ini mungkin terkait skala. Perusahaan kami berukuran sekitar 7.000 orang, dan beberapa tahun lalu memulai jalur serupa; butuh waktu sampai pengalaman remote menjadi lebih baik daripada lokal, tetapi sekarang jelas lebih baik
    Beberapa hal yang sebelumnya mustahil di versi khusus lokal juga jadi mungkin. Misalnya saat berpindah-pindah branch, mengganti mesin alih-alih mengubah file lokal membuat jeda context switching jauh lebih rendah
  • Sepenuhnya setuju. Jika seluruh solusi tidak bisa dijalankan sepenuhnya secara lokal, muncul friksi besar untuk memahami dan menalar solusi itu
    Jika untuk melakukan sesuatu harus menyalakan lebih dari 200 komponen, mengerjakan satu bagian saja yang hanya berinteraksi dengan beberapa komponen pun jadi sulit
    Di era server dengan 128 core lebih dan 256 thread lebih, saya makin condong berpikir bahwa untuk sebagian besar software, monolith kembali menjadi pilihan yang lebih baik
  • Di perusahaan kami, Linux antivirus dan berbagai sampah lain dimasukkan begitu saja ke cloud developer box, sehingga bahkan di tipe instance besar, build lebih dari 10x lebih lambat daripada laptop dan ratusan kali lebih lambat daripada mesin developer sungguhan seperti Threadripper
    Murni pemborosan uang dan waktu. Kalau semua system call di-hook oleh software vendor yang tidak berguna, jelas itu buruk untuk toolchain bergaya Unix yang menjalankan banyak subprocess
  • Menurut saya ini lebih dekat ke masalah SDM
    Di perusahaan teknologi besar seperti Google dan Meta, lingkungan pengembangan ada di cloud untuk mayoritas software engineer
    Pengalaman pengembangannya jauh lebih baik daripada lokal

• Untuk pengembangan iOS, kesimpulan dari riset pribadi saya dengan mempertimbangkan biaya adalah seperti ini
  M2 Pro bagus, tetapi peningkatannya tidak terlalu besar dibanding M1 Pro 10-core. Di XcodeBenchmark, 136 detik vs 120 detik: https://github.com/devMEremenko/XcodeBenchmark
  M3 Pro terasa seperti dilemahkan agar bisa dibedakan dari M3 Max, dan karena performance core-nya hanya 6, pada dasarnya mirip dengan M2 Pro
  Akhirnya saya membeli M1 Pro 10-core yang sedikit bekas dan sangat puas. Dengan biaya kurang dari setengah harga M3 Pro dasar, saya mendapatkan 85% performanya, dan juga mempertimbangkan bahwa biasanya CPU perlu setidaknya 33–50% lebih cepat agar perbedaannya terasa

  • Cerita bahwa M3 Pro dilemahkan terus diulang di internet sejak pengumumannya, tetapi sebenarnya itu pilihan yang sangat bagus
    Jauh lebih efisien daripada M2 Pro sementara performanya sedikit lebih baik. Di laptop, hal seperti itulah yang saya inginkan, dan bandwidth memori tidak terlalu saya pakai
  • Pengalaman saya juga mirip. Dalam waktu kompilasi nyata, M1 Pro masih bertahan cukup dekat dengan model M2 dan M3 laptop saat ini
    Tidak ada perbedaan sebesar yang ditunjukkan di tulisan ini. Bisa saja berbeda tergantung bahasa atau proyek, tetapi ketika saya membenchmark perintah kompilasi yang sama secara berdampingan, saya tidak melihat perbedaan sebesar ini
  • Menarik bahwa peningkatan M2 lebih kecil daripada yang terlihat di tulisan ini
    Karena toolchain kompilasinya berbeda, itu tidak mengejutkan; di toolchain Go pun bisa terlihat bahwa spesifikasi tertentu memengaruhi tiap tahap build secara berbeda, misalnya memori tambahan membantu performa linker
    Saya juga beberapa kali melihat reaksi bahwa performa M3 dibatasi secara aneh, dan semoga itu tidak berlanjut di model setelah M4
  • Baru-baru ini saya melakukan perhitungan yang sama, dan akhirnya membeli M1 Pro dengan memori dan disk dimaksimalkan. Itu deal yang bagus dan komputer yang sangat baik
  • Saya suka M1 MacBook Air untuk pengembangan iOS. Dari lini Pro, yang saya inginkan hanya layarnya, terutama PPI
    120Hz juga bagus, tetapi sepertinya tidak akan masuk ke laptop Air

• Saya dulu kontributor inti untuk Chromium dan Node.js, dan sekarang kontributor inti gRPC Core/C++, tetapi waktu build tidak pernah benar-benar membuat saya pusing
  Ada “build interaktif”, yaitu build inkremental untuk menjalankan ulang unit test terkait saat bekerja, dan build non-interaktif yang dijalankan lalu ditinggal minum kopi atau membaca email. Saya belum pernah melihat penggantian hardware membuat build non-interaktif berubah menjadi interaktif
  Perangkat pribadi saya adalah Intel i7 berusia lebih dari 5 tahun dengan memori 16GB, dan setelah tahu bahwa untuk melakukan link Node.js di WSL butuh memori lebih, saya menambahkan 16GB lagi
  Laptop kerja saya adalah Intel MacBook Pro dengan Touch Bar, dan saya tidak menganggapnya berdampak besar pada produktivitas. Yang penting adalah ukuran dan kualitas layar, serta kecepatan storage. Dibanding kemajuan CPU, pengaruh sistem build seperti kecepatan build inkremental dan dukungan build terdistribusi lebih besar. Untuk proyek pribadi saya memakai Bazel

  • Sepertinya para programmer sudah terbiasa menerima kompilasi dan linking yang lama, padahal perubahan sangat kecil pada satu fungsi hanya mengubah beberapa byte pada binary
    Kompilasi dan linking semestinya selesai hampir seketika, cukup cepat sampai kita tidak merasakan adanya tahap kompilasi
    Build rilis yang memakai teknik seperti optimisasi seluruh program boleh saja lama, tetapi loop kompilasi/debug/test biasa bisa dibuat instan. Kompilasi bahasa sistem memang luar biasa lambat karena alasan legacy, tetapi tidak harus selalu begitu
  • Saya juga pernah memakai Blaze lalu mencoba Bazel untuk proyek pribadi, tetapi karena proyeknya backend dan frontend yang di-Docker-kan, aturan build-nya cepat menjadi aneh dan sangat spesifik
    Karena saya menghabiskan banyak waktu mengutak-atik file BUILD, saya jadi bertanya-tanya apakah nilainya lebih besar daripada Makefile biasa. Itu kejadian 3 tahun lalu, jadi mungkin ekosistem publiknya sekarang sudah lebih baik
  • Saya rasa seri M cukup unggul dibanding Intel MBP dalam hal layar dan kecepatan storage. Saat di kantor beralih dari Intel MBP ke M1, layarnya jelas jauh lebih baik
    Untuk kecepatan storage saya kurang tahu, dan semua build kami berjalan di mesin remote development yang kuat
  • Itu karena sudah terbiasa dengan Bazel. Saya juga dulu begitu
  • Chromium adalah proyek raksasa. Untuk proyek dengan ukuran yang lebih umum, full build di laptop bisa selesai dalam waktu yang masuk akal

• Untuk orang yang ingin melakukan analisis data dengan AI seperti di tulisan itu, menurut saya jauh lebih mudah memasukkan data ke R atau Stata dan semacamnya lalu melakukan kueri sendiri
  Perintahnya lebih singkat dan akurat, dan yang terpenting jauh lebih dapat direproduksi
  Hal tersulit dalam analisis data adalah memahami data dan mekanisme yang menghasilkannya. Untuk itu perlu model kausal dari domain masalahnya
  Kalau AI belum dilatih terlebih dahulu dengan data lain dari domain tersebut, saya tidak yakin ia bisa membuat model kausal yang berguna. Tanpa model itu, mustahil menafsirkan data secara masuk akal, dan saya juga penasaran apakah model AI saat ini bisa mendeteksi confounding, pengaruh outlier yang berlebihan, serta variabel moderator efek yang menarik

  • Asisten AI berbasis GPT-4 pada dasarnya melakukan hal itu
    Saat saya melakukannya, saya memakai Python dan pandas, dan kita bisa meminta untuk ditunjukkan kode yang dipakai dalam analisis
    Bedanya antara memasukkan data ke R/Python lalu mencari “bagaimana melakukan xyzzzy” dan menulis kode sendiri, atau memakai ChatGPT

• Bagian “setiap developer menjalankan lingkungan incident.io lengkap secara lokal di laptop, dan mendapatkan feedback loop kurang dari 30 detik dari perubahan kode sampai berjalan” tampak sebagai pencapaian terbesar
  Selain saat membantu startup sebentar, saya belum pernah berada di perusahaan yang seluruh instance development/lokalnya bisa dijalankan di satu mesin
  Selalu ada sesuatu yang tidak bisa diakses, dan selalu ada jebakan

  • Sampai pekerjaan saya yang terakhir, aplikasi sialan itu tidak bisa dijalankan secara lokal dan itu benar-benar membuat frustrasi
    Saya tidak mengerti kenapa orang tidak lebih marah terhadap developer experience yang mengerikan seperti ini. Lulusan kuliah zaman sekarang sepertinya tidak tahu apa yang mereka lewatkan
  • Saya pernah bekerja di perusahaan seperti itu, dan setelah pergi saya sangat merindukannya
    Orang yang belum pernah hidup di dunia itu tidak memahami betapa jauh lebih baiknya, lalu merasionalisasikannya dengan berbagai cara
  • Sulit membayangkan tidak memiliki ini. Kami menjalankan semuanya secara lokal dengan k3s dan itu berjalan baik
    Namun tahun lalu kami menambahkan Snowflake, dan meskipun memang menyelesaikan masalah nyata, melakukan iterasi development pada bagian itu terasa menyakitkan
  • Dulu hal itu mungkin, tetapi makin besar skalanya, makin sulit didukung. Tingkat usaha yang diperlukan tumbuh kurang lebih secara kuadratik terhadap ukuran perusahaan
    Linear terhadap jumlah layanan yang harus didukung, dan juga linear terhadap jumlah engineer yang harus didukung. Selain itu muncul berbagai use case yang tidak cocok, lalu tanpa terasa tim infrastruktur menjadi bottleneck peluncuran fitur, dan orang mulai memakai cara masing-masing
    Begitu kotak Pandora itu terbuka, secara praktis mustahil untuk kembali. Namun mengurangi siklus development dari beberapa jam atau hari menjadi beberapa menit jauh lebih penting daripada memangkas beberapa menit sebesar 25%
  • Saya sedang berusaha sekuat mungkin agar ini bisa dilakukan pada aplikasi yang sedang kami buat. Karena harus menjalankan model object detection dan Stable Diffusion, saya harus meyakinkan CEO bahwa M2 Max akan membantu
    Sejauh ini berjalan baik

• Sebagai penulis, terima kasih sudah mengunggahnya
  Ada berbagai hal di dalamnya, seperti profiling kompilasi Go, membuat hot reloader, dan menganalisis dataset build dengan AI
  Kesimpulannya, M1 layak di-upgrade ke M3 Pro, dan dalam pengujian Max tidak membuat perbedaan besar. M2 cukup dekat dengan M3, sehingga bagi kami tidak layak di-upgrade
  Kalau ada pertanyaan, saya bisa menjawab

  • Terima kasih atas analisis detailnya, dan saya penasaran apakah Anda menghitung biaya waktu engineering yang masuk ke analisis ini
    Saya juga penasaran bagaimana biaya itu memengaruhi periode payback
  • Saya penasaran bagaimana Anda sampai pada kesimpulan bahwa SKU Max tidak jauh lebih cepat. Distribusi pada chart terlihat lebih cepat, tetapi teks di bawahnya hanya mengatakan tampaknya mirip
  • Saya penasaran apakah alasan manfaat M3 Max kecil bisa dianggap karena workload tidak benar-benar memanfaatkan core dengan baik
    Atau bisa juga karena pekerjaannya selesai terlalu cepat sehingga dalam penggunaan nyata perbedaannya tidak terasa
  • Saya penasaran apakah manajer menunda sebagian deliverable agar Anda punya waktu mengerjakan ini, atau apakah ini dilakukan seperti pekerjaan sampingan
  • Perbandingan yang menarik. Jika memungkinkan, saya juga ingin melihat tambahan build pada mesin dengan memori 8GB

• Idenya menarik, tetapi kualitas analisis datanya terlihat cukup rendah, dan tidak yakin apakah kita benar-benar mempelajari hal yang dipikirkan
  Khususnya, sulit memahami mengapa build di bawah 20 detik meningkat sedrastis itu saat beralih dari M1 Pro ke M2 Pro. Perbedaan performa nyata keduanya dalam pekerjaan kompilasi kode kira-kira 20–25%
  Juga tidak terlalu masuk akal bahwa mesin M3 memiliki lebih sedikit build di bawah 20 detik dibanding mesin M2, atau M3 Pro yang jumlah core-nya setengah justru memiliki lebih banyak build di bawah 20 detik dibanding M3 Max
  Besar kemungkinan perbedaan perilaku developer, seperti orang dengan jenis laptop berbeda biasanya mengerjakan hal yang berbeda, yang menyebabkan perbedaan ini
  Dari beberapa pengamatan setelah membaca sekilas, compiler Go tampaknya tidak terlalu memanfaatkan core tambahan, cara penggabungan datanya pada dasarnya kurang nyaman, dan metode perbandingannya juga kurang konsisten karena mencampur histogram dengan grafik kepadatan yang dibagi ke dalam rentang, serta memakai rentang sumbu-y yang berbeda
  Mac tidak melakukan throttling performa CPU hanya karena sedang memakai baterai. Jika build memang lebih lambat saat memakai baterai, sulit memastikannya hanya dari grafik, tetapi kemungkinan karena pengaturan “Daya Rendah” aktif

  • M3 memiliki bandwidth memori yang lebih kecil, jadi untuk sebagian use case sebenarnya merupakan downgrade

• Sedikit menyimpang, tetapi saya penasaran bagaimana perusahaan lain menyeimbangkan manajemen endpoint dan software keamanan dengan produktivitas developer
  Perusahaan kami menjalankan 5+ layanan latar belakang di laptop developer, baik Mac maupun Windows. Termasuk manajemen endpoint, intersepsi eskalasi hak akses, intersepsi dan inspeksi TLS, anti-malware, serta klien VPN
  Kombinasi ini berdampak besar pada performa. Apa pun yang dilakukan di mesin, layanan-layanan ini memakan CPU dan performa I/O, dan para developer telah mengeluhkan freeze dan tersendat secara acak
  Mengingat meningkatnya ransomware dan pencurian kekayaan intelektual, saya paham bahwa keamanan diperlukan, tetapi saya penasaran apakah ada perusahaan yang menemukan cara lebih baik untuk menyediakan keamanan dengan dampak yang lebih kecil pada produktivitas developer

  • Satu-satunya cara yang pernah saya lihat adalah melaporkannya ke tim IT/support saat situasi memburuk, lalu memberi tahu folder dan file yang perlu dikecualikan agar hal seperti file sementara build tidak memperlambat proses karena terhalang pemindaian