Pengalaman Bekerja di GitLab

• Enam tahun sejak bergabung dengan GitLab sebagai karyawan ke-28 pada Oktober 2015 hingga Desember 2021 adalah pengalaman yang memadukan kerja sepenuhnya remote, kekacauan startup yang tumbuh pesat, masalah performa, deployment, budaya organisasi, dan burnout
• Pada masa awal GitLab, keluhan terbesar pengguna adalah performa yang buruk dan gangguan yang sering terjadi, tetapi infrastruktur monitoring performa masih kurang, dan GitLab juga harus membuat tool yang bisa dipakai pelanggan self-hosting
• Pada 2017–2018, di tim Database, ia membuat database load balancer, dan pada periode yang sama terjadi penghapusan database produksi serta kegagalan backup, yang menyebabkan kehilangan data sekitar 6 jam dan pemulihan sekitar 24 jam
• Pada 2019–2021, tim Delivery menyatukan struktur repository terpisah untuk Community Edition dan Enterprise Edition, sehingga alur dari commit hingga deployment ke GitLab.com yang dalam kasus terburuk memakan waktu 3 minggu dipangkas menjadi beberapa jam hingga sekitar satu hari
• Pelajaran dari GitLab: skalabilitas harus menjadi bagian dari budaya; penilaian “minimum viable” tanpa data itu berbahaya; menjalankan SaaS dan self-hosting bersamaan menciptakan konflik kebutuhan; deployment cepat dan kompensasi berbasis peran itu penting

---

Sebelum Bergabung dengan GitLab dan Peran Awal

• Sebelum bergabung dengan GitLab, ia bekerja di sebuah startup kecil di Amsterdam, dan perusahaan itu berada dalam kondisi sulit sampai harus menyewakan sebagian kantor karena kekurangan dana
• Di waktu pribadi, ia mengerjakan Rubinius, dan karena ingin menstabilkannya agar layak dipakai di lingkungan produksi, ia mulai mencari pekerjaan yang memungkinkan dirinya mengerjakan hal terkait
• Ia bertemu Sytse di meetup Ruby dan workshop Rails Girls, mulai tertarik pada GitLab, lalu setelah mengirim email pada musim panas 2015, bergabung pada Oktober 2015 sebagai karyawan #28
• Tugasnya adalah meningkatkan performa GitLab, dan ia boleh memakai 20% waktu kerjanya untuk Rubinius
• Selama 6 tahun, ia berpindah melalui beberapa tim dengan otonomi besar, melapor kepada 10 manajer berbeda, dan mengalami pertumbuhan GitLab dari sekitar 30 orang menjadi sekitar 2000 orang

2015–2017: Kerja Remote dan Membangun Tool Performa

• Ia mulai bekerja di GitLab tepat sehari setelah hari kerja terakhirnya di perusahaan sebelumnya, beralih dari bekerja di kantor 5 hari seminggu menjadi kerja remote 5 hari seminggu
• GitLab awalnya adalah perusahaan sepenuhnya remote, tetapi suasananya sangat sosial, dengan pertemuan dan acara perusahaan yang sering diadakan di Amsterdam, Austin, dan kota lain
• Pada periode ini, GitLab mengalami fase pertumbuhan pertama, merekrut sekitar 100 karyawan baru; ukuran perusahaan naik dari sekitar 30-an menjadi 130-an, sempat turun ke 80-an, lalu tumbuh lagi
• Pada saat yang sama, perusahaan juga mengalami masalah khas startup yang tumbuh cepat: masalah performa serius, gangguan hampir setiap minggu, dan manajemen yang belum matang
  • “GitLab is slow” adalah keluhan terbesar pengguna
  • Keluhan tentang lambatnya GitLab juga sering muncul di Hacker News
• Perbaikan performa makin sulit karena kurangnya tool
  • Saat itu monitoring performa hanya berupa akun trial New Relic, dan dari total 15–20 server, hanya 1–2 server yang bisa dimonitor
  • Data yang masuk tidak merepresentasikan kondisi keseluruhan secara akurat
  • GitLab mensyaratkan tool yang digunakan juga tersedia bagi pelanggan self-hosting, dan jika memungkinkan bersifat open source
• Untuk meningkatkan performa, mereka harus membangun tool terlebih dahulu, dan hasilnya kemudian menjadi fitur resmi GitLab Performance Monitoring
• Profiler berat untuk lingkungan pengembangan, Sherlock, juga dibangun pada periode ini
• GitLab menyadari bahwa masalah performa tidak bisa diselesaikan oleh satu orang, lalu membentuk tim Performance dengan manajer khusus dan anggaran rekrutmen kecil
• Ia mencoba membuat Rubinius berjalan di GitLab, tetapi tidak berhasil; ditambah arah maintenance dan kontroversi di komunitas Ruby, akhirnya ia menghentikan pekerjaan tersebut

2017–2018: Tim Database, Load Balancer, dan Insiden Database Produksi

• Setelah satu setengah tahun pertama yang kacau, performa membaik secara signifikan, dan GitLab mulai menangani performa dengan lebih serius
• Cakupan tim Performance berubah dari peningkatan performa umum menjadi berfokus pada performa database, lalu menjadi tim Database
• Anggaran rekrutmen juga bertambah, dan seorang infrastructure engineer ditugaskan untuk membantu hal seperti konfigurasi database baru
• Fitur inti yang dibangun pada periode ini adalah GitLab database load balancer
  • Presentasi terkait dipublikasikan sebagai Scaling the GitLab database
  • Developer menulis query DB seperti biasa, dan load balancer merutekannya ke primary atau replica
  • Setelah operasi tulis, diterapkan sticking, yaitu tetap memakai primary sampai perubahan tercermin di semua replica
  • Fitur ini berdampak sangat positif pada performa, dan fakta bahwa penerapannya transparan tetap menjadi hal yang paling membanggakan
• Pada 31 Januari 2017, terjadi insiden penghapusan tidak sengaja pada database produksi GitLab.com
  • Detail insiden dipublikasikan sebagai GitLab.com database incident
  • Sistem backup sudah lama tidak berjalan dengan benar, dan sistem yang seharusnya memberi tahu error backup juga tidak berfungsi
  • Pemulihan dimungkinkan karena data production sekitar 6 jam sebelumnya sudah disalin ke lingkungan staging
  • Pemulihan memakan waktu sekitar 24 jam, dan terjadi kehilangan data sekitar 6 jam
• Pada periode yang sama, GitLab terus menginginkan database sharding, tetapi menurut data dan penilaian engineer saat itu, sharding tidak cocok untuk menyelesaikan masalahnya
  • Jumlah request baca di GitLab sekitar 10:1 dibanding tulis
  • Ukuran data yang disimpan juga belum cukup besar untuk membenarkan kompleksitas sharding
  • Seorang konsultan juga menyatakan bahwa sharding berlebihan bahkan untuk pelanggan dengan beban dan ukuran penyimpanan yang jauh lebih besar

2019–2021: Tim Delivery dan Perbaikan Waktu Deployment

• Sekitar 2018–2019, karena lelah dengan pekerjaan performa dan reliabilitas, ia pindah ke tim Delivery yang baru dibentuk
• Tujuan tim Delivery adalah memperbaiki proses dan tool rilis GitLab, dan kondisinya saat itu kacau
• Setelah sebuah commit masuk ke branch main, rata-rata butuh beberapa hari sampai deployment ke GitLab.com, dan dalam kasus terburuk bisa memakan waktu hingga 3 minggu
• Bottleneck terbesar adalah GitLab Community Edition dan GitLab Enterprise Edition berada di repository Git yang terpisah
  • Merge manual dan conflict resolution dibutuhkan secara rutin
  • Untuk menyelesaikan masalah ini, dilakukan pekerjaan selama beberapa bulan untuk menyatukan kedua proyek
  • Pekerjaan terkait dipublikasikan sebagai Merging CE and EE codebases
• Tim Delivery sangat memperbaiki proses rilis hingga perubahan bisa di-deploy dalam hitungan beberapa jam
  • Turun dari kasus terburuk 3 minggu menjadi sekitar satu hari dalam kasus terburuk adalah peningkatan besar
  • Namun kecepatan ini pun belum cukup cepat secara ideal

Perubahan Budaya Organisasi dan Proses Menuju Resign

• Tahun 2018 adalah tahun terakhir GitLab summit yang berfokus pada karyawan, dan sejak 2019 formatnya berubah menjadi lebih mirip konferensi tradisional yang ditujukan untuk pelanggan
• Karena pertemuan berskala lebih dari 2000 orang biayanya sangat besar, perubahan ini dapat dipahami secara finansial, tetapi dari sisi pengalaman sosial terasa kurang menyenangkan dibanding sebelumnya
• Masalah pengelolaan laptop juga menjadi faktor konflik yang berulang
  • GitLab mewajibkan atau mempertimbangkan pemasangan software remote management bagi karyawan yang mengakses resource GitLab dengan Mac perusahaan atau hardware pribadi
  • Tool yang diusulkan bersifat intrusif karena dapat digunakan untuk merekam aktivitas pengguna, dan ia merasa tidak ada jaminan yang cukup untuk mencegah penyalahgunaan
  • Banyak feedback dari karyawan sering diabaikan sampai karyawan-karyawan inti menekan perusahaan
• GitLab akhirnya memilih solusi pengelolaan laptop berbasis SentinelOne
• Perubahan budaya dan perubahan pribadi bertumpuk, membuat motivasi dan produktivitas menurun serta stres meningkat
• Setelah manajer yang mendapat penilaian baik pindah ke peran lain dan manajer baru mengambil alih tim, konflik muncul dan performance enablement plan diterapkan
  • PEP adalah tahap sebelum PIP, sebuah proses untuk menormalkan kembali hubungan dan pekerjaan
  • Awalnya ia diberi tahu bahwa proses ini untuk memperbaiki kedua pihak, tetapi dalam praktiknya ia merasa fokusnya hanya pada perubahan yang dituntut dari dirinya
  • Awalnya dijadwalkan satu bulan, lalu diperpanjang satu bulan lagi; setelah dua bulan, hasilnya dinilai memuaskan
• Setelah itu ia merasa GitLab dan dirinya bergerak ke arah yang berbeda, lalu mulai mempertimbangkan untuk keluar
• Karena IPO GitLab dan waktu pelaksanaan stock option, ia baru bisa resign pada Desember 2021
  • Saat itu di Belanda, ketika stock option dieksekusi, selisih antara exercise price dan valuasi dikenai pajak penghasilan 52%, terlepas dari apakah sahamnya sudah bisa dicairkan atau belum
  • Beban pajak yang besar membuatnya sulit mengeksekusi option sebelum GitLab go public
  • Setelah itu hukum berubah sehingga orang dapat memilih waktu pembayaran pajak, yakni saat exercise atau saat saham dilikuidasi
• Pada Desember 2021, ia meninggalkan GitLab dan mulai fokus penuh waktu pada Inko

Pelajaran dari Pengalaman di GitLab

• Skalabilitas harus menjadi budaya perusahaan

  • GitLab tidak cukup memprioritaskan skalabilitas, dan menurutnya masalah ini masih berlanjut ketika ia keluar
  • Pendapatan utama GitLab bukan berasal dari GitLab.com, melainkan dari pelanggan yang melakukan self-hosting GitLab Enterprise Edition
  • GitLab.com memakan biaya jauh lebih besar daripada uang yang dihasilkannya, sehingga fokus diarahkan ke pasar self-hosting
  • Banyak masalah performa GitLab.com tidak secara langsung berlaku bagi banyak pelanggan self-hosting
  • Banyak developer ingin meningkatkan performa, tetapi tidak diberi waktu dan resource untuk melakukannya

• Tim harus bergerak berbasis data dan berpusat pada developer

  • GitLab sangat digerakkan oleh product manager, dan fitur yang akan diimplementasikan terutama diputuskan oleh product manager dan director
  • Sebagian keputusan masuk akal, tetapi sebagian lain terasa seperti harus membuat sesuatu hanya karena dianggap ide bagus di Hacker News
  • Menurutnya, hasilnya bisa lebih baik jika struktur hierarki yang lebih sederhana diperkenalkan lebih awal, team lead diberi kewenangan lebih besar, dan mereka lebih banyak berinteraksi dengan pengguna
  • Menurutnya, peran product manager seharusnya berkontribusi secara teknis dalam membangun produk sekaligus menjadi penghubung antara tim dan pengguna

• Sulit menilai “minimal viable” tanpa data

  • Salah satu prinsip inti GitLab adalah selalu memulai dengan minimal viable change
  • Masalahnya, setiap orang memiliki definisi “minimal” yang berbeda
  • Sebagian tim menganggap performa atau usability yang baik sebagai syarat viable, tetapi tim lain tidak menganggapnya penting
  • Akibatnya, menurutnya, banyak fitur dibuat tetapi tidak berguna bagi pengguna
  • Serverless platform yang tidak diminta dan akhirnya dihentikan
  • Dukungan pengelolaan Kubernetes cluster yang tidak berfungsi selama 3 minggu tetapi tidak disadari siapa pun
  • Solusi chatops yang dibangun di atas CI alih-alih memakai solusi yang sudah ada
  • Fitur requirements management yang hanya bisa membuat dan melihat, tetapi tidak bisa mengubah atau menghapus
  • GitLab melakukan user survey setiap kuartal dan sebagian tim punya akses ke data partisipasi pengguna, tetapi berdasarkan ingatan dan percakapan dengan mantan rekan kerja, data ini lebih sering dipakai sesekali daripada menjadi inti workflow tim

• SaaS dan self-hosting sulit dijalankan bersama

  • GitLab menyediakan instalasi self-hosting dan SaaS sekaligus
  • Kedua model memiliki struktur pendapatan, kebutuhan, dan cara penerapan update yang berbeda
  • SaaS membutuhkan deployment cepat serta pemrosesan data dan workload berskala besar di infrastruktur terpusat
  • Sebagian besar instance self-hosting jauh lebih kecil daripada SaaS, sehingga masalah dan solusi SaaS tidak bisa diterapkan begitu saja
  • Akibatnya, di banyak bagian platform muncul kebutuhan untuk mempertimbangkan dua code path: untuk SaaS dan untuk self-hosting
  • Jika fokus pada salah satu, SaaS atau self-hosting, semua perhatian bisa diarahkan pada pengalaman yang sesuai dengan model operasi tersebut

• Lebih banyak orang tidak menjamin hasil yang lebih baik

  • GitLab merekrut banyak orang selama bertahun-tahun, dan kini mempekerjakan lebih dari 2000 orang
  • Jumlah developer pastinya tidak diketahui, tetapi dari melihat sekilas halaman tim, diperkirakan setidaknya ratusan orang
  • Menambah orang ke proyek tidak serta-merta meningkatkan produktivitas dan hasil, dan ini juga berkaitan dengan “The Mythical Man-Month”
  • Tanpa data, menurutnya sebagian besar perusahaan cukup dengan 20 developer atau kurang; sebagian membutuhkan 20–50 orang, dan hanya sedikit sekali yang membutuhkan 50–100 orang
  • Jika jumlah developer melebihi 100, menurutnya perlu dipikirkan apakah cakupan produk sudah terlalu melebar
  • Penilaian ini terkait developer software; bidang dengan biaya sinkronisasi yang relatif berbeda seperti produksi custom hardware, sales, dan support dianggap pengecualian

• Penilaian terhadap Ruby on Rails bersifat dua sisi

  • GitLab dibuat dengan Ruby dan Ruby on Rails, dan kombinasi ini sangat berkontribusi pada kesuksesan GitLab
  • Pada saat yang sama, ketika proyek membesar dan kontributor dengan berbagai tingkat pengalaman bertambah, Rails dapat memudahkan terciptanya kode berperforma buruk
  • Contoh masalah yang umum adalah N+1 query problem
  • ActiveRecord di Rails memiliki fitur untuk menyelesaikan ini, tetapi bersifat opt-in
  • Jika developer melupakannya, query terjadi per row dan menimbulkan masalah performa
  • Banyak masalah performa yang diselesaikan selama beberapa tahun awal GitLab adalah N+1 query
  • Ruby sendiri juga bahasa yang bagus, tetapi sifatnya yang banyak memakai meta programming menjadi sulit dalam proyek besar
  • Go, Rust, dan Node.js bisa lebih efisien daripada Ruby, tetapi menurutnya tidak ada framework yang sekuat Ruby on Rails
  • Python dan Django juga bisa menjadi pilihan, tetapi kemungkinan akan mengalami sebagian masalah yang sama seperti Ruby dan Rails

• Waktu deployment penting bagi keberhasilan organisasi

  • Menurutnya, setelah code di-push ke branch atau tag target deployment, code seharusnya bisa di-deploy dalam maksimal satu jam
  • GitLab butuh sekitar 4 tahun untuk mendekati kondisi ini, dan masih ada perjalanan yang tersisa
  • Deployment cepat membantu respons terhadap gangguan
  • Jika deployment memakan waktu berjam-jam, hot-patch mungkin diperlukan
  • Deployment cepat juga memengaruhi motivasi
  • Ada kepuasan ketika perubahan yang dibuat bisa benar-benar dilihat dan digunakan
  • Situasi ketika perubahan yang dikerjakan selama berminggu-minggu baru di-deploy 2 minggu kemudian menurunkan semangat
  • Organisasi harus sangat agresif dalam mengurangi waktu deployment dan waktu yang dihabiskan test suite dalam proses deployment
  • Intinya bukan semua test dan deployment harus berada di bawah waktu tertentu, tetapi memprioritaskan deployment secepat mungkin dalam batas yang diizinkan kebutuhan bisnis

• Gaji berbasis lokasi bersifat diskriminatif

  • Gaji GitLab dipengaruhi beberapa variabel, salah satunya lokasi
  • Jika perusahaan memiliki kantor fisik dan harus merekrut di wilayah tertentu, penyesuaian berbasis lokasi dapat dipahami; tetapi untuk perusahaan sepenuhnya remote, menurutnya tidak ada alasan yang sah untuk membayar dua orang dengan pengalaman dan tanggung jawab yang sama secara berbeda hanya karena tempat tinggal
  • Saat keluar, gaji yang ia terima di Belanda adalah sekitar €120.000 per tahun sebelum pajak, atau sekitar €8.500 per bulan
  • Jika tinggal di Bay Area, menurutnya ia akan menerima setidaknya dua kali lipat, mungkin lebih
  • Solusinya adalah memberikan kompensasi berdasarkan kebutuhan peran, bukan lokasi pelamar
  • 0xide Computer Company disebut sebagai perusahaan yang membayar jumlah yang sama, bukan berbasis lokasi
  • Topik terkait dibahas dalam Compensation as a Reflection of Values

Kesimpulan

• Masa bekerja di GitLab adalah campuran pengalaman yang sangat positif dan negatif
• Ia sangat bangga atas pencapaian di berbagai tim dan orang-orang yang pernah bekerja bersamanya
• Ia menyayangkan bahwa sekitar satu tahun terakhir membuat keseluruhan pengalaman terasa pahit
• Ia tidak menyesal pernah bekerja di GitLab, dan jika bisa mengulanginya, ia akan melakukan beberapa hal secara sedikit berbeda berdasarkan hindsight
• Meski memiliki kekurangan, ia menganggap GitLab jauh lebih baik daripada banyak perusahaan lain, dan tetap merekomendasikannya sebagai tempat yang layak untuk bekerja

[GN⁺]

Pendapat di Hacker News

• Perbandingan bahwa jika perusahaan menurunkan gaji berdasarkan warna kulit atau gender itu menjadi masalah besar, tetapi mengapa boleh jika berdasarkan tempat tinggal, perlu dipikirkan lebih jauh
  Warna kulit·gender dan tempat tinggal berbeda dalam hal apakah bisa diubah dan apakah benar-benar terkait dengan pekerjaan
  Tempat tinggal berkaitan dengan pekerjaan karena perusahaan harus menanggung pendirian entitas lokal, memahami sistem peradilan dan perpajakan, zona waktu, biaya perjalanan dinas, dan sebagainya
  Apakah kompensasi berdasarkan wilayah itu benar atau tidak bisa didiskusikan, tetapi jika dibandingkan dengan diskriminasi ras dan gender, GitLab seolah-olah dijadikan organisasi rasis dan seksis, sehingga diskusinya cepat berakhir

  • Jika melihat teks aslinya, gaji tahunannya sekitar €120.000, dan itu disebut sebagai gaji yang bagus menurut standar Belanda, serta memungkinkan kerja sepenuhnya dari rumah
    Ia mengatakan kalau tinggal di Bay Area, ia bisa mendapat lebih dari dua kali lipat, dan tidak adil hanya karena tempat tinggalnya berbeda, tetapi tampaknya tidak ada poin korban yang bisa didapat di sini
    Ini lebih mirip argumen yang kurang memahami ekonomi
  • Setelah bekerja di berbagai negara, orang akan cepat belajar bahwa mustahil membandingkan gaji antarwilayah begitu saja berdasarkan angka nominal
    Gaji yang saya terima sekarang di AS kira-kira dua kali lipat dibanding saat di Inggris, tetapi standar hidupnya mirip; dalam beberapa hal lebih buruk dan dalam beberapa hal lebih baik
    Penulis asli pun jika pindah ke Bay Area, meski kompensasinya lebih tinggi, kemungkinan besar standar hidupnya justru menurun
    Bukan hanya pendapatan, tetapi juga jaminan sosial, pajak, hingga budaya perlu dipertimbangkan, dan saya bahkan bersedia menerima pemotongan gaji besar untuk kembali ke Eropa agar hidup lebih nyaman
  • Saya rasa penulis asli melihat banyak hal secara keliru
    Motivasi GitLab untuk kompensasi berdasarkan wilayah dijelaskan di https://handbook.gitlab.com/handbook/total-rewards/compensat..., dan terlihat cukup masuk akal
    Jika orang di Filipina atau Ukraina pun dibayar setara Bay Area, mereka bisa terikat oleh borgol emas dan tidak bisa pergi bahkan ketika seharusnya pergi, lalu mengalami burnout
    Sebaliknya, jika membayar gaji median global, perusahaan tidak akan bisa merekrut orang di California atau London
    Klaim bahwa manajer produk tidak diperlukan dan tidak boleh ada lebih dari 100 developer untuk satu produk juga kontroversial
    Penulis asli tampak seperti engineer hebat dengan otonomi tinggi, yang mungkin akan jauh lebih bahagia dan sukses di startup yang relatif kecil
    Jika ia tidak perlu menunggu perubahan aturan pajak, mungkin ia bisa pergi lebih awal dan menulis kisah pengalaman yang baik
    Jika selain saham ia juga menerima kompensasi $300k di Amsterdam, patut dipikirkan juga betapa sulitnya meninggalkan perusahaan
  • Alasan utama perusahaan yang berawal dari Silicon Valley atau wilayah berbiaya hidup tinggi merekrut di wilayah berbiaya hidup rendah adalah karena mereka bisa memperoleh nilai yang lebih dari sebanding dengan kompensasi yang lebih rendah
    Jika kompensasi yang sama di seluruh dunia diwajibkan, perusahaan kemungkinan akan memilih merekrut lokal saja karena keuntungan offsite, zona waktu yang sama, dan komunikasi
    Terutama dalam kondisi ekonomi ketika di wilayah berbiaya hidup tinggi pun ada banyak kandidat yang ingin direkrut
    Ini bisa berubah ke depannya, tetapi berguna untuk melihat struktur insentif yang realistis
    Ada juga risiko yang ditanggung perusahaan saat merekrut dari negara lain, dan ini juga berefek meninggalkan pengetahuan serta benih perusahaan masa depan di wilayah setempat
  • Ini adalah konsekuensi langsung dari kerja dari rumah/kerja jarak jauh
    Bekerja dari kantor memberi karyawan daya tawar gaji berkat biaya hidup di wilayah tersebut, tetapi dalam perusahaan dan budaya yang sepenuhnya remote, perusahaan bisa merekrut dari mana saja dan membayar gaji yang mendekati penyebut umum terendah
    Kerja jarak jauh membuat semua orang seperti kontraktor independen yang bersaing dengan talenta dari seluruh dunia, sedangkan kerja kantor membuat orang terutama bersaing dengan orang-orang di wilayah yang sama

• Tampaknya ini kisah karyawan ke-28 yang awalnya melapor langsung ke CEO, lalu makin lama makin banyak manajer disisipkan di atasnya, sampai salah satu dari mereka memasukkannya ke PEP, ia menangkap sinyalnya, lalu pergi.
  Alurnya cukup standar, dan mungkin salah satu alasan mengapa orang di perusahaan besar sulit melakukan hal-hal besar dengan baik.
  Bahkan jika Anda memulai proyek di dalam perusahaan dan membuatnya sukses, perusahaan akan menyisipkan orang-orang di atas Anda, dan pada akhirnya Anda bisa menjadi karyawan ke-n di proyek yang Anda mulai sendiri, lalu dibilang kurang berkinerja.

  • Ini juga bisa dibaca sebagai tipe karyawan awal yang sangat sulit dikelola.
    Mereka hanya ingin mengerjakan hal yang menyenangkan dan menarik, pada akhirnya bersikap sangat keras soal hal-hal yang tidak penting, dan jika individual contributor yang dekat dengan CEO tidak mengakui pilihan manajer, itu menjadi mimpi buruk untuk dikelola.
    Mereka bisa bergerak ke sana kemari dan menimbulkan masalah tanpa memikul tanggung jawab atas keputusan.
    Keamanan endpoint dan penggunaan perangkat pribadi adalah salah satu petunjuknya.
    Budaya permisif seperti ini tidak bisa diskalakan karena biaya kepatuhan regulasi dan produktivitas pengembangan.
    Sulit melepaskan developer lama dari distro Linux favoritnya, tetapi untuk pekerjaan, memang lebih tepat memakai komputer kerja dan membiarkan perusahaan mengelola pembaruannya.
    Cerita soal backup database juga sama; jika itu tim database, backup adalah pekerjaan prioritas nomor satu.
    “Tidak ada backup” tidak bisa dilewatkan begitu saja dengan kalimat pasif, dan terlihat seolah mereka lebih tertarik pada perdebatan arsitektur sharding daripada menjaga situs tetap berjalan sehari-hari.
    Kesimpulan bahwa GitLab tidak cukup berinvestasi pada performa produk hosting juga, jika produk itu merugi besar, mungkin wajar saja untuk tidak memasukkan lebih banyak sumber daya.
    Yang perlu dilakukan adalah meyakinkan dengan alasan bisnis nyata mengapa pekerjaan itu lebih penting dan menghasilkan uang, bukan sekadar engineering yang menarik.
  • Saya juga sedang mengalami hal serupa di perusahaan saat ini.
    Seorang manajer memulai proyek yang sukses bersama saya, tetapi eksekutif dengan rakus menyeret politik dan dilema sosial ke dalamnya, menyisipkan lapisan manajemen, dan mencoba menggantikan saya serta manajer itu.
    Saya belajar mengapa kita tidak boleh benar-benar peduli pada pekerjaan, dan karena itu rasanya proyek tersebut akan rusak dan dibubarkan.
  • Kisah seperti ini adalah anekdot n=1, dan ada masalah karena kita hanya mendengar satu sisi cerita.
    Di sini ada suasana yang mengasumsikan bahwa karyawan tersebut benar-benar high performer, tidak membutuhkan manajer, dan tidak pantas menerima PEP, tetapi itu bukan asumsi yang aman.
    Saya pernah melihat karyawan awal di startup tahap awal yang tidak mampu, atau tidak mau, tumbuh mengikuti kecepatan perusahaan dan perannya yang membesar.
    Mereka sering tetap dipertahankan karena penghormatan atas kontribusi masa lalu, pengetahuan historis yang sulit digantikan, serta hubungan dengan founder dan karyawan awal yang kini menjadi pemimpin.
    Namun fakta bahwa seseorang adalah karyawan awal dan terlibat dalam proyek awal yang penting tidak berarti ia terus menjadi orang terbaik atau paling cocok untuk memegang pekerjaan itu.
    Mereka mungkin sangat hebat menjalankan sesuatu dengan tambal sulam, cron job, dan intervensi manual, tetapi di perusahaan besar cara operasi seperti itu bisa sama sekali tidak cocok.
    Jika mereka tidak beradaptasi, atau tidak puas karena harus bekerja dengan cara perusahaan besar, dampak buruknya lebih besar daripada bantuannya.
    Setiap perusahaan awal punya karyawan awal yang tidak ikut tumbuh bersama perusahaan, tetapi itu bukan satu-satunya atau hasil akhir yang paling umum.
    Di GitLab juga ada banyak karyawan yang sudah lama bekerja, tetapi kita tidak mendengar suara mereka dalam tulisan blog bernada keluhan, jadi bias seleksi perlu dipertimbangkan.
    Saya sudah lama memakai GitLab, dan produknya terus berkembang, jadi saya tidak setuju dengan klaim bahwa produknya mandek.
  • Sebanyak apa pun Anda berbicara dan menunjukkan bukti, statistik mentah dan statistik olahan, atau mengajukan argumen dari otoritas, jika para direktur hanya peduli pada fitur, semuanya terasa seperti berteriak ke udara kosong.
    Baru tiga tahun kemudian, ketika mereka melihat rilis terus gagal, itu menjadi masalah; tetapi rasanya bukan karena pengaruh saya, melainkan seperti hasil seseorang mencari “cara mencegah kegagalan rilis” di Google.
    Saya tidak tahu solusinya, dan sekarang saya kembali mengalami hal yang sama dengan topik lain.
  • Sebagai karyawan yang sangat awal, saya sangat paham perasaan ketika lead dan manajer terus masuk di atas kita, dan satu per satu mekanisme yang dulu membuat kita bisa bekerja efektif di tahap awal menghilang.
    Pada awalnya, kami cukup menyelesaikan hal-hal yang perlu dilakukan, tetapi kemudian setiap langkah harus melewati posisi manajer baru yang disisipkan, dengan alasan memastikan kami tidak melakukan hal yang salah.
    Itu terjadi terlepas dari ide dan kontribusi awal yang memungkinkan perusahaan tumbuh.
    Saya penasaran apakah latar belakang masih tersisanya issue lama bertahun-tahun terkait GitLab CI juga berkaitan dengan hal ini.
    Dilihat dari luar, GitLab tampak sudah sepenuhnya kehilangan kemampuan membuat hal-hal hebat, dan memberi kesan tidak mau memperbaiki bug yang sudah bertahun-tahun terus berulang.

• Bagian yang menyebut karyawan diizinkan memakai komputer pribadi nyaris mengejutkan
  Sekecil apa pun organisasinya, seharusnya perusahaan menyediakan perangkat milik perusahaan dan mewajibkan semua pekerjaan perusahaan dilakukan di perangkat itu
  Bagi perusahaan, ini memberi keuntungan besar dari sisi kontrol kekayaan intelektual; bagi karyawan, ini sangat membantu memisahkan jam kerja dan waktu pribadi; biayanya juga tidak terlalu besar

  • Jika Anda terutama memakai Linux, saya menyarankan membuat lingkungan eksekusi minimal yang bisa dijalankan dengan mudah di tempat seperti VirtualBox atau Parallels
    Ke mana pun pergi, Anda bisa tetap memakai kumpulan alat yang diinginkan, dan kemampuan untuk menghapus serta membuatnya kembali dengan cepat juga bagus untuk men-debug masalah semacam “di komputer saya bisa/tidak bisa”
    Di satu ujung ada pendekatan yang mengandalkan ingatan, dan di ujung lain ada cara membuat build yang sepenuhnya dapat direproduksi di mana saja dengan https://nixos.org/
    Di antaranya juga banyak pilihan, dan saya pernah melihat orang mengelola sekumpulan file Ansible yang memasang hal-hal yang diperlukan dengan host: localhost
    Saya memakai versi Ubuntu terbaru dan memelihara beberapa skrip shell [1] yang memasang 80% dari hal yang saya inginkan pada instalasi baru
    Jika ingin mengambil pendekatan yang lebih ilmiah, Anda bisa memasang sesuatu seperti https://atuin.sh/ untuk membuat statistik program yang benar-benar sering dijalankan berdasarkan riwayat shell jangka panjang
    [1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
  • Jika memakai perangkat pribadi, sulit memaksakan enkripsi seluruh disk, dan sulit pula menghindari kebocoran saat karyawan keluar
    Ini bukan solusi sempurna, tetapi setidaknya jika perangkatnya milik perusahaan, kebocoran berarti tindakan jahat atau akibat ketidakmampuan karena memindahkan data sensitif melalui jalur yang tidak disetujui
  • Saya bukan pengacara, jadi anggap dengan hati-hati, tetapi kemungkinan karyawan pun lebih baik diwajibkan memakai perangkat perusahaan
    Jika perusahaan digugat, isi perangkat pribadi pun bisa menjadi sasaran berbagai subpoena
  • Sebagian besar sistem operasi mendukung banyak pengguna
    Mewajibkan perangkat terpisah tidak otomatis memberi keuntungan bagi pengguna dari sisi keseimbangan kerja-hidup; itu hanya merepotkan
  • Memisahkan komputer kerja dan pribadi memang bisa membantu, tetapi secara pribadi menurut saya hanya sedikit membantu
    Perilaku memisahkan waktu kerja dan pribadi terutama ditentukan oleh kebiasaan, kemampuan, dan pada akhirnya keputusan diri sendiri

• Dulu saya merasa gaji berdasarkan wilayah adalah diskriminasi, tetapi sekarang saya sebagian besar sudah lepas dari pandangan itu
  Pada akhirnya, itu berarti menuntut gaji SF, dan orang India akan menuntut gaji Belanda atau SF
  Jika begitu, kemungkinan besar akan muncul perlombaan menuju titik terendah
  Fakta sederhananya adalah masing-masing orang memperoleh cukup untuk hidup baik di wilayahnya sendiri
  Jika ingin lebih, pindahlah; jika tidak pindah, pasti ada alasan yang layak
  Semua orang menginginkan gaji SF dan biaya hidup Indiana atau India, tetapi karena alasan yang jelas, itu sulit berlaku

  • Sebaliknya, ada juga perusahaan yang tidak menerapkan kompensasi berdasarkan wilayah
    Jika diterima, entah Anda berada di San Francisco, Poland, atau Indonesia, Anda mendapat gaji tingkat AS
    Posisi seperti ini sangat kompetitif
    Karena mereka membuka pintu ke seluruh dunia dan berkata “tunjukkan kemampuanmu”, mereka bisa melihat kumpulan pelamar dan talenta yang jauh lebih besar, dan di dalamnya ada banyak talenta luar biasa dari negara miskin yang sangat pintar dan berdaya dorong tinggi
    Begitulah cara kerja penawaran dan permintaan
    Jika Anda bersedia membayar lebih, biasanya Anda akan merekrut kandidat dengan level lebih tinggi
  • Argumen ini membuat seolah-olah tingginya biaya hidup di SF adalah penyebab gaji tinggi, tetapi sebenarnya alasan biaya hidup Bay Area tinggi adalah terkonsentrasinya perusahaan dengan efisiensi modal tinggi dan permintaan tenaga kerja terampil, serta karena sebagian besar wilayah Valley sama sekali enggan membangun gedung tinggi berkepadatan tinggi
    Saya mengenal cukup banyak orang yang bekerja jarak jauh dari berbagai negara bagian AS dan menerima gaji setara SF
    Tentu saja itu mungkin
    SF juga tidak boleh terlalu percaya diri
    Detroit pun dulu adalah Motor City sekaligus Music City, dan merupakan pusat budaya serta teknologi kelas dunia, tetapi kompetensi intinya terguncang oleh tenaga kerja di wilayah lain yang lebih murah dan efisien
  • Itu cara melihat yang sepenuhnya keliru
    Yang dituntut adalah upah yang sama untuk pekerjaan yang sama
    Jika anggota tim mengerjakan pekerjaan yang sama, tetapi orang lain menerima penuh sementara Anda hanya menerima sebagian, itu sangat tidak benar
    Kontribusi terhadap tim tidak bergantung pada lokasi Anda saat ini
    Berapa banyak waktu yang Anda habiskan untuk komuter juga tidak mengubah ekspektasi output
    Jika lokasi kantor terlalu mahal, perusahaan seharusnya menyelesaikannya dengan mencari lokasi yang lebih murah, bukan karyawan yang harus mensubsidi lokasi kantor perusahaan yang buruk
  • Pernyataan “biaya perusahaan sama saja, baik membayar $100.000 kepada karyawan Bay Area maupun karyawan Filipina” tidak benar
    100k yang diterima karyawan dan biaya bagi perusahaan itu berbeda
    Di setiap negara, pajak tambahan, jaminan sosial, dan tunjangan yang harus ditanggung perusahaan berbeda-beda, dan dalam banyak kasus diperlukan badan hukum lokal atau entitas bisnis virtual serta sumber daya pendukung kepatuhan hukum setempat
    Saya sendiri bekerja dalam peran global di perusahaan multinasional dan berada di pihak karyawan yang menerima gaji berdasarkan standar lokal, tetapi ada lebih banyak hal yang perlu dipertimbangkan daripada yang tampak dari luar
  • Pendekatan koperasi bernama Igalia menarik: https://wingolog.org/archives/2013/06/25/time-for-money
    Pada dasarnya, mereka menyesuaikan bukan berdasarkan biaya perekrutan, melainkan biaya hidup, sambil tetap menargetkan gaji yang setara

• Manajer yang buruk adalah momok industri ini
  Sebaliknya, banyak startup lahir karena pendirinya pernah mengalami manajer yang buruk di pekerjaan sebelumnya
  Ini mengingatkan saya pada kisah traitorous eight dan Fairchild Semiconductors
  Secara pribadi, jika saya tidak bertemu manajer nonteknis, politis, dan suka membalas dendam di pekerjaan sebelumnya, rasanya saya tidak akan punya motivasi untuk memulai startup saya sendiri
  Kalau dipikir-pikir, saya bahkan merasa seandainya saya bertemu manajer seburuk itu lebih awal di awal karier, itu mungkin lebih baik

  • Akan bagus jika ada cara menandai perusahaan yang memiliki budaya manajemen toksik tanpa merusak privasi atau langsung disensor
    Akan bagus juga jika kita bisa lebih mudah pindah ke perusahaan yang benar-benar membutuhkan kemampuan teknis kita tanpa beban proses HR

• Ada klaim bahwa seluruh model pemrograman Ruby didasarkan pada premis bahwa sebagian besar waktu dihabiskan untuk menunggu I/O atau jaringan, sehingga kecepatan bahasa tidak penting
  Namun sekarang, di sisi Node.js dan JVM ada model yang melakukan hal lain atau menangani lebih banyak request saat menunggu I/O/jaringan
  Pada 2024, memakai Ruby/Rails bisa jadi pemborosan, tetapi bisa menjadi pilihan bagus untuk aplikasi enterprise dengan jumlah pengguna terbatas, kasus ketika kecepatan pengembangan benar-benar paling penting, atau prototipe cepat untuk validasi pasar
  Rails adalah framework yang hebat dan produktivitasnya sangat tinggi, tetapi proyek Rails yang sudah berusia 2–3 tahun selalu sulit dipelihara

  • Ruby sekarang memiliki struktur terkait async seperti Fibers dan Ractor
    Proyek Rails tidak lebih sulit daripada proyek Django atau Express
    Codebase apa pun membutuhkan disiplin dan perawatan kebun yang konsisten agar gulma tidak tumbuh
    Jika Ruby dan Rails punya kelemahan, itu masih performa bahasa mentah serta kebutuhan/penggunaan memori yang lebih tinggi, sehingga kurang menarik untuk pekerjaan yang membutuhkan latensi rendah atau jejak memori kecil
  • Saya ingin membantah pernyataan bahwa produktivitasnya tak tertandingi
  • Rails baik-baik saja untuk 99% use case
    Berdasarkan pengalaman, masalah biasanya muncul saat trafik tiba-tiba berfluktuasi besar, atau ketika ada sangat banyak pengguna aktif yang memakai websocket; untuk sisi websocket, sebagian besar terselesaikan dengan anycable
    Namun sangat sedikit produk yang akan mencapai batas seperti itu, dan kalaupun mencapainya, itu bisa diselesaikan
    Stripe, GitHub, dan Shopify adalah contoh utama bahwa Rails dapat diskalakan dengan baik dalam berbagai cara
  • Sepertinya yang dimaksud bukan Ruby, melainkan Ruby on Rails, dan keduanya tidak memiliki “seluruh model pemrograman” yang didasarkan pada pemikiran tentang I/O
    Pendorong besar Rails adalah pemikiran DHH tentang kebahagiaan developer, dan ini sangat terkait dengan kecepatan pengembangan
    Diskusi I/O di komunitas Rails ada karena itu penting untuk menjalankan web server, bukan karena itu satu-satunya atau fokus utama dalam keputusan bahasa maupun framework
    Jika tujuannya memaksimalkan penggunaan CPU web server, di Rails pun itu bisa dilakukan dengan menjalankan beberapa proses, dan ini sudah lama digunakan dengan cara yang mirip menjalankan beberapa thread di JVM
    Mungkin kurang nyaman, tetapi itu model yang sudah dipakai sejak 90-an, dan karena web request biasanya berjalan secara independen, komunikasi antarproses pun sering kali bukan masalah besar
    Menggeneralisasi sebagai “pemborosan” itu terlalu kasar
    Menulis aplikasi dengan Rust juga bisa menjadi pemborosan tergantung situasinya; semuanya bergantung pada di mana tekanannya berada
    Pada tahap awal, tidak berhasil merilis jauh lebih mengkhawatirkan, dan bahkan pada tahap menengah hingga akhir, kecepatan developer adalah salah satu faktor yang paling sulit diskalakan
    Sebagai CTO perusahaan yang memakai backend Rails dan frontend React, kecepatan pengembangan sangat penting, dan kecepatan pengembangan Rails terus menjadi keunggulan besar
    Memang ada masalah scaling, tetapi 99%-nya bukan masalah Rails, melainkan masalah database

• Saya menganggap perusahaan yang ingin membayar engineer berdasarkan lokasi sebagai bentuk diskriminasi lain
  Mereka seharusnya membayar berdasarkan kemampuan karyawan, bukan berdasarkan lokasi
  Aturan pemerintah mengatakan jangan mendiskriminasi berdasarkan gender, agama, orientasi seksual, dan sebagainya; lalu apakah diskriminasi gaji berdasarkan lokasi itu adil?
  Saya pernah melihat teman yang pindah dari Europe ke Asia dalam peran yang sama menerima bayaran lebih rendah hanya karena lokasinya berubah, padahal orangnya sama dan perannya sama

  • Kenyataannya, karyawan hanya dibayar jumlah minimum yang diperlukan agar mereka mau masuk kerja
    Jika mereka pindah ke pasar yang kurang kompetitif sehingga lebih sulit mendapatkan pekerjaan lain, kemungkinan mereka tetap masuk kerja dengan gaji lebih rendah menjadi lebih besar
    Meski remote membuatnya tampak tidak terikat pada pasar lokal, pemerintah sering kali memasang hambatan besar terhadap perekrutan internasional, sehingga negara tertentu bisa menjadi pasar yang kurang kompetitif
    Jika seseorang melakukan pekerjaan yang sama di perusahaan yang sama tetapi gajinya turun karena pindah ke negara lain, hampir pasti itu sebabnya mereka menerima pemotongan tersebut
  • Saya tidak setuju
    Menurut saya, perusahaan harus membayar berdasarkan kemampuan karyawan untuk menikmati kenyamanan dan kesehatan, bukan berdasarkan ukuran nilai universal tertentu
    Saya rasa nilai universal semacam itu mustahil
    Argumen bahwa pembayaran hanya harus berdasarkan kemampuan tanpa sengaja merusak komunitas, dan melalui ketimpangan memperburuk gentrifikasi serta penghancuran kohesi sosial
    Lokasi itu penting
  • Perbedaan gaji justru bisa dianggap lebih tidak diskriminatif
    Pembayaran itu diberikan agar orang mendapatkan kualitas hidup yang sama, jenis tempat tinggal yang sama, kesempatan menghidupi keluarga, dan kesempatan menyekolahkan anak ke sekolah yang sebanding
    Biaya untuk hal-hal ini berbeda di tiap negara, sehingga pendapatan yang dibutuhkan juga berbeda
  • Saya tidak mengerti mengapa diasumsikan bahwa pembayaran harus berdasarkan kemampuan
    Perusahaan membutuhkan kemampuan tertentu, dan mereka hanya membayar sebesar nilai yang ditetapkan pasar untuk kemampuan itu, tidak lebih
    Karena pasar memberi harga berbeda untuk kemampuan yang sama berdasarkan lokasi, gaji pun berbeda
  • Diskriminasi adalah soal hal-hal yang tidak bisa dipilih seseorang
    Agama adalah pengecualian yang agak ambigu, tetapi adil atau tidak, ini bukan diskriminasi

• Jika GitLab.com selalu jauh lebih mahal biayanya daripada uang yang dihasilkannya, dan perusahaan terutama menghasilkan uang dari pelanggan self-hosted GitLab Enterprise Edition, saya mempertanyakan apakah kurang berinvestasi pada skalabilitas benar-benar sebuah kesalahan
  Prioritas utama perusahaan adalah berinvestasi pada hal yang menghasilkan uang, bukan pada hal yang membuat rugi
  Memang mungkin ada penilaian tingkat tinggi bahwa gitlab.com yang lebih berkinerja baik dapat membawa lebih banyak pelanggan dan reputasi, tetapi jika bisnis sebenarnya adalah menjual software self-hosted, masuk akal untuk memusatkan sumber daya pengembangan ke sana

  • Jika GitLab.com adalah produk yang merugi, saya tidak mengerti mengapa harganya sama dengan opsi self-hosted
    Saya pernah benar-benar membeli lisensi GitLab, lalu setelah tahu biaya kursinya sama baik hosting diserahkan ke GitLab maupun kami jalankan sendiri, saya bertanya-tanya mengapa kami harus menanggung biaya infrastrukturnya
  • Saya paham maksud penulis asli
    Kalau GitLab.com akan dikerjakan setengah-setengah, dalam jangka panjang mungkin lebih baik melakukannya dengan benar, atau menghapus produk itu dan berfokus hanya pada pelanggan self-hosting seperti GitLab Enterprise Edition
    Namun tidak ada satu pun di manajemen yang ingin mengambil keputusan seperti itu
    Akibatnya produk dijalankan sebagai sesuatu yang setengah matang
    Bagi orang-orang yang benar-benar peduli pada produk itu sendiri, situasi seperti ini bisa membuat frustrasi
    Setiap kali developer baru masuk, mereka akan berkata “kita harus lebih memperhatikan skalabilitas”, dan para senior akan menjawab “ya ya, kami tahu…”
  • Jika output perusahaan dirancang dengan cara merilis produk yang cacat, maka itu memang sebuah kesalahan
  • Mungkin karena banyak departemen IT menganggap on-premise lebih aman, dan dengan begitu mereka mendapatkan ilusi bahwa kebocoran source code bisa dicegah

• Secara ekonomi, jika developer Amsterdam memberikan nilai yang sama dengan developer Bay Area, kemungkinan besar memang tepat untuk memberi gaji yang sama
  Harga pasar lokal developer Amsterdam memang lebih rendah, tetapi kita sedang membangun perusahaan global dan bersaing dengan perusahaan global lain
  Saat ini mungkin bisa mendapatkan developer Amsterdam dengan harga diskon, tetapi pada akhirnya pesaing akan menawarkan jumlah yang lebih mendekati nilai mereka, atau mereka akan pergi untuk mengerjakan urusan mereka sendiri
  Saya rasa perusahaan-perusahaan terkuat pada akhirnya akan membayar talenta dengan kompensasi tanpa memandang lokasi
  Pada akhirnya yang penting adalah nilai yang diberikan
  Jika Anda punya codebase Ruby besar seperti GitLab dan ingin menjual ke perusahaan besar yang menekankan performa dan keandalan, saya rasa Anda akan membayar orang seperti ini lebih dari €120k per tahun
  Sebagian besar engineer yang menekankan performa, type safety, dan keandalan tidak tertarik pada Ruby, jadi harga pasar untuk kombinasi teknologi itu jelas lebih tinggi
  Saya tidak tahu apakah levelnya sampai $500k per tahun seperti di Bay Area, tetapi perusahaan kuat yang menginginkan talenta papan atas akan kehilangan talenta jika tidak mengaitkan kompensasi dengan nilai yang diberikan, bukan lokasi

  • Atau harus merekrut dua kali lebih banyak orang seperti itu

• Saya melihat waktu yang dibutuhkan untuk deploy kode sebagai salah satu metrik terpenting, mungkin yang paling penting, untuk mempertahankan kecepatan developer saat startup berkembang
  Context switching adalah salah satu aktivitas paling mahal dalam keseharian developer, tetapi juga salah satu yang paling mudah diabaikan
  Para manajer suka menyusun jadwal tim sesuai jadwal mereka sendiri, tetapi ini sering mengganggu “maker schedule” para individual contributor
  Banyak organisasi menyadari hal ini dan berfokus pada biaya context switching dari sisi jadwal, tetapi bagi developer, waktu dari build hingga deploy sama pentingnya, atau bahkan lebih penting