Bagaimana cara mengubah seorang programmer copy / paste / spaghetti untuk melihat cahaya?


35

Pertanyaan ini terinspirasi oleh pertanyaan ini . Sementara pertanyaan lain itu dianggap terlokalisasi, saya percaya masalah mendasarnya adalah sesuatu yang sangat umum di industri kami. Saya tahu ada beberapa pengembang, yang akan membaca ini dan berpikir saya membuat hal ini dan kemudian mereka mungkin menjawab bagaimana semua orang peduli dengan pekerjaan mereka dan ingin belajar, tetapi hanya melihat posting Programmer SE lainnya ( contohnya ), Saya tahu itu tidak benar secara universal.

Jadi katakanlah Anda memiliki seseorang di tim Anda (atau mungkin mayoritas) yang prosedur operasi standarnya adalah untuk menyalin / menempel dan yang percaya bahwa semuanya dapat diselesaikan jika hanya Anda menambahkan cukup panggilan fungsi dan variabel. Orang ini tidak pernah mendengar TDD, KERING atau SOLID dan di luar 40 jam di tempat kerja ketika mereka sibuk bekerja, mereka tidak pernah membaca satu metodologi / praktik / buku desain.

Di masa lalu saya (dan yang lainnya) bertanya, bagaimana Anda mengajar OOD . Tapi sekarang saya berpikir itu bukan pertanyaan yang tepat. Pertanyaan sebenarnya adalah bagaimana Anda mendekati orang / tim tersebut dan membuat mereka ingin tahu tentang cara yang lebih baik dalam melakukan sesuatu? Bagaimana Anda menginspirasi mereka untuk belajar? Tanpa itu, tampaknya semua pengajaran, pertemuan, ceramah, diskusi tidak berguna jika mereka benar-benar bahagia kembali ke meja mereka dan melakukan apa yang selalu mereka lakukan.

Saya bekerja dengan banyak orang seperti itu. Mereka sebenarnya adalah individu yang cukup cerdas, tetapi saya benci ketika saya mendengar, "Saya selesai mengkode, hanya perlu refactor dan dibagi menjadi beberapa kelas untuk membuat DXM bahagia". Mereka tidak melakukan refactor untuk kode yang lebih bersih, mudah dibaca, dapat dipelihara, tetapi hanya karena jika tidak mereka akan dimarahi. Saya tahu mereka mampu belajar, sepertinya ada sedikit motivasi.

Ketika saya memberikan pekerjaan, umumnya bug memiliki cara yang lebih sedikit dan pekerjaan yang saya miliki tidak pernah menjadi 5.000 baris kelas. Yang lain akan membuat komentar seperti, "kode Anda jauh lebih bersih dan mudah dibaca daripada barang-barang kami", sehingga mereka melihat perbedaannya. Tetapi pada saat yang sama, saya merasa mereka percaya bahwa mereka dibayar selama 40 jam terlepas dari apa yang mereka lakukan, jadi mereka sebenarnya tidak keberatan jika mereka menghabiskan 3 hari penuh di QA mencari bug yang seharusnya tidak diperkenalkan di posisi pertama. Atau mereka membutuhkan waktu satu minggu untuk memodifikasi satu kelas karena ada begitu banyak dependensi yang akhirnya mereka sentuh. Namun, "mungkin kelas itu seharusnya ditulis secara berbeda" sepertinya tidak pernah muncul.

Adakah yang bisa dilakukan dalam situasi ini? Adakah yang berhasil? Atau yang terbaik adalah mengisolasi pola pikir seperti itu ke bagian-bagian proyek yang tidak kritis dan meminimalkan kerusakan?

CATATAN: Ketika saya mengatakan "kurangnya motivasi". Saya tidak berpikir itu kurang motivasi untuk bekerja atau melakukan pekerjaan dengan baik karena mereka hanya berhenti peduli. Sebagian besar tim kami sebenarnya justru sebaliknya. Mereka pasti peduli dengan produknya. Kami memiliki orang-orang yang akan bekerja malam dan akhir pekan. Bagian yang saya coba lalui adalah dengan kebiasaan dan keterampilan yang lebih baik, mereka sebenarnya tidak perlu bekerja terlalu banyak. Saya kira "40 jam" membuat pos ini terdengar agak terlalu negatif.


Negara apa ini?

3
@ ThorbjørnRavnAndersen - AS. sekarang Anda harus menulis tanggapan karena saya sangat ingin tahu bagaimana info itu mempengaruhi itu :) Saya selalu berpikir bahwa kita semua adalah manusia dan jenis barang ini bersifat universal. Dan tidak, pertanyaan ini tidak ada hubungannya dengan outsourcing.
DXM

8
Perbedaan budaya antar negara dapat menjadi substansial, dan setiap upaya untuk memperkenalkan perubahan harus mempertimbangkan hal ini. Apa yang berhasil di satu budaya kemungkinan besar tidak akan bekerja di yang lain. Dalam kasus Anda, saya percaya cara terbaik adalah membuat manajemen secara resmi menaikkan standar apa yang dapat diterima.

Jawaban:


18

Anda mendapati diri Anda alasan: "Saya tahu mereka mampu belajar, sepertinya ada motivasi yang kurang."

Ada orang yang bersemangat dengan pekerjaan mereka. Dan ada orang lain yang, kadang-kadang cukup kompeten, bekerja hanya demi uang . Mereka tahu barang-barang mereka, tetapi mereka tidak menikmati pekerjaan mereka. Mereka tidak akan menghabiskan waktu ekstra melakukan refactoring tambahan untuk membuat kode dapat dibaca atau memecahkan masalah yang menarik ketika peretasan cepat dan jelek dapat melakukan pekerjaan.

Fenomena ini ada di setiap pekerjaan. Hanya saja beberapa pekerjaan tidak terlalu menarik (pernahkah Anda melihat seorang akuntan yang mencintai pekerjaannya dan sudah memimpikannya ketika ia masih kecil?), Tetapi dalam pemrograman, ada banyak orang yang benar-benar mencintai apa yang mereka lakukan (jika tidak Programmer.SE akan sangat kosong). Ini berarti bahwa sebagai pengembang yang bersemangat, yang berbicara setiap hari dengan pengembang yang bersemangat lainnya, kami memiliki lebih banyak peluang untuk terkejut melihat seseorang yang melakukan pemrograman hanya demi uang.

Apa yang bisa kita lakukan? Tidak terlalu banyak. Dalam semua kasus, itu bukan untuk Anda, tetapi untuk sumber daya manusia untuk memilih orang yang benar-benar termotivasi motiv. Dan memecat orang yang tidak.

Anda dapat mencoba memotivasi rekan Anda sendiri, tetapi itu sangat sulit. Jika Anda memberi mereka buku untuk dibaca, mereka akan mengembalikannya tanpa dibuka beberapa minggu kemudian. Jika Anda memberi mereka saran, mereka tidak akan mendengarkan, karena mereka tidak peduli².

Kamu bisa:

  • Meyakinkan atasan Anda untuk menetapkan sejumlah aturan ketat di perusahaan Anda: pedoman gaya , dll. Ini tidak akan memotivasi orang-orang itu untuk melakukan pekerjaan yang lebih baik, tetapi setidaknya mereka tidak akan dapat melakukan kode sumber yang tidak sesuai dengan persyaratan .

  • Bekerja pada persyaratan, terutama persyaratan non-fungsional . Bagaimana dengan persyaratan yang mengatakan bahwa suatu proyek tertentu harus mengandung kurang dari 5.000 baris kode IL (tidak, saya tidak berbicara tentang LOC yang tidak berarti ) ³? Bagaimana dengan keharusan untuk mendapatkan hasil spesifik pada kompleksitas siklomatik atau kopling kelas ?

  • Tingkatkan jumlah jam yang Anda habiskan di perusahaan Anda untuk melakukan tinjauan kode . Tentukan apa yang ditinjau: jika Anda memiliki daftar periksa, tambahkan poin yang terkait dengan refactoring, keterbacaan, komentar yang bersih dan berguna, dll. Jika Anda tidak memiliki daftar periksa, Anda harus.

  • Gunakan pemrograman pasangan [lebih] . Ini dapat membantu meningkatkan kualitas kode dan memotivasi rekan kerja yang kurang termotivasi.

  • Gunakan sistem kompensasi yang mirip dengan apa yang digunakan di Fog Creek.


¹ Tentang wawancara: sebelum mempekerjakan Anda, sumber daya manusia harus memiliki aset tidak hanya tingkat teknis Anda, tetapi juga motivasi Anda . Sayangnya, beberapa perusahaan melupakan bagian kedua dari wawancara ini, dan merekrut orang-orang yang tidak terlalu menikmati pemrograman. Untungnya, dalam kebanyakan kasus, pekerjaan di mereka perusahaan tidak pernah menyenangkan, dan uji Joel jarang melebihi 2.

² Mereka benar - benar tidak peduli, bahkan jika mereka mendapat lebih sedikit uang. Saya cukup dekat dengan salah satu pelanggan saya (saya seorang freelancer) yang percaya bahwa pekerjaannya adalah mengembangkan situs web untuk pelanggannya sendiri. Dia juga punya desainer. Saya memberi tahu mereka berkali-kali tentang cara mereka dapat meningkatkan produktivitas mereka sebesar 2 atau lebih. Jika mereka hanya mempekerjakan seseorang yang kompeten, mereka akan meningkatkan pendapatan mereka setidaknya 3. Namun mereka memiliki cukup uang, dan tidak peduli dengan kualitas atau berapa biayanya bagi pelanggan yang tidak tahu, dibandingkan dengan seseorang yang produktif.

³ Yang saya maksud adalah jumlah baris kode IL yang Anda lihat di Kode Metrik dalam Visual Studio , metrik yang sebenarnya berarti sesuatu. The nyata LOC tidak masalah dan Anda tidak perlu mengukurnya; itu salah satu metrik paling bodoh yang pernah ada. Menegakkan garis-garis kode IL berarti bahwa pengembang akan dipaksa untuk benar-benar memperbaiki kode, dan tidak hanya menutup sepuluh baris kode dalam satu baris yang tidak dapat dibaca.


3
Saya tidak setuju: Motivasi untuk bekerja dan motivasi untuk belajar adalah dua hal yang sepenuhnya berbeda. Misalnya, beberapa orang menyukai pekerjaan dan pekerjaan mereka, tetapi mereka mungkin berpikir "SOLID" hanyalah kata-kata bingo omong kosong atau "TDD" adalah beberapa konsep menara gading tanpa digunakan di dunia nyata.
nikie

5
@maple_shaft benar: Beberapa orang bekerja 70 jam-minggu dan menghasilkan kode spageti terburuk tanpa tes apa pun (mereka tidak punya waktu untuk omong kosong seperti itu!). Meskipun bersemangat dan terus meningkatkan keterampilan mereka, tetapi pulanglah setelah 40 jam, karena mereka tahu mereka tidak bisa produktif lebih lama dari itu. Jangan gabungkan kedua hal ini!
nikie

13
Tidak tidak Tidak. Kesediaan untuk dieksploitasi oleh majikan! = Kemampuan menghasilkan kode berkualitas. Ada terlalu banyak dari "tinggal sampai 02:00 untuk menyelesaikannya" omong kosong yang terjadi di industri kita sudah tanpa kita menyatukannya dengan beberapa Pengembang Ideal mitos. Jika ANDA suka bekerja 80 jam seminggu, lebih banyak daya untuk Anda. Saya memiliki hal-hal yang penting bagi saya selain pekerjaan. Untuk menyimpulkan saya buruk pada apa yang saya lakukan karena itu palsu di terbaik. Tidak ada industri lain yang lolos dari industri kita, dan terserah kita untuk mengubahnya, jika itu akan berubah.
Dan Ray

6
Harus bekerja sampai jam 2 pagi untuk mengerjakan suatu proyek adalah cara yang sangat efisien untuk membunuh cinta untuk proyek tersebut, terutama bagi mereka yang memiliki kewajiban keluarga.

2
Saya pikir semua poin yang dibuat di sini valid, tetapi beberapa dari Anda mungkin telah salah mengerti MainMa. Dia tidak pernah mengatakan bekerja sampai jam 2 pagi karena Anda dipaksa karena tenggat waktu. Alih-alih, ia hanya merujuk pada orang-orang yang begitu terperanjat dalam kegembiraan melihat sesuatu bekerja sehingga kadang-kadang, mereka lebih suka menyelesaikannya daripada tidur. Saya bisa mengaitkannya dengan ini. Bagi saya satu contoh ekstrem adalah tugas yang sedang saya kerjakan untuk menambahkan dukungan tunneling ke perpustakaan streaming video kami. Diperkirakan 5 hari, tetapi dengan arsitektur pipa baru kami, semuanya berjalan dengan sangat baik, saya mulai pada hari Jumat sore ...
DXM

12

"Saya sudah selesai coding, hanya perlu refactor dan dibagi menjadi beberapa kelas untuk membuat DXM senang".

Cara berpikir seperti itu ada kanker pada tim mana pun dan akan mematikan motivasi seluruh tim jika tidak segera diurus. Tentu saja saya merujuk pada fakta bahwa dengan senioritas dan / atau prestasi Anda berada pada posisi otoritas teknis, memberi Anda kekuatan untuk membantu mempengaruhi dan membawa praktik-praktik baik ke dalam tim Anda.

Ini semua baik dan bagus, namun jika tim Anda jelas dijual pada proses ini, mereka tidak akan memilih Anda dalam pernyataan seperti ini satu sama lain yang jelas menunjukkan kurangnya rasa hormat terhadap proses dan kurangnya rasa hormat pada Anda. Mereka masih melihat praktik terbaik ini sebagai penghalang yang disebabkan oleh Anda dan bukan proses yang dimiliki oleh tim yang tim Anda akan pertahankan dengan kemampuannya sendiri.

Anda menyebutkan dalam komentar sebelumnya bahwa anggota tim lain memang mengikuti praktik dan standar ini dengan baik dan menerapkannya dengan benar. Pertama-tama fokuskan perhatian pada dukungan dari mereka, tanyakan pada mereka apa yang berhasil, apa yang tidak berhasil, apa yang mereka sukai dan apa yang ingin mereka lihat berubah. Jika Anda melakukan ini dan menanggapi pendapat mereka dengan serius, mereka akan merasa sangat berbeda tentang standar seolah-olah itu adalah keputusan masyarakat alih-alih prosedur yang diturunkan kepada mereka dari atasan.

Anda mendukung dukungan untuk praktik terbaik dan standar dengan menunjukkan kepada tim bagaimana mereka telah meningkatkan proses pengembangan perangkat lunak atau kualitas perangkat lunak.

Berikan suara pada masalah untuk diskusi dan dokumentasikan hasilnya, idealnya setiap keputusan harus bulat demi legitimasi tetapi jika Anda berurusan dengan penyumbat garis keras ini mungkin tidak mungkin dan bisa menghentikan setiap masalah. Gunakan suara mayoritas dalam situasi ini. Jika mayoritas bertentangan dengan standar dan praktik yang Anda usulkan maka Anda sudah kehilangan ruang itu, menyerah saja pada saat itu.

Mereka akan memiliki standar dan prosedur itu dan akan menegakkannya sehingga Anda tidak perlu melakukannya. Sebagai pemimpin teknologi Anda tidak harus mendeklarasikan dekrit dan dekrit, itu adalah cara yang buruk untuk menjadi seorang pemimpin.

Begitu tim merasa seolah-olah mereka memiliki prosedurnya maka anggota tim yang mulai memberi label Anda pada prosedur tertentu dan praktik terbaik akan menjadi tidak sah untuk berpikir demikian. Tim Anda akan membantu memperbaiki sikap ini pada orang lain.


1
+1 untuk penekanan pada fokus pada hubungan daripada prinsip
sunwukung

5

Pertanyaan bagus! Saya pikir jawabannya tergantung pada mengapa orang tidak ingin meningkatkan keterampilan mereka. Kemungkinan jawaban adalah:

  • Mereka pikir mereka terlalu sibuk untuk mempelajari sesuatu yang baru atau mereka berpikir cara baru dalam melakukan sesuatu (seperti menulis semua tes) akan memakan waktu lebih lama dan mereka tidak punya waktu untuk itu. Maka jawaban yang jelas adalah: beri mereka lebih banyak waktu. Mempelajari sesuatu atau mencoba sesuatu seperti TDD ketika Anda selalu melakukan hal-hal yang berbeda akan membutuhkan lebih banyak waktu beberapa kali pertama. Jika programmer Anda tidak punya waktu, Anda tidak dapat menyalahkan mereka karena tidak mencoba.
  • Mereka memiliki persepsi yang berbeda tentang keterampilan mereka sendiri, yaitu mereka pikir mereka adalah programmer yang sangat baik menghasilkan kode berkualitas tinggi. Ini adalah medan psikologis yang sulit, karena menghancurkan kepercayaan itu bisa sangat melemahkan semangat. Mungkin beberapa jenis kompetisi informal dapat membantu (siapa yang menghasilkan cacat / fitur paling sedikit? Kode terpendek? WTF paling sedikit / menit dalam tinjauan kode?).
  • Mungkin ada masalah motivasi yang sebenarnya (yaitu mereka hanya ingin "melakukan waktu dan dibiarkan sendiri" sampai waktu penutupan). Untungnya, ini terlalu umum / tidak berhubungan dengan pemrograman, karena saya benar-benar tidak punya jawaban untuk itu.
  • Mereka pemula dan mereka tidak tahu yang lebih baik. Dalam hal itu, pelatihan, ulasan kode mungkin membantu, atau "klub buku" di mana anggota tim harus mendiskusikan buku teknis baru setiap bulan.
  • Mereka telah melihat peluru perak sebelumnya, (dan sangat kecewa) dan mereka berpikir apa pun yang Anda coba jual adalah hanya kata kunci baru yang terdengar bagus secara teori dan jarang digunakan dalam praktik. Dalam hal itu, mendemonstrasikan keuntungan selama ulasan kode dan sesi pemrograman pasangan mungkin bekerja. Usahakan untuk tidak sepenuhnya tahu segalanya saat Anda melakukannya.

Solusi terbaik benar-benar tergantung pada masalah root: Misalnya, pedoman pengkodean formal, metrik dan ulasan dapat bekerja untuk pemula, tetapi orang-orang di "persepsi yang salah tentang keterampilan mereka sendiri" -crowd mungkin berjuang melawan mereka atau memainkan metrik karena mereka melihat mereka sebagai penghalang birokrasi yang kontraproduktif untuk menyelesaikan pekerjaan mereka.


Poin bagus. Saya terutama menyukai yang pertama - dan saya bahkan akan menggeneralisasi: Anda pertama-tama harus memperjelas bahwa belajar tentang pekerjaan didorong , dan bahwa boleh saja secara eksplisit menyisihkan waktu untuk itu.
sleske

Jika orang memiliki persepsi yang berbeda tentang keterampilan mereka, mungkin mereka hanya mengukur kesuksesan dalam parameter yang berbeda? Jika Anda mengukur kualitas kode, dan mereka memikirkan seberapa cepat kode dapat dibuat, jelas hasilnya akan berbeda - dalam kasus seperti ini, harus bertanya bagaimana mereka mengukur keberhasilan. Orang yang berbeda memiliki cara berpikir yang berbeda tentang hal ini.
tp1

3

Pertanyaan sebenarnya adalah bagaimana Anda mendekati orang / tim tersebut dan membuat mereka ingin tahu tentang cara yang lebih baik dalam melakukan sesuatu? Bagaimana Anda menginspirasi mereka untuk belajar? Tanpa itu, tampaknya semua pengajaran, pertemuan, ceramah, diskusi tidak berguna jika mereka benar-benar bahagia kembali ke meja mereka dan melakukan apa yang selalu mereka lakukan.

Itu dia! Ini memang pertanyaan nyata.

Untuk memberikan backgound, Kami hanya tidak punya waktu untuk melakukan banyak pelatihan formal - tetapi kadang-kadang jika saya lakukan - itu masih tidak melihat cahaya. Saya juga telah menjadi bagian dari perusahaan di mana pelatihan formal menjadi proses itu sendiri tetapi dan Saya sering menjadi saksi bahwa mereka jarang mengajar mereka cara berpikir.

Jadi pertanyaan yang saya ajukan kepada mereka bukanlah bagaimana mengajar mereka - tetapi bagaimana membuat mereka belajar? Perbedaannya halus tetapi apa yang akan membuat semua perbedaan.

Saya tidak tahu apakah saya benar; tetapi sering saya percaya pada dialog dari Matrix film - "Ini pertanyaan yang mendorong kita!" Yang paling penting adalah membuat mereka berpikir, membuat mereka bertanya mengapa! Dan tentu saja, sebagian besar yang berpikir mereka sudah tahu segalanya tentang beberapa pola desain karena mereka mendapat nilai bagus di program universitas - adalah yang paling sulit di sana.

Bagaimana Anda membuatnya menjadi pertanyaan seperti itu? Pendekatan umum saya adalah "yang melemparkan mereka ke dalam kolam jika Anda ingin mereka belajar berenang" . Saya setuju bahwa orang mungkin tidak setuju; dan saya dengan senang hati akan setuju untuk tidak setuju dengan mereka. Ketika Anda melemparkannya ke kolam - mereka sebenarnya tidak belajar berenang secara otomatis; tetapi itu memunculkan naluri bertahan hidup yang membuat mereka berpikir - begitu itu terjadi mereka secara alami akan memikirkan BAGAIMANA dan MENGAPA.

Sebuah contoh praktis yang saya berikan kepada orang-orang adalah menempatkan mereka dalam proyek yang sangat kompleks daripada apa yang mereka harapkan untuk mendapatkannya dan membiarkan mereka bertarung dalam pertempuran mereka sendiri. Ketika mereka mulai mengurai kode dan merasa sulit untuk melacaknya - Anda menyadari bahwa mereka mulai mengajukan pertanyaan yang bagus.

Ini mungkin terdengar agak ekstremis, ini mungkin terdengar pemborosan sumber daya . Dan saya yakin, ada banyak orang lain yang akan memberi saya saran untuk tidak melakukan ini. Tetapi ini berhasil bagi saya!

Tidak peduli apa paket pembayaran dan tag SDM yang Anda tetapkan tidak akan menyelesaikan masalah motivasi dasar . Untuk itu satu-satunya jalan adalah mereka ditantang; Jika Anda mencetuskan semangat dasar manusia ini - segalanya berfungsi. Jika Anda tidak bisa, itu adalah permainan longgar.

PS: Hanya kebetulan saya memposting jawaban di sini https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - dan saya mendapatkan semua bashing; terutama kebanyakan orang percaya bahwa entah bagaimana bisnis tidak mampu membuang sumber daya! Saya yakin, jawaban ini mungkin mendapatkan perlakuan serupa di sini. Tetapi kebenarannya adalah, membuat orang untuk bekerja dan membuat mereka percaya dalam melakukan pekerjaan yang baik adalah subjek psikologi manusia tentang bagaimana menyusun silabus kursus.

Bagaimanapun, tugas yang Anda gambarkan di sini sama saja dengan memicu hasrat batin untuk melakukan perubahan besar. Dan semakin besar sistem semakin sulit. Mulailah dengan orang yang lebih muda yang masih terbangun dengan semangat saya-tidak-akan-melakukan-pekerjaan-baik dan menantang status quo.


terima kasih sudah membuka matriks, sekarang saya harus menghabiskan 2 jam hidup saya menontonnya lagi :) Lucu tapi saya menemukan bahwa "freshers" adalah orang-orang yang akan menyerap apa pun yang Anda lemparkan ke mereka. Setelah menjadi lulusan dari program CS yang bagus, saya membuatnya sangat jelas apa yang saya pikirkan tentang "pendidikan" mereka dan kebanyakan mereka setuju dengan saya. Saya menemukan masalah terbesar adalah orang-orang yang telah melakukan ini selama 10, 15, 20+ tahun. Saya juga setuju dengan pendekatan "coba-coba" Anda. Itulah tepatnya bagaimana saya belajar apa yang tidak boleh dilakukan. Masalahnya adalah a) butuh waktu lama yang tidak mampu dilakukan oleh sebagian besar tim dan b) ketika bekerja dalam sebuah tim ...
DXM

.. pengaturan (berani saya katakan "semi-gesit", jangan benci saya S.Lott :)), kami tidak memiliki kepemilikan tunggal, yang memerlukan uji coba. Jika mereka menulis sesuatu yang gagal, seseorang akan turun tangan dan memperbaikinya. Sebagai seseorang yang berada di kolam dan sebagian besar berhasil, saya ingin berpikir, saya ingin tahu apakah ada sesuatu yang dapat dilakukan untuk mentransfer pola pikir itu tanpa harus seluruh tim Anda melalui kolam.
DXM

@DXM Saya setuju dengan keprihatinan Anda yang lebih baik tidak membuang seluruh tim ke kolam sekaligus. Iya nih. Intinya, mulailah melempar beberapa dari mereka satu per satu! Setidaknya itu adalah kesepakatan yang baik di antara kami. Saya pikir pola pikir yang telah tumbuh selama bertahun-tahun - akan membutuhkan waktu dan ketekunan untuk berubah.
Dipan Mehta

@DXM untuk memberi Anda hal-hal yang lebih konkret - coba inisiatif kecil sekaligus - tunjukkan pencapaian dan tunjukkan bahwa manajemen berarti bisnis untuk melakukan pekerjaan dengan baik di sini. Dan promosikan pola pikir - selangkah demi selangkah. kegigihan akan menjadi suatu keharusan, tetapi saya telah mencapai hal seperti itu di perusahaan terakhir saya. Seiring waktu, manajemen terus memberikan tim saya sebagai contoh bagaimana melakukannya dengan baik.
Dipan Mehta

1
Saya suka jawaban Anda, terutama jika itu bekerja untuk Anda, jadi berikut ini bukan kritik, tetapi hanya sebuah catatan: sayangnya, ini tidak berhasil dalam setiap kasus. Saya memiliki beberapa kasus ketika pengembang yang tidak termotivasi memulai proyek besar. Itu berakhir sama setiap kali: proyek gagal, dan mereka menyalahkan manajemen atau kolega mereka atau fakta bahwa tidak ada cukup waktu atau sumber daya atau persyaratan tidak cukup jelas. Saya bertanya-tanya apa yang membuat perbedaan antara mereka yang akan belajar berenang dan mereka yang lebih cenderung menyalahkan air.
Arseni Mourzenko

2

Seperti yang Anda tunjukkan, motivasinya. Jangan salah mengira mereka tidak mempedulikan mereka yang tidak tahu. Mereka jelas tahu apa yang harus dilakukan. Mereka hanya tidak peduli . Jika itu masalahnya, pertanyaan sebenarnya di sini adalah ... apa kesalahan manajemen Anda yang membuat mereka tidak termotivasi? Apakah Anda anggota terbaru tim? Mungkin mereka sudah pernah mengalami semua ini sebelumnya, dengan itu hanya menyebabkan masalah dari manajemen mereka. Jadi mereka hanya melakukan pekerjaan paling rendah yang diperlukan untuk mempertahankan pekerjaan mereka karena mereka tidak berpikir melakukan lebih banyak akan ditanggapi oleh majikan.


Saya adalah pemimpin tim dan telah bersama tim selama hampir 9 tahun tetapi menjadi pemimpin kira-kira setahun yang lalu. Saya pikir ada perbedaan antara "tidak peduli dengan pekerjaan atau kualitas kode saya" dan "tidak peduli belajar keterampilan baru". Kami sebenarnya telah membuat banyak perbaikan di sisi manajemen dan banyak rekan tim kami sekarang cukup senang. Namun, beberapa cukup puas melakukan apa yang selalu mereka lakukan. Mereka benar-benar dimasukkan ke dalam jam tambahan tanpa diminta, sangat responsif tetapi masih cukup puas dengan debugging bug mereka sendiri 75% dari waktu.
DXM

1
Nah, seperti di setiap profesi, tidak semua orang akan berada di bagian atas kurva lonceng. Mungkin saja Anda hanya memiliki beberapa orang di dalamnya untuk gaji.
GrandmasterB

Anda tahu, setiap tahun kami memilih kutipan tim dan tahun 2011 adalah "itu apa adanya", tetapi kami akan memulai tahun baru dan setidaknya untuk saat ini, saya akan menolak untuk menerima bahwa itu adalah apa adanya, Meskipun saya setuju dengan Anda bahwa sebagian besar waktu sebenarnya. Saya telah memikirkan lebih lanjut tentang pertanyaan ini dan sebenarnya memiliki ide yang mungkin memiliki potensi. Karena saya tidak dapat menjawab pertanyaan saya sendiri (masalah pribadi, bukan batasan sistem), jika 2 orang lagi memilih untuk membuka kembali programer.stackexchange.com/questions/127080/... Saya akan memposting di sana :)
DXM

2

Menurut saya ini adalah masalah manajemen dan kepemimpinan - jika ini adalah tim Anda maka Anda dapat bekerja untuk membuat peningkatan (pribadi dan kode) atribut inti dari tim Anda, pertanyaannya adalah apakah kehendak yang didukung oleh manajemen Anda - karena Anda akan ingin melakukan hal-hal yang akan memakan waktu (mereka akan mendapatkan kemenangan bersih karena Anda harus mengurangi utang teknis baru dan akan membayar utang teknis yang ada).

Jadi, Anda menegaskan bahwa Anda ingin tim untuk meningkatkan, Anda mendapatkan persetujuan mereka bahwa ini adalah hal yang baik (bahwa tim, secara keseluruhan, bekerja untuk meningkatkan kualitas kode-kodenya) dan Anda kemudian memulai program untuk membuat ini terjadi - kedengarannya sangat mudah ... Saya sadar itu tidak!

Saya pikir ada dua bagian untuk ini - pendidikan dan praktik kerja.

  • Edukasi Anda bisa memulai satu kali makan siang seminggu - semua orang makan bersama, Anda menjalankan presentasi 20 ~ 30 menit dengan Q&A. Anda mulai dengan dasar-dasar yang Anda inginkan - SOLID dapat menempati 2 ~ 4 minggu pertama - seiring waktu Anda membuat tim untuk berbicara secara bergilir dan Anda dapat mencari cara untuk memutuskan siapa yang berbicara tentang apa di antara Anda. Izinkan speaker beberapa waktu persiapan dalam bekerja. Di luar itu, dorong kehadiran kelompok pengguna lokal (dengan membuatnya setidaknya sebagian sebagai kegiatan sosial jika memungkinkan)
  • Praktik kerja ... baik itu tergantung pada apa yang Anda lakukan sekarang dan alat apa yang Anda miliki, tetapi Anda mungkin ingin melihat menyetujui standar pengkodean, memperkenalkan ulasan kode rekan (apakah itu solid), pengujian unit (belum tentu menguji dulu) , menjalankan server integrasi berkelanjutan dan melihat lebih banyak pengujian otomatis (selain pengujian unit). Tetapi ini secara substansial harus diperkenalkan dengan persetujuan / persetujuan (bukan server build / CI!) Dan Anda harus ingin meningkatkan kualitas sebagai sebuah tim. Selalu ada hal yang bisa ditingkatkan (Kaizen)

Layak juga melihat Kanban (yang dilihat sebagai driver untuk perubahan / peningkatan).

Satu pemikiran terakhir - saya seorang programmer kejuruan, dan saya ingin tim saya tetap sama tetapi bekerja lebih dari 40 jam seminggu sebenarnya bukan hal yang baik sehingga tujuan seseorang adalah memiliki tim yang menyelesaikan pekerjaannya efektif dan baik dalam minggu kerja normal dan dalam hal ini argumen untuk meningkatkan praktik kerja adalah bahwa itu lebih mungkin misalnya: menambahkan unit test untuk mendemonstrasikan kasus gagal ketika (sebelum) perbaikan bug memberi Anda keyakinan bahwa itu adalahtetap; memiliki build server memberi Anda kepercayaan diri pada kemampuan Anda untuk membangun solusi Anda dengan bersih - jika build itu juga menghasilkan paket penyebaran, itu berarti bahwa penyebaran disederhanakan secara dramatis; Kode SOLID, menurut definisi, lebih mudah untuk dimodifikasi; dan secara keseluruhan, semakin sedikit utang teknis yang Anda keluarkan, semakin sedikit Anda harus membayar kembali ...


0

Saya jatuh ke pemrograman secara tidak sengaja ~ 30 tahun yang lalu. Saya termotivasi untuk mempelajari prinsip-prinsip rekayasa perangkat lunak dasar dengan ditugaskan untuk memelihara / mendukung kode orang lain. Dalam tugas-tugas ini, saya belajar bagaimana pembaca kode mengalami kode - bagaimana berempati dengan pembaca kode. Saya tidak ingin menimbulkan rasa sakit karena kode saya yang buruk pada orang lain!

Praktek menugaskan pemrogram baru ini untuk mempertahankan / mendukung kode orang lain bukanlah suatu keajaiban, dan tampaknya memberikan motivasi untuk belajar bagaimana menghasilkan kode yang solid lebih sering daripada tidak.


1
Saya memulai dengan cara yang sama, meskipun tidak secara kebetulan. Ini sangat mirip dengan apa yang dikatakan Dipan Mehta dalam jabatannya. Anda melempar seseorang ke kolam, pastikan itu tidak terlalu dalam, dan biarkan mereka berenang. Anda adalah salah satu dari mereka yang belajar berenang, tetapi itu tidak universal (lihat jawabannya di komentar). Saya juga percaya bahwa jenis pendekatan ini bekerja lebih baik untuk orang baru daripada mereka yang sudah memiliki kebiasaan yang sudah berurat berakar. Kemudian, mereka tidak hanya perlu berenang, tetapi juga menentang praktik yang sudah ada saat ini.
DXM
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.