Tidak Melakukan Apa-Apa di Tempat Kerja

• Kinerja software engineer lebih ditentukan oleh pekerjaan berimpact tinggi pada saat yang tepat daripada lebih banyak waktu atau lebih banyak kode, dan dalam keseharian pendekatan 80% utilisasi dengan menghabiskan sekitar 20% hari kerja jauh dari komputer itu efektif
• Di organisasi engineering besar, peluang yang bergantung pada waktu seperti mendukung kontrak besar, meredakan insiden, atau merilis fitur utama dapat menciptakan nilai besar, dan jika sudah terlalu sibuk peluang ini mudah terlewat
• Jika terus-menerus menangani tiket prioritas rendah, kita jadi tidak melihat situasi tim lain, pembaruan tim, atau insiden yang sedang berlangsung, dan manajer juga akan sulit menilai bahwa kita punya kelonggaran
• Waktu untuk tidak melakukan apa-apa memungkinkan pemulihan dari stres, ketenangan saat merespons insiden, ide baru, dan fokus pada pekerjaan penting
• Menyisakan ruang secara sengaja dalam keseharian, lalu hanya masuk 100% pada periode dengan imbal hasil sangat besar, menciptakan kondisi yang lebih mudah untuk menjadi engineer berkinerja tinggi

---

Peluang Berimpact Tinggi

• Banyak engineer seharusnya bekerja lebih sedikit; ini bukan berarti menulis lebih sedikit kode atau membuat lebih sedikit perubahan, melainkan mengurangi waktu benar-benar bekerja dalam sehari dan bahkan bekerja dengan tempo lebih lambat saat bekerja
• Dalam kondisi normal, targetkan tingkat utilisasi 80%, dan ketika tidak ada proyek bertekanan tinggi, habiskan 20% waktu kerja jauh dari komputer
• Kinerja perusahaan teknologi sangat dipengaruhi oleh kejadian yang tidak biasa, dan banyak perubahan yang menghasilkan dampak terbesar bisa tercapai dengan jumlah kerja yang mengejutkan kecil
• Dalam pengembangan software tidak ada poin untuk usaha itu sendiri; yang penting adalah menyelesaikan masalah yang tepat pada waktu yang tepat

• Tiga contoh yang mungkin terjadi di organisasi besar

  • Mendukung fitur atau perbaikan bug saat perusahaan sedang berupaya menutup kontrak enterprise besar dapat membantu kontrak itu jadi terlaksana
  • Fitur tersebut tidak harus luar biasa; kadang cukup dengan menunjukkan kemauan dan kemampuan untuk membuat perubahan yang spesifik
  • Mencegah atau meredakan insiden sejak awal dapat mengurangi kehilangan pendapatan langsung saat insiden, serta kehilangan pendapatan setelahnya akibat pelanggan hengkang atau menolak kontrak
  • Hanya dengan mengetahui bahwa feature flag yang tepat harus dimatikan saja bisa menghemat uang dalam jumlah besar
  • Saat perusahaan hendak merilis fitur penting, keberhasilan dan kegagalan bisa bergantung pada perubahan kecil yang sulit ditemukan
  • Contohnya menambahkan field baru dengan cepat ke pengaturan pengguna, atau memperbaiki fitur ekspor data enterprise lama yang tidak disentuh selama bertahun-tahun
  • Keakraban dengan sistem bisa menjadi perbedaan antara perubahan yang butuh beberapa jam dan perubahan yang butuh seminggu

• Ketergantungan pada waktu

  • Semua peluang ini bergantung pada waktu; setelah login di pagi hari, kita tidak bisa secara acak langsung menutup kontrak besar, meredakan insiden, atau cepat membuat fitur utama
  • Berada di tempat dan waktu yang tepat saja tidak cukup; kita juga harus belum terlalu sibuk

Menjaga Kelonggaran

• Jika terus menangani pekerjaan prioritas rendah dan mempertahankan kondisi utilisasi 100%, kita akan kehilangan peluang pekerjaan berimpact tinggi dalam dua cara
• Pertama, jika terlalu sibuk, kita bahkan tidak menyadari peluang itu ada
  • Waktu untuk berbicara dengan orang yang mengerjakan hal lain, membaca pembaruan tim, atau melihat insiden yang sedang berlangsung jadi berkurang
  • Cara terbaik untuk ikut dalam pekerjaan berimpact tinggi adalah menawarkan keahlian kita sendiri
• Kedua, jika selalu terlihat sibuk, manajer akan sulit melibatkan kita
  • Jalur terbaik kedua untuk terlibat adalah ketika manajer atau product manager menilai bahwa “orang ini punya ruang untuk membantu” lalu menghubungkan kita
  • Manajer dan product manager sering kali lebih tahu pekerjaan berimpact tinggi apa yang sedang berjalan karena mereka masuk ke rapat yang tidak dihadiri engineer

Tidak Melakukan Apa-Apa

• Jika kita perlu mengosongkan waktu untuk pekerjaan berimpact tinggi dan tidak boleh hanya terus menutup tiket, maka pada level menit-per-menit kita memang boleh benar-benar tidak melakukan apa-apa
• Software engineering bisa menjadi pekerjaan yang penuh stres, tetapi biasanya bukan pekerjaan yang terus-menerus penuh stres
  • Stres biasanya muncul dalam situasi seperti insiden sesekali, pekerjaan mendesak bertekanan tinggi, atau PHK yang baru terjadi
• Jika kita mendekati periode kerja yang tekanannya relatif rendah dengan intensitas mendesak, maka saat benar-benar harus menangani situasi bertekanan tinggi kita sudah telanjur lelah dan sensitif
• Bahkan di periode kerja bertekanan tinggi, sikap tidak melakukan apa-apa tetap bisa membantu
  • Engineer yang tidak terbiasa on-call sebaiknya tidak terburu-buru, dan lebih baik mengambil beberapa napas sebelum masuk ke panggilan atau sebelum berbicara
  • Dalam respons insiden, secara umum kita perlu “berpikir dengan gerakan lambat”
• Sebagian besar insiden akan terselesaikan sendiri, dan perubahan “mungkin membantu” yang dimasukkan terburu-buru saat insiden sering kali justru memperburuk keadaan daripada memperbaikinya
• Secara umum, hanya dengan menghindari panik saja kita sudah menangani respons insiden lebih baik daripada kebanyakan engineer
• Waktu untuk tidak melakukan apa-apa menjadi ruang tempat sesuatu bisa terjadi
  • Ketika otak mendapat kesempatan untuk beristirahat, kemungkinan munculnya ide baru meningkat
  • Saat mendapat pekerjaan penting, kita bisa fokus sepenuhnya tanpa harus sekaligus menangani tiga hal lain di belakang layar
  • Saat tidak sibuk, kita punya waktu untuk sekadar melihat keadaan dan menyerap data baru

Sengaja Tidak Mengerjakan Hal Tertentu

• Banyak engineer merasa tidak nyaman ketika melihat ada pekerjaan yang bisa dilakukan tetapi memilih tidak mengerjakannya
• Kecenderungan ini adalah ciri psikologis yang dimiliki banyak software engineer, dan sampai batas tertentu justru yang membuat mereka cocok untuk pekerjaan ini
• Untuk menciptakan waktu tidak melakukan apa-apa, kadang kita perlu memaksa diri agar sengaja tidak ikut campur

• Menghindari glue work

  • Engineer pada umumnya sebaiknya menghindari glue work
  • Glue work mencakup hal-hal seperti membuat orang saling berbicara, memperbarui dokumentasi untuk pekerjaan yang tidak kita pimpin, atau mencari sumber daya untuk menyelesaikan utang teknis
  • Sebagian besar glue work mencerminkan fakta bahwa organisasi tidak secara eksplisit menempatkan pekerjaan itu sebagai prioritas
  • Jika organisasi memang menjadikannya prioritas, tidak perlu seseorang sukarela mengambilnya sendiri
  • Jika hal yang tidak diprioritaskan organisasi memang aman untuk diabaikan, maka mengambilnya adalah pemborosan waktu dan bisa mengganggu manajer
  • Bahkan jika hal yang tidak diprioritaskan organisasi itu sebenarnya kesalahan besar, bila individu menanganinya sebagai gantinya, perusahaan jadi tidak merasakan akibat dari kesalahannya sendiri dan yang menanggung biayanya adalah karier serta kesehatan mental individu itu
  • Ini transaksi yang buruk bagi individu, contoh yang buruk bagi rekan junior, dan preseden buruk ketika setelah burnout akan ada orang lain masuk ke posisi yang sama
  • Jika akibatnya benar-benar serius, lebih baik biarkan akibat itu terjadi agar organisasi merasakan sakitnya dan mengubah kebijakan

• Terlalu suka membantu membuat kita rentan

  • Sikap yang terlalu ingin membantu membuat kita rentan terhadap orang-orang yang ingin menarik tenaga kerja tanpa imbalan
  • Di perusahaan teknologi ada banyak orang yang ingin mengambil pekerjaan dari software engineer tanpa kompensasi yang setara
  • Ini berbeda dari pekerjaan yang datang lewat jalur normal dan dihargai lewat promosi, bonus, atau gaji reguler
  • Pekerjaan yang bermasalah datang melalui jalur informal, dan berasal dari orang yang tidak punya kemampuan atau kemauan untuk secara resmi mencatat pekerjaan itu atas nama kita
  • Contohnya, product manager dari organisasi lain meminta kita mengambil statistik tertentu karena kita pandai membuat query data
  • Contoh lain, engineer dari tim lain meminta pair programming tetapi pada praktiknya membuat kita menulis semua kodenya dan perubahan diajukan atas nama mereka
  • Melakukan pekerjaan seperti ini sampai batas tertentu tidak masalah, dan membantu orang saat memungkinkan juga boleh
  • Hanya saja kita harus bisa memberi tekanan balik dengan menolak atau membalas beberapa jam atau beberapa hari kemudian

• Jangan terlalu banyak berinvestasi pada pekerjaan yang kemungkinan akan hilang

  • Sebaiknya jangan terlalu banyak berinvestasi pada pekerjaan yang kemungkinan akan hilang
  • Saat product designer masih menyusun keinginannya secara real-time, jangan menulis ulang seluruh halaman setiap jam
  • Contohnya ketika pukul 9 pagi mereka ingin header halaman dengan satu cara, pukul 10 diubah, lalu pukul 11 berubah lagi
  • Dalam situasi seperti ini, lebih baik tidak melakukan apa-apa dulu, misalnya pergi berjalan kaki, lalu menulis ulang sekali pada sore hari berdasarkan desain terbaru
  • Ide besar dari manajer yang tidak punya cukup dorongan politik juga merupakan kasus yang umum
  • Sering kali kita bisa membiarkan waktu berjalan sampai proyek itu dibatalkan
  • Namun jika salah menilai tingkat dukungan politik proyek, kita bisa terlihat malas dan berakhir harus buru-buru menghasilkan sesuatu

Kesimpulan

• Saran dan alat dalam software engineering sering kali berfokus pada kemampuan memperluas upaya teknis agar bisa mengerjakan lebih banyak hal sekaligus, mengambil proyek dengan cakupan lebih besar, dan menulis lebih banyak kode
• Keberhasilan dalam software engineering tidak ditentukan oleh hal-hal tersebut
• Keberhasilan ditentukan oleh kemampuan melakukan hal yang benar pada waktu yang benar, dan untuk itu kita perlu sengaja menyisakan sebagian tenaga dalam pekerjaan sehari-hari
• Menjadi engineer berkinerja tinggi dengan 80% usaha itu mungkin, dan justru lebih mudah mengurangi kesalahan bodoh akibat stres serta lebih mudah melompat ke pekerjaan berimpact tinggi yang menghasilkan keuntungan besar
• Ada juga masa ketika kita memang perlu masuk dengan usaha 100%; dua atau tiga kali setahun kita bisa bekerja dalam waktu panjang, dengan fokus tinggi, dan memikirkan masalah sepanjang hari
• Cara kerja seperti ini sebaiknya disimpan untuk saat imbal hasilnya benar-benar besar, dan pada periode lainnya lebih baik bekerja dengan relatif santai

[GN⁺]

Komentar Hacker News

• Tulisan yang bagus, tapi pada akhirnya lagi-lagi masalahnya adalah insentif
  Benar bahwa mencegah atau meredam masalah lebih awal bisa menghemat banyak uang, tetapi yang berulang kali saya lihat di banyak perusahaan adalah pencegahan masalah tidak dihargai, sementara menumpuk banyak bahan bakar lalu memadamkan kebakaran yang tak terhindarkan justru mendapat pengakuan dua kali lipat. Bahkan di organisasi yang “baik” pun begitu
  Saya tidak pernah bisa benar-benar larut dalam politik ala teori permainan berupa sengaja merilis kode sampah dengan cepat lalu mengambil kreditnya. Karena saya terlalu bangga pada hasil kerja saya sendiri
  Selama lebih dari 5 tahun saya merawat dan mengembangkan framework untuk menghilangkan sekumpulan masalah yang menyiksa versi produk sebelumnya, tetapi tim partner yang merilis kode sampah hingga menimbulkan insiden lalu memperbaikinya dipuji secara terbuka, sementara tim kami tidak mendapat kredit apa pun justru karena insiden seperti itu tidak terjadi. Karena ini adalah pencegahan yang tidak bisa diukur

  • Secara teori permainan, tim yang berulang kali menimbulkan masalah hingga kehilangan pelanggan seharusnya dihukum setimpal. Kalau tidak, mungkin masalah akibat rilis cepat memang tidak terlalu memengaruhi retensi pelanggan sebesar yang dibayangkan
  • Cukup taburkan Thread.sleep(100000) di mana-mana lalu tunggu sampai semuanya rusak. Nanti Anda jadi orang yang panjang lebar dan heroik melakukan pemadaman kebakaran sampai Jumat tengah malam setelah rilis
    Jangan tanya kenapa itu dihargai, dan tentu saja kadang organisasi mengubah standar penghargaan ke hal lain
  • Soal kalimat “kita tidak mendapat kredit karena tidak adanya insiden itu tidak bisa diukur”, secara filosofis saya rasa bahkan berat dari ketiadaan pun bisa diukur
  • Sayangnya itu sepenuhnya benar, tapi bukan satu-satunya cara
    Pendekatan yang jujur adalah membuat beberapa alat yang rumit namun esensial, sehingga engineer lain terus datang mencari saya. Saya jadi sangat pandai menemukan penyalahgunaan alat tertentu, dan ketika bisa menunjukkan bug di kode orang lain dalam hitungan detik, saya terlihat jauh lebih pintar daripada kenyataannya
    Idealnya alat itu andal, berguna, tetapi juga rumit. Saat developer lain memakai alat itu lalu menemui bug, mereka akan terus datang lagi, dan saya bisa menunjukkan kesalahan mereka. Agar strategi ini berhasil, kesalahannya hampir selalu harus ada di pihak mereka, dan kode saya harus kokoh
    Jika ditemukan bug sungguhan di kode saya, sebaiknya bug kecil di kasus tepi, saya harus sangat rendah hati dan minta maaf, lalu memuji developer yang menemukan bug rumit itu di rapat tim
    Ini lebih baik daripada mendapat kredit dengan memperbaiki kode buggy buatan sendiri. Cara itu mungkin ampuh pada manajer atau junior, tapi engineer senior lain akan membencinya
    Cara membuat alat yang rumit tapi stabil ini akan membuat Anda berulang kali, sering kali jauh lebih dari dua kali, mendapat pengakuan, dan pengakuan dari developer lain pada akhirnya akan sampai juga ke telinga manajer. Pemimpin yang cerdas tahu sinyal ini lebih baik daripada demo yang mencolok
    Pemimpin yang membanjiri pujian hanya karena developer tertentu bisa membuat prototipe dengan cepat pada akhirnya akan belajar dari kesalahan. Pendiri muda tampaknya sering melewati tahap memuji hal-hal yang dangkal ini
  • Saya setuju jika dibingkai sebagai pertentangan seperti itu, tetapi perlu sedikit nuansa
    Sebagian dari pekerjaan membuat produk atau bundel fitur itu lebih dekat ke eksplorasi daripada engineering yang hebat. Kadang lebih baik membuat dua fitur yang cukup bagus untuk mengetahui apa yang bernilai bagi pengguna, daripada membuat satu fitur yang benar-benar kokoh
    Saya selalu cenderung ke kubu “coba saja dulu lalu kita lihat”. Meski begitu, saya tetap bersyukur ada orang dengan sikap berbeda yang membuat git
    Ada keseimbangan di sini, dan itu bergantung pada seberapa besar masalah yang sedang dihadapi merupakan masalah eksplorasi. Di sini “kekokohan” berarti hal seperti ketersediaan, kemudahan pemeliharaan, dan kemungkinan foto sensitif pengguna bocor, dari sudut pandang engineering murni

• Bagian tentang “orang-orang yang ingin memeras pekerjaan tanpa imbalan” itu layak dibingkai dan dipajang
  Terutama situasi seperti manajer produk dari organisasi lain berkata, “Karena Anda jago query data, bisa bantu ambil statistik untuk X?” atau engineer dari tim lain meminta “pair”, tapi pada akhirnya saya yang menulis semua kodenya lalu dia diam-diam mengirim perubahan atas namanya sendiri

  • Di tempat saya bekerja, Principal Engineer adalah jabatan yang diinginkan semua orang, imbalannya juga bagus, tetapi jarang tercapai. Semua orang yang pernah bekerja dengan saya dalam jabatan itu sangat kompeten dan juga menyenangkan secara pribadi, dan saya pernah bertanya pada salah satu dari mereka bagaimana dia mendapatkan jabatan itu di perusahaan sebelumnya
    Strateginya adalah membantu orang dan secara aktif memberikan kredit kepada orang lain. Dalam 1:1 atau rapat dengan beberapa lapis manajemen, dia terus menekankan nilai pekerjaan anggota timnya, dan karena itu dia mendapatkan simpati tim
    Beberapa tahun kemudian, ketika proyek bernilai besar tertinggal dari jadwal dan beberapa engineer kunci keluar dari perusahaan, dia bekerja lembur dan membawa proyek itu menuju keberhasilan, lalu pada penilaian berikutnya dia mendapat jabatan dan kenaikan gaji
    Proyek itu memang menjadi dorongan terakhir, tetapi bukan hanya dia engineer yang lembur. Dia menganggap promosinya datang berkat itikad baik yang dibangunnya dengan memberikan kredit kepada orang lain selama masa kerjanya
  • Menurut saya ini bergantung pada seberapa terlibat atasan Anda. Salah satu tipe orang yang paling tidak ingin saya ajak kerja sama adalah yang berkata “itu bukan tugas saya”
    Saya ingin bekerja dengan orang-orang yang melihat masalah dan mengusulkan solusi, entah itu tertulis di deskripsi pekerjaannya atau tidak
    Jika pekerjaan saya tidak diakui, itu adalah masalah kepemimpinan. Cara menolak mentah-mentah pekerjaan terasa seperti jalan menuju budaya organisasi yang kaku dan lambat
  • Kalimat yang layak dibingkai adalah “tolong buatkan tiketnya”
  • Benar, tapi saya tidak melihatnya sehitam-putih itu. Di luar mengurus kompensasi saya sendiri secara langsung, ada juga insentif untuk membantu perusahaan itu sendiri agar berhasil, jadi meski tidak mendapat parade, membantu permintaan kecil tetap bisa rasional
    Begitu juga, suatu hari saya mungkin butuh sesuatu dari rekan kerja, dan saat itu saya akan berterima kasih jika mereka membantu secara proaktif alih-alih mengusir saya dengan “silakan lewat kanal resmi”. Kanal resmi bisa memakan waktu jauh lebih lama
  • Perusahaan yang baik punya budaya, dan orang-orang saling membantu
    Percakapan saat makan siang bisa membantu orang memahami sesuatu
    Tetapi mengerjakan tugas berjam-jam untuk seseorang bisa jadi perkara yang berbeda sama sekali

• Bukan bermaksud menyindir, lebih ke pengamatan, tetapi di organisasi yang cukup besar atau birokratis, mencegah masalah lebih awal sulit mendapatkan penghargaan atau visibilitas. Capaian seperti itu masuk sebagai “memang sudah seharusnya dilakukan”
  Karena itu, orang yang piawai dalam politik kantor justru memilih membiarkan insiden terjadi lalu bergerak heboh pada daftar tindak lanjut. Kuncinya adalah jangan sampai insiden itu berkembang menjadi bencana, dan itu pekerjaan yang cukup rumit

  • Sudah belajar ini sejak awal di organisasi yang konservatif. Pencegahan itu berisiko. Lebih baik menyiapkan solusi untuk dipakai saat sesuatu benar-benar salah, karena barulah saat itu persetujuan bisa didapat
  • Semua contoh yang memberi dampak besar tampak seperti pekerjaan yang sulit diakui
    Kalau menyelamatkan kontrak penjualan, yang dapat tepuk tangan adalah tim sales, dan komisinya juga mereka yang terima. Saya tidak mendapat bagian sedikit pun
  • Bencana kadang juga menjadi sinyal yang bagus ke level atas bahwa ada masalah dalam organisasi. Kalau semua kebakaran dipadamkan secara heroik, atasan mungkin tahu, tetapi atasan dari atasan dari atasan akan melihat organisasi berjalan sangat baik dan semuanya serba hijau
    Kalau dibiarkan beberapa hal terbakar, atasan dari atasan dari atasan akan melihat apinya, dan mungkin ada perbaikan. Mungkin itu cara termudah untuk berkomunikasi dengan mereka
  • Intinya adalah apakah orang-orang menyadarinya. Saya pernah dengar di pemerintah daerah, mereka kadang memangkas program yang populer untuk memancing penolakan, lalu mengambil pujian saat program itu dipulihkan. Di sela-selanya mereka juga bisa menyelipkan kebijakan lain yang perlu tetapi tidak populer
  • Karier dan bonus sering dibangun lewat bermain jadi pahlawan

• Dulu saya pernah menulis setengah jadi ke arah ini, memakai analogi RPG fantasi. Kalau memainkan karakter yang memakai mana di game seperti itu, kita cepat belajar bahwa kalau mana dihabiskan di setiap pertarungan kecil lalu berjalan-jalan dalam keadaan kosong, saat benar-benar dibutuhkan nanti tidak akan ada apa-apa yang tersisa
  Energi mental yang dipakai untuk kerja pada dasarnya tidak jauh berbeda. Kalau menyisakan sedikit di tangki, saat hal tak terduga terjadi kita bisa memakainya secara strategis tanpa membahayakan kesehatan, yaitu burnout
  Kalau pernah satu party dengan pemain yang tidak bisa mengelola mana di game seperti itu, kita juga tahu orang itu bukan rekan tim yang terlalu baik

  • Saya pernah merasa bahwa kalau terlalu lama tidak cukup tertantang, melewati tantangan berikutnya bisa menjadi sangat sulit
    Di bidang apa pun, masa ketika kemampuan saya berada di puncak adalah saat ada cukup banyak pekerjaan di depan saya sehingga bisa dikerjakan konsisten seperti mesin, dan saya cukup dipercaya untuk bekerja menuju tujuan tanpa gangguan sehingga tidak perlu terus berhenti untuk menjelaskan. Keterampilan berkembang seperti kebakaran hutan dan pekerjaan selesai lebih cepat dari perkiraan
    Sayangnya, tempat kerja yang memanfaatkan struktur seperti itu sangat jarang. Terlalu banyak penghalang dan gangguan yang mencegah masuk ke deep work yang sesungguhnya
  • Kalau saya, saya akan menamatkan RPG dengan 29 Ether masih tersisa, padahal kalau dipakai dari awal permainan akan jauh lebih sedikit grinding-nya

• Kalau ingin merusak sistem, cukup jalankan baseline operation di 100%. Tidak ada ruang longgar dan tidak ada kapasitas untuk menampung permintaan baru, jadi gangguan kecil saja akan membuat sistem terus-menerus berada dalam mode gagal

  • Efisiensi adalah musuh dari ketahanan
  • Hanya saja, keruntuhan itu tidak benar-benar terjadi. Kalau engineer burnout atau menua, mereka tinggal merekrut orang baru, lalu siklusnya berulang
    Masalah dengan tulisan seperti ini atau buku seperti Peopleware / Slack adalah bahwa mereka tidak menyajikan metrik nyata yang cukup meyakinkan agar orang akuntansi mau mencoba pendekatan lain

• Analogi yang mengubah sudut pandang saya berasal dari “The Power of Full Engagement”. Kurang lebih isinya, “Kamu bertingkah seperti atlet ketahanan kelas dunia yang tidak punya off-season. Berhenti.”

• Ada banyak kebijaksanaan di sini. Selain menyisakan sebagian kapasitas untuk saat pekerjaan yang benar-benar bernilai tinggi datang, saya juga merasa rekayasa perangkat lunak bukan pekerjaan yang bisa dilakukan dengan baik jika kita terus sibuk tanpa henti
  Kalau tujuannya menulis kode secepat mungkin, jarang sekali hasilnya desain yang bagus. Tulisan ini juga tidak membahas sisi penting lainnya, yaitu cara bekerja di 80% kapasitas tanpa dimarahi manajer
  Ini perlu sedikit kehati-hatian dalam komunikasi dan estimasi pekerjaan. Salah satu nasihat bagus yang saya dengar dari developer senior yang lebih tua di pekerjaan pemrograman pertama saya masih saya ingat sampai sekarang: perkirakan dulu berapa lama sesuatu akan selesai, lalu gandakan sebelum mengatakannya ke manajer atau pengguna
  Seiring pengalaman bertambah, pengalinya mungkin turun dari 2x menjadi sekitar 1,5x, tetapi prinsipnya tetap berlaku

  • Kent Beck pernah bilang, entah di Good News Factory atau dalam sebuah ceramah, bahwa timnya tidak pernah menjanjikan lebih dari setengah jumlah yang mereka rasa sebenarnya bisa mereka kerjakan. Itu pendekatan yang baik untuk keberlanjutan
    Yang harus dioptimalkan dan dijadikan preseden adalah kemampuan mengirimkan hasil secara konsisten dalam jangka panjang, dengan kecepatan berkelanjutan. Ini permainan panjang, dan overpromising hanya akan mengikis kepercayaan. Justru kepercayaan itulah alat terbesar developer untuk mendapatkan ruang yang mereka butuhkan
    Janjikan lebih sedikit, bangun kepercayaan bahwa apa yang dikatakan akan dikerjakan memang dikerjakan, dan dapatkan ruang agar tidak burnout
    Semakin senior, terutama kalau sudah jadi lead, menetapkan batasan, menjaga perhatian, dan mencegah burnout memang menjadi bagian dari pekerjaan. Karena ada terlalu banyak cara untuk merusak diri sendiri
  • Ucapan “gandakan estimasi waktu sebelum mengatakan ke manajer atau pengguna” memang benar, tetapi saya penasaran apakah itu sudah mempertimbangkan Hukum Hofstadter
    Bahkan jika Hukum Hofstadter sudah diperhitungkan, pekerjaan tetap selalu memakan waktu lebih lama dari perkiraan
    https://en.wikipedia.org/wiki/Hofstadter%27s_law

• Dari sudut pandang orang yang banyak bekerja di posisi berhadapan langsung dengan pelanggan, jebakan terburuk yang berkali-kali saya temui adalah menjadi akrab dengan pelanggan yang membayar. Dalam posisi dipekerjakan sebagai ahli untuk membantu, kalau pelanggannya memang orang yang sangat baik, mengatakan tidak menjadi sangat sulit
  Yang lebih buruk adalah ketika orang itu bukan pengambil keputusan, melainkan berada dalam posisi dipaksa untuk menekan saya agar melakukan sesuatu. Sebagai ahli tepercaya, menolak itu mudah ketika pelanggan sendiri mengusulkan ide buruk, tetapi ketika atasannya yang tak pernah saya hadapi langsung memberi instruksi, saya ditempatkan pada posisi terlihat seperti biaya yang tidak berguna, atau menjadi yes-man yang meninggalkan monster di belakang
  Kadang saya iri pada orang yang kebanyakan bekerja secara internal. Setidaknya mereka masih bisa mencoba meyakinkan seseorang di level atas

• Bagian tentang pekerjaan glue ini menarik; saat bekerja di perusahaan besar, ini merupakan bagian yang eksplisit dalam evaluasi kinerja tahunan. Google menyebutnya “citizenship”, dan menurut saya itu istilah yang cukup tepat menangkap esensinya. Intinya adalah, “apa yang telah kamu buat menjadi lebih baik untuk orang lain di perusahaan”
  Di satu sisi memang agak aneh. Ini tidak ada di deskripsi pekerjaanku, jadi secara teknis ini pekerjaan tanpa bayaran, tetapi pada saat yang sama juga merupakan bagian dari ekspektasi resmi. Di sisi lain, menyenangkan bekerja di tempat di mana semua orang meluangkan sedikit waktu dan usaha untuk memperbaiki lingkungan bagi semua orang
  Jika dijadikan tuntutan yang eksplisit bagi semua orang, ini juga menjadi upaya untuk menghindari budaya beracun “saya engineer rockstar jadi sibuk mengerjakan hal penting, biar orang lain saja yang mengerjakan pekerjaan glue”. Dan “orang lain” itu biasanya perempuan, serta hampir pasti dibayar lebih rendah daripada engineer rockstar tersebut
  Tulisan asli memberi implikasi bahwa perusahaan seharusnya merekrut orang khusus untuk melakukan pekerjaan glue, tetapi pada praktiknya ini terdiri dari terlalu banyak potongan yang beragam sehingga hampir mustahil menyerahkannya kepada satu orang. Misalnya, jabatan apa yang bisa mencakup sekaligus “penulisan dokumentasi, wawancara software engineer, dan pengorganisasian acara offsite tim”
  Namun semua pekerjaan itu memang perlu, dan tuntutan citizenship membantu membagi beban itu dengan lebih adil
  Menurut saya, ungkapan yang lebih baik bukan “jangan lakukan pekerjaan glue”, melainkan “jangan jadi satu-satunya orang bodoh yang melakukan pekerjaan glue tanpa kompensasi”. Artinya, semua orang harus mengambil sebagian, dan kita perlu mendorong budaya di mana itu diakui secara resmi sebagai pekerjaan

• Beroperasi dengan utilisasi 80% adalah kebiasaan yang baik, dan membantu ketika tidak ada manajer bergaya mandor yang menuntut 100% sepanjang hari setiap hari. Orang seperti itu salah mengartikan software engineer yang berpikir dengan tenang dan nyaman sebagai kemalasan pasif
  Karena itu, kerja jarak jauh adalah cara terbaik untuk menyisakan sebagian utilisasi sebagai cadangan dan menjaga kesehatan mental
  Sedikit pekerjaan glue dapat membuat kehidupan kerja semua orang jauh lebih baik, dan jika tidak ada yang tahu caranya, itu bisa menjadikan saya orang yang sangat dibutuhkan atau pahlawan di tim

  • Menurut saya 80% pun masih tinggi. Dan ini berbeda untuk tiap developer
    Mengingat cara saya kesulitan untuk belajar, berpikir, dan mulai bekerja, 80% versi saya secara teknis sama sekali tidak sama dengan 80% milik rekan yang lebih kuat secara teknis
    Jika kecenderungan neurodiversitas sedikit saja diperhitungkan, angka 80 milik seseorang bisa jadi 120 bagi orang lain