- Chris Krycho bekerja di LinkedIn selama sekitar 5 tahun menangani infrastruktur frontend dan pengalaman developer untuk aplikasi web desktop, dan mengalami benturan antara mengubah codebase berskala besar secara aman dan tuntutan eksekusi produk yang cepat
- Saat ia bergabung, aplikasi desktop LinkedIn memiliki sekitar 2 juta baris JavaScript, lalu berkembang menjadi monorepo sekitar 3,2 juta baris; migrasi secara realistis sulit dilakukan tanpa otomasi dan tanpa meminimalkan beban tim produk
- Modernisasi Ember dan adopsi TypeScript ditujukan untuk mengurangi error dan meningkatkan kualitas pengembangan; analisis bahwa transisi ke TypeScript dapat mengurangi volume error log aplikasi setidaknya 25% digunakan untuk meyakinkan pihak internal
- Rencana berpindah dari Ember ke React mempertemukan strategi otomasi bertahap 3–5 tahun dari tim Chris dengan pendekatan yang ingin merancang ulang cara lama secara besar-besaran demi eksperimen produk yang lebih cepat
- Dalam proses menangani insiden besar, keterbatasan alert, observability, resilience, dan code review terungkap; Chris pergi karena arah organisasi yang menempatkan kecepatan sebagai prioritas utama tidak sejalan dengan nilai-nilainya
Pekerjaan selama 5 tahun dan skala codebase
- Chris Krycho bergabung dengan LinkedIn pada akhir Januari 2019 dan bekerja di sana selama sekitar 5 tahun
- Area tanggung jawabnya bukan infrastruktur server, melainkan infrastruktur frontend dan peningkatan pengalaman developer untuk aplikasi web desktop LinkedIn
- Ia memimpin proyek modernisasi JavaScript berskala besar di aplikasi desktop yang menangani pengalaman browser non-mobile LinkedIn.com
- Aplikasi di perusahaan sebelumnya berukuran sekitar 150 ribu baris, tetapi frontend LinkedIn saat ia bergabung memiliki sekitar 2 juta baris kode
- Pada aplikasi yang sama, 150–200 engineer melakukan commit setiap kuartal, dan puluhan tim terus menerapkan satu produk yang sama
- Saat ia bergabung, jumlah engineer remote kurang dari 100 orang dari total beberapa ribu engineer, dan Chris adalah kasus yang jarang karena bekerja remote dari Colorado
Cara bermigrasi dari 2 juta baris kode
- Salah satu pekerjaan besar awal adalah memperkenalkan sintaks class JavaScript modern ke kode berbasis Ember
- Ada masalah ketika class Ember lama dan class JavaScript native bercampur dalam inheritance chain, dan secara internal hal ini disebut “Zebra Striping”
- Migrasi pada skala ini harus diotomasi sebisa mungkin
- Memperbaiki 2 juta baris secara manual bisa memakan waktu berbulan-bulan atau lebih
- Sulit meminta tim produk menghentikan pengembangan fitur dan hanya mengadopsi sintaks baru
- LinkedIn memiliki proses inisiatif horizontal (horizontal initiatives) yang melintasi banyak tim, dengan prinsip operasional untuk menjaga partisipasi tim produk di bawah 10%
- Tim Chris menilai bahwa pendekatan di mana tim infrastruktur membuat PR lewat otomasi, lalu tim produk menangani review dan smoke test, akan lebih mudah diterima daripada meminta tim produk menjalankan codemod sendiri
- Pekerjaan terkait Ember secara keseluruhan memakan waktu 18 bulan; sebagian besar berlangsung dalam 6 bulan, tetapi keterlambatan di sebagian tim menyisakan ekor panjang
Logika pengurangan error yang meyakinkan adopsi TypeScript
- Setelah modernisasi Ember, tim Chris menjadikan banyaknya error JavaScript di frontend sebagai target berikutnya
- Karena skala error log LinkedIn sangat besar, mereka menggunakan infrastruktur logging internal alih-alih layanan eksternal
- LinkedIn melampaui 1 miliar anggota pada tahun sebelumnya, dan saat Chris pergi monorepo berukuran sekitar 3,2 juta baris
- Setengahnya adalah kode test
- Setengahnya adalah kode production
- Tim Chris menganalisis secara terpisah kategori error yang dapat ditangkap TypeScript
- Sebagian error tidak dapat ditangkap bahkan oleh TypeScript, tetapi mereka memperkirakan bahwa setelah seluruh migrasi selesai, volume log aplikasi dari jutaan error JavaScript per hari dapat dikurangi setidaknya 25%
- Dokumen transisi TypeScript yang ditulis Chris berulang kali dibagikan di antara engineer dan manager
- Masalah yang ingin diselesaikan
- Manfaat yang dapat diharapkan
- Perbandingan dalam daya saing rekrutmen
- Dasar pertimbangan untuk dibandingkan dengan prioritas lain
- Setelah itu, Chris berperan sebagai pakar internal yang membantu menangani masalah tipe TypeScript yang sulit
Dari Ember ke React: transisi bertahap dan perombakan menyeluruh
- LinkedIn adalah pengguna EmberJS terbesar di dunia, tetapi pekerjaan Chris akhirnya bergeser ke arah menyusun rencana untuk berpindah dari Ember ke React
- Para pemimpin senior melihat biaya migrasi LinkedIn terlalu tinggi dan memperlambat kecepatan produk
- Rencana tim Chris adalah strategi otomasi bertahap selama 3–5 tahun
- Memperkuat otomasi agar tim produk hampir tidak perlu berhenti
- Memisahkan dan mentransisikan build pipeline, data layer, routing layer, reactivity system, dan view layer secara berurutan
- Alurnya adalah mengganti sistem rendering dan reactivity Ember ke sisi React pada tahap akhir
- Tim lain menargetkan masalah kecepatan secara lebih langsung
- Tujuannya mengurangi waktu dari ide hingga A/B test dari beberapa bulan menjadi beberapa minggu
- Mereka melihat perbedaan stack dan cycle time yang panjang di desktop web, mobile web, iOS, dan Android sebagai masalah
- Chris menerima pendekatan tim itu sebagai sikap yang mendekati “finger guns mode”
- Ia merasa mereka tidak cukup menangani masalah yang akan muncul saat memperluas pengalaman mendukung puluhan orang menjadi dukungan untuk ratusan engineer
- Ia melihat banyak respons terhadap pertanyaan bernada “itu tidak akan menjadi masalah”
- Rencana 3–5 tahun tim Chris tidak mendapat respons baik dari leadership
- Rencana itu sendiri panjang dan tidak menarik
- Timnya juga mengajukannya seperti “pilihan yang paling tidak buruk”, sehingga daya yakinnya lemah
Masalah resilience yang terungkap dalam penanganan insiden
- Setelah Chris kembali dari liburan Natal, terjadi masalah yang membuat sebagian pengguna LinkedIn tidak dapat melihat halaman LinkedIn.com hingga sekitar 20 menit
- Masalah ini terkait dengan layanan prerendering yang menjalankan kode client dengan Node.js untuk mengumpulkan data backend dan mengirimkannya dengan cepat
- Layanan tersebut mengalami memory leak, dan kontainer akan di-restart ketika melewati batas memori
- Beberapa faktor yang memperbesar insiden saling bertumpuk
- Alert untuk memory kill tidak memadai
- Jumlah kontainer yang boleh restart secara bersamaan ada sebagai key di file YAML
- Nilai tersebut secara tipe adalah nilai yang memungkinkan, tetapi salah untuk sistem ini
- Nilai konfigurasi itu pada dasarnya hampir sama dengan jumlah seluruh service yang sedang berjalan
- Ketika penghentian deployment berlangsung lama seperti long weekend, service-service kehabisan memori pada waktu yang mirip, lalu restart sekaligus dan tidak dapat menangani request pengguna
- Jika sebagian server down, beban server yang tersisa meningkat, dan penggunaan memori server-server itu juga naik lebih cepat, sehingga muncul situasi server down pada skala data center
- Pada saat yang sama, pekerjaan rightsizing resource untuk mengurangi penggunaan CPU dan memori fleet sedang berjalan, sehingga ruang cadangan sudah berkurang
- Chris dan engineer lain menilai diperlukan alert, observability, dan resilience yang lebih baik
- Meski satu server Node masuk keadaan runaway, host process tidak seharusnya ikut mati
- Lebih aman jika hanya proses Node yang dihentikan, alert dikirim, lalu proses di-restart
- Mereka juga meninjau jalur fallback yang beralih ke fetch di sisi client saat service down
Benturan bahwa code review saja tidak dapat mencegahnya
- Rapat penanganan insiden berlangsung beberapa kali per minggu, dengan sifat berbagi progres dan melapor kepada eksekutif
- Manager dari tim lain mengambil alih penanganan insiden dan menambah personel, dan Chris memandangnya sebagai alur yang tidak memercayai jawaban dirinya dan tim yang sudah ada
- Dalam proses itu, seorang senior engineer bertanya, “Mengapa code review tidak bisa menyelesaikan ini?”
- Chris menilai code review saja tidak dapat menjamin hal yang sama tidak terjadi lagi
- Manusia melakukan kesalahan
- Sulit bagi engineer junior untuk meragukan apakah nilai konfigurasi dalam PR dari SRE yang sangat senior masuk akal
- Sistem harus beroperasi dengan aman bukan hanya pada hari terbaik senior engineer, tetapi juga pada hari buruk junior engineer
- Bagi Chris, software engineering mencakup desain sistem yang mendukung engineer untuk menghasilkan outcome produk
- Kegagalan teknis dan komunikasi organisasi tidak terpisah, dan seperti kata Charity Majors, pada level tinggi tidak ada masalah yang murni sosial atau murni teknis
Leadership, budaya remote, dan benturan nilai
- Chris merasa tim dan pendekatannya tersisih oleh usulan tim lain
- Rencana tim lain berkembang menjadi arah untuk memikirkan ulang aplikasi desktop dan mobile sekaligus, dan bersifat meninjau kembali cara LinkedIn membangun produk secara menyeluruh
- Chris ingin membuat usulan itu lebih baik, tetapi merasa kekhawatiran atau pertanyaannya tidak cukup diterima
- Ia mengatakan pernah diberi tahu oleh seorang manager, “Kamu terlalu idealis, tidak cukup memperhatikan untung-rugi, dan harus mengubah nilai-nilaimu”
- Chris melihat kerja remote memengaruhi pembentukan relasi
- LinkedIn memiliki budaya tatap muka yang kuat, dan banyak orang membangun relasi secara alami di kafetaria atau lorong
- Ia merasa kontak fisik berulang dengan engineer senior dan eksekutif dapat membuat perbedaan dalam situasi konflik
- Chris juga merefleksikan bahwa dirinya memiliki kelemahan dalam membangun relasi
Alasan akhirnya pergi
- Chris melihat banyak masalah dalam codebase lama sebagai hasil dari terlalu melebihkan kecepatan dan tidak memperbaiki atau menghapus masalah di jalur pendukung
- Ia menilai bahwa jika kecepatan menjadi nilai utama, kecepatan awal mungkin didapat, tetapi sulit dipertahankan seiring waktu
- Ia mengatakan pernah mengalami burnout di pekerjaan sebelumnya, dengan migrain berat, sakit perut, tidak bisa berolahraga, menangis tiba-tiba, dan panic attack
- Ia melihat bahwa jika terus bekerja di LinkedIn, ia akan tetap berada dalam keadaan harus berusaha setiap hari agar tidak marah
- Dengan membandingkannya seperti mencoba mengubah arah organisasi raksasa memakai perahu dayung kecil, ia memutuskan untuk tidak menghabiskan bertahun-tahun pada cara dan pekerjaan yang tidak ia yakini
- Chris mempelajari aplikasi berskala 3 juta baris, migrasi TypeScript di perusahaan besar, dan persoalan engineering berskala besar di LinkedIn, tetapi pergi untuk mencari pekerjaan yang sejalan dengan nilai-nilainya
1 komentar
Pendapat Hacker News
Menurut saya bagian paling menarik di podcast itu adalah masukan bahwa ia “terlalu idealistis, kurang memperhatikan untung-rugi, dan perlu mengubah nilai-nilainya.” Bahkan sebelum membaca pun saya sudah mendapat kesan seperti itu, dan terdengar seolah-olah ia beberapa kali menerima masukan berharga, tetapi sengaja mengabaikannya
Hal yang sulit bagi seorang senior staff engineer bukanlah sekadar ‘benar’, melainkan menciptakan penyelarasan di seluruh organisasi menuju solusi yang benar. Karena saya ikut mengerjakan penulisan ulang facebook.com dengan React pada 2019, cerita ini terasa sangat menarik
Saya cukup berhasil dalam berkomunikasi, tetapi selama di LinkedIn saya tidak terlalu berhasil dalam penyelarasan itu. Sebagian adalah tanggung jawab saya, dan sebagian juga tanggung jawab LinkedIn
Namun dalam kasus ini, ungkapan “terlalu idealistis” benar-benar berarti “jangan pedulikan hal yang tidak berkontribusi langsung pada untung-rugi,” dan saya menolak itu sampai ke tulang. Untung-rugi memang penting, tetapi pengalaman pengguna, developer experience, dan etika dasar tentang apa yang kita bangun juga penting
Dalam organisasi, kita membela sebaik mungkin apa yang kita yakini benar, lalu orang lain atau suatu badan konsensus memutuskan apakah mereka setuju. Menerima hasil itu atau berkompromi, atau pergi, adalah keputusan saya, dan dalam karier saya sudah pernah melakukan keduanya
Di sebuah unicorn terkenal, ada seorang senior staff engineer yang sangat cerdas, rasional, dan baik hati. Ia mendorong peningkatan framework yang dipakai dengan biaya 50 juta dolar per tahun dari v2 ke v3, dan dibandingkan perpindahan dari Python 2 ke 3, perubahan ini sangat kecil
Hasil investigasi menunjukkan pada dasarnya bisa diharapkan peningkatan performa 10%, tetapi manajemen tidak mau “membuang waktu untuk upgrade versi.” Akhirnya engineer itu mendorongnya sendiri, membuat versi pratinjau dalam waktu kurang dari sebulan, lalu dalam dua bulan memigrasikan sebagian pekerjaan berdampak besar dan menghemat biaya beberapa kali lipat dari gajinya sendiri
Setelah biaya politik dan biaya engineering awal dibayar, semua orang ingin pindah, dan setahun kemudian ketika deployment selesai, lapisan manajemen di atasnya kira-kira terbelah antara di-PHK dan keluar sendiri, tetapi engineer itu dan migrasinya tetap ada. Kadang staff engineer bukan keras kepala, melainkan satu-satunya orang waras di dunia yang gila
Saya pernah berada di posisi seperti itu dan bisa memilih tidak ikut, tetapi tidak selalu mungkin untuk melakukannya
Saya pernah melihat eksekutif diyakinkan bukan karena ada ide atau rencana terbaik, melainkan karena koneksi yang tepat, makan siang yang tepat, dan kata-kata yang tepat
Pernyataan “kamu terlalu idealistis dan kurang memperhatikan untung-rugi” juga bisa menjadi label untuk menyingkirkan seseorang. Apalagi jika orang itu memang menjual diri dan idenya ke atasan dengan cara seperti itu
Secara pribadi, di organisasi yang lebih kecil daripada Facebook tetapi memiliki ratusan engineer dan codebase besar, saya beberapa kali melakukan perubahan dan upgrade skala besar terkait Ruby, Rails, dan Postgres, dan metodologi yang dijelaskan Chris sangat masuk akal serta sesuai dengan cara yang saya rasakan berhasil
Saya setuju bahwa peran kepemimpinan membutuhkan kepercayaan dan rasa hormat agar efektif. Tentu saja, agar kepercayaan itu berguna, arahnya juga harus benar. Kemajuan ke arah yang salah bukanlah kemajuan
Saya belum pernah bekerja tanpa mengenal codebase LinkedIn, tetapi saya sudah berkali-kali melihat codebase serta struktur organisasi/politik yang terdengar menakutkan mirip. Karena itu, biasanya saya mendukung pendekatan finger-gun
Penulisan ulang ala finger-gun juga bisa diimplementasikan dengan baik. Jika ada beberapa klien yang melakukan hal yang sama, salah satunya bisa dijadikan dasar untuk platform lain; bahkan jika mulai dari nol, bisa dibuat bersih, cepat, dan ringkas
Kunci keberhasilannya adalah menyerahkan sistem baru kepada tim kecil berisi para veteran yang sekaligus pakar domain dan pakar teknis. Ini kontroversial, tetapi menurut saya semua keberhasilan—termasuk urusan pemeliharaan operasional yang biasa—berasal dari sini. Sisanya hanya memperlambat
Masalah besar yang terus diulang kebanyakan eksekutif teknologi adalah menyerahkan sistem besar berikutnya kepada orang-orang yang paling minim pengalaman. Saya juga ingin mendengar wawancara yang simetris dari pihak finger-gun
Itu wajar karena hal-hal tersebut sudah terbukti efektif bagi mereka, tetapi tidak selalu yang terbaik. Selain itu, meskipun tim veteran memulai proyek, jarang mereka bertahan sampai akhir; dan jika mereka tidak perlu menanggung hasil atau dampak lanjutannya, mengambil keputusan menjadi terlalu mudah
Rencana harus memiliki opsi realistis untuk menangani rintangan, dan itu bukan hanya opsi teknis, melainkan juga mencakup waktu dan kemampuan orang yang akan mengerjakannya. Misalnya, jika rencananya beberapa tim mengoperasikan server, itu mungkin secara teknis memungkinkan, tetapi jika tim tidak punya waktu atau kemampuan, itu bukan opsi yang realistis
Sebaliknya, merencanakan rute yang rumit untuk menghindari semua rintangan juga buruk. Saat kita tiba, rintangannya mungkin sudah bergerak, dan mungkin ada rintangan di jalan yang belum kita ketahui. Jika hanya merencanakan satu jalur, kita akan berhenti di situ
Namun yang kita lihat sekarang adalah penjelasan podcast yang merangkum perdebatan arsitektur kompleks seperti kartun, jadi kita tidak bisa tahu argumen orang-orangan mana yang sebenarnya lebih dekat terjadi di LinkedIn
Katanya, dewan direksi memberi tahu seluruh engineering bahwa mulai saat itu, dalam proyek apa pun, tidak seorang pun boleh mengarahkan detailnya
Kedengarannya Chris membuat beberapa pilihan yang kurang beruntung. Ia mengusulkan rencana 5 tahun, mengarahkan insiden ke arah menyalahkan alih-alih kepemimpinan, lebih banyak berbicara tentang masalah daripada menyelesaikannya, dan tampaknya juga kurang membangun hubungan
Di satu sisi saya bersimpati kepada Chris, tetapi di sisi lain ia juga terlihat tidak tahu cara menghasilkan kinerja di lingkungan seperti ini. Itu tidak apa-apa. Tidak semua orang harus belajar bekerja di dalam simpul birokrasi, dan startup lebih sederhana dalam hal itu
Ada alasan mengapa perusahaan besar seiring waktu kehilangan ketajamannya, dan mengapa seorang eksekutif akhirnya menghadapi kerugian -10% YoY di ruang rapat tanpa satu pun VP yang berani jujur
Saat berada dalam situasi seperti ini, secara psikologis kita kehilangan arah. Rasanya saya benar, tetapi benarkah? Apakah orang-orang di sekitar memang semampu itu, dan benar-benar tidak tertarik belajar dari rekan kerja?
Beberapa tahun kemudian, ketika sudah pergi dan menoleh ke belakang, orang-orang itu sudah dipecat atau pergi, organisasi masih belum mampu melakukan X, dan kelincahan serta kemampuan tim-tim yang bergabung setelahnya ternyata memang nyata
Di satu sisi, itu bisa saja kesombongan, ketidakcakapan politik, atau ketidakmampuan beradaptasi dengan budaya kerja yang patologis. Di sisi lain, mungkin itu memang respons yang tepat
Jika sebuah organisasi sedang melewati fase budaya yang patologis, mungkin memang wajar orang-orang berbakat, berhati-hati, dan bersemangat menjadi gila karenanya. Orang-orang yang tidak menjadi gila karena hal itu mungkin tidak ada hubungannya dengan produktivitas dan pertumbuhan, atau lebih buruk lagi, menjadi kerugian bersih
Karena itu, lingkungan seperti ini berubah menjadi psikodrama. Apakah situasinya memang seburuk ini, atau saya yang bereaksi berlebihan
Tetapi dalam situasi ketika para eksekutif mengatakan, “meskipun ini migrasi yang kami minta, jangan memperlambat kecepatan iterasi produk sama sekali,” itu juga satu-satunya rencana yang kami rasa bisa kami bawa
Saya tidak begitu mengerti maksud bagian bahwa insiden itu diarahkan ke menyalahkan. Justru kami berusaha melakukan sebaliknya, dan tidak menyalahkan orang yang menurunkan ambang batas memori atau orang yang salah mengetik nilai di YAML. Kami hanya bersikeras agar akar penyebabnya benar-benar diselesaikan, bukan dibiarkan sampai orang berikutnya meledakkannya lagi
Bagian bahwa kami hanya berbicara alih-alih menyelesaikan masalah juga tidak begitu saya mengerti. Saya hanya tidak membanggakan panjang lebar di siaran tentang apa yang sudah saya kerjakan; masalah-masalah yang saya selesaikan di sana sebenarnya terselesaikan cukup baik
Kurang membangun hubungan adalah bagian terlemah saya, seperti yang juga saya katakan di episode itu. Hubungan saya dengan para engineer baik, tetapi saya sangat gagal membangun kepercayaan politik terutama dengan lapisan manajemen atas
Meski begitu, saya tidak melihatnya sekadar karena saya tidak tahu cara berhasil di lingkungan itu. Saya melihat cara untuk bisa berhasil, tetapi ada juga pilihan untuk tidak bertindak dengan cara yang tidak saya yakini. Banyak engineer yang saya hormati mau melakukan tarian politik demi hal yang mereka yakini, tetapi tidak untuk hal yang tidak mereka yakini
Saat ini bekerja di LinkedIn. Peran Chris dan podcast-nya tampaknya membahas Ember dan pengembangan web frontend, dan jumlah baris kode serta build yang ia sebut kemungkinan adalah voyager-web, aplikasi web representatif monolitik milik LinkedIn
Di LinkedIn ada sistem lain yang punya jutaan baris kode dan build yang panjang. Lapisan tengah, stack data offline, sistem metrik, dan hal-hal seperti KafkaKafkaKafka
Sayangnya, build 17 menit itu tergolong cukup bagus. Kalau 17 menit tanpa gangguan infrastruktur sementara, itu sangat bagus
Hampir tidak ada konsep testing di seluruh perusahaan, dan tidak ada QA. Para engineer mendorong proyek setengah matang agar bisa dimasukkan ke materi promosi jabatan, lalu lanjut ke hal berikutnya
Saat menggunakan tool internal sehari-hari, terlalu banyak masalah yang harus saya selesaikan sendiri, dan strukturnya membuat engineer yang sebenarnya ingin bekerja pada praktiknya menjadi QA
Sebaliknya, seharusnya arahnya adalah membuat build lebih cepat atau membuat infrastruktur build lebih cepat dan murah
Setidaknya di tim tempat saya berada, ada penekanan yang cukup besar pada kualitas kode dan budayanya juga terus membaik. Namun saya pernah mengerjakan satu tugas terkait voyager, dan itu saya ingat sebagai mimpi buruk
Penulisan ulang skala besar berisiko bahkan pada codebase yang masih bisa dikelola, dan sisa-sisanya tampaknya tidak pernah benar-benar hilang sampai akhir. Beberapa tahun kemudian, siapa yang mau mencari poin dengan menulis ulang halaman pengaturan yang terselip di sudut?
Saya sudah terlalu sering melihat upaya seperti ini, jadi seharusnya ada framework untuk menulis ulang codebase, tapi tidak ada. Tool perbaikan kode otomatis menuntut konsistensi, tetapi jarang ada tempat yang menjaga konsistensi seperti itu. Pola kode berevolusi terlalu banyak seiring waktu, rasanya seperti melihat lingkaran usia pada pohon
Pada dasarnya kita memasukkan kode ke dalam kotak, menata ulang kotak-kotak itu, lalu dengan masuk akal mengatakan bahwa susunan tertentu lebih efisien. Tapi kenapa kita belum menemukan cara yang lebih baik? Otomasi bekerja di level kode, tetapi tidak bekerja di level kotak
Ini adalah contoh berjalannya Hukum Conway. Karena organisasinya tidak berubah, besar kemungkinan mereka akan membuat sup kode yang sama lagi
Sebagai orang yang pernah berada di perahu yang sama, inisiatif engineering yang positif harus datang dari atas ke bawah melalui sponsor di posisi yang sangat tinggi. Anda tidak bisa mengubah organisasi dari bawah ke atas, dan pada akhirnya organisasilah yang membentuk codebase
Hukum Conway tidak berubah, tetapi tidak selalu hanya bergantung pada bagan organisasi resmi. Ini bisa ditangani dengan membuat struktur komunikasi sementara antara tech lead yang tepat dan manajer yang kompeten
Namun cukup ada beberapa manajer di tengah yang lemah secara teknis atau ingin membangun kerajaannya sendiri, seluruhnya mudah berantakan; dan tergantung siklus hidup perusahaan, mungkin sudah tidak ada harapan karena Hukum Besi Birokrasi Pournelle
Misalnya, kalau semua developer buruk, berikan saja framework populer. Itu hanya alasan untuk menghindari menangani masalah manusia, seperti membiarkan anak-anak mengelola tempat penitipan anak
Jika menginginkan keunggulan, standar tinggi harus ditegakkan lewat aturan yang menuntut akuntabilitas serta memberikan kepemilikan, imbalan, dan tanggung jawab. Ini tidak rumit, tetapi dari atas harus tegas dan tidak takut konflik
Namun Anda mungkin akan kehilangan semua harapan bahwa perusahaan seperti Microsoft bisa membuat sesuatu lalu tidak merusaknya
Saya menghabiskan 12 tahun di LinkedIn. Sedihnya, sekarang jauh dari organisasi engineering yang dulu. Masa ketika Kevin Scott memimpin engineering benar-benar jauh lebih baik jika dibandingkan
Jutaan baris JavaScript—itu sendiri sudah menjadi perwujudan kebloated-an
Saya pernah berpikir untuk mengimplementasikan ulang sesuatu seperti LinkedIn, atau lebih tepatnya membuat basis data kontak saya sendiri tanpa fitur yang “mirip Facebook”
Masalahnya adalah bagaimana membuat kontak-kontak saya berpindah secara massal. Terlepas dari kebloated-an, masalah utama Microsoft LinkedIn adalah mereka tidak membiarkan kita mengekspor informasi kontak, dan untuk sebuah platform kontak, ini adalah fitur wajib
https://queue.acm.org/detail.cfm?id=2567673
Ringkasan: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn pindah ke Node pada awal 2010
Namun melihat reaksi di thread ini, saya jadi bertanya-tanya apakah angka itu sebenarnya keliru
Saya belum pernah melakukannya di LinkedIn, tetapi itu trik kotor yang saya pakai saat mengekspor daftar peserta konferensi yang ada di situs web publik. Tergantung situasinya
Saya terkesan dengan cara Chris Krycho berbicara jujur tentang kesulitannya sendiri tanpa mengarah ke permainan saling menyalahkan. CoRecursive adalah salah satu podcast favorit saya karena membahas konteks kompleks di balik kode
Kedengarannya seperti peran soft leadership yang hampir selalu berat. Posisi yang “bertanggung jawab” atas sesuatu, tetapi punya sedikit atau bahkan tidak punya wewenang atas bagian organisasi lainnya
Jika ada kepemimpinan teknis yang nyata, bisa jadi mereka sedang tidak ada, atau sudah terlalu lama berada di sana dan meski disebut “ahli sistem”, tidak lagi bersentuhan dengan masalah sebenarnya. Pernah mengalaminya, dan tidak mau lagi