Apa yang harus Anda lakukan jika junior Anda tidak menerima saran Anda? [Tutup]

Saya memimpin tim yang terdiri dari 3-4 pengembang junior. Pekerjaan saya - selain menulis kode - adalah untuk memberikan pengawasan dan bimbingan bagi para junior.

Tetapi, saya sepenuhnya memahami betapa pengembang menghargai otonomi dalam pekerjaan mereka, dan saya tidak ingin menghancurkan motivasi intrinsik mereka dengan menyuapi mereka dengan pikiran dan algoritma saya; Saya ingin mereka mengeksplorasi masalah dengan cara mereka sendiri, dan memikirkannya sendiri dan hanya datang kepada saya ketika mereka benar-benar menghadapi masalah yang tidak dapat diatasi.

Ketika mereka datang kepada saya, kadang-kadang saya harus mengusulkan algoritma yang sama sekali berbeda untuk menyelesaikan masalah karena algoritma mereka tidak cukup kuat (ingat, saya adalah senior dan saya telah melihat lebih banyak daripada mereka). Tentu saja saya akan menjelaskan hal ini dengan cara yang baik agar tidak menyakiti perasaan mereka, dan saya akan dengan lembut menguraikan bagaimana solusi saya jauh lebih unggul daripada mereka, tidak ada nada merendahkan atau kata-kata mengutuk.

Tapi tetap saja, mereka terkadang enggan menerima saran saya, sebagian karena mereka telah berinvestasi begitu banyak dalam algoritma mereka sendiri, atau sebagian karena ketakutan bahwa menggunakan metode baru akan memerlukan lebih banyak waktu belajar dan membuat mereka tampak di hadapan manajemen seolah-olah mereka pergi ke mana-mana. Tapi jauh di lubuk hati saya, saya tahu betul bahwa algoritma saya jauh lebih baik daripada mereka dan mereka harus mengadopsinya.

Apa yang harus saya lakukan jika mereka tidak menerima saran saya? Haruskah saya meminta mereka untuk mengikuti jalan saya, atau haruskah saya membiarkan kepala mereka terbentur di dinding berkali-kali dan menunggu mereka kembali kepada saya? Melakukan yang pertama membuat saya menjadi seorang diktator, tetapi melakukan yang selanjutnya akan menghabiskan waktu pengembangan yang berharga dan mengeluarkan biaya perbaikan bug. Saya benar-benar dalam dilema di sini.

Bantu mereka untuk memahami mengapa mereka harus membuat perubahan yang Anda sarankan. Dan dengarkan mereka jika mereka punya alasan kuat untuk tidak melakukan perubahan. Berdiskusi, dan mencapai kesepakatan berdasarkan apa yang terbaik untuk dilakukan.

Pendekatan ini penting karena alasan berikut:

• Anda ingin mereka membuat perubahan karena alasan bisnis / teknis yang kuat. Sangat penting untuk menjadi jelas tentang apa ini (ingat bahwa Anda juga bisa salah, jadi rendah hati ....).
• Anda benar-benar ingin menyampaikan alasan di balik saran Anda - dengan cara itu penerima akan belajar untuk menyelesaikan sendiri masalah yang sama di masa depan. Anda juga akan memiliki hubungan yang lebih baik jika junior Anda merasa bahwa mereka belajar beberapa wawasan yang baik dari Anda.
• Anda tidak akan dihormati jika Anda menggunakan senioritas Anda dan tidak dapat menunjukkan bahwa Anda benar-benar memiliki alasan yang bagus.
• Bos Anda mungkin ingin yakin bahwa Anda menggunakan waktu junior Anda secara efektif pada hal-hal yang menciptakan nilai nyata, bukan hanya "melakukannya dengan cara saya" demi hal itu.

Jika Anda cerdas, Anda juga bisa membuat mereka datang ke jawaban hanya dengan mengajukan pertanyaan . Dilakukan dengan benar, junior Anda akan sampai pada kesimpulan yang benar sendiri (dan karenanya jauh lebih bersedia untuk mengimplementasikannya). Contoh pertanyaan:

• Kode Anda mengasumsikan akses ke basis data produksi. Bagaimana kita bisa mengubahnya sehingga masih akan bekerja dan dapat diuji dengan benar oleh JUnit dalam lingkungan pengembangan yang terputus? (jawaban potensial: ah! kita harus menggunakan injeksi ketergantungan ....)
• Apa yang akan terjadi jika penyerang dengan sengaja mengirimkan beberapa SQL yang dibuat secara cerdik dalam formulir entri data online Anda? (jawaban potensial: ah! mungkin kita seharusnya tidak membangun pernyataan SQL dengan menggabungkan teks yang tidak diverifikasi dari internet)

EDIT : Jika Anda berhasil meyakinkan junior Anda bahwa hal yang benar untuk dilakukan adalah mengikuti saran Anda, tetapi mereka masih enggan daripada di sini adalah beberapa saran tambahan:

• Jelajahi mengapa mereka enggan. Mungkin saja mereka perlu menyadari secara pribadi bahwa tidak masalah jika Anda mengeluarkan kode, asalkan Anda mendapatkan hasilnya. Atau bisa jadi mereka merasa di bawah tekanan waktu karena tenggat waktu. Anda perlu tahu, jika tidak, Anda tidak dapat membantu mereka .....
• Anda dapat menekankan bahwa mereka dapat memperlakukan perubahan sebagai cara untuk meningkatkan keterampilan refactoring mereka. Setelah keterampilan refactoring cukup baik, Anda harus dapat mengarahkan ulang bahkan basis kode yang cukup besar dan kompleks relatif cepat.
• Anda harus menekankan bahwa semuanya akan ada dalam kontrol sumber, sehingga mereka selalu dapat kembali ke versi lama jika diperlukan.

Saya membenci sikap sombong Ketua Tim saya yang terakhir tetapi menghormatinya karena dia memiliki pengetahuan teknis yang unggul dan dia banyak mengajar saya tanpa mengajari saya. Yang paling penting dia tidak pernah memaksaku pergi dengan rencananya. Dia akan berperan sebagai penasihat Iblis dengan rencanaku, memaksaku untuk membuktikan bahwa rencanaku tanpa cacat. Dia akan mencari celah dan menunggu penjelasan saya mengapa itu bukan celah atau solusi yang lebih murah. Dia akan bertanya kepada saya apakah ada solusi alternatif dan mengusulkan beberapa ide jika saya tidak punya. Saya harus mengevaluasi ide-idenya dan bahwa rencananya tidak optimal atau Jika dia yakin bahwa rencanaku benar atau setidaknya memiliki rasio risiko-hadiah yang sama dengan rencananya, dia akan memberikan lampu hijau. Jika saya gagal dengan ide saya, saya harus mencoba solusinya.

Harus ada pertukaran antara kebebasan dan tenggat waktu. Anda tidak memiliki kemewahan untuk memperpanjang batas waktu dan Anda tidak dapat membiarkan junior Anda melanggar batas waktu itu. Anda harus sopan tetapi tegas dengan mereka bahwa setelah mereka mencoba algoritma mereka dan tidak membuatnya bekerja, mereka memiliki kewajiban untuk mendengarkan Anda. Buktikan dengan contoh bahwa Anda tahu barang-barang Anda. Tapi, yang sama pentingnya membuat mereka belajar, jangan mengajar mereka.

Jika itu merupakan persyaratan, maka catatlah seperti itu. Jika itu hanya saran, seperti yang Anda perhatikan, maka mereka harus bebas untuk melakukannya sebaliknya. Beberapa pertanyaan yang akan saya tanyakan:

• Apakah Anda memiliki wewenang untuk mendorong solusi spesifik?
• Berapa luas otoritas itu?
• Apakah ada solusi yang buruk atau hanya berbeda?

Saya yakin Anda bisa bertanya lebih banyak, tetapi dua yang pertama fokus pada otoritas Anda dan yang terakhir pada apakah masalah ini benar-benar layak didorong.

Jawaban berikut memiliki beberapa poin tambahan yang bagus dan saya akan menambahkan di sini bahwa Anda perlu memperlakukannya lebih sebagai proses kolaboratif di mana Anda bekerja paling tidak beberapa di antaranya dengan "tim" Anda daripada hanya mengeluarkan perintah kepada mereka. Mereka akan belajar saat mereka mengatasi masalah dengan Anda lebih dari sekadar diberitahu, "pertimbangkan melakukannya dengan cara ini."

Belajar benar-benar hanya terjadi di mana kegagalan terjadi, karena kegagalan adalah motivator dan memberikan isyarat memori untuk mengingat di masa depan. Ini pada dasarnya adalah apa yang kita sebut pengalaman, dan pengalaman yang baik di tempat kerja akan datang dari kegagalan dan belajar dari kegagalan. Jika junior Anda mampu melakukan semuanya dengan benar pertama kali, mereka tidak akan belajar apa-apa, atau mereka tidak akan menjadi junior.

Jika Anda memiliki terlalu banyak junior yang mengacaukan segalanya, mungkin perusahaan Anda memiliki staf yang salah, dengan terlalu banyak pengembang tingkat junior di mana kendala waktu membutuhkan orang yang lebih berpengalaman untuk meminimalkan risiko Anda, namun bahkan kemudian Anda dapat memiliki masalah dan penundaan, karena pengembang senior membuat kesalahan untuk belajar dari juga.

Junior Anda harus belajar dan mendapatkan pengalaman agar dapat mengatasi lingkungan di mana tenggat waktu sangat ketat. Sebagai pemimpin tim, adalah tugas Anda untuk memberikan contoh dan menginspirasi junior Anda untuk bekerja secara efisien, namun kenyataannya adalah Anda harus mengesampingkan masalah kebanggaan pribadi dan kekhawatiran untuk jadwal yang ketat Anda jika Anda ingin junior Anda benar-benar belajar sesuatu , dan karena itu Anda harus membiarkan mereka gagal. Karena itu, adalah tugas Anda untuk melakukan panggilan. Terkadang Anda perlu memberi ruang bagi junior untuk gagal, dan kemudian membawa mereka dengan sabar melalui proses peninjauan untuk menunjukkan kepada mereka di mana mereka dapat meningkatkan gagasan mereka. Di lain waktu, Anda perlu meletakkan kaki Anda, tetapi lakukan dengan cara yang memungkinkan Anda untuk menunjukkan bahwa melakukan itu di luar kebutuhan asli yang tidak mencerminkan buruk pada kemampuan junior Anda per-se.

Adapun masalah tenggat waktu yang ketat, ini adalah di mana Anda perlu menjadwalkan dan mengalokasikan pekerjaan Anda sesuai dengan kekuatan dan kelemahan relatif dalam tim Anda. Akhirnya uang berhenti dengan Anda. Ketika Anda bertanggung jawab atas orang lain, Anda tidak berada di sana untuk menjadi teman semua orang, Anda ada di sana untuk menyelesaikan pekerjaan yang sulit dalam keadaan sulit. Bagaimana Anda menjaga semua orang di sisi Anda berbicara kepada orang lain melalui keprihatinan dan masalah Anda, membuat alasan yang masuk akal mengapa Anda memerlukan anggota tim Anda untuk melakukan sesuatu dengan cara tertentu.

Dari pengalaman pribadi saya, Anda perlu menyediakan waktu dengan junior Anda untuk mendiskusikan kekuatan dan kelemahan kedua ide tersebut dan kemudian secara kolaboratif mencari solusi terbaik yang akan menyelesaikan masalah yang ada - bahkan dengan risiko membiarkan diri Anda dibuktikan salah - dan kemudian bergerak maju. Jika Anda berdua tidak dapat mencapai konsensus pada akhir waktu yang dialokasikan, maka pada saat itu Anda harus mengakhiri rapat dengan ringkasan yang mempertimbangkan masalah yang dibahas dan mencatat bahwa tidak ada konsensus yang tercapai. Terlepas dari hasil pertemuan Anda, Anda berterima kasih kepada junior Anda untuk waktu yang dihabiskan, dan menunjukkan bahwa Anda akan kembali dengan keputusan Andasegera. Setelah mempertimbangkan diskusi Anda dengan cermat, Anda akan memiliki opsi untuk mengalokasikan waktu tambahan untuk diskusi lebih lanjut, atau memerintahkan junior untuk melanjutkan rencana apa pun yang telah Anda selesaikan sesuai dengan hasil pertemuan Anda.

Ya, waktu sangat berharga kadang-kadang, tetapi ketika Anda memilih untuk mengambil junior Anda perlu menerima bahwa Anda mengambil tanggung jawab untuk berinvestasi dan memelihara pengembangan profesional mereka, dan Anda perlu menerima bahwa sebagai hasilnya itu akan sementara waktu setidaknya menghabiskan waktu Anda.

Saya akan mempertanyakan apakah Anda benar-benar mempresentasikan saran Anda dengan cara yang tidak merendahkan. Saat Anda menggunakan frasa seperti:

solusi saya jauh lebih unggul daripada mereka

dan

jauh di lubuk hati saya, saya tahu betul bahwa algoritma saya jauh lebih baik daripada mereka dan mereka harus mengadopsinya.

itu membuat saya berpikir bahwa Anda mungkin menemukan sikap "cara saya lebih unggul". Tidak ada orang yang suka diberi sikap itu. Ketika saya menerimanya di masa lalu, saya secara aktif menggunakan cara yang berbeda untuk membuktikan orang tersebut salah. Bisa jadi junior Anda melakukan hal yang sama.

Cara yang lebih baik adalah duduk bersama orang tersebut dan mendiskusikan algoritme mereka. Tunjukkan mengapa Anda tidak berpikir itu akan berhasil, dan dengarkan jawaban yang mereka berikan dengan pikiran terbuka. Lihat apakah algoritme mereka dapat dimodifikasi agar berfungsi dengan benar.

Jika apa yang Anda miliki junior pasti tidak akan berhasil, maka jelaskan kepada mereka mengapa itu tidak akan berhasil. Bagian mana yang salah, atau akan melibatkan penulisan ulang nanti, atau tidak cocok dengan model bisnis. Pastikan mereka memiliki pemahaman yang baik tentang alasan Anda. Kemudian jelaskan algoritme Anda kepada mereka, tunjukkan bagian di mana ia akan bekerja dan kode mereka akan gagal.

Pertama-tama, apakah Anda tahu alasan sebenarnya mengapa junior Anda tidak menerima saran Anda?

Terkadang Anda tahu, seorang junior sebenarnya bisa menulis sesuatu yang lebih baik daripada seniornya karena perspektif yang lebih baru dan pendidikan CS yang lebih mutakhir. Meskipun sebagai senior Anda mungkin telah melihat lebih banyak contoh dunia nyata. Tetapi jebakan buruk yang sering saya lihat senior saya kadang jatuh ke dalam adalah lupa bahwa praktik terbaik dapat berubah dari waktu ke waktu. Saya yakin ini tidak berlaku untuk Anda karena Anda telah memperbarui diri di situs-situs seperti ini. ;)

Saya sarankan mencoba mendekati junior Anda tanpa "aura" senior, mencoba untuk berbicara dalam istilah level dengan mereka, menunjukkan rasa ingin tahu dalam kode yang telah mereka tulis. Ajukan pertanyaan, dengarkan tanggapan mereka. Jangan bertanya dengan cara menuduh seperti:

"Kode kamu sangat tidak fleksibel, kamu perlu mengubahnya ke ini ..."

alih-alih bertanya

"Aku hanya bertanya-tanya, bagaimana jika ada seseorang yang ... apakah kodemu berhasil mengatasinya? ... kupikir pola strategi mungkin membantu di sini. Bagaimana menurutmu?"

Ini saya percaya akan membantu Anda terlibat dalam percakapan yang lebih sehat dengan mereka daripada seperti seorang profesor / dosen yang memandang rendah mereka seperti tahu segalanya. Ini juga akan membantu Anda untuk lebih memahami alasan dan perspektif mereka.

Apakah Anda mengontrol akses push ke repositori?

Di open source, akses push selalu dikontrol oleh penjaga gerbang yang bertugas menegakkan kualitas. Jika Anda secara aktif memantau komitmen yang mereka dorong, Anda harus benar-benar mengetahui di mana mereka dapat meningkatkan.

Apakah mereka dapat meretas atau meningkatkan kode Anda. Jika mereka mendapat kesempatan untuk melihat internal tentang bagaimana kode Anda bekerja, mereka dapat belajar bagaimana beradaptasi dengan gaya Anda dengan lebih baik. Jika Anda mendorong saran Anda tanpa menerima saran dengan pikiran terbuka maka mereka akan cenderung tidak mendengarkan pendapat Anda.

Ada beberapa keadaan di mana tidak ada jawaban yang benar (seperti preferensi gaya pengkodean). Dalam hal itu, cobalah untuk menetapkan (atau menegakkan) kebijakan di seluruh perusahaan sehingga mereka memahami bahwa gaya kode harus disesuaikan agar konsisten dengan basis kode utama. Menggunakan pedoman gaya yang sudah mapan (seperti panduan gaya Microsoft untuk C #) adalah cara terbaik, terutama untuk pengembang baru di tim.

Jika Anda membuat pernyataan selimut tentang teknik pengkodean mereka, ada peluang yang cukup bagus bahwa Anda tidak sepenuhnya memahami alasan di balik pilihan mereka. Nada pertanyaan Anda saja membuat Anda terdengar sombong. Apa yang Anda dapatkan / korbankan dengan mendorong pendekatan Anda pada pengembang yang lebih muda?

Pertanyaan kunci yang perlu Anda tanyakan pada diri sendiri adalah, apakah saran Anda diarahkan untuk mempertahankan / meningkatkan kualitas basis kode atau untuk menegaskan dominasi / superioritas Anda terhadap rekan-rekan Anda? Yang pertama adalah kontrol kualitas yang sederhana dan dapat dibenarkan karena itu, tangga merugikan dinamika tim terlepas dari hak Anda.

Either way, jika Anda ingin mendorong solusi Anda ke rekan-rekan Anda, Anda harus memiliki bukti nyata bahwa itu sebenarnya unggul. Peningkatan kinerja yang luar biasa seharusnya cukup mudah untuk diperbaiki, apa pun yang kurang sepadan dengan usaha (kecuali aplikasi-aplikasi penting kinerja). Memaksa pekerjaan Anda pada orang lain untuk membenarkan rasa superioritas pribadi Anda akan berakhir dengan Anda dikecualikan sebagai 'lelaki tua berotot'.

Catatan: Programmer terbaik dan paling berbakat yang saya temui selama bertahun-tahun selalu tampak adalah orang-orang yang bersedia untuk berhenti dan menjelaskan kisah belakang di mana mereka memulai pendekatan mereka.

Nah ini sepertinya menarik dan sangat alami dengan programmer muda sangat melekat pada kode yang telah mereka tulis, mungkin mereka telah menghabiskan beberapa waktu untuk tiba di tempat yang sama atau mereka mengambilnya dari beberapa situs yang bagus (Sungguh, Hey Jon skeet menulis ini pria ! !).

Meskipun demikian, string dasar yang dilampirkan di sini adalah lampiran dengan kode yang mana Anda perlu berkonsentrasi dan saya pikir Anda perlu melakukan upaya yang cukup besar untuk membuat mereka mengerti bahwa eksekusi dan hasil yang diharapkan lebih penting daripada nama mereka menjadi terukir pada repositori sumber karena mendorong dalam kode ini. Anda harus menggambar garis mengapa kode Anda lebih baik dan juga baik dalam hal mempertahankannya untuk pekerjaan di masa depan.

Mempertimbangkan bahwa beberapa kegagalan adalah yang utama (perlu beberapa patah hati untuk keterikatan apa pun) tetapi dengan upaya bertahap saya pikir mereka akan muncul dan akan dapat menghargai upaya Anda lebih baik. Sedikit waktu dan beberapa kegagalan adalah apa yang saya pikir Anda butuhkan. Memaksakannya pada mereka akan menjadi cara lain di sekeliling beberapa kisah sukses dan kemudian kiamat dan pemberontakan.

Setiap orang memiliki gaya yang berbeda. Jika Anda menemukan 10 orang yang berbeda dan memberi mereka masalah nontrivial, mereka akan memberi Anda 10 pendekatan berbeda menggunakan 10 gaya "standar pengkodean" yang berbeda.

Intinya adalah: pilih barang yang penting. Jika sesuatu disampaikan kepada Anda oleh seorang junior yang tidak menghasilkan solusi yang benar, apakah itu sangat tidak efisien (+1 urutan besarnya, bukan instruksi di sini atau di sana), atau menciptakan celah keamanan, kemudian jelaskan masalah Anda dan mengapa. Jika itu adalah komentar "Saya akan melakukan ini", yah itu bagus, Anda akan melakukan "itu" dan dia melakukan "sesuatu yang lain" tetapi masalahnya masih diselesaikan dengan cukup (lihat poin di atas). Pindah ke fitur selanjutnya atau perbaiki.

Bagian dari belajar untuk menjadi pemimpin yang baik adalah belajar untuk mengenali apa yang benar-benar penting dan apa yang sebenarnya tidak. Plus, Anda menghapus diri sendiri sebagai penghambat potensial kinerja grup Anda jika mereka harus memeriksa semuanya melalui Anda.

EDIT: pastikan saran Anda asli dan bukan persyaratan terselubung. Sebuah saran hanya itu- saran mana yang bebas untuk diikuti atau tidak. Jika itu suatu persyaratan, nyatakan demikian.

Seperti yang telah ditunjukkan oleh beberapa yang lain, jika Anda benar-benar hanya membuktikan para pengembang junior dengan saran dan mereka diutarakan demikian maka Anda benar-benar tidak punya banyak alasan untuk merasa kesal pada mereka jika mereka tidak mengikutinya karena mereka mungkin tidak melihat banyak alasan untuk melakukannya. Demikian juga, Anda benar-benar tidak bisa pergi mencaci maki mereka karena tidak mengikuti saran Anda karena mereka tidak arah sebenarnya untuk melakukan sesuatu dengan cara tertentu.

Dalam hal mencoba membuat pengembang junior melakukan sesuatu seperti yang Anda inginkan:

• Kontrol terminologi Anda, membuat saran tidak sama dengan membuat rekomendasi yang pasti tidak sama dengan memberikan arahan . Gunakan terminologi yang sesuai untuk menyampaikan maksud Anda dan jika Anda berpikir bahwa cara Anda melakukan sesuatu adalah cara yang lebih baik untuk melakukannya, beri tahu mereka bahwa itu adalah rekomendasi Anda untuk melakukannya. Demikian juga, jika itu benar-benar kritis bahwa hal-hal dilakukan dengan cara tertentu (yaitu tidak dapat menahan penundaan waktu) maka hanya menjadi tumpul dan memberi mereka arahan tentang bagaimana hal itu harus dilakukan.
• Pengembang junior masih melalui proses pembelajaran terlepas dari bagaimana Anda mengutarakan sesuatu, selalu memberikan semacam alasan di balik apa yang Anda katakan kepada mereka kecuali ada alasan khusus yang tidak dapat Anda lakukan. Bahkan dalam kasus itu, kebanyakan orang akan mengerti jika Anda mengatakan sesuatu seperti, "Itu harus dilakukan dengan cara ini, saya tidak peduli untuk itu sendiri tetapi keputusan sudah dibuat." mereka cenderung masuk akal.
• Jika itu benar-benar hanya saran maka pastikan bahwa ide Anda sebenarnya lebih baik daripada bagaimana melakukannya. Jika Anda tidak berpikir demikian, maka duduklah bersama pengembang dan lakukan tinjauan kode dan konsep sehingga mereka dapat membenarkan solusi mereka. Mungkin sekali mereka mulai menjelaskannya kepada orang lain - dan Anda mengajukan pertanyaan yang benar - mereka akan melihat cara yang lebih baik dan ingin melakukan pengkodean ulang dengan cara mereka sendiri.
• Jangan bertengkar tentang detail jika solusi mereka mirip dengan apa yang Anda sarankan semula, mungkin mereka mengambil apa yang Anda katakan dan memperhitungkannya dengan sedikit berbeda atau mengubah konsep asli mereka berdasarkan saran Anda.

Ini adalah pengantar yang sempurna untuk pengujian unit. Jika junior devs Anda memiliki solusi, itu harus dapat diuji. Mintalah mereka membuat unit test untuk menekankan kode mereka. Kemudian tinjau tes unit . Jika Anda dapat menunjukkan lubang dalam tes, maka mudah untuk menjalankannya kembali dan melihat solusinya pecah di bawah tekanan.

Itu memungkinkan Anda untuk menunjukkan kepada mereka mengapa solusi Anda lebih baik, memberi Anda tes unit yang dapat Anda gunakan kembali ketika kode berubah, dan memberikan pengalaman belajar yang berharga kepada para junior pengembang. Dan siapa tahu, Anda mungkin menemukan bahwa solusi mereka baik-baik saja.

Pada titik tertentu Anda harus bertanggung jawab. Anda terdengar seperti berusaha untuk membiarkan mereka menyuarakan pendapat mereka. Saran Anda mungkin tidak sempurna. Para pengembang lainnya mungkin tidak mengerti / setuju dengan Anda. Mereka mungkin tidak setuju satu sama lain. Jika Anda yang bertanggung jawab, itu bukan demokrasi. Mereka tahu itu ketika mereka mengambil pekerjaan itu.

Jika tidak ada situasi di mana mereka harus mengikuti Anda, Anda tidak pantas dan tidak memiliki tujuan sebagai bos mereka. Ubah peran Anda dalam tim menjadi sumber daya dan bukan otoritas jika Anda tidak berencana menggunakannya. Pada titik tertentu Anda harus mengirimkan kode terbaik yang Anda bisa di bawah batasan waktu yang tersedia dan tidak dapat berdebat, meneliti dan memperdebatkan lagi setiap baris kode hingga akhir waktu.

Berikan perintah. Hidup dengan konsekuensinya. Belajar dari pengalaman. Rasa hormat adalah jalan dua arah. Anda menunjukkannya dan ternyata tidak.