Menangani rekan kerjaku yang kuno

Saya seorang programmer yang cukup muda, dan saya bekerja di departemen IT perusahaan menengah. Saya memiliki rekan kerja, dan dia adalah programmer Visual Basic 6 yang sangat bagus. Maksud saya sangat bagus. Secara jujur. Dia dapat mengirimkan aplikasi yang berfungsi, yang mengandung sangat sedikit bug, pada saat saya perlu mendapatkan secangkir kopi pertama saya, dan mem-boot komputer saya. Dia memang baik.

Masalahnya, kami bekerja dengan tim, dan gaya kerjanya benar-benar kuno. Dia tidak percaya pada perangkat lunak versi (jika Anda hanya memastikan kode Anda benar, Anda tidak perlu semua omong kosong itu). Tidak percaya pada penyebaran (saya bisa memberikan executable yang berfungsi. Bagaimana yang digunakan adalah untuk sysadmin untuk mencari tahu). Tidak percaya pada abstraksi. ('jika Anda ingin membuat subrutin, silakan, tetapi jangan panggil subrutin dari subrutin itu. Itu menjadi berantakan seperti itu, dan kodenya sulit untuk diikuti. Dengan cara ini setiap orang dapat mengikuti setiap langkah di jalan. 'atau' ya, tentu Anda bisa menggunakan perpustakaan itu untuk melakukannya untuk Anda, tetapi dengan begitu Anda tidak benar-benar mengerti apa yang sedang terjadi ') dan tentu saja tidak percaya pada OOP. (kami bekerja di VB.net)

Dia sangat baik dalam apa yang dia lakukan, dia dapat memberikan aplikasi jauh lebih cepat daripada yang saya bisa. Tapi itu tidak bekerja dalam tim. Anggota tim kami yang lain diam, dan tidak suka berbicara, meskipun ia cenderung setuju. Manajer kami berpikir saya membuat poin yang valid, tetapi bukan seorang programmer.

Saya memiliki waktu yang sangat sulit untuk mempertahankan program yang telah ditulisnya, dan itu tidak membuat suasana tim yang baik. Menurut Anda apa yang terbaik untuk saya lakukan?

Ini kedengarannya seperti "Dia orang baik tapi ..." di mana Anda tahu kebenaran akan datang. Dan kebenaran terdengar seperti dia tidak begitu baik dari seorang insinyur. Perangkat lunak yang baik bukan hanya tentang kecepatan kerja dan pengembangan. Ini juga tentang hal-hal lain yang Anda sebutkan - rawatan, kompatibilitas, abstraksi (untuk efisiensi di masa depan), dll.

Jadi, itu dikatakan, sepertinya Anda memiliki pengembang masalah di tangan Anda. Yang lebih buruk bagi Anda adalah bahwa dia terbukti dan mungkin mengatur caranya. Jadi apa yang bisa kamu lakukan?

• Bekerjalah di sekitarnya.
• Berusaha keras untuk menghasilkan proyek Anda dengan jadwal yang ketat seperti yang dilakukannya.
• Dan jika Anda tidak bisa, hasilkan yang lebih baik .
• Seiring waktu konsep-konsep terbukti yang ia tolak akan mulai membuahkan hasil untuk Anda.

Di sisi lain, jika Anda dipaksa bekerja dengan caranya, pergi.

Jangan mencoba mengubah kolega Anda. Anda menggambarkannya sebagai seseorang yang dapat memberikan perangkat lunak yang berfungsi. Mungkin terlambat untuk mengintegrasikannya dalam tim.

Jadi, Anda memiliki dua pilihan:

• Sesuaikan diri Anda. Mungkin dengan waktu Anda akan dapat meyakinkannya tentang utilitas sistem kontrol sumber? Anda harus meningkatkan lingkaran pengaruh Anda . Semakin resisten terhadap perubahannya, semakin banyak waktu yang Anda butuhkan.

• Hapus diri Anda dari team. Anda memiliki banyak poin untuk membenarkan hal ini. Mungkin Anda harus membiarkannya mempertahankan aplikasi sendiri, dan mendedikasikan diri pada hal-hal baru.

• Hapus diri Anda dari company. Terkadang, ini adalah satu-satunya solusi.

Jika saya jadi Anda, saya akan mengatur sistem kontrol sumber saya sendiri sekarang. Mulailah menggunakannya untuk semua yang Anda kode, dan kelola sehingga anggota tim Anda yang lain memiliki akun dan dapat mengaksesnya. Rekan kerja Anda yang lain kemungkinan akan antusias menggunakannya.

Rekan Anda yang tidak percaya pada praktik semacam itu mungkin tidak mudah dibujuk. Namun, kode apa pun yang Anda dipaksa untuk bekerja dengan yang ditulis olehnya harus masuk ke kontrol versi sehingga Anda dapat bekerja dengannya. Ketika dia membutuhkan akses ke perubahan Anda, kirim dia petunjuk langkah demi langkah sederhana tentang cara menarik kode Anda dari repositori.

Anda tidak harus agresif atau melangkah lebih tinggi darinya untuk membuatnya terlibat dalam proses yang lebih modern. Kadang-kadang hanya dengan cara Anda sendiri dan menjadi pemimpin dengan tindakan lebih efektif daripada mencoba meyakinkan seseorang dengan kata-kata. Langkah kecil. Jika dia mulai lebih responsif terhadap kontrol versi, mulailah refactoring subrutin dan menambahkan tes unit untuk melindungi terhadap perubahan. Otomatiskan tes dan tunjukkan padanya bagaimana dia dapat mengakses hasil begitu dia membuat checkin.

Seringkali orang hanya menolak karena mereka tidak suka perubahan. Tetapi jika perubahan disajikan kepada mereka secara bertahap dan dengan cara yang membuatnya mudah untuk diikuti, seringkali mereka akan melihat manfaatnya dengan sangat cepat.

Yang terpenting, buat semuanya sesederhana mungkin untuknya (Keep It Simple Stupid). Biarkan dia mulai mengikuti praktik-praktik ini dengan caranya sendiri. Tapi jangan biarkan itu menyeret Anda ke bawah.

Aku akan jujur, kamu tidak melukis fotonya yang bagus. Metode kuno, perangkat lunak yang sulit dirawat, keras kepala terhadap cara kerja yang baru, melawan abstraksi, dll

Dari apa yang Anda katakan, jika dia memproduksi perangkat lunak yang sebagian besar bebas bug LEBIH CEPAT daripada Anda tanpa menggunakan perpustakaan yang dapat digunakan kembali dan pola desain yang ditujukan untuk pengembangan aplikasi yang cepat, maka ia mengatakan lebih banyak tentang diri Anda, daripada dia ...

..tentang dia..yeh, cari cara untuk TIDAK bekerja dengannya dan TIDAK dikaitkan dengan pekerjaannya. Sepertinya dia memiliki sikap egois yang khas terhadap pekerjaannya. Anda tidak dapat bekerja dengan seseorang seperti itu, Anda hanya dapat mengamati mereka bekerja dan merapikannya (seperti Anda saat ini).

Saya pernah melihat ini sebelumnya ,

Dan saya hampir berani bertaruh: Tipe pria ini hanya muncul "cepat" karena ia memiliki seperangkat "pola" di kepalanya. 99% aplikasi Lini Bisnis adalah CRUD , hal-hal dasar.

Dia mungkin menggunakan satu ton Salin & Tempel dari kode yang ada sendiri (tidak ada yang salah dengan itu).

Tapi..

Saat dia menemukan sesuatu yang jauh dari kompleks, itu jatuh, mengapa? karena tidak lagi cocok dengan "pola" dasar.

Sebuah tantangan kecil ...

Saya akan membuat proyek di samping, yang kompleks yang benar-benar mendapat manfaat dari OOP dan penggunaan kembali kode.

Kemudian tunjukkan padanya proyek itu dan minta dia untuk mengimplementasikan fitur untuk fitur tersebut.

Saya kemudian bertaruh bahwa kodenya hampir pasti akan 10 kali lebih besar & 10x lebih buruk jika dia menerapkannya dengan caranya.

Lihat ini dari sisi bisnis.

Anda membutuhkan lebih banyak waktu untuk menghasilkan kode buggier. Anda menghasilkan lebih sedikit pendapatan karena itu Anda payah.

Jika, seiring waktu, Anda dapat membalikkan ini maka Anda dapat membalikkan ini.

Tapi mungkin, mungkin saja, programmer kuno ini benar-benar dapat mengajarkan Anda beberapa hal tentang menghasilkan kode dengan cepat sehingga bebas bug? Mungkin tekniknya tidak setua sekolah seperti yang Anda pikirkan?

Saya merasa curiga bahwa seseorang dapat menghasilkan kode hebat seperti itu tanpa beberapa praktik yang sangat baik. Anda mungkin dapat mempelajari praktik-praktik itu dan menerapkannya pada "praktik terbaik" dan hal-hal trendi yang Anda pahami.

Jika manajer Anda bukan seorang programmer cobalah dan taruh dalam istilah yang dia akan mengerti.

• Kita harus menggunakan sourecontrol karena jika tidak, kita bisa mendapatkan masalah besar dalam pemulihan

• Saya butuh x lebih lama karena dia menolak untuk mengikuti beberapa proses yang cukup mendasar.

Di sisi lain, pastikan Anda tidak terlalu terjebak dalam kesempurnaan yaitu ini adalah praktik terbaik yang harus kita ikuti. Kemungkinan rekan kerja Anda memiliki banyak hal untuk ditambahkan, Anda mungkin harus mendorongnya ke arah yang benar secara perlahan.

Sepertinya Anda rekan kerja tidak pernah berkembang dalam tim. Jenis guru solo semacam itu tidak memungkinkan dinamika kelompok yang baik. Jadi, beri tahu atasan Anda tentang hal itu dan cobalah untuk membahas pro dan kontra dengan teman Anda sebelum melakukannya. Jika Anda bisa melakukannya dengan cara yang lebih baik, tetapi jika dia menolak, naiklah ke dalam cahin perintah

Bicaralah dengan manajer Anda, jelas dan sederhana seperti yang Anda lakukan di sini. Ada potensi di sini untuk pertumbuhan - jika rekan kerja Anda baik seperti yang Anda katakan dia seharusnya tidak membuatnya terlalu meyakinkan untuk membuatnya mulai mengkonversi menggunakan kontrol sumber dan. Net dengan konsep OO yang tepat.

Saya akan berbicara dengan orang lain untuk mendapatkan gambaran yang lebih luas tentang bagaimana keadaan di mana Anda berada. Mungkin ada beberapa pemisahan di sana sehingga kodenya tidak harus bercampur terlalu banyak dengan yang lain karena ada potensi untuk memisahkannya ke wilayahnya sendiri untuk satu cara yang bisa ditangani meskipun ini lebih untuk yang lebih tinggi seperti direktur atau CIO untuk membuat daripada pengembang.

Anda mungkin ingin berbicara dengannya untuk melihat sistem apa yang lebih besar yang telah ia bangun karena ada beberapa sistem perusahaan besar yang cenderung menjadi banyak blok bangunan di mana kode spaghetti dapat mengalir ke tanah, "Oh, itulah sebabnya OOP bisa menjadi baik! " meskipun ini terkadang membawa kasus di mana terbukti cukup berguna untuk melihat bagaimana ini bisa menjadi hal yang berguna untuk dimiliki di kotak peralatan seseorang.

Apati mungkin menjadi tersangka lain untuk melihat apakah itu sebabnya dia menolak beberapa hal yang saya anggap dekat dengan fundamental dalam hal bagaimana saya cenderung merancang kode tetapi kemudian mungkin saya sudah memiliki terlalu banyak bantuan Kool.

Tantang dia (dengan cara yang baik) untuk membuktikan Anda sebaliknya, tunjukkan sisi keren alat dan praktiknya. Jangan menggurui.

Sebagai contoh, mungkin ia tidak percaya pada versi sebagai bantuan, tetapi tunjukkan padanya bagaimana percabangan / penggabungan dan bagaimana ia dapat bekerja pada beberapa fitur eksperimental tanpa perlu memiliki penggembungan file.

Mengenai OOP, tunjukkan padanya beberapa pola desain keren / kompleks, seperti pola perintah, pola tugas dan bagaimana hal itu dapat menghemat waktu yang berharga, dan semua tim Anda.

Jika Anda tidak membuatnya tertarik pada sedikit pun ... dia mungkin kasus yang hilang, tetapi sekali lagi, Anda memiliki alat untuk tim Anda dan Anda mengungguli dia. Cobalah untuk menggunakan perangkat lunak repositori yang menampilkan / mengirim pesan melalui email yang dapat dilihat oleh manajer Anda, yang akan membawa transparansi kepada manajer Anda dan membiarkan rekan kerja Anda keluar dari gambar (bitbucket.org memiliki repositori pribadi gratis dengan ruang tak terbatas, jika Anda menggunakan lincah).

Pada akhirnya, jangan mencoba meyakinkan dengan kata-kata tetapi dengan tindakan tak terbantahkan, itu adalah cara terbaik untuk berurusan dengan orang-orang keras kepala IMHO (kadang-kadang membalikkan psikologi bekerja juga, lol).

baik, teknik yang Anda sebutkan jelas baik, tetapi Anda juga perlu bertanya pada diri sendiri apakah Anda mendorong mereka sebagai ideologi. Saya menemukan bahwa programmer muda cenderung sedikit evangelis tentang apa yang mereka dapatkan di perguruan tinggi. ingat bahwa teknik ini bagus karena hasilnya: kontrol versi memungkinkan pengembangan bersamaan, pelacakan desain, pengembangan, pengujian, tahapan perbaikan bug yang lebih jelas. jika proyek Anda benar-benar jangka pendek, banyak yang tidak sesuai, dan akhirnya akan membuat Anda kurang gesit. ini tidak berarti bahwa praktik terbaik berarti menggunakan setiap praktik terbaik yang mungkin. abstraksi, misalnya, jelas bisa menjadi lebih dari sekadar bantuan, setidaknya beberapa kali. kontrol versi paling masuk akal ketika Anda telah memperpanjang jadwal pengembangan, kode kompleks, banyak programmer - ada semacam sinergi, yang sulit untuk mendapatkan traksi dengan sedikit demi sedikit.

Saya pikir tempat untuk memulai adalah mengawasi potensi penggunaan kembali - seiring berjalannya proyek, pikirkan kesamaan, atau kerangka kerja yang lebih umum. mencoba keluar di depan proyek akan menjadi langkah yang kuat, dan mungkin membiarkan Anda bekerja dalam lebih banyak teknik ...

Anda harus meminta penyelia Anda untuk melakukan presentasi untuk SEMUA ORANG tentang mengapa perangkat lunak "versi" bagus. Jangan lajang rekan kerja Anda.

Saya sendiri ragu dengan perangkat lunak kontrol sumber, karena saya melihat orang menyalahgunakannya sepanjang waktu - sebagai cara untuk menghindari pekerjaan.

Rekan kerja saya terus-menerus bergabung, terus-menerus menginjak kaki masing-masing. Tetapi kuliah ramah yang baik tentang manfaatnya akan menjadi hal yang menyenangkan dan akan memacu diskusi.