Meninggalkan LinkedIn

• Ketika melakukan pekerjaan dengan benar berbenturan dengan kecepatan tinggi perusahaan, apa pilihan Anda?
• Kisah insinyur Chris Krycho yang memilih opsi kedua: tetap berpegang pada keyakinannya dan pergi mencari pekerjaan yang sesuai dengan prinsipnya, alih-alih berkompromi.
• Chris pada akhirnya meninggalkan LinkedIn untuk mengejar pekerjaan yang selaras dengan prinsip-prinsipnya.
• Ringkasan dari hal-hal yang ia ceritakan di podcast.
• Kisahnya menyoroti ketegangan antara "kebutuhan akan inovasi" dan "pentingnya kesehatan proyek".

Hari pertama Chris Krycho di LinkedIn

• Chris bergabung dengan LinkedIn pada akhir Januari 2019. Ia menjalani berbagai proses onboarding yang umum ditemui di perusahaan besar maupun perusahaan kecil yang sehat.
• Chris dijadwalkan bekerja jarak jauh dari Colorado, tetapi dua minggu pertamanya dihabiskan untuk onboarding dan bersama tim.

Jutaan baris kode

• Dibandingkan dengan pengalamannya di perusahaan sebelumnya, ia sangat terkejut dengan skala aplikasi klien frontend dan layanan backend LinkedIn.
• Frontend LinkedIn mencapai 2 juta baris kode, jauh lebih banyak daripada seluruh kode di perusahaan sebelumnya.

Tim infrastruktur

• Peran Chris ada di tim infrastruktur, tetapi fokusnya bukan membangun server, melainkan dukungan rekayasa atau peningkatan pengalaman pengembang.
• Tujuannya adalah membantu agar aplikasi desktop LinkedIn yang sangat besar lebih mudah dikerjakan.

Modernisasi JavaScript

• Ia ikut serta dalam pekerjaan modernisasi kode melalui pengenalan class JavaScript. Sambil menyelesaikan masalah yang muncul saat menggunakan framework Ember, ia belajar banyak hal.
• Ia menyadari bahwa pekerjaan migrasi pada codebase besar harus diotomatisasi semaksimal mungkin, karena volumenya terlalu besar untuk ditangani secara manual.

Penerapan TypeScript

• Mereka memutuskan beralih ke TypeScript untuk mengurangi error yang terjadi di frontend.
• TypeScript bisa diterapkan secara bertahap, dan ini memberikan skalabilitas yang dibutuhkan LinkedIn.

Rencana migrasi lambat vs 'Finger Gun's Plan'

• Chris dan timnya mengusulkan rencana 3~5 tahun untuk memigrasikan kode Ember ke React, tetapi tim lain mengajukan 'Finger Gun's Plan' yang menjanjikan perombakan menyeluruh dan kecepatan tinggi.
• Perbedaan pendekatan ini mencerminkan konflik antara masalah yang dialami Chris dan timnya dengan budaya perusahaan yang memprioritaskan kecepatan.

Pengalaman dan pelajaran Chris

• Menyadari adanya masalah notifikasi yang tidak memadai.
• Seluruh server di data center mati akibat reaksi berantai dari peningkatan penggunaan memori dan restart server.
• Mereka mencoba menyelesaikan masalah dengan mereset sistem dan menyesuaikan izin.
• Kegagalan tidak bisa dihindari, dan software engineering adalah merancang sistem yang mendukung proses para engineer dalam menghasilkan produk.
• Menekankan perlunya sistem dengan ketahanan berlapis-lapis.

Penolakan terhadap insiden

• Dalam proses pemecahan masalah, muncul ketidakpuasan akibat kurangnya kepercayaan dari pihak manajemen.
• Terjadi perbedaan pendapat dan masalah komunikasi dengan engineer senior.
• Ia menekankan bahwa sistem tidak boleh hanya bekerja saat berada dalam kondisi terbaik, tetapi harus mampu mendukung dalam semua situasi.

Tekanan yang meningkat

• Meski terus berupaya mengatasi technical debt dan meningkatkan ketahanan, ketidakpuasan dari eksekutif semakin besar.
• Terjadi konflik dengan eksekutif yang menuntut solusi sederhana untuk masalah yang kompleks.

Restrukturisasi organisasi

• Terjadi restrukturisasi organisasi dan perubahan peran akibat 'tim finger guns'.
• Ia menyadari adanya pengalaman baru dan peluang belajar di peran lain.

Refleksi dan kesadaran

• Melakukan refleksi diri melalui pengalaman masa lalu dan situasi saat ini.
• Menyadari pentingnya membangun hubungan antarmanusia dan komunikasi.
• Memahami bahwa masalah teknis dan masalah sosial saling terhubung.

Kesimpulan dan pelajaran

• Chris tetap mempertahankan pandangan kritis terhadap budaya yang menjadikan kecepatan sebagai nilai tertinggi.
• Ia mencari peluang baru melalui refleksi atas karier dan nilai-nilai pribadinya.
• Perjalanan Chris untuk menemukan peran yang mengejar keunggulan engineering terus berlanjut.

Opini GN⁺

• Pengalaman Chris Krycho menunjukkan dengan baik konflik antara prinsip teknis dan kebutuhan bisnis.
• Keputusannya menekankan pentingnya menemukan keseimbangan antara nilai pribadi dan pilihan profesional.
• Mengelola perubahan di lingkungan teknologi skala besar seperti LinkedIn itu kompleks, dan ini memberi pelajaran penting bagi perusahaan lain juga.
• Penerapan teknologi seperti TypeScript dapat membantu meningkatkan kualitas kode dan mengurangi error, tetapi pada codebase besar dibutuhkan pendekatan bertahap.
• Saat mendorong perubahan teknis seperti ini, perlu mempertimbangkan keseimbangan antara pengalaman pengembang dan kecepatan rilis produk.

[GN⁺]

Komentar Hacker News

• Ia mengatakan bahwa dalam percakapan dengan seorang manajer, ia mendengar, 'Kamu terlalu idealis, tidak cukup memprioritaskan profit, dan perlu mengubah nilai-nilaimu.' Ia menyatakan rasa penolakannya terhadap hal itu dan menegaskan tekadnya untuk mempertahankan nilai-nilainya. Bagian ini disebut sebagai bagian paling menarik dari podcast tersebut, dan penulis merasa hal itu memberi kesan bahwa ia sengaja mengabaikan umpan balik penting. Pelajaran yang dipetik dalam karier adalah bahwa tantangan sebenarnya bukan mengetahui apa yang benar, melainkan menyatukan seluruh organisasi pada solusi yang benar.

  • Contoh benturan nilai dalam percakapan dengan manajer
  • Kesan bahwa umpan balik penting sengaja diabaikan
  • Pelajaran penting bahwa kesepakatan seluruh organisasi atas solusi yang benar adalah hal yang krusial

• Pada 2019, saya ikut mengerjakan penulisan ulang facebook.com ke React. Saya tidak mengetahui secara langsung codebase atau organisasi LinkedIn, tetapi saya punya pengalaman melihat perusahaan dengan codebase dan struktur organisasi yang serupa. Saya mendukung pendekatan 'finger gun', yang jika diimplementasikan dengan baik dapat menghasilkan dampak positif. Ketika beberapa klien mencoba melakukan hal yang sama, satu di antaranya bisa dijadikan dasar untuk melayani platform lain. Atau, jika memulai dari nol, hal itu bisa dilakukan dengan cara yang bersih, cepat, dan ringkas. Unsur umum keberhasilan adalah tim kecil berisi veteran yang membangun sistem baru; saya percaya keberhasilan lahir dari tim engineer kecil yang menggabungkan pakar domain dan pakar teknis. Masalah besar yang terus berulang dalam manajemen teknis adalah bahwa orang-orang yang paling minim pengalaman justru membangun sistem besar berikutnya.

  • Berbagi pengalaman penulisan ulang ke React
  • Menekankan pentingnya pendekatan 'finger gun' dan tim kecil berisi veteran
  • Menunjukkan masalah ketika orang yang kurang berpengalaman membangun sistem besar

• Penulisan ulang besar itu berisiko bahkan pada codebase yang masih bisa dikelola, dan masalah-masalah sisa tidak pernah benar-benar hilang. Setelah beberapa tahun, siapa yang mau menulis ulang halaman pengaturan tersembunyi? Andai ada framework untuk menulis ulang codebase, tetapi kenyataannya tidak ada. Codemod otomatis menuntut konsistensi, dan jarang ada yang benar-benar mematuhinya. Seiring waktu, pola kode banyak berubah, jadi rasanya seperti melihat lingkaran usia pada batang pohon. Ini seperti memasukkan kode ke dalam kotak lalu menyusunnya ulang, tetapi otomatisasi tidak terjadi pada level kotak.

  • Risiko penulisan ulang codebase dan masalah-masalah sisa
  • Tidak adanya framework untuk penulisan ulang kode
  • Kesenjangan antara otomatisasi di level kode dan otomatisasi di level kotak

• Saya saat ini bekerja di LinkedIn, dan saya rasa peran Chris yang disebut di podcast itu serta pengembangan web frontend berkaitan dengan ember. Sepertinya yang dimaksud adalah voyager-web, aplikasi web flagship monolitik milik LinkedIn. Di LinkedIn, selain voyager-web, ada banyak sistem lain dengan jutaan baris kode dan waktu build yang panjang. Misalnya middle-tier, offline data stack, sistem metrik, Kafka, dan lain-lain. Waktu build 17 menit sebenarnya cukup bagus; jika bisa 17 menit tanpa kegagalan infrastruktur sementara, itu sangat bagus.

  • Berbagi pengalaman kerja saat ini di LinkedIn
  • Penjelasan tentang berbagai sistem dan waktu build
  • Penilaian terhadap waktu build 17 menit

• Ratusan ribu hingga jutaan baris kode JavaScript menunjukkan tingkat pembengkakan yang berlebihan. Ini membuat saya berpikir untuk mengimplementasikan ulang layanan seperti LinkedIn atau membuat database kontak saya sendiri. Masalahnya adalah bagaimana memindahkan kontak dalam jumlah besar. Salah satu masalah utama Microsoft LinkedIn adalah tidak bisa mengekspor informasi kontak, padahal itu adalah fitur yang mutlak diperlukan pada platform kontak.

  • Menunjukkan pembengkakan berlebihan pada kode JavaScript
  • Sulitnya memindahkan informasi kontak
  • Pentingnya fitur ekspor informasi kontak

• Saya telah menghabiskan 12 tahun di LinkedIn, tetapi sekarang kondisinya sudah jauh dari organisasi engineering di masa lalu. Menurut saya, masa ketika Kevin Scott memimpin engineering jauh lebih baik.

  • Pengalaman bekerja lama di LinkedIn
  • Perbedaan antara organisasi engineering dulu dan sekarang

• Ini adalah situasi di mana Hukum Conway bekerja. Selama organisasinya tidak berubah, mereka akan menciptakan kekacauan kode yang sama lagi. Inisiatif engineering yang positif harus datang dari atas, dan membutuhkan dukungan dari level yang sangat tinggi. Tidak mungkin mengubah organisasi dari bawah ke atas; organisasilah yang membentuk codebase.

  • Kemungkinan terulangnya kekacauan kode tanpa perubahan organisasi
  • Perlunya inisiatif engineering positif dari level atas

• Saya sangat terkesan dengan sikap Chris Krycho yang berbicara jujur tentang kesulitannya tanpa memainkan permainan saling menyalahkan. CoRecursive adalah salah satu podcast favorit saya karena menggali konteks kompleks di balik kode.

  • Sikap jujur Chris Krycho dan upayanya menghindari saling menyalahkan
  • Penilaian positif terhadap podcast CoRecursive

• Perpindahan dari Ember ke React tampak seperti kasus yang cocok dengan teknologi yang dibuat oleh klien tempat saya pernah bekerja. Ia membuat bahasa bernama 'Unhack' agar pencarian dan penggantian bisa dilakukan pada level AST. Ia menggunakan bahasa yang memungkinkan Anda menentukan pola dalam kode asli lalu menentukan pola lain untuk menggantikannya. Saya berhenti bekerja dengan klien itu beberapa tahun lalu, jadi saya tidak tahu apakah itu masih ada sekarang.

  • Contoh perpindahan teknologi dari Ember ke React
  • Bahasa 'Unhack' yang memungkinkan pencarian dan penggantian pada level AST

• Bahwa codebase LinkedIn berantakan bukanlah hal yang mengejutkan jika Anda pernah memakai situs webnya. Anda mengklik posting yang menarik, mencoba mencari tahu lebih banyak tentang orang yang menulisnya, lalu menekan tombol kembali dan feed Anda dimuat ulang sehingga posting itu hilang. Saat mencoba menggulir pesan yang diterima, seluruh halaman web melambat dan butuh 10-15 detik untuk mendaftarkan input. Mengapa saya menerima 30 notifikasi palsu? Itu adalah notifikasi palsu yang dibuat untuk memaksa interaksi dari orang-orang. Algoritma rekomendasinya juga benar-benar buruk.

  • Sulitnya menggunakan situs web LinkedIn
  • Notifikasi palsu dan lambatnya respons halaman web
  • Menunjukkan masalah pada algoritma rekomendasi