Jangan menjadi pengembang perangkat lunak yang Anda benci untuk diajak bekerja sama

Jadilah baik untuk diri sendiri, karir Anda dan orang lain

Saya memiliki lebih dari 10 tahun pengalaman industri sebagai pengembang perangkat lunak. Saya juga pernah bekerja sebagai Scrum Master di banyak proyek. Saat ini, saya bekerja di salah satu perusahaan teknologi terbesar.

Saya bukanlah pengembang yang paling berpengalaman atau paling mahir di luar sana. Namun, saya telah bekerja dengan cukup banyak pengembang perangkat lunak untuk menyadari bahwa saya lebih menikmati bekerja dengan pengembang tertentu dibandingkan dengan pengembang lain.

Pengembang yang saya senang bekerja sama adalah mereka yang berkolaborasi dengan baik dengan saya. Mereka profesional namun menyenangkan. Persaingan persahabatan mereka mendorong saya untuk menjadi lebih baik setiap hari.

Dan ada pengembang yang sangat mengganggu saya.

Saya telah menguraikan karakteristik pengembang yang sulit ini. Ini bukan daftar kata-kata kasar. Saya membuat daftar untuk belajar darinya untuk pengembangan pribadi saya. Saya juga menggunakan daftar tersebut untuk memeriksa diri saya dari waktu ke waktu sebagai sarana refleksi diri profesional.

Berikut ini adalah daftar hal-hal menjengkelkan yang dilakukan pengembang perangkat lunak. Untuk setiap karakteristik, saya menyertakan saran tentang apa yang dapat kita lakukan.

Gangguan #1: Memiliki keahlian yang ceroboh

Anda tahu pengembang itu. Pengembang yang memberikan nama samar pada variabel, memiliki kesalahan ketik pada nama fungsi dan meninggalkan sisa komentar lama dalam kode. Pengembang itu tidak mau repot-repot menjalankan pemformat kode meskipun sudah diberitahu 5 kali. Pengembang yang mengabaikan masalah lint bahkan ketika IDE meneriakkan peringatan tersebut kepada mereka.

Keahlian yang ceroboh mengganggu pengembang lain. Hal ini juga memperlambat proses pembangunan. Dalam peninjauan kode, pengembang lain harus membuang waktu untuk mengomentari masalah mencolok yang seharusnya dihilangkan selama pengkodean. Dalam kasus lain, pengembang lain harus memperbaiki sendiri masalah ini.

Lebih parahnya lagi, sikap lesu meningkatkan kemungkinan adanya bug pada perangkat lunak. Bug membutuhkan uang dan waktu untuk memperbaikinya.

Saya frustrasi dengan pengerjaan yang ceroboh karena ini adalah masalah sikap. Hal itu hanya bisa berubah jika pengembang yang ceroboh itu memutuskan untuk bangga dengan pekerjaan mereka.

Sebagai pengembang perangkat lunak, kita mempunyai banyak kebebasan untuk memilih cara kita melakukan sesuatu.

Menggunakan kebebasan ini untuk mengasah keterampilan kita adalah kerja keras. Lebih mudah untuk menjadi pengembang perangkat lunak daripada banyak profesi lainnya. Namun demikian, ada manfaat jangka panjang yang besar jika kita berusaha keras.

“Tanpa keahlian, inspirasi hanyalah sebatang buluh yang terombang-ambing ditiup angin”

— Johannes Brahms, pianis dan komposer Jerman

Bangga dengan keahlian kita membuat kita semakin baik dalam apa yang kita lakukan. Hal ini juga secara tidak sengaja membantu kita memperoleh lebih banyak kepuasan dari pekerjaan kita. Menjadi lebih baik dalam apa yang kita lakukan akan membuka lebih banyak peluang di masa depan.

Gangguan #2: Tidak menghargai waktu orang lain

Ada pengembang yang selalu datang terlambat ke rapat. Setiap orang kadang-kadang terlambat. Namun, datang terlambat sepanjang waktu adalah sebuah kebiasaan.

Bergantung pada pentingnya pengembang tersebut dalam pertemuan tersebut, ada dua hal yang dapat terjadi. Tim harus menunggu pengembang atau harus meluangkan waktu untuk memberi tahu mereka tentang apa yang mereka lewatkan.

Kebiasaan datang terlambat ke rapat merupakan tindakan yang tidak menghormati orang lain. Ini mungkin bukan masalah besar jika Anda datang terlambat beberapa menit, tapi inilah rumus kasar saya untuk menghitung waktu yang terbuang:

Total time waste = n x (t1 + t2)
n = number of people
t1 = time late to meeting
t2 = time wasted bring the developer up to speed

Contoh skenario:

Sebuah tim memiliki enam pengembang. Salah satu pengembang datang terlambat 10 menit. Tim membutuhkan waktu lima menit untuk mempercepatnya. Total waktu yang hilang adalah 6x(10+5) menit. Itu berarti total 90 menit terbuang sia-sia.

Datang terlambat ke rapat mengganggu alur rapat. Rekan-rekan lain mungkin sedang berdiskusi produktif ketika mendiang pengembang menyela.

Ketepatan waktu adalah sebuah sikap.

Memiliki sikap tepat waktu menghemat waktu dan kegelisahan setiap orang. Selain itu juga memberikan kesan positif terhadap keandalan. Hadir di setiap pertemuan tepat waktu berarti kita peduli. Artinya, kemungkinan besar kita juga tidak peduli untuk menyelesaikan pekerjaan tepat waktu.

Gangguan #3: Mengabaikan aspek pekerjaan yang bukan kode

Ada kalanya saya mendengar seorang developer berkata “UI yang saya buat jelek karena saya bukan seorang desainer”. Ini membuatku ingin masuk ke mode Hulk dan membalik meja berdiriku.

Pengkodean hanyalah salah satu tanggung jawab pengembang.

Menjadi ahli dalam pengembangan perangkat lunak berarti kita mengadopsi pendekatan holistik terhadap pekerjaan kita. Kami juga harus mempertimbangkan aspek-aspek seperti pengalaman pengguna, arsitektur, dan strategi bisnis.

Menganggap bahwa pengembangan perangkat lunak hanyalah tentang pengkodean sama saja dengan mengatakan Anda bisa mengemudi karena Anda tahu di mana letak pedal gas.

Mengabaikan gambaran besarnya akan membuat perangkat lunak sulit digunakan, mahal pemeliharaannya, dan tidak konsisten dengan komponen lainnya.

Merupakan tanggung jawab kita sebagai pengembang perangkat lunak untuk mendidik diri kita sendiri dalam segala aspek. Memang benar, kita tidak bisa menjadi ahli di segala bidang. Yang penting di sini adalah memiliki kesadaran yang memadai. Kami selalu dapat meminta bantuan ahli bila diperlukan.

Memiliki pandangan holistik tentang berbagai hal juga akan memungkinkan kita memahami peran lain dengan lebih baik.

Saat saya berdiskusi dengan desainer, saya membiasakan diri mempelajari bagaimana keputusan desain dibuat. Saya melakukannya dengan mengajukan pertanyaan. Ini meningkatkan pemahaman dasar saya tentang prinsip-prinsip desain.

Belajar melihat gambaran yang lebih besar dengan lebih baik adalah proses yang berkesinambungan. Sebuah proses yang didorong oleh rasa ingin tahu dan komitmen untuk menghasilkan karya yang baik.

Gangguan #4: Berbicara tentang alasan, bukan solusi

Setiap orang pasti mempunyai masa buruk pada suatu saat. Terkadang, dibutuhkan waktu lebih lama untuk mendapatkan hasil yang kita inginkan. Ini baik-baik saja. Tidaklah baik jika pengembang terus-menerus memberikan alasan dan bukannya hasil.

Alasan umum mencakup keterbatasan waktu, pengetahuan yang tidak memadai, atau kesulitan tugas.

Menghasilkan alasan secara terus-menerus tidak memberikan efek positif apa pun pada tim. Itu hanya membuang-buang waktu. Dalam kasus terburuk, hal ini menurunkan standar keunggulan dalam tim.

Daripada berdalih, saya lebih suka mendengar tentang langkah spesifik yang telah diambil pengembang.

Ini memiliki banyak manfaat:

Memberi tim kesempatan yang lebih baik untuk menawarkan bantuan atau solusi
Memungkinkan tim untuk belajar dari masalah tersebut
Memberikan gambaran yang lebih baik tentang kemajuan tugas

Berbicara tentang solusi adalah apa yang kami lakukan. Bagaimanapun, kami adalah insinyur. Insinyur memecahkan masalah.

Gangguan #5: Berfilsafat tentang hal yang tidak diketahui alih-alih mencari tahu masalahnya

Dalam banyak kesempatan, rekan kerja memperdebatkan topik teknis berdasarkan pendapat mereka. Pendapat yang tidak didukung oleh fakta apapun.

Diskusi yang panjang seperti ini bisa diakhiri dengan mencari tahu faktanya, bukan berdebat.

“Kebenaran selalu ditemukan dalam kesederhanaan, dan bukan dalam keberagaman dan kebingungan.”

— Isaac Newton, pria yang cerdas

Dalam pengembangan perangkat lunak, kami menangani masalah teknis dan non-teknis.

Dengan masalah teknis, kami memiliki kemewahan yang biasanya berwarna hitam dan putih. Setiap perselisihan dapat diselesaikan dengan mencoba kode di sandbox atau menjalankan perangkat lunak untuk memeriksa fungsinya.

Masalah non-teknis diselesaikan dengan membaca dokumentasi, bertanya pada ahlinya, atau googling.

Gangguan #6: Mengeluh dan memiliki aura negatif

Kebanyakan pengembang yang pernah bekerja dengan saya adalah orang-orang yang positif dan antusias. Mungkin itu sebabnya bekerja dengan pengembang negatif sangat mengganggu saya.

Negatif itu menular. Jika seseorang mengeluh, itu memusatkan perhatiannya pada sisi negatifnya. Orang lain akan cenderung mengambil sikap yang sama.

“Negatif adalah musuh kreativitas.”

— David Lynch, sutradara film

Tentu saja, tidak semuanya bagus dalam pengembangan perangkat lunak. Ada masa-masa sulit. Terkadang kita harus bekerja dengan kode warisan dari zaman kegelapan atau dengan alat yang memiliki kinerja yang buruk.

Lebih baik bertanya pada diri sendiri apa yang bisa kita kendalikan daripada mengulangi apa yang tidak bisa kita ubah.

Kita dapat mengalokasikan sumber daya untuk pemfaktoran ulang kode atau menulis dokumentasi. Kita dapat mengetahui apakah kita dapat mengubah pengaturan memori alat yang lambat untuk mempercepatnya.

Gangguan #7: Bertele-tele dalam rapat

Dalam rapat, saya melihat banyak orang yang menoleh ke belakang ketika “pengembang itu” terus mengoceh.

Seperti profesi lainnya, komunikasi verbal adalah salah satu soft skill utama yang harus kita pelajari.

Saat berkomunikasi, langsung pada intinya akan menghasilkan keajaiban. Rekan kerja akan memahami kita dan situasinya dengan lebih baik.

Salah satu hal yang membuat saya kesal dalam komunikasi adalah ketika seorang pengembang berbicara dengan non-coder menggunakan jargon. Desainer terkadang berpura-pura mengangguk ketika pengembang mengoceh tentang seluk-beluk JavaScript. Apa pun untuk membuat mereka berhenti bicara.

Mengetahui dengan siapa Anda berbicara dan berbicara dalam istilah mereka adalah hal yang masuk akal. Terkadang, akal sehat tidaklah umum.

Gangguan #8: Mencuri penghargaan untuk diri sendiri

Sesekali, saya akan melihat pengembang mencuri penghargaan atas pekerjaan yang dihasilkan oleh upaya tim. Mereka akan menulis email ke manajemen untuk mengiklankan fitur tersebut atau membicarakan suatu tugas seolah-olah mereka melakukannya sendiri.

Seringkali, hal ini dikomunikasikan dengan cara yang licik dan tidak terus terang. Pernyataan pengambilan kredit tersirat secara cerdik.

Strategi seperti itu mungkin menghasilkan visibilitas jangka pendek bagi individu tersebut.

Dalam jangka panjang, pengembang seperti itu akan teralienasi. Hal ini dilakukan karena pilihan atau secara tidak sadar. Anggota tim lainnya akan mengembangkan komunikasi mereka untuk menyoroti kontribusi mereka dengan lebih baik.

Akan lebih masuk akal untuk memberikan penghargaan kepada orang lain ketika sudah waktunya. Tidak perlu berlebihan. Tapi saya katakan berikan penghargaan yang pantas.

Ada banyak cara untuk memberikan kredit. Kami dapat menyebutkan kontribusi rekan tersebut selama Daily Scrum. Kami dapat berterima kasih kepada rekan tersebut melalui email dan menyalin manajernya.

Ada banyak sekali manfaat memberikan kredit:

Anda merasa baik karena Anda jujur.
Rekan yang berkontribusi merasa diakui.
Memungkinkan manajer untuk memiliki kesan yang lebih akurat tentang koleganya.
Tim memiliki gambaran yang lebih baik tentang keahlian individu.

Oleh karena itu, marilah kita menyadari kapan harus memberi atau menerima pujian.

Kesimpulan

Jalan untuk menjadi pengembang yang lebih baik adalah proses yang tidak pernah berakhir. Terkadang, masuk akal untuk berhenti sejenak untuk merenungkan cara kita melakukan sesuatu. Seni refleksi diri profesional membantu kita memperbaiki arah kita. Menjadi lebih baik dalam perdagangan akan meningkatkan tingkat kepuasan kita terhadap apa yang kita hasilkan.

Marilah kita menjadi pengembang perangkat lunak yang ingin kita ajak bekerja sama.

Jangan menjadi pengembang perangkat lunak yang Anda benci untuk diajak bekerja sama