Pengakuan Seorang Pengembang Perangkat Lunak: Tidak Ada Lagi Sensor Diri

• Seorang pengembang yang selama berbulan-bulan berhenti menulis dan beraktivitas online karena rasa takut memutuskan untuk berhenti menyensor diri, lalu mengakui kekurangan teknis dan pribadi yang selama ini tidak bisa ia akui
• Mengakui bahwa ia tidak memahami konsep polymorphism selama lebih dari 10 tahun, kehilangan kemampuan SQL, dan selama ini mendeploy sebagian besar kode tanpa pengujian otomatis
• Saat mencoba menyesuaikan diri dengan perubahan tech stack perusahaan, ia menghentikan pembelajaran C# dan Blazor, masih mencintai Ruby tetapi tidak bisa menggunakannya secara profesional, serta merasakan beban psikologis karena manajer dan rekan kerja membaca blognya
• Pengalaman mengalami perundungan siber setelah mengirim PR yang ditulis dengan AI, juga pandangan jujurnya tentang kerja jarak jauh dan tidak perlunya proses pengembangan yang dikustomisasi di dalam organisasi
• Ditutup dengan tekad untuk melepaskan rasa takut dan terus melanjutkan pembelajaran berkelanjutan serta menulis secara terbuka tanpa sensor diri lagi

---

Awal: pemicu untuk berhenti takut dan berhenti menyensor diri

• Sejak April ada masa ketika ia terlalu takut untuk bisa memublikasikan tulisan, dan sampai memutus semua aktivitas di media sosial, news aggregator, dan forum
  • Ia merasa keadaan ini tidak bisa diteruskan, lalu memutuskan untuk kembali menulis dengan melampaui rasa takut itu
• Ia hidup sambil menutupi rapat-rapat dasar yang lemah karena tak ingin itu terlihat, tetapi akhirnya mulai melihat bahwa banyak pengembang sebenarnya bekerja dengan celah pengetahuan yang mirip
  • Cara belajarnya selama ini mirip slime mold yang tumbuh terlalu besar hanya di area yang dipakai, sementara pengetahuan yang tidak digunakan mengering begitu saja
• Belakangan ini ia mulai mengisi ulang dasar-dasar itu, dan saat menyusun kembali apa yang dipelajari dalam bentuk tulisan dan ucapan, muncul rasa yang lebih ringan untuk mengakui bahwa “saya tidak tahu”
• Dengan benar-benar merasakan bahwa dasar bisa dipelajari kembali, ia mendapatkan keyakinan bahwa tidak ada kata terlambat

Waktu ketika ia tidak memahami polymorphism selama lebih dari 10 tahun

• Sejak 2012 ia merasa dirinya menulis kode berorientasi objek, tetapi akhirnya mengakui bahwa bahkan sampai sekitar satu tahun lalu ia masih belum benar-benar memahami polymorphism
  • Ia menghadapi kenyataan bahwa kode yang ditulis selama ini, alih-alih benar-benar berorientasi objek, lebih dekat ke pemrograman terstruktur
  • Ia bahkan belum pernah punya gagasan mengubah desain dengan mengganti percabangan kondisional menjadi kelas
• Setelah membaca tulisan Sandi Metz dan materi Martin Fowler, ia terlambat memahami konsep itu, dan menjadi jelas bahwa ada begitu banyak hal yang ia lewatkan

• Mengapa sulit mengungkapkan hal ini

  • Sulit baginya untuk mengungkap bahwa orang yang selama ini berperan menilai konsep berorientasi objek dalam wawancara rekrutmen ternyata justru tidak memahami polymorphism
  • Ini juga langsung memperlihatkan bahwa di awal karier ia lebih condong belajar alat daripada prinsip, dan tidak mudah menghadapi kenyataan bahwa karena tidak berlatar belakang jurusan CS, ia melewatkan terlalu banyak dasar

Pengalaman melupakan SQL

• Di masa lalu jelas pernah ada masa ketika ia mahir menulis JOIN dan subquery sambil mengerjakan latihan dari buku SQL
• Namun setelah pekerjaan yang berfokus pada frontend terus berlanjut dan tak ada lagi kebutuhan memakai SQL, pada suatu titik ia menyadari bahwa satu keterampilan teknis telah hilang sepenuhnya dari kepalanya
  • Query dasar masih teringat, tetapi untuk menjelaskan perbedaan left join dan outer join ia harus membuka dokumentasi lagi

• Mengapa sulit mengakuinya

  • Saat muda, ia percaya bahwa meski beberapa tahun berlalu, fakta dan keterampilan akan hidup kembali hanya dengan sedikit petunjuk
  • Kini ia merasakan kenyataan bahwa kemampuan itu tidak tetap sama, dan fakta bahwa SQL adalah keterampilan pertama yang hilang bulat-bulat dari ingatannya terasa sangat besar
  • Tidak mudah menulis secara terbuka tentang bertambahnya usia dan perubahan alur ingatan

Kenyataan bahwa ia telah mengembangkan perangkat lunak tanpa pengujian otomatis

• Ia mengakui bahwa lebih dari 95% kode yang telah dideploy selama ini berjalan di produksi tanpa pengujian otomatis
  • Di awal karier ia belum pernah berkenalan dengan konsep testing, dan pada masa Ember pun sulit untuk benar-benar memanfaatkan alat pengujian dengan baik
• Belakangan ia lebih sering menangani kode legacy, sehingga tidak punya cukup waktu untuk mengerjakan persiapan agar kode bisa diuji
  • Hanya di subsistem baru ia sempat menambahkan testing

• Mengapa sulit mengungkapkan hal ini

  • Ia merasakan pengakuan ini sebagai fakta yang paling merusak bagi kariernya
  • Dalam standar Uncle Bob, kode yang berjalan tanpa testing bisa dipandang sebagai sikap yang tidak etis, dan ia takut menghadapi jurang antara standar itu dan kenyataan hidupnya sendiri
  • Ia juga melihat kemungkinan besar bahwa jika hal ini diketahui publik, itu akan berujung pada penilaian negatif dalam proses rekrutmen, sehingga bahkan pencatatan proses belajarnya sendiri pun tertunda

Alasan ia tidak jadi mempelajari Blazor

• Ketika perusahaan memutuskan beralih dari Angular ke Blazor, ia adalah satu-satunya orang di tim tanpa pengalaman C#, sehingga mulai belajar dengan tergesa-gesa untuk mengejar ketertinggalan
• Beberapa bulan kemudian keputusan migrasi itu dibatalkan, dan motivasinya untuk belajar pun hilang total sehingga ia berhenti tanpa menuntaskan bukunya
• Pada dasarnya C# atau .NET memang bukan bahasa yang ingin ia gunakan untuk side project, dan semua itu memperlihatkan bahwa ia belajar murni demi pekerjaan

• Mengapa sulit menuliskan hal ini

  • Di tulisan sebelumnya ia sudah secara langsung berjanji akan menulis lanjutan, dan terasa makin tidak nyaman untuk menulis hal lain tanpa memenuhi janji itu
  • Karena tulisan terkait Blazor mencatat jumlah pembaca yang tinggi, ia takut mengakui bahwa arahnya berubah akan terlihat seperti kekalahan

Keinginan untuk lebih banyak memakai Ruby

• Ruby sampai sekarang tetap menjadi bahasa yang paling nyaman dan menyenangkan baginya, dan merupakan bahasa yang secara alami ia pilih untuk contoh, open source, kata, dan hackathon
• Namun sejak 2013, tidak pernah sekalipun ia menerima gaji untuk menulis Ruby, dan di pekerjaan ia memakai bahasa seperti TypeScript
• Karena ia sangat menyukai rekan-rekan yang ia temui di berbagai perusahaan, ia terus harus berkompromi pada bahasa demi memilih orang
• Ia ingin menggunakan waktu sepulang kerja dan akhir pekan untuk Ruby, tetapi karena kewajiban lain dan target belajar yang berbeda, realitasnya hampir tidak ada cukup waktu untuk benar-benar memakai Ruby

• Mengapa sulit mengungkapkan hal ini

  • Manajer dan CTO membaca blog ini, sehingga ia takut mengatakan ingin lebih banyak memakai Ruby akan dibaca sebagai sinyal ingin resign
  • Ia juga tidak ingin terlihat seperti orang yang memaksakan bahasa yang tidak familier ke dalam perusahaan

Pengalaman perundungan siber yang tetap menyakitkan meski sudah dewasa

• Saat ia mengirim patch kecil yang dibuat dengan LLM ke sebuah proyek open source dan membagikan pengalaman itu di forum online,
  ia menghadapi ledakan serangan pribadi seperti tidak kompeten, menjijikkan, dan berbahaya
• Serangan itu melampaui situs tersebut dan berlanjut ke situs web lain, email, SMS, dan telepon, membuatnya benar-benar merasakan bahwa dirinya tidak aman
• Ia meminta administrator forum untuk menghapus nama aslinya, tetapi justru lebih banyak PII ditambahkan ke profilnya,
  dan bahkan muncul teks palsu yang menyatakan bahwa ia mengarang cerita soal kontak dari luar, yang kemudian tertempel permanen
• Pada akhirnya ia tidak punya pilihan selain menonaktifkan akun dan meninggalkan situs itu

• Mengapa sulit menuliskan hal ini

  • Perundungan yang berlangsung beberapa hari itu adalah pengalaman online paling beracun yang pernah ia alami, dan dampaknya masih terasa sampai sekarang
  • Ia terus dihantui ketakutan bahwa para pelaku bisa datang lagi jika cerita ini dipublikasikan
  • Ia juga makin sulit membicarakannya karena memikirkan kemungkinan bahwa informasi palsu yang tertinggal di profilnya dapat berdampak buruk pada pekerjaan

Pemikiran bahwa tim SaaS tidak membutuhkan ‘proses khusus’

• Di industri perangkat lunak sudah ada proses yang dipoles selama puluhan tahun,
  dan pendekatan seperti Agile, Lean, Kanban, dan XP sudah hadir sebagai struktur yang terbukti
• Maka secara alami tumbuh keyakinan bahwa kemampuan perusahaan yang terbatas lebih baik difokuskan pada pengembangan produk daripada menciptakan proses baru

• Mengapa sulit mengatakan hal ini

  • Saat menulis, ia selalu punya kebiasaan bertumpu pada topik yang benar-benar ia pahami, dan dalam kasus ini pemicunya adalah proses pengembangan perangkat lunak kustom yang diusulkan rekan satu perusahaan
    • Ia merasa ada risiko tulisan itu terlihat seperti kritik publik terhadap rekan tertentu atau idenya
  • Ia mengagumi kemampuan menulis orang seperti Kent Beck dan Martin Fowler, yang mampu menjelaskan cara kolaborasi yang lebih baik tanpa sekaligus menargetkan rekan yang melakukan kesalahan secara frontal
    • Ia merasa dirinya belum memiliki keseimbangan seperti itu, sehingga ragu untuk menulis

Cara kerja jarak jauh menghambat kolaborasi yang sebenarnya

• Kerja jarak jauh memang menyelesaikan banyak masalah, tetapi sulit baginya menepis perasaan bahwa pengembangan perangkat lunak itu sendiri berjalan lebih baik ketika orang-orang berada di ruang yang sama
• Panggilan video adalah komunikasi berbandwidth rendah dan minim nuansa sensorik, sehingga kesadaran periferal hilang dan lebih sulit menangkap bahwa rekan sedang mengalami kesulitan
• Meminta bantuan juga terasa lebih membebani, dan cara berpikir spasial dengan whiteboard atau sticky note mudah rusak ketika dipindahkan ke alat online
• Konflik juga memburuk lebih cepat karena ada sifat bawaan yang membuat orang di balik monitor lebih mudah diberi citra sebagai musuh

• Mengapa sulit menuliskan hal ini

  • Setelah pandemi, perusahaannya menjadi perusahaan full remote, dan berkat itu ia bisa membangun kehidupan dengan tanah seluas 27 acre dan bahkan sapi perah untuk keluarga
  • Karena struktur hidupnya kini sulit dipindahkan ke kota, mengatakan bahwa ia tidak lebih menyukai kerja jarak jauh terasa seperti memberi kesan buruk pada tempat kerja saat ini maupun semua pekerjaan remote yang akan ia lamar nanti

Rencana setelah ini

• Melalui tulisan ini ia merasa telah kembali mengambil langkah pertama untuk melampaui rasa takut,
  dan ke depan ia berencana terus mempelajari dasar-dasar sambil menuliskan semua yang ia pelajari tanpa menyembunyikan apa pun
• Ia juga memberi tahu bahwa orang-orang yang punya pengalaman serupa, ingin membantu, atau penasaran dengan tulisan berikutnya
  bisa mengikuti kabarnya lewat Mastodon, RSS, dan mailing list

[GN⁺]

Opini Hacker News

• Saya belajar sesuatu dari seorang rekan yang sangat cerdas. Dia tidak takut pada hal yang tidak ia ketahui, dan terus bertanya sampai benar-benar paham. Saya merasa kepercayaan diri dan kesabaran yang dibutuhkan untuk belajar di depan umum itu luar biasa
• Saya suka kerendahan hati dan kejujuran tulisan ini. Tidak perlu malu karena tidak tahu. Sudah 37 tahun saya belajar, dan saya masih terus mempelajari hal-hal baru.
  Saya juga lebih suka bekerja di kantor, tapi itu bukan berarti saya mendukung RTO (kembali ke kantor). Itu cuma preferensi pribadi saya.
  Sepertinya kecemasan dan impostor syndrome di industri ini membuat orang jadi agresif. Kalau semua orang lebih jujur, rasanya kita semua akan lebih nyaman.
  Dan sebagai pengakuan, saya belum pernah menulis sesuatu yang lebih rumit dari Fibonacci dalam Lisp atau Haskell. Otak saya tidak bekerja dengan cara itu
  • Saya tidak setuju dengan pendapatmu tentang kerja jarak jauh, tapi karena kamu menyampaikannya sebagai pendapat pribadi, saya rasa itu tidak masalah.
    Namun, teks aslinya menuliskan pengalamannya sendiri seolah-olah itu adalah kebenaran objektif yang digeneralisasi. Terutama penggunaan sudut pandang orang kedua yang terasa arogan.
    Cara menyampaikannya sama pentingnya dengan isinya. Terutama untuk topik sensitif seperti kerja jarak jauh, pilihan kata harus hati-hati.
    Saya sendiri pernah harus bekerja jarak jauh karena masalah kesehatan keluarga, jadi nada tulisan itu terasa terlalu enteng dan membuat saya marah.
    Pada akhirnya, sebelum bilang orang lain terlalu sensitif, kita sebaiknya dulu melihat bagaimana kata-kata kita bisa berdampak
  • Saya juga tidak pernah menulis lebih dari Fibonacci sebelum ikut proyek berbasis Lisp. Setelah memakainya setiap hari, akhirnya saya terbiasa
  • Kenapa orang dimaki kalau bilang lebih suka kerja jarak jauh? Karena setelah pandemi orang-orang merasa telah mendapatkan kebebasan, lalu merasa itu dirampas lagi. Mungkin itu sebabnya reaksinya sangat keras
  • Belakangan ini para guru coding YouTube selalu merasa merekalah yang benar soal apa pun. Apa pun yang kamu lakukan, rasanya selalu dianggap salah
• Setiap kali mendengar pembicaraan soal kerja jarak jauh, saya jadi rindu era IRC. Waktu itu kita sudah sangat baik dalam kolaborasi jarak jauh.
  Alih-alih ngobrol di lorong, kami menyelesaikan masalah lewat chat tim, dan semua orang aktif membantu.
  Sekarang malah terasa kita kurang pandai memanfaatkan alat dibanding dulu
  • Sekarang banyak orang yang takut menulis di kanal publik. Dulu ada anonimitas, tapi sekarang berbasis nama asli jadi orang lebih berhati-hati.
    Karena ruang untuk bicara anonim makin berkurang, muncul budaya yang membuat orang sulit bicara bebas
  • Dulu saat memakai Slack di kantor, itu jauh lebih efisien daripada sekarang.
    Waktu itu kalau gagal, kita tinggal ke meja sebelah dan beres; sekarang kalau gagal, ya sudah mentok
  • Kerja jarak jauh di masa COVID bukan kerja jarak jauh yang sesungguhnya. Itu adalah keadaan terisolasi, dan budaya maupun prosesnya belum siap.
    Karena itu orang menyalahkan kerja jarak jauh atas rasa kesepian mereka
  • Saya pikir penyebab perubahan ini lebih karena perubahan kepribadian daripada demografi. Dulu banyak ‘anak-anak aneh’, dan mereka tidak takut bertanya.
    Sekarang lebih banyak orang yang tersosialisasi dengan rapi, sehingga lebih lemah dalam komunikasi asinkron
  • Memperbaiki bug lewat chat tidak sama dengan makna ‘menghirup udara yang sama’.
    Karena kepadatan membaca sinyal nonverbal lebih rendah, isyarat sosial juga berkurang
• Meski sama-sama di industri SaaS, rasanya seperti hidup di dunia yang sepenuhnya berbeda.
  Banyak developer mengikuti jalur karier ketimbang rasa tertarik.
  Saya sudah belajar ulang SQL sampai tiga kali. Karena teknologi terus berubah, mustahil mengingat semuanya.
  Yang penting bukan sintaks, melainkan kemampuan memecahkan masalah dan berkolaborasi.
  Saya rasa AI akan sulit menggantikan itu
• 95% kode yang saya tulis punya 0% test coverage. Itu terjadi di banyak negara dan banyak perusahaan. Saya penasaran apakah cuma saya yang begitu
  • Automated test adalah alat yang memberi rasa percaya diri saat pengembangan berulang. Setelah terbiasa, rasanya sulit kembali ke cara lama
  • Saya juga mirip begitu, tapi sekarang sedang mencoba berubah. Menambahkan test belakangan ke proyek yang tidak punya test itu benar-benar sulit
  • Ada sisi di mana test itu terlalu dibesar-besarkan. Kadang memberi rasa aman yang keliru. Banyak juga bahasa yang memang tidak cocok untuk testing
• Suasana orang-orang yang bekerja di sekitar kita membantu memicu fokus.
  Ada efek penularan fokus. Ruang kerja bersama bisa meningkatkan produktivitas
  • Saya juga tipe seperti itu. Tapi perusahaan memaksa ‘clean desk policy’, dan itu membuat saya tidak nyaman. Saya butuh lingkungan yang dipersonalisasi
  • Saya merasakan efek serupa di kafe yang ramai. Produktivitas orang lain memacu saya
  • Ini mirip konsep ‘body doubling’ pada ADHD
  • Saya juga lebih suka bekerja di kantor, tapi ruang dengan pintu itu wajib.
    Pintu adalah alat terbaik untuk mengatur kolaborasi dan fokus.
    Dibanding status ‘away’ online, pintu fisik memberi sinyal yang jauh lebih jelas
  • Tapi tidak semua orang bekerja baik di lingkungan seperti itu.
    Demi fokus seseorang, memaksa orang lain datang ke kantor itu tidak manusiawi
• Tulisan ini berani. Tapi ini juga menunjukkan dengan jelas masalah menggeneralisasi pengalaman pribadi.
  Bukan kerja jarak jauhnya yang buruk, mungkin saja itu pengalaman bekerja di perusahaan dengan sistem pendukung yang buruk
• Penulis terlalu keras pada dirinya sendiri. Mengakui bahwa kita tidak tahu memberi rasa lega.
  Saya juga sering bilang, “Saya tidak tahu.” Itu ciri orang dengan EQ tinggi
  • Atasan saya dulu suka saat saya bilang “Saya tidak tahu.” Kejujuran membangun kepercayaan
  • Di tempat kerja itu tidak apa-apa, tapi secara online sulit mengatakan “Saya tidak tahu” karena khawatir soal reputasi
  • Saat wawancara dan ditanya soal git rebase, saya rasa yang lebih penting daripada detail teknis adalah kemampuan menggunakannya dalam praktik
• Saya suka kejujuran penulis. Saya juga punya pengalaman serupa.
  Saat live coding dengan Kotlin, saya panik karena tidak bisa mengingat sintaks switch.
  Itu membuat saya sadar bahwa bahasa yang dipakai setiap hari pun bisa cepat terlupakan
  • Saya juga selalu mencari lagi sintaks switch. Kalau jarang dipakai, wajar kalau lupa
  • Kalau makin banyak developer yang menua, saya rasa kita akan lebih toleran terhadap ‘momen lupa’ seperti ini
  • Semua orang melakukan kesalahan. Bahkan atasan pun kadang lupa shortcut untuk paste
  • Kalau jarang dipakai, kemampuan teknis cepat menurun, tapi saat dipakai lagi biasanya cepat kembali.
    Konsep bertahan lama, tapi detail sintaks cepat hilang
• Awalnya saya kira tulisan ini akan membahas lenyapnya developer karena AI.
  Tapi kenyataannya, bahkan untuk membicarakan kecemasan itu pun suasananya terasa sulit.
  Saya juga menikmati menulis kode dengan Claude, tapi pada saat yang sama ada rasa takut.
  Kalau kita adalah generasi yang paling memahami hakikat perubahan yang akan datang, maka kita perlu membicarakannya
  • Kode yang dibuat Claude tidak akan lebih baik daripada kode manusia. Hanya saja kecepatan produksinya meningkat.
    Masalahnya, bisa jadi itu hanya meningkatkan produktivitas orang yang tidak punya kemampuan
  • Beberapa tahun ke depan, kita kemungkinan tetap menjadi team lead bagi AI agent.
    Tapi kalau perusahaan mulai memakai AI sebagai manajer, ruang bagi developer manusia akan makin sempit.
    Mulai sekarang kita perlu bersiap beralih ke peran seperti konsultan efisiensi AI
  • Saya pribadi akan berkolaborasi dengan AI atau melakukan hal menarik lain. Pemrograman bukan segalanya
  • Perusahaan yang punya kebijakan “AI doomer” itu jelas budaya organisasi yang toksik. Harus segera cari kerja lain