Skill Coding Lo Hebat, Tapi Attitude Lo Bikin Repot

Di Dunia Tech, Lo Bisa Jadi Jenius Coding, tapi Kalau Lo Jadi "Beban Tim", Nggak Ada yang Mau Satu Tim Sama Lo

Bro, mari kita mulai dengan sebuah skenario klasik yang mungkin pernah lo temui di kantor atau di komunitas teknologi. Kenalin, sebut saja namanya Budi. Budi ini adalah seorang software engineer yang skill teknisnya nggak ada obat. Dia adalah dewa JavaScript, master ReactJS, dan bisa men-debug bug misterius di APIbackend yang sudah membuat lima orang engineer senior pusing selama tiga hari. Kalau ada masalah teknis yang mustahil, Budi adalah jawabannya.

Tapi...

Setiap kali ada sesi code review, komentarnya selalu pedas, singkat, dan meremehkan. "Ini logikanya apa, sih? Anak magang juga bisa lebih bagus." Setiap kali ada sesi brainstorming, dia akan memotong ide semua orang sebelum mereka selesai bicara. Setiap kali kodenya dikritik balik, dia akan defensif dan tidak mau menerima masukan. Dan dia tidak akan pernah mau menulis dokumentasi, karena merasa itu "bukan kerjaan engineer sejati".

Akibatnya? Meskipun Budi adalah aset teknis yang luar biasa, tidak ada seorang pun di tim yang benar-benar suka atau mau bekerja sama dengannya. Proyek yang ada Budinya seringkali penuh drama, tensi tinggi, dan membuat engineer junior merasa bodoh dan tidak berharga. Budi adalah perwujudan sempurna dari sebuah arketipe legendaris di dunia teknologi:"The Brilliant Jerk" atau "Si Jenius yang Menyebalkan".

Inilah paradoks yang akan kita bedah tuntas di artikel super panjang ini. Di industri Software Engineering yang sangat kompetitif,hard skill atau kemampuan teknis memang menjadi tiket masuk utama lo. Tapi, yang akan menentukan seberapa jauh lo bisa melaju dalam karier, apakah lo akan menjadi seorang tech lead, seorang arsitek, atau bahkan seorang CTO, seringkali bukanlah seberapa canggih kode yang bisa lo tulis. Melainkan, seberapa "enak" lo diajak bekerja sama.

Ini bukan lagi sekadar soal sopan santun basa-basi, bro. Ini adalah soal dampak profesional yang sangat nyata.Attitude yang buruk, sekecil apapun itu, secara langsung akan menurunkan produktivitas seluruh tim, menghambat laju inovasi, dan secara perlahan tapi pasti, menciptakan sebuah lingkungan kerja yang toksik.

Jadi, di artikel ini, kita akan melakukan sebuah sesi "psychological debug". Kita akan identifikasi berbagai "spesies" developer dengan attitude "beban". Kita akan analisis "system crash" apa saja yang bisa mereka timbulkan di dalam sebuah tim. Dan yang terpenting, kita akan berikan sebuah panduan "refactoring" yang praktis bagi kita semua untuk bisa melakukan introspeksi dan perbaikan diri.

The Hall of Shame: Mengenali Spesies-spesies Developer "Beban" yang Mungkin Ada di Tim Lo (atau di Diri Lo)

"Si Jenius Menyebalkan" itu punya banyak sekali varian dan subspesies. Coba lo perhatikan baik-baik, dan jujur pada diri sendiri, apakah ada sebagian kecil dari diri lo yang masuk ke dalam salah satu kategori ini?

The Rockstar (Sang Bintang Rock yang Nggak Mau Diatur)

• Ciri-ciri Khas: Developer ini merasa dirinya adalah Jimi Hendrix di dunia perkodingan. Ia merasa bahwa kode yang ia tulis adalah sebuah karya seni suci yang tidak boleh diganggu gugat. Ia seringkali menolak untuk mengikuti coding standard atau best practice yang sudah disepakati oleh tim, dengan alasan bahwa "aturan itu membatasi kreativitas gue". Ia akan menggunakan gaya penulisan kode atau struktur folder yang hanya ia sendiri yang mengerti.
• Kalimat Sakti: "Yang penting jalan, kan?"
• Dampak: Kodenya mungkin memang jenius, tapi menjadi mimpi buruk untuk dirawat (maintain) oleh orang lain. Ia menciptakan sebuah "kerajaan" kecil di dalam codebase yang tidak bisa disentuh oleh siapa pun.

The Gatekeeper (Sang Penjaga Gerbang Pengetahuan)

• Ciri-ciri Khas: Ini adalah tipe developer yang secara sengaja menimbun pengetahuan. Biasanya, ia adalah satu-satunya orang di dalam tim yang mengerti cara kerja sebuah bagian yang sangat krusial dari sistem (misalnya, sistem otentikasi atau API pembayaran). Ia tidak pernah mau menulis dokumentasi. Saat ditanya, jawabannya seringkali rumit dan tidak jelas. Tujuannya? Agar posisinya "aman" dan semua orang akan selalu bergantung padanya.
• Kalimat Sakti: "Wah, ini rumit, bro. Biar gue aja yang kerjain."
• Dampak: Ia menciptakan sebuah single point of failure yang sangat berbahaya bagi perusahaan. Jika ia sakit, cuti, atau resign, seluruh tim bisa lumpuh.

The Know-It-All (Si Paling Tahu Segalanya)

• Ciri-ciri Khas: Di setiap meeting teknis, sesi brainstorming, atau sesi code review, ia harus selalu terlihat menjadi orang yang paling pintar di ruangan. Ia akan selalu memotong pembicaraan orang lain, meremehkan ide-ide yang dianggapnya "bodoh", dan tidak pernah sekalipun mau mengakui jika ia tidak tahu sesuatu. Baginya, bertanya adalah sebuah tanda kelemahan.
• Kalimat Sakti: "Udah, udah, gue ngerti maksud lo. Tapi cara yang bener itu begini..."
• Dampak: Ia membunuh keamanan psikologis (psychological safety) di dalam tim. Anggota tim lain, terutama yang lebih junior, akan menjadi sangat takut untuk bisa bertanya, memberikan ide, atau bahkan sekadar mengutarakan pendapat. Inovasi pun mati.

The Lone Wolf (Sang Serigala Penyendiri)

• Ciri-ciri Khas: Developer ini mungkin sangat jago dan bisa menyelesaikan tugasnya dengan sangat cepat dan sempurna. Masalahnya, ia melakukannya di dalam "guanya" sendiri. Ia anti-sosial. Ia akan menolak untuk ikut dalam sesi brainstorming karena menganggapnya buang-buang waktu. Ia tidak akan pernah mau membantu junior yang sedang kesulitan. Dan ia menganggap kolaborasi sebagai sebuah gangguan.
• Kalimat Sakti: (Tidak ada, karena dia jarang bicara. Biasanya hanya membalas dengan emoji 👍).
• Dampak: Meskipun output individunya mungkin tinggi, ia tidak memberikan efek pengganda (multiplier effect) pada tim. Ia adalah seorang pemain solo yang hebat, tapi ia tidak membuat timnya menjadi lebih hebat.

The Blamer (Si Tukang Menyalahkan)

• Ciri-ciri Khas: Saat terjadi sebuah masalah atau bug di lingkungan produksi, orang pertama yang akan ia cari bukanlah sebuah solusi, melainkan "siapa yang salah". Ia sangat defensif terhadap hasil kerjanya sendiri dan sangat cepat dalam menunjuk jari ke orang lain atau ke departemen lain.
• Kalimat Sakti: "Ini bukan salah di kode gue. Pasti salah di data API-nya."
• Dampak: Ia menciptakan sebuah budaya saling menyalahkan (blame culture) yang sangat beracun, di mana orang akan lebih sibuk melindungi diri sendiri daripada berkolaborasi untuk memecahkan masalah.

"Kerusakan Kolateral": Dampak Nyata dari Satu Attitude Buruk di Dalam Tim

Kehadiran satu orang "brilliant jerk" saja di dalam sebuah tim bisa menyebabkan sebuah "kerusakan kolateral" yang luar biasa besar.

• Penurunan Kecepatan Tim secara Drastis (Velocity Drop): Waktu produktif tim akan banyak terbuang hanya untuk berdebat kusir, untuk mencoba memahami kode yang tidak standar, atau untuk menunggu "Si Penjaga Gerbang" menyelesaikan tugasnya.
• Kematian Keamanan Psikologis dan Inovasi: Seperti yang telah disebutkan, anggota tim lain akan menjadi takut untuk mengambil risiko. Mereka akan lebih memilih untuk diam dan mengerjakan tugas yang "aman" daripada harus berhadapan dengan kritik pedas atau arogansi.
• Peningkatan Utang Teknis (Technical Debt) yang Membengkak: Kode yang ditulis oleh "Si Bintang Rock" tanpa mengikuti standar atau tanpa dokumentasi adalah sebuah bom waktu. Di kemudian hari, tim akan harus menghabiskan waktu berkali-kali lipat lebih banyak hanya untuk bisa memahami dan memperbaikinya.
• Tingkat Turnover Karyawan yang Tinggi: Ini adalah dampak yang paling mahal. Tidak ada orang hebat yang mau bekerja dalam lingkungan yang toksik. Satu "brilliant jerk" bisa menjadi penyebab dari perginya beberapa talenta bagus lainnya yang sudah tidak tahan lagi. Ini bukan sekadar opini. Sebuah studi besar dari MIT Sloan School of Management menemukan bahwa budaya kerja yang toksik adalah prediktor nomor satu dari tingkat atrisi (keluarnya karyawan), bahkan 10 kali lebih kuat pengaruhnya daripada masalah kompensasi atau gaji.

Studi Kasus: "Biaya" Mahal dari Seorang Developer Toksik

Kasus 1: Proyek ReactJS yang Gagal Total karena "The Rockstar"

Sebuah tim sedang dalam proses membangun sebuah aplikasi frontend yang sangat kompleks menggunakan ReactJS. Di dalam tim tersebut, ada satu orang developer senior yang sangat jago, namun juga sangat arogan.

Saat tim memutuskan untuk menggunakan sebuah state management library standar seperti Redux atau Zustand, ia menolaknya. Ia bersikeras bahwa semua library itu "jelek" dan ia bisa membangun sistem state management-nya sendiri yang jauh lebih superior. Karena posisinya yang senior, tim pun terpaksa mengalah.

Ia kemudian menghabiskan waktu sebulan untuk membangun sebuah sistem custom yang sangat rumit, yang hanya ia sendiri yang mengerti. Dua bulan kemudian, ia tiba-tiba mendapatkan tawaran dari perusahaan lain dan resign. Apa yang terjadi? Tidak ada satu orang pun di dalam tim yang tersisa yang bisa memahami atau melanjutkan cara kerja dari sistem state management buatannya. Proyek tersebut akhirnya harus diundur selama tiga bulan hanya untuk bisa merombak total dan menulis ulang seluruh bagian yang pernah ia kerjakan, menggunakan standar yang seharusnya.

Kasus 2: "The Gatekeeper" dan Krisis API yang Melumpuhkan Perusahaan

Di sebuah perusahaan e-commerce, ada satu sistem API pembayaran inti yang sangat kritikal. Dan kebetulan, sistem ini dari awal dibangun dan dirawat hanya oleh satu orang engineerBackend Engineering yang sangat senior. Ia adalah "pahlawan" yang selalu bisa memperbaiki masalah jika terjadi.

Namun, ia adalah seorang "Penjaga Gerbang". Ia tidak pernah mau mengajarkan cara kerja sistem itu kepada orang lain. Tidak ada dokumentasi yang jelas. Suatu hari, ia mengambil cuti panjang selama dua minggu untuk berlibur ke tempat terpencil tanpa sinyal. Dan tentu saja, di saat itulah, sebuah masalah kritis terjadi pada API pembayaran tersebut.

Seluruh perusahaan panik. Tidak ada seorang pun yang tahu harus berbuat apa. Selama hampir 24 jam, sistem pembayaran mereka lumpuh total, menyebabkan kerugian penjualan yang diperkirakan mencapai miliaran rupiah. Ketergantungan total pada satu orang ini adalah sebuah bom waktu yang akhirnya meledak.

Kebijakan Keras "No Brilliant Jerks" yang Diterapkan di Nexvibe

Di Nexvibe, mereka sangat menyadari betapa mahalnya "biaya" dari seorang karyawan yang toksik, sejenius apapun dia. Karena itu, mereka menerapkan sebuah kebijakan rekrutmen yang sangat tegas, yang terinspirasi dari budaya di Netflix, yaitu "No Brilliant Jerks".

Dalam proses wawancara untuk posisi Software Engineering, selain ada sesi tes coding individual untuk menguji hard skill, mereka juga memiliki sebuah sesi wajib yang disebut "Wawancara Kolaborasi". Dalam sesi ini, seorang kandidat akan diberikan sebuah masalah desain sistem yang ambigu, dan ia diminta untuk memecahkannya bersama-sama dengan 2-3 orang engineer dari Nexvibe di depan papan tulis.

Seorang Engineering Manager di Nexvibe menjelaskan, "Di sesi ini, kami tidak hanya melihat apakah dia bisa menemukan solusi teknis yang benar. Kami justru lebih memperhatikan bagaimana ia berinteraksi. Apakah ia mendengarkan masukan dari orang lain? Bagaimana reaksinya saat idenya ditantang? Apakah ia meremehkan pendapat yang berbeda? Kami pernah, dan akan selalu, berani untuk menolak seorang kandidat dengan skill coding 10/10, jika attitude kolaborasinya hanya 3/10."

"Refactoring" Diri Sendiri: Dari Seorang Developer Beban Menjadi Seorang Developer Idaman

Bro, jika setelah membaca daftar "spesies" tadi dan lo merasa, "Anjir, kayaknya ada sedikit sifat gue di situ," jangan langsung berkecil hati. Itu adalah pertanda yang sangat bagus. Kesadaran adalah langkah pertama dari semua perbaikan. Kabar baiknya,attitude itu bukanlah sesuatu yang permanen. Ia bisa "di-refactor".

• Dari Arogansi menjadi Percaya Diri yang Rendah Hati: Bedakan antara percaya pada kemampuan diri lo dengan merasa diri lo lebih superior dari orang lain. Seorang developer senior sejati justru akan semakin rendah hati, karena ia sadar betapa banyak hal yang masih belum ia ketahui.
• Dari Mengkritik menjadi Membimbing: Saat melakukan code review, ubah mindset lo dari seorang "hakim" menjadi seorang "mentor". Jangan hanya menunjuk di mana letak kesalahannya. Coba tanyakan, "Apa pertimbangan lo saat memilih pendekatan ini?" Lalu, tawarkan alternatif solusi dengan cara yang suportif.
• Dari "Ini Kode Gue" menjadi "Ini Kode Kita Bersama": Adopsi sebuah mindset bahwa codebase adalah sebuah aset milik bersama, sebuah taman yang harus dirawat bersama.

Quote dari Seorang CTO Legendaris

Bima Prakoso, seorang CTO yang telah membangun beberapa tim engineering kelas dunia, sering mengatakan ini saat merekrut:

"Saya bisa melatih seorang developer junior dengan attitude yang hebat untuk bisa menjadi seorang coder yang hebat dalam waktu satu atau dua tahun. Tapi saya mungkin akan butuh seumur hidup (dan seringkali gagal) untuk bisa melatih seorang coder jenius dengan attitude yang buruk untuk bisa menjadi seorang rekan kerja yang baik. Yang pertama adalah sebuah investasi. Yang kedua adalah sebuah biaya. Dan saya tidak suka menanggung biaya."

Kesimpulan: Kode Lo Mungkin Dijalankan oleh Mesin, tapi Ia Ditulis dan Dibaca oleh Manusia

Bro, di dunia Software Engineering modern, kita tidak lagi bekerja di dalam gua sendirian seperti seorang pertapa. Kita bekerja di dalam sebuah tim yang saling bergantung. Sehebat apapun lo sebagai seorang individu, lo tidak akan pernah bisa lebih hebat daripada kekuatan kolektif dari sebuah tim yang solid, yang saling percaya, dan yang senang untuk bekerja bersama.

Skill coding lo yang hebat mungkin akan membuat lo bisa mendapatkan pekerjaan pertama lo. Tapi,attitude lo lah yang akan menentukan apakah lo akan bisa memiliki sebuah karier yang panjang, dihormati, dan memuaskan.

Warisan lo sebagai seorang engineer nantinya bukanlah seberapa canggih algoritma yang pernah lo tulis. Warisan lo yang sesungguhnya adalah seberapa banyak orang yang terinspirasi, yang terbantu, dan yang merasa bertumbuh karena pernah memiliki kesempatan untuk bisa bekerja bersama lo.

Jadi, ini tantangan buat lo. Coba lakukan sebuah refleksi yang jujur. Dari kelima "spesies" developer beban yang telah kita bahas tadi, adakah ciri-ciri yang mungkin, meskipun hanya sedikit, "mirip" dengan diri lo?

Jika ada, jangan menghakimi diri lo sendiri. Itu normal. Itu artinya lo manusia. Tantang diri lo sendiri di minggu ini untuk secara sadar "me-refactor" satu saja dari attitude tersebut. Mungkin dengan cara mencoba untuk lebih banyak mendengar di meeting. Atau mungkin dengan cara menulis satu halaman dokumentasi untuk sebuah fitur yang baru saja lo selesaikan.

Karena pada akhirnya,commit terbaik yang bisa lo buat bukanlah untuk sebuah codebase, melainkan untuk versi yang lebih baik dari diri lo sendiri.