Bagaimana kita dapat membuat praktik terbaik pengembangan perangkat lunak lebih menarik bagi orang tanpa latar belakang perangkat lunak?

Di mana saya bekerja ada beberapa pengembang perangkat lunak berpengalaman dengan latar belakang perangkat lunak, tetapi mayoritas pengembang adalah fisikawan atau ahli kimia dengan pengetahuan domain yang sangat baik tetapi pengalaman terbatas dalam hal mengembangkan perangkat lunak berkualitas tinggi yang dapat dipelihara. Untuk mengatasinya, kami telah mulai mengadakan pembicaraan dan lokakarya rutin.

Menurut Anda topik apa yang sebaiknya kita diskusikan untuk membantu orang-orang ini menjadi pengembang perangkat lunak yang lebih efektif?

Secara khusus kami berjuang untuk mendapatkan antusiasme untuk pembicaraan ini karena banyak pengembang tidak melihat perangkat lunak sebagai subjek yang menarik. Bagaimana kita bisa membuat ini lebih menarik bagi orang-orang tanpa latar belakang perangkat lunak?

Terima kasih

Saya pikir ini akan sulit, jadi bersiaplah untuk perjuangan - tetapi bukan tidak mungkin. Pada akhirnya pemrograman (terutama non-cowboy-hack'n'slash coding) tidak akan menjadi super menarik bagi semua orang. Ini terutama berlaku bagi orang-orang yang sudah bekerja di bidang yang secara intelektual menantang dan memberi penghargaan pada dirinya sendiri.

Pertama-tama, buat pembicaraan dan lokakarya menyenangkan dengan diri mereka sendiri - makanan gratis (pastikan makanan itu enak!) Dan camilan serupa adalah tempat yang bagus untuk memulai. Cobalah untuk menyuntikkan sedikit humor juga dan, paling tidak pada awalnya, buat mereka cukup singkat dan informal yang Anda bisa.

Kedua, pastikan pembicaraan dan lokakarya itu relevan. Cobalah untuk tidak membuatnya terlalu abstrak (bahkan jika konsep yang dibahas adalah abstrak) dan jika Anda mungkin bisa, pastikan bahwa mereka dapat mencoba apa yang telah dibahas. Bahkan lebih baik memeriksa apa yang telah mereka lakukan di antara sesi dan memberikan umpan balik positif. Jika mereka tidak relevan dan mereka tidak menerapkan apa yang telah Anda diskusikan maka mereka akan (dengan benar) melihatnya sebagai buang-buang waktu.

Akhirnya cobalah untuk memperkenalkan beberapa standar pengkodean dasar, lebih disukai yang tidak terlalu mengganggu bagaimana mereka saat ini beroperasi. Jika Anda berada di dunia .net, Resharper adalah yang baik untuk memulai karena akan memperingatkan tentang hal-hal seperti konvensi penamaan. Anda dapat melakukannya lebih jauh dengan StyleCop (yang dapat diintegrasikan ke dalam Resharper) - tetapi pastikan Anda menyesuaikan aturan terlebih dahulu. Jika Anda tidak menggunakan .net maka saya yakin alat serupa akan ada di tempat lain. Tidak banyak, tapi ini awal.

Jangan mengharapkan hasil instan (kecuali mungkin standar pengkodean yang diberlakukan secara otomatis) - Saya telah mendengar 6, 9 dan 12 bulan sibuk untuk memperkenalkan praktik terbaik.

Saya hanya membolak-balik sejauh ini, tetapi tampaknya ada sedikit nasihat yang baik, relevan, untuk Anda di buku yang akan datang Mengemudi Perubahan Teknis .

Jika ahli kimia dan fisikawan ini pada dasarnya bukan pengembang profesional, dan tidak dimaksudkan untuk menjadi seperti itu, saya akan menyarankan untuk berpikir secara berbeda pada masalahnya.

Pengembang "nyata" harus menyediakan lingkungan yang mudah bagi mereka untuk berkembang. Anda harus memberikan bimbingan dan Anda harus memberikan peer review kode mereka dengan insentif yang kuat untuk membuat kode itu cukup baik untuk dilewati.

Dengan kata lain, jangan perlakukan mereka sederajat, tetapi berikan semua yang Anda bisa agar mereka unggul dalam apa yang sebenarnya mereka lakukan itu adalah kekuatan mereka.

Saya bekerja dengan insinyur jaringan yang sangat pintar yang bukan pengembang dan tidak mau. Saya bisa mengerti karena saya tidak ingin menjadi insinyur jaringan.

Apa yang kami temukan yang berfungsi dengan baik adalah bagi insinyur dan saya untuk melakukan pemrograman tim. Kami berada di situs yang berbeda, jadi kami menggunakan telepon, membuka sesi berbagi layar biasanya dengan screenperintah, dan mengeluarkan kode.

Kami telah melakukannya berkali-kali dan merasa itu bekerja dengan sangat baik. Saya memahami bagaimana mereka melakukan hal mereka dengan lebih baik, dan insinyur sedang belajar bagaimana kita menulis kode yang dapat dipelihara dan diuji.

Peran apa yang mereka miliki di perusahaan? Jika Anda membutuhkan pengembang, maka biarkan mereka pergi jika mereka bukan pengembang yang baik dan tidak tertarik untuk menjadi pengembang yang baik. Jika mereka seharusnya menjadi fisikawan dan ahli kimia, Anda dapat menjalankan lokakarya, tetapi jangan berharap mereka mempertahankan tingkat minat yang tinggi. Jika keduanya seharusnya, naikkan harapan dan pastikan Anda membayar mereka cukup untuk membenarkan mereka mengambil peran pengembang perangkat lunak sambil mempertahankan pengetahuan dan keterampilan domain yang kompleks.

Kecuali jika bagian dari peran seseorang adalah menjadi pengembang, mereka mungkin tidak akan pernah tertarik mengembangkan perangkat lunak berkualitas tinggi. Hanya karena seseorang membuat skrip dan peretasan yang cepat tidak berarti mereka benar-benar ingin menjadi pengembang perangkat lunak, itu hanya sarana untuk mencapai tujuan, seperti seorang akuntan yang mencari rumus Excel yang rumit. Jika Anda memerlukan perangkat lunak berkualitas tinggi yang dapat dipelihara, maka pengembang perangkat lunak harus membuatnya.

tunjukkan manfaatnya kepada mereka . jika tidak, mengapa mereka peduli?