Menginspirasi rekan kerja untuk mengadopsi praktik pengkodean yang lebih baik?

Dalam Menangani pertanyaan rekan kerja kuno saya , berbagai orang membahas strategi untuk berurusan dengan rekan kerja yang tidak mau mengintegrasikan alur kerja mereka dengan tim.

Saya ingin, jika mungkin, mempelajari beberapa strategi untuk "mengajar" seorang rekan kerja yang tidak tahu apa - apa tentang teknik dan alat modern, dan mungkin sedikit apatis.

Saya sudah mulai bekerja dengan seorang programmer yang sampai saat ini telah bekerja dalam isolasi relatif, di bagian lain dari perusahaan. Dia memiliki pengetahuan domain yang luas dan yang paling penting dia telah menunjukkan keterampilan pemecahan masalah yang baik , sesuatu yang tampaknya kurang dimiliki oleh banyak kandidat.

Namun, kode aktual (C #) yang saya lihat adalah kemunduran ke hari-hari VB6. Struktur prosedural, notasi Hongaria, variabel global (penyalahgunaan static), tidak ada antarmuka, tidak ada tes, tidak digunakannya Generik, melempar System.Exception... Anda mendapatkan idenya.

Programmer ini sedikit lebih tua dari saya dan, setidaknya dengan kesan pertama, tidak secara aktif mencari perubahan positif. Saya tidak akan mengatakan resisten terhadap perubahan, karena saya pikir itu sebagian besar merupakan masalah tentang bagaimana topik tersebut dibahas , dan saya ingin dipersiapkan.

Programmer cenderung orang yang keras kepala, dan masuk dengan senjata merintis dan melembagakan tinjauan kode rip-it-to-shreds dan kebijakan ketat ditegakkan sangat mungkin tidak akan menghasilkan hasil akhir yang saya inginkan. Jika ini adalah karyawan baru, seorang programmer junior, saya tidak akan berpikir dua kali untuk mengambil posisi "mentor", tapi saya sangat khawatir memperlakukan karyawan yang berpengalaman sebagai pemula yang tidak mengerti (yang bukan dia - dia hanya belum mengimbangi kemajuan tertentu di lapangan).

Bagaimana saya bisa meningkatkan standar kualitas kode pengembang ini dengan cara Dale Carnegie, melalui persuasi lembut dan insentif non-materi? Apa yang akan menjadi strategi terbaik untuk melakukan perubahan halus, bertahap, tanpa menciptakan situasi yang bermusuhan?

Apakah orang lain - terutama pengembang utama - pernah dalam situasi seperti ini sebelumnya? Strategi mana yang berhasil merangsang minat dan menciptakan dinamika kelompok yang positif? Strategi mana yang tidak berhasil dan akan lebih baik untuk dihindari?

Klarifikasi:

Saya benar-benar merasa bahwa beberapa orang menjawab berdasarkan perasaan pribadi tanpa benar-benar membaca semua detail pertanyaan. Harap perhatikan hal-hal berikut, yang seharusnya tersirat tetapi saya sekarang membuat eksplisit:

• Rekan kerja ini hanya "senior" saya berdasarkan usia. Saya tidak pernah mengatakan bahwa jabatannya, lingkup pengaruh, atau tahun-tahun di organisasi melebihi jabatan saya, dan pada kenyataannya, tidak ada yang benar. Dia seorang programmer LOB yang telah terserap ke dalam toko pengembangan utama. Itu dia.

• Saya bukan karyawan baru, programmer junior, atau idiot naif lainnya dengan rencana besar untuk mengubah perusahaan dalam semalam. Saya pada dasarnya bertanggung jawab atas proses perangkat lunak, tetapi karena banyak orang yang telah bekerja sebagai "lead" tahu, tanggung jawab tidak selalu berkorelasi secara tepat dengan bagan organisasi.

• Saya tidak bertanya kepada orang-orang bagaimana cara saya, datang neraka atau air tinggi . Saya bisa melakukan itu jika saya mau, dengan hasil bersih adalah bahwa orang ini akan menjadi kesal dan / atau berhenti. Tolong coba pahami bahwa saya mencari metode sosial , kooperatif untuk mendorong perubahan.

• Penyebutan "... variabel global ... tidak ada tes ... melempar System.Exception" dimaksudkan untuk menunjukkan bahwa masalahnya bukan hanya dangkal atau estetika . Praktik yang dapat bekerja untuk aplikasi CRUD yang relatif kecil tidak serta merta bekerja untuk aplikasi perusahaan besar, dan pada kenyataannya, tidak ada kode sejauh ini yang benar-benar telah lulus tes integrasi.

Tolong, cobalah untuk mengambil pertanyaan pada nilai nominal, menerima bahwa saya benar-benar tahu apa yang saya bicarakan, dan baik menjawab pertanyaan yang sebenarnya saya tanyakan atau pindah.

PS Ucapan terima kasih yang tulus kepada mereka yang -did- menawarkan saran yang membangun daripada berdebat dengan premis. Saya akan membiarkan ini terbuka untuk sementara waktu lebih lama karena saya berharap untuk mendengar lebih banyak dalam pengalaman dunia nyata.

Titik awalnya adalah kenal audiens Anda . Anda tampaknya sudah memahami hal ini karena Anda tahu perbedaan antara membimbing rekan kerja junior dan memengaruhi rekan kerja senior.

Anda masih perlu mencari tahu apa yang akan memotivasi individu ini. Apa yang berhasil pada satu kakek tua (seperti saya), mungkin tidak bekerja untuk kakek tua Anda.

Jika dia suka mentor / mengajar orang lain, Anda bisa mendekati masalah dengan mengajukan pertanyaan seperti "mengapa Anda melakukannya dengan cara ini?" Itu bisa membuat dialog berjalan di mana Anda dapat memintanya untuk mengevaluasi pendekatan yang lebih baru dan memberikan pendapatnya.

Jika itu tidak berhasil, Anda bisa menunjukkan bug yang dapat dihindari dengan menggunakan praktik atau gaya yang Anda ingin dia adopsi. Ini membutuhkan lebih banyak pekerjaan karena Anda harus menemukan bug dan menunjukkan bagaimana perilaku yang ingin Anda dorong akan membantu.

Jika dia tampaknya bersedia membantu orang lain, Anda dapat menarik keinginannya untuk membantu para pemula . Jelaskan bahwa "anak-anak hari ini" tidak terbiasa melihat gayanya pengkodean dan akan lebih mungkin untuk memecahkan kodenya karena itu.

Terkadang Anda mungkin harus langsung menghadapinya dan memaksakan masalah tersebut. Anda harus memilih pertempuran ini dengan hati-hati. Pastikan Anda mulai dengan topik di mana Anda tahu Anda bisa membuktikan kepadanya bahwa Anda memiliki cara yang lebih baik.

Saya pikir Anda memiliki sikap yang benar. Pastikan untuk menunjuk untuk mengatakan semua hal-hal baik yang telah Anda katakan - Keterampilan memecahkan masalah yang hebat, memahami bisnis, dll dan hanya meminta sedikit waktu untuk menunjukkan kepadanya standar saat ini bahwa grup tersebut adalah menggunakan dan memberinya kesempatan untuk mengajukan beberapa pertanyaan tentang mereka.

Ketika Anda bersama-sama membawakannya kopi atau sesuatu, dan beri tahu dia bahwa bekerja dengan standar akan menguntungkannya dengan membuatnya lebih mudah untuk mendukung kode Anda yang ada dan juga membuatnya lebih mudah bagi seseorang untuk dapat membantunya jika dia tercakup dalam pekerjaan (nilai tambah yang besar untuk seseorang yang telah bekerja secara terpisah), dll.

Pastikan dia terlibat dan mendapatkan penjelasan yang baik tentang mengapa Anda melakukan hal-hal yang Anda lakukan dan tidak fokus pada mengapa dia tidak harus melakukan hal-hal yang dia lakukan, bawa orang lain jika Anda harus dan buat mereka menjelaskannya kepada Anda. Jadikan diri Anda tersedia setelah itu jika ia memiliki pertanyaan dan tindak lanjut dengan beberapa tempat yang dapat ia rujuk sebagai contoh standar Anda.

Jika dia tidak tertarik setelah itu maka Anda bisa merujuk ke pertanyaan pertama yang Anda tautkan.

Ini benar-benar tugas manajer Anda

1. Sadarilah bahwa perusahaan harus memiliki standar pengkodean. Setiap perusahaan yang agak profesional memiliki ini, tidak peduli ukuran perusahaan.
2. Suruh semua orang duduk bersama dan mulai mengerjakan standar. Dengan begitu, setiap orang dapat memiliki pendapat mereka, dan mereka kemudian akan lebih termotivasi untuk mengikuti standar.

Jika manajer Anda tidak menyadarinya sendiri, mereka tidak memenuhi syarat untuk pekerjaan mereka. Dan jika demikian, Anda harus memberi mereka dorongan di atas dua di atas. Keuntungan memiliki standar pengkodean sangat banyak, benar-benar tidak ada argumen untuk tidak memilikinya. (Jika beberapa programmer merasa bahwa mereka adalah "seniman" dan tidak boleh dibatasi oleh batas-batas profesionalisme, mereka seharusnya mendapatkan pekerjaan melakukan seni rupa sebagai gantinya.)

Standar pengkodean itu sendiri harus pertama-tama dan terutama berfokus pada pelarangan praktik berbahaya dan fungsi perpustakaan berbahaya. Berusahalah menuju bagian bahasa yang Anda gunakan lebih aman dan lebih murni. Jaga agar standar pengkodean bebas dari "gaya pengkodean", karena gaya pengkodean jauh lebih sulit untuk disetujui, dan tidak sepenting itu. Agak klasik bahwa perusahaan memutuskan untuk membuat standar pengkodean dan kemudian segera terjebak dalam diskusi omong kosong tentang di mana menempatkan {} braces.

Untuk referensi, lihat bagaimana standar MISRA-C / C ++ dan CERT C / C ++ / Java ditulis.

Pertama-tama Anda perlu mengklarifikasi MENGAPA Anda ingin mengubah cara orang ini bekerja. Jika itu hanya untuk alasan estetika, saya pikir Anda harus mempertimbangkan kembali, karena orang ini telah menunjukkan bahwa cara kerjanya benar-benar berfungsi.

Namun, jika ada alasan teknis untuk itu, maka Anda harus mempertimbangkan mendekati orang tersebut dengan sesuatu seperti:

Saya punya saran untuk bagaimana Anda dapat menghemat waktu yang membosankan untuk Anda, dan uang untuk perusahaan. Apakah kamu tertarik?

Ketahuilah bahwa ini haruslah buah-buahan yang menggantung rendah karena kemungkinan besar akan membutuhkan perubahan kebiasaan yang ada yang selalu membutuhkan usaha ekstra.

Sekalipun Anda memiliki banyak saran, pilih saja satu atau dua, dan tunjukkan bahwa itu akan menjadi perubahan menjadi lebih baik.

Entah ini akan berhasil, dan Anda akan ditanya apakah Anda memiliki lebih banyak saran, atau tidak akan dan kemudian kerusakan terbatas pada satu atau dua saran.

Perhatikan bahwa sangat penting untuk menjadi sukses, dan melakukannya dengan cepat.

Anda juga harus berhati-hati. Mungkin ada alasan yang sangat baik untuk melakukan hal-hal dengan cara mereka dilakukan, tetapi Anda terlalu baru untuk melihat mengapa. Karena itu, hormatlah kepada penatua Anda dan tanyakan sebelum Anda menganggap bahwa saran Anda lebih baik. Anda mungkin belajar satu atau dua hal.

Saya ingin sangat mencegah Anda dari mendapatkan di wajahnya karena ini akan menyebabkan situasi menjadi lebih buruk dengan sangat cepat. Saya menyadari itu dibesarkan sebagai jenis upaya terakhir tetapi dalam pengalaman saya, pada titik ini, pengembang telah secara fungsional berhenti berpartisipasi.

Memaksa masalah bisa mengubah individu menjadi musuh di mana mereka melakukan pertempuran dengan setiap tindakan Anda. Itu benar-benar akan memiliki dampak tim negatif dan itu tidak berakhir sampai seseorang berhenti atau dipecat.

Jika orang ini benar-benar memiliki pengetahuan domain yang Anda butuhkan / inginkan maka mintalah mereka mendokumentasikan pengetahuan itu.

Mulai dengan membaginya dengan lembut: Saya tidak tahu seberapa berpengalaman dan seberapa baik Anda dalam memberikan umpan balik. Anda mungkin sudah tahu, mempekerjakan, atau bahkan telah menolak yang berikut, tetapi begini saja. Ada beberapa panduan untuk memberikan umpan balik ketika Anda ingin mengubah perilaku seseorang. Struktur percakapan yang telah saya pikirkan, dan masih mencoba menggunakan dalam situasi di mana saya ingin memberikan umpan balik (karena mereka bekerja) adalah sebagai berikut:

1. Jelaskan perilaku yang Anda lihat. Ini harus perilaku konkret. Contoh: "Saya melihat bahwa Anda menggunakan banyak variabel statis dalam kode Anda"
2. Jelaskan bagaimana hal itu berdampak pada Anda / tim Anda. Contoh: "Saya merasa kode seperti itu sulit dikelola"
3. Tawarkan solusi yang masuk akal . (solusi yang mungkin disebutkan dalam jawaban lain, dan saya sendiri akan mencoba beberapa jawaban nanti.)
4. Beri dia peluang untuk membahas solusinya. Tanyakan padanya apa pendapatnya tentang solusinya. Terima jawabannya pada nilai nominal. Anda telah memberinya pendapat, dan dia bebas untuk menerimanya atau tidak. *

Sumber daya cepat tentang umpan balik dapat misalnya ditemukan di http://managementhelp.org/communicationsskills/feedback.htm (meskipun ada banyak hal semacam ini di web)

Sekarang pada bagian solusinya, dari apa yang saya baca dalam jawaban Anda, saya kumpulkan dia cukup pintar, dan memiliki pola pikir yang benar, tetapi dia hanya ketinggalan dalam praktik baik modern. Mereka membutuhkan waktu dan upaya untuk menguasainya, terlepas dari mempelajari sebenarnya tentang mereka di tempat pertama, jadi Anda harus memberinya kesempatan untuk melakukannya. Itu mungkin berarti mengumpulkan sumber belajar (web, majalah, buku, apa pun) sebagai titik awal, dan memberinya waktu luang untuk mempelajarinya. Saya bisa membayangkan memberikannya setiap sore hari Jumat untuk memperluas wawasan tentang gaya pemrograman, di mana ia dapat melakukan apa pun yang ia yakini untuk mencapai tujuan-tujuan itu. Orang secara inheren ingin memperbaiki diri. Berikan bahan dan waktu, dan mereka akan memanfaatkannya dengan baik.

Mungkin yang paling penting, jangan berharap perubahan dalam semalam. Dia sudah melakukan banyak hal dengan caranya lama, dan mungkin sudah cukup baik dalam hal itu. Butuh beberapa waktu untuk menjadi lebih baik dengan cara baru dalam melakukan sesuatu, dan untuk sementara waktu, dia mungkin tidak akan melihat banyak nilai dalam cara baru, karena pada awalnya, tidak ada. Cara lamanya mungkin akan lebih efektif untuk sementara waktu.

* Catatan: lucunya tentang percakapan adalah mereka sangat sulit untuk dimodelkan. Mereka memiliki kehidupan mereka sendiri, jadi meskipun terlihat bagus di atas kertas, ia cenderung agak berlumpur.

Jelaskan bagaimana Anda ingin segala sesuatunya selesai dan tunjukkan kepadanya bagaimana ia bekerja dengan pilihan desain dan arsitektur yang telah Anda buat untuk proyek pada awal proyek yang Anda inginkan agar dia kerjakan. Duduk satu lawan satu (dan secara pribadi) dan jelaskan masalah yang telah Anda lihat dalam pengkodean sebelumnya dan mengapa mereka menjadi masalah untuk proyek ini. Tanyakan kepadanya apa yang harus dia lakukan untuk menjadi lebih baik, tetapi jelaskan bahwa tidak menjadi lebih baik bukanlah suatu pilihan.

Kemudian gunakan ulasan kode sebagai alat untuk membuatnya menyesuaikan metode kerjanya. Rencanakan waktu yang lama untuk yang pertama dan benar-benar bicarakan mengapa Anda lebih menyukai ini daripada itu dan biarkan dia menjelaskan alasannya. Pastikan untuk benar-benar mendengarkannya, orang-orang lebih mudah berubah ketika mereka merasa keprihatinan mereka telah diatasi. Harapkan dalam perencanaan Anda (tapi jangan katakan padanya) untuk mengerjakan ulang tugas pertama dan jangan menerimanya sampai memenuhi standar tim Anda. Begitu dia tahu apa yang Anda harapkan dan Anda tidak akan membiarkannya untuk kepentingan waktu, dia mungkin akan datang ke tempat Anda bekerja. Tetapi Anda mungkin harus menggunakan ulasan kode sebagai alat pendidikan untuk beberapa iterasi. Anda tidak harus jijik tentang tidak menerima pekerjaan sampai memenuhi standar Anda, tetapi Anda harus tegas tentang hal itu dan konsisten. Mengenakan'

Pertanyaan $ 64.000 adalah apakah dia memberikan proyeknya tepat waktu dan memenuhi persyaratan fungsionalitas. Jika demikian, dia melakukannya dengan benar. Tidak ada cara yang benar atau salah dalam pengembangan perangkat lunak. Pada akhirnya ini tentang memecahkan masalah. Dan jika masalah diselesaikan untuk kepuasan klien / pelanggan, maka menurut definisi , pengembangan perangkat lunak dilakukan dengan benar.

Hal ini menjadi masalah yang sama sekali berbeda tentu saja jika proyeknya arent yang sedang diselesaikan. Pada saat itu perubahan perlu dilakukan oleh penyelia Anda, mungkin dengan masukan Anda. Tetapi hanya karena dia melanggar rasa kode estetika pribadi Anda atau kebijaksanaan konvensional hari ini tidak berarti apa yang dia lakukan adalah 'salah'. Anda bukan arbitor dari definisi 'kode yang baik'. Bagaimanapun, dia mungkin memiliki pendapat yang rendah tentang kode Anda.

Jadi ... kecuali ada benar-benar masalah dengan karyanya (yang Anda havent ditunjukkan ada), tidak melakukan apa-apa. Bagian dari menjadi pengembang yang sukses adalah belajar untuk menggabungkan kode Anda dengan gaya pengembang lain.

Lagi pula, dia bisa datang ke sini dan mengajukan pertanyaan serupa tentang berurusan dengan pengembang yang kurang berpengalaman yang lebih peduli dengan mengikuti mode daripada menyelesaikan proyek. Ini semua tentang perspektif.

Sebagai pengembang junior yang berbicara dengan pengembang senior, terlalu berisiko bagi Anda untuk mencoba dan mendekatinya dengan ide yang lebih baik daripada miliknya.

Cara terbaik untuk mengatasinya adalah dengan mencoba dan meyakinkan bos Anda tentang praktik yang lebih baik, dan lihat apakah ia akan membuat keputusan bahwa semua kode harus mengikuti standar spesifik dan ditegakkan ke standar tersebut melalui ulasan kode rekan.

Sebagian besar orang (bahkan jika pada tingkat subconcious) pendendam, egois, dan defensif, bahkan jika mereka benar-benar tidak menyadari motif bawah sadar mereka sendiri, mereka akan tersinggung jika Anda mencoba mengubahnya atau menyiratkan bahwa mereka salah dalam bagaimanapun juga.

Chain of Command adalah cara paling aman untuk pergi karena dia HARUS mendengarkan bosnya, juga tidak harus menyukainya. Biarkan bos menjadi orang jahat, untuk itulah dia ada di sana.

Jika Anda tidak dapat menjual bos atau dia bosnya, maka cukup atasi bug-nya tetapi pimpin dengan memberi contoh dalam kode ANDA.

Kamu tidak bisa

Anda tidak dapat menginspirasi orang untuk melakukan hal-hal yang tidak mereka sadari dalam pengembangan perangkat lunak. Saya berbicara dari pengalaman karena saya sering mencoba melakukan hal ini dalam karier saya, dan setiap kali hasil akhirnya adalah bahwa status saya sendiri berkurang di mata perusahaan; Saya bahkan dipecat atau berhenti dengan frustrasi setelah tidak terjadi apa-apa, hanya karena mencoba meningkatkan budaya pembangunan di sekitar saya menjadi praktik-praktik modern.

Jika rekan kerja Anda tidak bodoh, Anda bisa menunjukkannya kepada mereka. Karena mereka, bagaimanapun, tidak ada yang dapat Anda lakukan karena mereka tidak mampu atau cukup peduli tentang perangkat lunak sebagai pengerjaan untuk berusaha mengadopsi praktik pengkodean yang lebih baik. Kemungkinannya adalah jika Anda mencoba, mereka akan mengabaikannya atau berkeliaran tanpa benar-benar memahami, yang dari bunyi itu adalah apa yang sudah mereka lakukan ("Pengembangan Trial dan Kesalahan" yaitu hanya meretas kode sampai kesalahan berhenti) .