Saya menonton suatu hari pertunjukan Kate Gregory di konferensi ++ ++ 2018.
Kate adalah programmer yang baik dan pembicara yang hebat. Laporan itu sendiri memunculkan banyak hal menarik tentang pemrograman C ++ dan pemrograman secara umum (patut dilihat). Tapi yang paling penting saya terpikat oleh satu (secara harfiah sambil lalu) berpikir bahwa dia mengekspresikan. Kate mampu dengan sangat singkat dan dalam kasus untuk mengidentifikasi motivasi programmer. Dia terdengar seperti ini: "Programmer, sambil bekerja, berusaha memaksimalkan kebahagiaannya." Kedengarannya klise, tetapi memang benar.
Kita dapat mengatakan bahwa kita mendukung proyek, pelanggan, perusahaan, kemanusiaan dan perdamaian dunia (dan ini bahkan mungkin benar). Tapi mari kita jujur. Kita adalah orang-orang dan, seperti semua orang, pertama-tama, kita berusaha untuk memaksimalkan kebahagiaan kita - secara global sepanjang hidup kita, secara strategis dalam karier kita, secara taktis dalam proyek saat ini, dan picik di sini dan sekarang, ketika menulis fungsi ini, baris kode ini. Ya, kami melakukan ini dan akan lebih baik untuk mencari tahu apa yang membuat kami lebih bahagia dan apa yang membuat kami lebih sedikit. Ini akan memungkinkan kita untuk lebih memahami kolega, bawahan, dan diri kita sendiri.
Saya ingin segera mengurutkan masalah remunerasi, kondisi kerja, atasan, staf, dan lainnya. Jika Anda bekerja di mana Anda bekerja, maka semua ini akan cocok untuk Anda. Mari kita fokus pada apa yang membuat kita bahagia dan tidak bahagia ketika bekerja langsung pada kode.
Tes
Semua proyek dengan tes sama-sama bahagia, setiap proyek tanpa tes tidak bahagia dengan caranya sendiri. Saya dapat mengatakan dengan yakin bahwa programmer dalam proyek dengan cakupan tes yang baik rata-rata lebih bahagia daripada di proyek tanpa tes pada umumnya. Saya bahkan melihat bagaimana programmer, dengan siapa atasan mereka tidak setuju untuk menulis tes penuh, menulis mereka secara diam-diam (kadang-kadang bahkan setelah jam). Mengapa ini terjadi? Tes tertulis membuat programmer lebih bahagia. Keberadaannya sudah menjadi tanda bahwa setidaknya sesuatu dalam proyek Anda sedang dilakukan sesuai dengan praktik industri terbaik (bahkan jika sisanya tidak). Tes yang berhasil diselesaikan menunjukkan tanda centang hijau yang indah, memuji programmer (dan setelah semua, mungkin tidak ada orang lain yang akan memujinya). Keberhasilan penyelesaian 100% dari tes menyediakan beberapa jenis tanah yang stabil di bawah kaki Anda, ketika Anda sudah bisa percaya pada sesuatu - ini menambah kepercayaan kami pada hari ini dan besok, membuat kami lebih bahagia. Dan bahkan tes yang gagal melakukan tugasnya - memberi tahu kami bahwa kami menulisnya untuk alasan yang baik, memuji kami atas pandangan jauh ke depan kami. Jika Anda ingin membuat seorang programmer lebih bahagia, biarkan dia (atau bahkan memaksanya memaksakan) menulis tes (tentu saja, semuanya baik-baik saja).
Perbaikan bug dan pengembangan fungsionalitas baru
"Saya tidak akan memberi tahu Anda untuk seluruh Odessa", tetapi sebagian besar programmer yang saya temui dalam hidup saya lebih suka menulis fungsionalitas baru daripada memperbaiki kode legac. Mengapa Tetapi karena menyentuh bug berarti menyentuh kemalangan orang lain. Sesuatu yang tidak beres untuk seseorang dan itu sangat penting bahwa dia tidak terlalu malas untuk membawa kesedihannya ke pengembang. Harus masuk ke posisinya, cobalah untuk mereproduksi. Dan setelah semua, itu akan berhasil mereproduksi - dan akan ada pukulan untuk harga diri karena bug yang diterima, atau itu tidak akan berhasil dan itu akan diperlukan (oh Tuhan, tidak!) Untuk menghubungi orang yang hidup yang telah menemukan masalah dan mencoba untuk mendapatkan informasi lebih lanjut. Semua ini tidak bisa disebut menyenangkan.
Pada saat yang sama, menulis fungsional baru merupakan sentuhan potensial kebahagiaan. Kami belum merusak apa pun, itu bukan kesalahan kami. Kami sedang menulis kode baru untuk menyelesaikan masalah baru. Mungkin itu akan berhasil. Mungkin kita akan menerima pujian yang layak (bonus, promosi). Ini sudah lebih dekat ke tingkat atas piramida kebutuhan manusia
menurut Maslow .
Apa kesimpulannya? Pekerjaan programmer harus seimbang, seharusnya tidak memiliki satu perbaikan bug. Setiap programmer perlu mempercayakan pengembangan fitur baru dari waktu ke waktu. Ya, tidak ada jalan keluar dari perbaikan bug, tetapi setidaknya kita bisa mencoba mencapai keseimbangan “kurang-lebih nol” antara kebahagiaan dan ketidakbahagiaan dalam hal ini.
Refactoring
Bekerja dengan kode yang baik itu bagus. Sayangnya, kode yang baik tidak jatuh dari langit. Bahkan tidak mungkin untuk mengambil dan menulisnya pertama kali. Kita harus membuat kode yang baik dari yang buruk, karena tidak ada lagi yang bisa dilakukan darinya. Di sini, programmer membuat pilihan: setiap hari, ketika mereka datang untuk bekerja, mereka terus menderita dan bekerja dengan kode yang buruk, atau masih mengambil dan mencoba membuat kode yang baik darinya. Dalam kasus kedua, Anda sering harus bertarung dengan manajemen yang tidak mengerti berapa jam waktu yang dapat dihabiskan jika fitur baru tidak ditambahkan ke produk dan bug lama juga tidak diperbaiki. Ya, Anda harus berjuang. Untungnya, dalam perang ini kita memiliki argumen: kode yang ringkas dan indah kurang rentan kesalahan, dukungannya membutuhkan waktu lebih sedikit (dan biaya lebih sedikit uang), itu cocok untuk perubahan ketika persyaratan bisnis baru muncul, dll. Selain itu, perang ini, sebagai suatu peraturan, tidak lama: perang berakhir dengan semacam kompromi seperti "tidak, saya tidak akan memberikan satu bulan untuk refactoring, tetapi mari kita alokasikan 2 jam seminggu pada hari Jumat". Oke, itu bagus. Kami hanya mendapatkan sepotong kebahagiaan bagi diri kita sendiri. Ya, itu masih harus dibangun dengan tangan Anda sendiri, tetapi ini sudah menjadi mungkin.
Menggunakan perpustakaan dan alat modern
Banyak yang mungkin tahu sakitnya harus bekerja dalam proyek yang macet karena suatu alasan pada kompiler (kerangka kerja, perpustakaan) bertahun-tahun yang lalu. Mereka menjelaskan kepada kami bahwa untuk alasan ini dan itu tidak mungkin untuk meningkatkan ke versi baru di sini dan sekarang, tetapi suatu hari nanti, mungkin, jika berhasil ... Apa yang dapat Anda lakukan? Pertama, kita harus mengakui kepada diri sendiri bahwa keadaan tidak menguntungkan kita dan situasi membuat kita lebih tidak bahagia daripada yang seharusnya. Kedua, ide yang sama dapat disuarakan oleh pihak berwenang (atau pelanggan). Tidak mungkin ada orang yang membantah hal ini. Dan pada saat ini Anda dapat mencoba menawar untuk diri sendiri: misalnya, waktu untuk tes, fungsionalitas baru, dan refactoring. (Anda dapat meningkatkan gaji, tetapi di awal artikel saya berjanji untuk tidak menyertakannya.)
Ngomong-ngomong, waktu yang dihabiskan untuk tugas-tugas bermanfaat seperti itu sebenarnya tidak hanya dapat membuat Anda sedikit lebih bahagia di sini dan sekarang, tetapi juga menghilangkan alasan yang sangat "menakutkan" mengapa tidak mungkin untuk beralih menggunakan alat yang lebih baru. Situasi nyata dari hidup saya:
- Kami tidak yakin bahwa transisi ke perpustakaan baru tidak akan membawa kami masalah baru ...
- Dan di sini saya menulis 200 tes untuk kode menggunakan perpustakaan ini, mari kita coba untuk lulus dan kami akan meluncurkannya.
- Hmm, ayolah.
Setelah 2 minggu - perpustakaan baru dalam produksi.
Anda mungkin dapat terus mengeksplorasi aspek lain. Tetapi ide umumnya sama: beberapa tugas dan keadaan membuat programmer lebih bahagia, yang lain - lebih tidak bahagia. Jika akan ada lebih banyak yang kedua daripada yang pertama - mood dan produktivitas programmer akan turun, cepat atau lambat ini akan menyebabkan masalah dalam proyek atau kepergiannya dari tim. Oleh karena itu, baik programmer dan manajernya harus berpikir tidak hanya tentang "kebaikan global" dari proyek, perusahaan atau pengguna, tetapi juga bagaimana tetap relatif bahagia dengan pengembang. Kalau tidak, apa gunanya?