Tanyakan pertanyaan-pertanyaan ini tentang petunjuk Anda.
- Apakah mereka terbiasa bekerja sendiri atau dengan tim yang sangat kecil?
- Apakah mereka sebagian besar berkode di toko yang satu ini?
- Apakah mereka terbiasa mengambil keputusan?
- Apakah mereka terbiasa "hanya menyelesaikannya"?
- Apakah mereka menulis sebagian besar kode?
Jika jawabannya "ya", maka saya akan melukis gambar dari jenis programmer memimpin tertentu. Jika itu cocok dengan apa yang Anda alami, mungkin itu akan membantu masuk ke kepala mereka. Jika tidak, abaikan jawaban ini .
Ini adalah seseorang yang telah berada di sana sejak hari pertama, telah menghabiskan bertahun-tahun di pekerjaan yang sama bekerja pada basis kode yang sama, terbiasa memiliki cara mereka sendiri, dan tidak memiliki banyak pengalaman dengan cara lain.
Mereka tidak mempertimbangkan orang lain ketika menulis kode karena semuanya masuk akal bagi mereka. Tentu saja, mereka menulisnya, atau mereka telah menghabiskan waktu bertahun-tahun memahaminya.
Mereka menganggap gaya pengkodean sebagai preferensi pribadi, bukan alat untuk mengurangi pemeliharaan dan bug. Ketika berdebat tentang gaya pengkodean, mereka akan kesulitan mendengar argumen Anda karena mereka mungkin tidak pernah berpikir banyak tentang mengapa mereka melakukan sesuatu dengan cara mereka. Apa yang akan mereka dengar adalah "Aku ingin melakukannya dengan caraku" atau "Aku ingin melakukannya dengan cara yang baru, mewah, dan trendi".
Mereka diatur dengan cara mereka. Karena mereka telah melakukannya dengan cara yang sama untuk waktu yang lama semua alat dan editor mereka dan otak dikonfigurasikan dengan tepat sesuai gaya mereka. Setiap penyimpangan dari gaya ini akan bertentangan dengan cara kerja yang diatur dengan hati-hati tetapi sangat rapuh ini. Upaya untuk mengubah akan menarik keluhan tentang editor mereka, alat, cara mereka suka bekerja, atau menjadi "sulit dibaca". Mereka menolak perubahan karena mereka telah membungkus diri mereka begitu ketat dalam status quo mereka tidak dapat berubah.
Ini adalah seseorang yang belum pernah belajar rekayasa perangkat lunak dan arsitektur perangkat lunak. Mereka hanya menyatukan apa saja yang berhasil.
Anda memiliki masalah orang, bukan masalah teknologi.
Anda harus melatih ulang lead Anda, atau Anda harus berhenti.
Pergi ke manajemen adalah pilihan terakhir . Baik untuk alasan @JaredSmith menunjukkan dan karena Anda akan kalah. Orang ini telah menghabiskan bertahun-tahun menghasilkan uang untuk mereka. Dia menulis perusahaan mereka. Dia melakukan banyak kebakaran. Untuk Anda dia seorang koki koboi membuat spageti. Bagi mereka, dia adalah pahlawan yang membangun dan menyelamatkan perusahaan.
Untuk melatih kembali Anda harus ...
- Dapatkan kepercayaannya.
- Cari tahu bagaimana dia berpikir.
- Atasi ketakutannya tentang perubahan.
- Buat perubahan lebih mudah.
- Tunjukkan bagaimana ini lebih baik untuknya .
Perhatikan gayanya dengan serius dan masuk ke dalam kepalanya. Tanyakan padanya tentang itu. Mengapa dia melakukan hal-hal seperti itu? Apa yang dia lihat ketika dia membacanya? Bagaimana cara berinteraksi dengan alat-alatnya? Bagaimana dia menelusuri kode? Mengetahui semua hal ini akan memungkinkan Anda untuk memahami dan mengatasi keberatannya.
Temukan akar obyektif dari keberatan subyektifnya, buat itu dapat ditindaklanjuti. "Sulit dibaca" bersifat subyektif, dan tidak memberi Anda informasi. Anda tidak dapat melakukan apapun tentang itu. "Saya buta warna dan penyorotan sintaksis tidak berfungsi" adalah objektif, ini memberi Anda informasi, dan Anda dapat melakukan sesuatu tentang itu. Saya akan merekomendasikan buku berjudul Getting To Yes untuk lebih lanjut tentang itu.
Setelah Anda mendapatkan masalah root, masalah sebenarnya yang dia alami, lihat apakah Anda dapat memperbaikinya atau mengatasinya. Maka itu tidak masalah. Mereka mungkin masih memiliki masalah emosional dengan perubahan, tetapi setidaknya mereka tidak dapat lagi berdebat bahwa ini adalah masalah aktual.
Lakukan sedikit demi sedikit. Ini adalah seseorang yang telah melakukannya dengan cara yang sama selama bertahun-tahun. Dia terbiasa melihat pola-pola tertentu dalam kode dan menggunakannya untuk memahaminya. Tiba-tiba mengubah semua pola itu akan membingungkan. Betapa frustrasinya untuk perlahan-lahan membawa mereka ke kecepatan dengan latihan yang dikenal baik, Anda harus berjalan melalui itu.
Advokasi untuk gaya komunitas standar. Ini menghilangkan argumen bahwa ini tentang preferensi pribadi dan memberikan tekanan pada mereka untuk membenarkan mengapa gaya mereka yang berbeda jauh lebih baik. Jika Anda berencana untuk merekrut, akan lebih mudah untuk mengintegrasikan karyawan baru.
Advokasi untuk gaya kode otomatis. Buat mengikuti gaya yang benar dengan menekan tombol. Gunakan alat yang dimulai dengan gaya standar, memungkinkan Anda mengonfigurasinya sesuai selera Anda, dan dapat menata ulang kode dengan menekan satu tombol. Membuatnya semudah mungkin mengikuti gaya menghilangkan banyak argumen tentang betapa sulitnya untuk mengikuti. Mereka dapat mengkodekan sesuka mereka, dan ketika selesai mereka menekan tombol dan mengikuti gaya yang dapat dibaca orang lain.
Karena orang ini tidak dalam pemikiran untuk memikirkan orang lain, Anda harus menunjukkan bagaimana perubahan ini menguntungkan mereka. Ini bisa sesederhana "karena ini adalah standar sekarang, Anda tidak perlu melalui pertarungan ini lagi dengan orang berikutnya yang Anda pekerjakan". Atau bisa juga "jika kami melakukan tes, Anda bisa lebih agresif mengubah kode dan tidak terlalu khawatir mengubah hal-hal". Atau "jika ada dokumen yang bagus, orang tidak perlu repot dengan pertanyaan tentang cara kerja kode". Agar ini menjadi efektif, Anda harus tahu apa yang mereka inginkan - beberapa orang suka diganggu, itu membuat mereka merasa penting.
Itu jalan yang sangat panjang. Anda harus memutuskan apakah Anda memiliki kesabaran untuk mengelola dan melatih kembali bos Anda. Pikirkan diri Anda lebih sebagai guru mereka daripada bawahan frustrasi mereka, dan Anda mungkin merasa lebih baik tentang hal itu.