Menulis kode tidak sulit, yang sulit adalah menangani「orang」 dan「kompleksitas」. Insinyur Google senior berbagi pengalaman 14 tahun, dari pola pikir pengguna hingga kolaborasi tim, 21 aturan emas ini membantu Anda mencapai karir yang lebih mendalam dan bermakna.
（Latar belakang: Google Terjemahan Instan resmi membuka semua merek headphone: lebih dari 70 bahasa tersedia, ponsel Android AS-Meksiko-India sebagai pelopor）
（Keterangan tambahan: Google resmi meluncurkan「Gemini 3」! Menduduki puncak model AI paling pintar di dunia, apa saja sorotannya?）

Daftar isi artikel

• 1. Insinyur top terobsesi memecahkan masalah pengguna
• 2. 「Membuktikan diri benar」tak ada nilainya, mencapai tujuan yang benar bersama adalah fokusnya
• 3. Lebih condong ke tindakan. Rilis saja! Anda bisa mengubah halaman buruk, tapi tidak bisa mengubah halaman kosong
• 4. Kedalaman terlihat dari kejernihan, kecerdasan dari beban
• 5. 「Kebaruan」adalah pinjaman bunga tinggi dari perbaikan, rekrutmen, dan beban kognitif
• 6. Kode tidak akan bersuara untukmu, manusia yang akan
• 7. Kode terbaik adalah baris yang belum pernah kamu tulis
• 8. Ketika skala cukup besar, bahkan Bug-mu pun memiliki pengguna
• 9. Sebagian besar tim「lambat」sebenarnya adalah tim「kehilangan fokus」
• 10. Fokuslah pada hal-hal yang bisa kamu kendalikan, abaikan yang tidak bisa
• 11. Abstraksi tidak menghilangkan kompleksitas, hanya memindahkannya
• 12. Menulis memaksa kejernihan, pengajaran adalah cara tercepat belajar
• 13. Membuat pekerjaan lain menjadi mungkin adalah tak ternilai, tapi juga tak terlihat
• 14. Jika kamu menang setiap perdebatan, mungkin kamu sedang mengumpulkan resistensi diam-diam
• 15. Ketika indikator menjadi tujuan, itu bukan indikator yang baik lagi
• 16. Mengakui「saya tidak tahu」lebih menciptakan rasa aman daripada pura-pura paham
• 17. Konteksmu lebih panjang umur dari pekerjaan apa pun yang pernah kamu lakukan
• 18. Sebagian besar peningkatan performa berasal dari「menghapus pekerjaan」bukan「algoritma cerdas」
• 19. Keberadaan proses adalah untuk mengurangi ketidakpastian, bukan menciptakan dokumen
• 20. Akhirnya, waktu akan lebih berharga daripada uang, bertindaklah sesuai itu
• 21. Tidak ada jalan pintas, tapi ada efek majemuk

• Pemikiran terakhir

Addy Osmani, Direktur AI Google Cloud, adalah insinyur perangkat lunak berpengalaman dan pemikir, pernah menjabat sebagai kepala pengalaman pengembang di Chrome selama hampir 14 tahun, terlibat dalam proyek DevTools, Lighthouse, dan Core Web Vitals. Kini, dia bertanggung jawab mengoordinasikan pekerjaan antara Google DeepMind, tim teknik, produk, dan hubungan pengembang.

Pada hari ketiga, dia memposting sebuah artikel mendalam tentang pengalaman kerjanya di blog pribadi. Menggabungkan pengalaman kerjanya selama bertahun-tahun di Google dan profesionalisme, merangkum 21 saran berharga tentang komunikasi, pilihan teknologi, dan perencanaan karir, disusun dan diterjemahkan oleh tim Zhuangqi:

Ketika saya bergabung dengan Google sekitar 14 tahun lalu, saya pikir pekerjaan ini adalah menulis kode yang sempurna. Saya hanya benar sebagian. Semakin lama saya di sini, semakin saya sadar bahwa insinyur yang berkinerja baik tidak selalu yang menulis kode terbaik, melainkan mereka yang belajar mengendalikan segala sesuatu di luar kode: termasuk hubungan antar manusia, politik tempat kerja, kesepakatan bersama, dan ketidakpastian.

Pengalaman ini adalah hal yang saya harap saya pahami lebih awal. Beberapa membantu saya menghemat berbulan-bulan frustrasi, yang lain membutuhkan bertahun-tahun untuk benar-benar saya pahami. Semuanya tidak terkait dengan teknologi tertentu: perubahan teknologi terlalu cepat dan tidak penting. Yang penting adalah pola yang berulang di berbagai proyek dan tim.

Saya berbagi ini karena saya banyak mendapatkan manfaat dari insinyur yang bersedia membantu junior. Ini adalah sedikit balasan dari saya.

1. Insinyur top terobsesi memecahkan masalah pengguna

Mencintai satu teknologi dan mencari berbagai aplikasi sangat menggoda. Saya pernah melakukannya, semua orang pernah. Tapi insinyur yang menciptakan nilai terbesar adalah mereka yang melakukan「reverse work」: mereka terobsesi memahami masalah pengguna secara mendalam, dan solusi muncul secara alami dari pemahaman tersebut.

Obsesi terhadap pengguna berarti meluangkan waktu mempelajari tiket layanan pelanggan, berbicara dengan pengguna, mengamati kesulitan mereka, terus bertanya「mengapa」sampai menyentuh inti masalah. Insinyur yang benar-benar memahami masalah biasanya akan menemukan bahwa solusi elegan seringkali lebih sederhana dari yang dibayangkan. Insinyur yang memulai dari solusi sering menambah kompleksitas yang tidak perlu demi membenarkan solusi mereka.

2. 「Membuktikan diri benar」tak ada nilainya, mencapai tujuan yang benar bersama adalah fokusnya

Kamu bisa menang setiap perdebatan teknis, tapi kalah dalam proyek. Saya pernah melihat insinyur pintar karena selalu ingin menjadi yang paling pintar di ruangan, mengumpulkan kebencian diam-diam. Biaya ini kemudian muncul sebagai「masalah eksekusi misterius」atau「resistensi tak terduga」.

Keahlian bukan tentang「benar」, melainkan tentang berpartisipasi dalam diskusi untuk menyelaraskan masalah, menciptakan ruang bagi orang lain, dan meragukan kepastian diri sendiri. Pendapat kuat, hati terbuka—ini bukan karena kamu kekurangan keyakinan, melainkan karena dalam ketidakpastian, keputusan yang diambil tidak boleh terkait dengan harga diri.

3. Lebih condong ke tindakan. Rilis saja! Kamu bisa mengubah halaman buruk, tapi tidak bisa mengubah halaman kosong

Mengejar kesempurnaan bisa menyebabkan paralysis. Saya pernah melihat insinyur menghabiskan berminggu-minggu membahas arsitektur ideal dari sesuatu yang belum pernah mereka bangun. Solusi sempurna jarang berasal dari pemikiran murni—ia berasal dari benturan dengan kenyataan. AI bisa membantu dalam banyak hal.

Lakukan dulu, lakukan yang benar, lalu lakukan lebih baik. Tampilkan prototipe yang jelek ke pengguna. Tulis draf awal dokumen desain yang berantakan. Rilis MVP yang membuatmu sedikit malu. Pelajaran dari feedback nyata selama seminggu jauh lebih berharga daripada diskusi teori selama sebulan. Semangat membawa kejernihan, analisis menyebabkan paralysis dan tidak ada hasil.

4. Kedalaman terlihat dari kejernihan, kecerdasan dari beban

Insting menulis kode yang「cerdas」seakan menjadi bukti kemampuan insinyur. Tapi rekayasa perangkat lunak adalah reaksi kimia dari「waktu」 dan「insinyur lain」yang terlibat. Dalam lingkungan ini, kejernihan bukan gaya, melainkan mengurangi risiko operasional.

Kode kamu adalah memo strategis untuk orang asing yang mungkin memperbaiki masalah tengah malam. Tingkatkan pemahaman mereka, bukan keanggunanmu. Insinyur senior yang paling saya kagumi selalu memilih「cerdas」untuk「kejernihan」.

5. 「Kebaruan」adalah pinjaman bunga tinggi dari perbaikan, rekrutmen, dan beban kognitif

Anggap pilihan teknologi sebagai「token inovasi」dari perusahaan dengan anggaran terbatas. Setiap kali kamu menggunakan teknologi non-standar secara substansial, itu seperti menghabiskan satu token. Kamu tidak mampu membayar terlalu banyak. Fokusnya bukan「jangan pernah berinovasi」tapi「berinovasilah hanya di tempat kamu mendapatkan imbalan unik」。

Segala sesuatu yang lain harus dianggap「biasa」karena kebosanan berarti mode kegagalannya sudah diketahui. 「Alat terbaik untuk pekerjaan ini」seringkali adalah「alat yang paling tidak buruk di antara banyak pekerjaan」—karena mengelola kebun binatang teknologi akan menjadi beban nyata.

6. Kode tidak akan bersuara untukmu, manusia yang akan

Di awal karir, saya pikir performa kerja yang baik akan membuktikan segalanya. Saya salah. Kode diam-diam tinggal di repositori. Apakah atasanmu menyebutkanmu dalam rapat, apakah rekan merekomendasikanmu untuk proyek, itu yang penting.

Dalam organisasi besar, keputusan dibuat dalam rapat tanpa undangan, oleh orang yang hanya punya lima menit untuk mengelola dua belas prioritas, berdasarkan ringkasan yang tidak pernah kamu tulis. Jika saat kamu tidak hadir, tidak ada yang bisa menjelaskan pengaruhmu, maka pengaruhmu tidak berarti apa-apa. Ini bukan soal mempromosikan diri, tapi menunjukkan rantai nilai yang jelas bagi semua orang (termasuk dirimu sendiri).

7. Kode terbaik adalah baris yang belum pernah kamu tulis

Budaya insinyur merayakan penciptaan. Tidak ada yang akan dipromosikan karena menghapus kode, meskipun penghapusan seringkali lebih mengoptimalkan sistem daripada menambah. Setiap baris kode yang belum pernah kamu tulis adalah yang tidak perlu kamu debug, pelihara, atau jelaskan.

Sebelum membangun, tanyakan satu pertanyaan mendalam: 「Kalau kita tidak melakukan apa-apa, apa yang akan terjadi?」 Kadang jawabannya adalah「tidak ada yang buruk」, dan itu adalah solusi kamu. Masalahnya bukan karena insinyur tidak bisa menulis kode atau menggunakan AI, melainkan karena kita terlalu mahir menulis sehingga lupa bertanya「haruskah kita menulis」.

8. Ketika skala cukup besar, bahkan Bug-mu pun memiliki pengguna

Ketika pengguna cukup banyak, setiap perilaku yang dapat diamati akan menjadi dependensi—apa pun yang kamu janjikan (Haleem’s Law). Ada yang mengakses API-mu, mengotomatisasi fitur unikmu, meng-cache Bug-mu.

Ini memberi wawasan profesional: kamu tidak bisa menganggap pekerjaan kompatibilitas sebagai「pemeliharaan」, dan fitur baru sebagai「pekerjaan nyata」. Kompabilitas adalah produk itu sendiri. Saat merancang penghapusan, anggaplah sebagai proses migrasi yang melibatkan waktu, alat, dan empati. Sebagian besar「perancangan API」sebenarnya adalah「penghentian API」。

9. Sebagian besar tim「lambat」sebenarnya adalah tim「kehilangan fokus」

Ketika proyek terhenti, nalurimu menyalahkan eksekusi: kekurangan sumber daya, pilihan teknologi yang salah. Biasanya ini bukan masalah utama. Di perusahaan besar, tim adalah unit konkurenmu, tapi biaya koordinasi meningkat secara eksponensial dengan jumlah tim. Sebagian besar「lambat」sebenarnya adalah gagal menyelaraskan—orang membangun sesuatu yang salah, atau membangun sesuatu yang benar dengan cara yang tidak kompatibel. Insinyur senior menghabiskan lebih banyak waktu memperjelas arah, antarmuka, dan prioritas, bukan menulis kode lebih cepat, karena itu adalah bottleneck utama.

10. Fokuslah pada hal-hal yang bisa kamu kendalikan, abaikan yang tidak bisa

Di perusahaan besar, banyak variabel yang tidak bisa kamu kendalikan—struktur organisasi, keputusan manajemen, perubahan pasar, arah produk. Terjebak dalam hal ini hanya akan menimbulkan kecemasan dan sia-sia. Insinyur yang rasional dan efisien akan fokus pada lingkaran pengaruh mereka.

Kamu tidak bisa mengendalikan restrukturisasi, tapi kamu bisa mengendalikan kualitas pekerjaan, reaksi, dan apa yang kamu pelajari. Saat menghadapi ketidakpastian, pecah masalah dan cari tindakan konkret yang bisa kamu ambil. Ini bukan soal pasrah, tapi soal strategi fokus. Menghabiskan energi untuk hal yang tidak bisa diubah adalah mencuri waktu dari hal yang bisa kamu ubah.

11. Abstraksi tidak menghilangkan kompleksitas, hanya memindahkannya

Setiap abstraksi adalah taruhan, bertaruh kamu tidak perlu memahami prinsip dasar. Kadang kamu menang, tapi abstraksi selalu bocor. Saat gagal, kamu harus tahu apa yang terjadi di bawahnya. Insinyur berpengalaman tetap belajar「pengetahuan dasar」meskipun tumpukan teknologi semakin tinggi. Bukan karena nostalgia, tapi karena menghormati saat abstraksi gagal. Gunakan tumpukan alatmu, tapi pahami model mental tentang bagaimana mereka gagal di dasar.

12. Menulis memaksa kejernihan, pengajaran adalah cara tercepat belajar

Menulis memaksa kamu berpikir. Saat menjelaskan konsep kepada orang lain—baik dalam dokumen, presentasi, review kode, bahkan sekadar ngobrol dengan AI—saya sering menyadari bagian yang tidak saya pahami.

Proses membuat konten yang jelas bagi orang lain juga membuatnya lebih jelas bagi saya. Ini bukan sekadar berbagi pengetahuan secara murah hati, tapi juga teknik belajar yang sangat egois. Jika kamu merasa sudah paham, coba jelaskan secara sederhana. Tempat kamu terjebak adalah tempat kamu memahami dangkal. Mengajar adalah proses debugging model mentalmu sendiri.

13. Membuat pekerjaan lain menjadi mungkin adalah tak ternilai, tapi juga tak terlihat

「Kerja lem」—dokumen, orientasi karyawan baru, koordinasi lintas tim, perbaikan proses—sangat penting. Tapi jika dilakukan tanpa sadar, itu akan menghambat pertumbuhan teknis dan membuatmu kelelahan. Perangkapnya adalah menganggapnya sebagai「bekerja sukarela membantu」, padahal itu adalah kontribusi yang sadar, dengan batasan dan terlihat. Batasi waktu, bergiliran, ubah menjadi output (dokumen, template, otomatisasi).

Anggaplah sebagai pengaruh, bukan karakter pribadi.

14. Jika kamu menang setiap perdebatan, mungkin kamu sedang mengumpulkan resistensi diam-diam

Saya belajar meragukan kepastian diri. Saat saya「menang」dengan sangat mudah, biasanya ada yang tidak beres. Orang berhenti berdebat bukan karena mereka yakin, tapi karena mereka menyerah—mereka akan mengungkapkan keberatan saat eksekusi, bukan di rapat. Keselarasan sejati membutuhkan waktu lebih lama.

Kamu harus benar-benar memahami sudut pandang orang lain, memasukkan umpan balik, bahkan kadang mengubah pendapat secara terbuka. Kepuasan menang dalam perdebatan jangka pendek tidak sebanding dengan nilai bekerja sama dengan mitra yang sepenuh hati dalam jangka panjang.

15. Ketika indikator menjadi tujuan, itu bukan indikator yang baik lagi

Setiap indikator yang kamu tunjukkan ke manajemen akhirnya akan dimanipulasi. Bukan karena niat buruk, tapi karena manusia akan mengoptimalkan apa yang diukur (Goodhart’s Law). Jika kamu melacak jumlah baris kode, kamu akan mendapatkan lebih banyak baris. Jika melacak kecepatan, kamu akan mendapatkan estimasi yang membengkak.

Pendekatan senior: untuk setiap indikator, minta dua indikator. Satu untuk kecepatan, satu untuk kualitas atau risiko. Tekankan menginterpretasi tren, bukan sekadar angka ambang batas. Tujuannya adalah wawasan, bukan pengawasan.

16. Mengakui「saya tidak tahu」lebih menciptakan rasa aman daripada pura-pura paham

Insinyur senior yang mengatakan「saya tidak tahu」bukan menunjukkan kelemahan, tapi memberi izin. Saat pemimpin mengakui ketidakpastian, itu memberi sinyal: ruangan ini aman untuk orang lain. Saya pernah melihat tim yang dipimpin insinyur senior yang tidak pernah mengakui kebingungan, dan itu sangat merugikan: masalah tidak ditanyakan, asumsi tidak dipertanyakan, insinyur junior diam karena mereka pikir mereka satu-satunya yang tidak paham. Tunjukkan rasa ingin tahu, dan kamu akan mendapatkan tim yang benar-benar belajar.

17. Konteksmu lebih panjang umur dari pekerjaan apa pun yang pernah kamu lakukan

Di awal karir, saya fokus pada pekerjaan dan mengabaikan jaringan relasi. Itu kesalahan. Berinvestasi dalam hubungan (dengan kolega di dalam dan luar perusahaan) selama puluhan tahun sangat bermanfaat. Mereka yang pertama mendengar peluang, membangun jembatan lebih cepat, mendapatkan rekomendasi posisi, dan berkolaborasi dengan orang yang sudah dipercaya bertahun-tahun. Pekerjaan tidak selamanya, tapi relasi adalah abadi. Bangunlah hubungan dengan rasa ingin tahu dan kemurahan hati, bukan transaksi.

18. Sebagian besar peningkatan performa berasal dari「menghapus pekerjaan」bukan「algoritma cerdas」

Ketika sistem melambat, nalurimu adalah menambah: cache, paralelisme, algoritma lebih pintar. Kadang itu benar, tapi saya melihat lebih banyak peningkatan performa dari bertanya: 「Apa saja yang kita hitung dan tidak perlu?」 Menghapus pekerjaan yang tidak perlu hampir selalu lebih berpengaruh daripada mempercepat pekerjaan penting. Kode tercepat adalah kode yang tidak pernah dijalankan.

19. Keberadaan proses adalah untuk mengurangi ketidakpastian, bukan menciptakan dokumen

Proses terbaik memudahkan koordinasi, menurunkan biaya kegagalan. Proses terburuk adalah「birokrasi drama」—keberadaannya bukan untuk membantu, tapi untuk menyalahkan saat terjadi masalah. Jika kamu tidak bisa menjelaskan bagaimana proses mengurangi risiko atau meningkatkan kejernihan, mungkin itu hanya beban. Jika orang menghabiskan lebih banyak waktu mencatat daripada bekerja, itu masalah besar.

20. Akhirnya, waktu akan lebih berharga daripada uang, bertindaklah sesuai itu

Di awal karir, kamu menukar waktu dengan uang, itu tidak masalah. Tapi suatu saat, cara perhitungan akan berbalik. Kamu akan menyadari bahwa waktu adalah sumber daya yang tidak bisa diperbarui. Saya pernah melihat insinyur senior kelelahan mengejar pangkat berikutnya, mengoptimalkan beberapa persen gaji. Ada yang mendapatkannya, tapi kebanyakan kemudian meragukan apakah itu sepadan dengan apa yang mereka korbankan. Jawabannya bukan「jangan bekerja keras」tapi「ketahui apa yang kamu perdagangkan, dan lakukan secara sadar」。

21. Tidak ada jalan pintas, tapi ada efek majemuk

Keahlian profesional berasal dari latihan sengaja—sedikit di luar kemampuanmu saat ini, refleksi, pengulangan, bertahun-tahun. Tidak ada versi ringkasnya. Tapi harapannya: ketika belajar menciptakan pilihan baru, bukan sekadar pengetahuan acak, itu akan menghasilkan efek majemuk. Menulis (untuk kejernihan), membangun komponen yang dapat digunakan kembali, mengumpulkan pelajaran pahit menjadi panduan operasional. Insinyur yang memandang karir sebagai「efek majemuk」bukan「lotere」biasanya bisa berjalan jauh.

Pemikiran terakhir

21 poin ini terdengar banyak, tapi inti sebenarnya hanya beberapa: tetaplah penasaran, tetap rendah hati, dan ingat bahwa pekerjaan selalu berhubungan dengan manusia—termasuk pengguna produk yang kamu bangun dan rekan satu tim yang membangun bersama.

Karir insinyur sangat panjang, cukup panjang untuk membuatmu gagal berkali-kali dan tetap sukses. Insinyur yang paling saya kagumi bukan yang tidak pernah salah, melainkan yang belajar dari kesalahan, berbagi penemuan, dan gigih.

Jika kamu baru memulai perjalanan ini, ketahuilah bahwa seiring waktu, perjalanan ini akan menjadi semakin menakjubkan. Jika sudah bertahun-tahun, semoga beberapa poin ini bisa menyentuh hati dan memberi inspirasi.