Bagaimana Anda memberi tahu jika saran dari pengembang senior buruk? [Tutup]

Baru-baru ini, saya memulai pekerjaan pertama saya sebagai pengembang junior dan saya memiliki pengembang yang lebih senior yang bertugas membimbing saya di perusahaan kecil ini. Namun, ada beberapa kali ketika dia akan memberi saya nasihat tentang hal-hal yang saya tidak setuju (itu bertentangan dengan apa yang saya pelajari dalam beberapa buku bagus tentang topik yang ditulis oleh para ahli, pertanyaan yang saya tanyakan di beberapa situs Q&A juga setuju dengan saya) dan mengingat jadwal sibuk kita, kita mungkin tidak punya waktu untuk berdebat panjang.

Sejauh ini, saya telah mencoba untuk menghindari masalah dengan mendengarkannya, mengangkat tandingan berdasarkan apa yang saya pelajari sebagai praktik yang baik saat ini. Dia menaikkan poin aslinya lagi (sebagian besar waktu dia akan mengatakan praktik terbaik, lebih dapat dipertahankan tetapi tidak melangkah lebih jauh), saya mencatat (karena dia tidak menaikkan titik baru untuk melawan titik tandingan saya), pikirkan tentang dan penelitian di rumah, tetapi jangan membuat perubahan (saya masih belum yakin). Tetapi baru-baru ini, dia mendekati saya lagi, melihat kode saya dan bertanya kepada saya mengapa saya belum mengubahnya dengan sarannya. Ini adalah yang ketiga kalinya dalam 2-3 minggu.

Sebagai pengembang junior, saya tahu bahwa saya harus menghormatinya, tetapi pada saat yang sama saya tidak bisa setuju dengan beberapa nasihatnya. Namun saya ditekan untuk melakukan perubahan yang saya pikir akan membuat proyek lebih buruk. Tentu saja sebagai pengembang yang tidak berpengalaman, saya bisa saja salah dan caranya mungkin lebih baik, mungkin salah satu dari kasus pengecualian itu.

Pertanyaan saya adalah: apa yang bisa saya lakukan untuk menilai dengan lebih baik jika saran pengembang senior baik, buruk atau mungkin itu baik, tetapi ketinggalan zaman dalam konteks hari ini? Dan jika itu buruk / ketinggalan jaman, taktik apa yang bisa saya gunakan untuk tidak menerapkannya dengan caranya meskipun ada 'tekanan' sambil mempertahankan fakta bahwa saya menghormatinya sebagai senior?

Pertama, sebagai pengembang senior, saya berharap junior yang saya pimpin dalam proyek menyampaikan kekhawatiran mereka kepada saya secara langsung dan langsung. Jika mereka tidak setuju, itu tidak masalah bagi saya. Dalam beberapa kasus, saya akan mengambil tindakan atas keprihatinan mereka. Dalam kebanyakan kasus, kekhawatiran mereka dicampakkan menyisihkan dengan penjelasan singkat dari penalaran , bukan dari tidak menghormati pengembang dia / dirinya sendiri tetapi karena beberapa alasan lain seperti:

1. Junior tidak memiliki semua informasi yang ada untuk memahami keputusan yang dibuat. Dalam beberapa kasus, sedikit penjelasan dapat membantu pengembang bergerak melewati kekhawatiran dan menangani situasi yang tidak ideal.
2. Junior memiliki informasi BAD. Jangan lupa bahwa Anda adalah seorang junior. Itu setara dengan menjadi remaja dalam hal perangkat lunak. Saya yakin Anda memiliki banyak ide hebat, tetapi mungkin saja Anda tidak tahu segalanya. Saya menemukan bahwa pengembang junior yang paling resistan adalah mereka yang sangat percaya bahwa mereka tahu apa yang terbaik untuk kode, perusahaan, dunia. Pengembang ini lebih baik dilayani dengan memperoleh kerendahan hati.
3. Keputusan untuk melakukan sesuatu dengan cara tertentu dibuat di atas kepala senior. Senior masih bekerja untuk orang lain pada akhirnya. Sebenarnya mungkin ada cara yang lebih baik untuk melakukan sesuatu, cara yang lebih efisien untuk menulis sesuatu, atau perangkat lunak / perangkat keras yang lebih baik untuk membantu melakukan pekerjaan itu. Bisnis masih mendorong keputusan. Manajer bisnis, direktur, VP, dll. Sering membuat keputusan yang memengaruhi proses pengembangan. Ini di luar kendali senior, dan ketika junior mengeluh tentang hal itu, semua yang mereka lakukan adalah menambah stres senior.
4. Senior yang baru saja keluar tidak punya waktu untuk memperhitungkannya. Ada tenggat waktu, dan kadang-kadang mengubah pola, praktik, dan perilaku di tengah-tengah waktu adalah mahal untuk tenggat waktu itu. Karena itu lehernya pada blok memotong sering kali lebih penting untuk mendapatkan produk fungsional dan tepat waktu daripada "ditulis dengan sempurna".

Ini hanya hal-hal yang dapat saya pikirkan dari atas kepala saya. Ada banyak alasan mengapa sebuah ide, praktik, konsep mungkin ditolak atau dibuang oleh seseorang yang lebih tinggi dari Anda. Banyak dari mereka tidak menyenangkan, tetapi mereka semua bermuara pada kenyataan bahwa kita semua adalah manusia dan kita semua memiliki pendapat. Pendapatnya kebetulan lebih unggul secara numerik dari Anda saat ini.

Mengingat konsep-konsep itu dalam pikiran Anda harus terus membawa keprihatinan Anda kepada pengembang senior. Temukan pengembang senior lain yang mungkin dapat mengisi bagian yang kosong. Banyak pengembang senior berada di tempat mereka berada karena mereka lebih baik dengan perangkat lunak daripada dengan orang-orang. Beberapa ada di mana mereka berada karena mereka tahu pantat siapa yang harus dicium ketika mereka magang. Temukan seseorang yang benar-benar mengerti apa artinya membimbing seseorang dan mendapatkan pendapat jujur ​​mereka. Mereka mungkin tidak setuju dengan Anda dan mengisi kekosongan yang tidak Anda miliki. Mereka mungkin setuju dengan Anda dan membantu menyatukan perjuangan Anda atau membuat situasi Anda lebih baik.

Kapan pun Anda harus melakukan pemberontakan apa pun. Bahkan jika Anda percaya dalam hati Anda bahwa jalan Anda benar, Anda telah diberi instruksi untuk diikuti dan Anda harus mengikutinya (kecuali jika itu jelas-jelas ilegal). Jika Anda mengalami kesulitan dalam mengikuti instruksi ini, Anda mungkin ingin mencoba mencari alasan mengapa karena Anda akan menemukan pola perilaku ini sangat lazim di banyak perusahaan yang memproduksi segala jenis perangkat lunak.

Pilihan terbaik Anda adalah terus melakukan pekerjaan Anda secara etis dan profesional. Dapatkan perangkat lunak yang diminta Anda lengkapi dengan cara yang patut dicontoh dan luput dari situasi dengan dipromosikan dari situ. Jika promosi tidak datang, Anda akan memiliki banyak referensi dan pengalaman untuk mengejar peluang di departemen atau perusahaan lain.

Hormati pengembang senior. Dia lebih siap untuk kesuksesan proyek daripada Anda. Karena dia memiliki tanggung jawab, dia juga mendapatkan wewenang. Jika dia mengatakan ubah sesuatu maka lakukanlah.

Yang sedang berkata, jangan ragu untuk menyampaikan kekhawatiran Anda, ketika Anda menghadapi masalah seperti yang sudah Anda miliki.

Terakhir, duduk dengannya dan jelaskan kepadanya pertanyaan yang sama dengan yang Anda posting di sini. Mungkin Anda kehilangan sesuatu yang besar, mungkin dia akan lebih terbuka untuk saran Anda, atau, jangan biarkan dia dalam kegelapan jika Anda pikir sarannya buruk.

Ketika ini terjadi, apa yang perlu Anda lakukan adalah melakukan percakapan dengan pengembang senior . Mungkin dia tahu sesuatu yang tidak Anda ketahui tentang kode atau persyaratan teknis / bisnis. Jika demikian, Anda harus mempelajarinya.

Lakukan secara pribadi. Ini mungkin dilihat sebagai otoritas yang menantang, dan hal-hal seperti itu paling baik dilakukan satu-satu. Tunjukkan kesediaan untuk berkompromi dan berkolaborasi dengan mengakui dan menghormati senioritasnya, tetapi tetaplah gigih dalam menjawab pertanyaan Anda. Dekati situasi dari kerangka kolaboratif, bukan yang agresif. Anda mungkin mempertimbangkan memintanya untuk membimbing Anda.

Pada akhirnya, Anda harus menyeimbangkan ide-ide Anda sendiri (yang, agar adil, relatif baru dan belum teruji) dengan ide-idenya. Mungkin Anda memang benar, tetapi Anda harus melakukan yang terbaik untuk belajar dari orang yang lebih berpengalaman sehingga Anda dapat membuat keputusan yang lebih tepat. Pengembang senior yang baik menyambut peluang untuk berkolaborasi, membimbing, dan belajar, bahkan dengan pengembang junior, dan menyambut gagasan mereka ditantang secara konstruktif karena mereka juga tahu bahwa kadang-kadang mereka salah.

Cara yang sering Anda katakan adalah melalui pendekatan akal sehat. Ingatlah bahwa pengembang senior mungkin tahu lebih banyak tentang proyek ini, tetapi mungkin tidak tahu lebih banyak tentang cara yang tepat untuk melakukan sesuatu. Anda harus mengukur apa yang dia memberitahu Anda lakukan - dia memberikan nasihat buruk jika apa yang dikatakannya lalat dalam menghadapi apa nya atasannya mengklaim (yaitu orang-orang yang lebih senior dari dia, belum tentu di perusahaan Anda ... Aku sedang berbicara tentang pengembang "selebritas" terkenal yang sering memposting atau menulis buku tentang cara yang benar untuk melakukan pengembangan perangkat lunak, atau setidaknya praktik terbaik yang diterima industri).

Berikut adalah contoh "saran buruk" dari pengembang senior (atau pengembang apa pun): Jika mereka sama sekali tidak tahu apa itu kopling longgar dan mengapa itu adalah hal yang baik, dan Anda diminta untuk menulis semua kode, katakanlah, kode tersebut -di belakang file ASPX, jelas pengembang senior tidak mengerti dan sarannya tidak boleh didengarkan.

Jika, di sisi lain, dia memberi tahu Anda bagaimana modul spesifik dalam sistem bekerja, sering kali lebih baik mendengarkan selama lagi, apa yang dia katakan kepada Anda tidak meludahi prinsip-prinsip pengembangan yang tepat.

Inilah aturan saya: Seorang pengembang senior di sebuah perusahaan mungkin hanya menjadi pengembang dengan masa kerja terpanjang; dia mungkin tidak memiliki keterampilan nyata. Apakah dia mengatakan hal-hal yang bertentangan dengan apa yang dikatakan beberapa pengembang paling dihormati di bidang Anda (orang-orang dengan pengalaman lebih banyak darinya, dan yang jauh lebih kompeten dan dihormati)? Jika ya, kemungkinan nasihatnya buruk kecuali ada keadaan yang sangat ekstrem.

Sepenuhnya mengharapkan downvotes / ketidaksetujuan untuk sudut pandang yang sangat bias.

Mungkin sulit untuk memahami sudut pandang pengembang senior, dan ya dia mungkin memimpin hal-hal yang salah, namun ketika menyangkut proyek besar, konsistensi lebih penting.

Memiliki 50 beberapa pengembang semua mengikuti gaya pengkodean mereka sendiri, standar, metodologi, dan pola desain akan menjadi kekacauan total. Jika hal-hal yang dilakukan salah itu selalu lebih baik untuk menjadi salah secara konsisten daripada banyak jenis kesalahan yang berbeda dan beberapa hal yang dilakukan dengan benar.

Ketika tiba saatnya untuk melakukan pemeliharaan, menambah fitur, atau memperbaiki apa yang "salah" maka akan jauh lebih mudah jika masalah dengan desain yang ada diketahui di muka.

Adalah baik untuk tidak setuju dengan hormat tetapi pada akhirnya Anda yang terbaik adalah untuk mengantre. Siapa pun di tim yang nakal tidak dianggap sebagai pemain tim.

Jika senior tidak dapat memberi Anda alasan bagus mengapa mereka mengabaikan praktik terbaik industri, maka jangan buang waktu Anda di sana. Anda tidak akan pernah maju karena Anda terlalu mengancam, dan lagi pula, apakah Anda ingin menghabiskan waktu mempertahankan setumpuk kode yang buruk?

Sebagian besar pengembang berhenti membaca ketika mereka meninggalkan perguruan tinggi. Anda belum, jadi Anda sudah di atas 10%. Ada banyak peluang hari ini. Jika tidak ada pasar kerja di kota Anda, maka cari kota yang lebih baik.

Wow, itu adalah kesempatan luar biasa bagi Anda untuk bersinar dan memamerkan keterampilan Anda. Di awal karir saya, saya memiliki seseorang yang menjadi penyelia saya yang tidak dapat membuat keputusan, keputusan apa pun, jadi saya menggunakan kesempatan itu untuk belajar bagaimana melakukan pekerjaan naik level selanjutnya. Itu membuat saya dipromosikan. Anda harus melakukan hal yang sama.

Sebagai pengembang senior, jenis pemetikan agresif pasif pasif ini akan membuat saya gila dan setelah berkonfrontasi Anda akan membuat saya memberi Anda ulasan buruk. Solusi yang sempurna adalah yang bisa dinikmati bersama oleh tim.

Adapun gaya, ini harus ditentukan oleh panduan gaya Anda dan praktik terbaik ditentukan oleh asal Anda. Jika Anda bersemangat berdebat untuk itu, tetapi sekali keputusan dibuat hidup dengannya dan bekerja dengan batas-batas tim Anda berada.

Anda berada dalam situasi yang tidak terlalu baik, tetapi, seperti yang ditunjukkan HLGEM, Anda dapat mengubah posisi ini menjadi berkah tersembunyi. Pertanyaan Anda memiliki banyak segi, jadi saya akan mendekati beberapa bagian.

Saya curiga, dia tidak tahu. Pada saat yang sama, dia mencoba menunjukkan kepadaku kesombongan sehingga aku tidak banyak bertanya kepadanya.

Ini mungkin benar. Ada banyak pengembang yang telah berkecimpung di industri ini selama beberapa dekade dan tidak mampu memimpin perangkat lunak - dari sudut pandang pengembangan atau pendampingan (ada perbedaan). Pengalaman datang dari mengatasi tantangan baru dan mencoba ide-ide baru dan mempelajari keterampilan baru, tetapi mayoritas programmer menghabiskan hidup mereka di sayap The Corporate Office, mengerjakan Aplikasi Penggajian dengan alat Visual Basic dan Java yang setia, tidak pernah melihat balap dunia oleh kantor abu-abu mereka yang dingin.

Tidak ada yang salah dengan ini . Bagi banyak pengembang ini semua yang mereka inginkan dan sangat puas dengan situasi - namun, ini bukan situasi yang ideal untuk membina generasi programmer masa depan, apalagi memimpin pengembang.

Bravado dan arogansi bisa menjadi mekanisme pertahanan, mencoba menutupi kekurangan. Bagaimana kamu menanganinya? Jangan menghadapinya langsung - jika pimpinan Anda tidak kompeten, dan bos tidak mau memperbaiki situasi maka Anda harus hidup dengan itu . Itu tidak berarti berguling dan mati, tetapi Anda tidak bisa memaksa seseorang untuk menjadi pemimpin yang baik.

Namun, dia hanya meninjau kode saya, dan sebagian besar komentarnya terkait dengan pedoman pengkodean

Inilah yang membuat saya berpikir Anda benar karena dia mungkin bukan programmer yang baik. Itu bukan untuk mengatakan bahwa dia bukan programmer yang lebih baik daripada Anda saat ini (setidaknya dia akan memiliki lebih banyak pengalaman dan paparan dari berada di industri begitu lama) tetapi sekali lagi, itu tidak diterjemahkan menjadi seorang memimpin efektif. Panduan semuanya baik dan bagus, tetapi kedua adalah fungsi, keefektifan, dan efisiensi kode.

Apa yang harus saya lakukan dalam situasi seperti itu?

Saya telah memberi tahu manajer saya tentang situasi ini, dan saya telah memintanya untuk mengubah kepemimpinan saya, meskipun dia mengatakan "ya" setiap kali, tetapi dia tidak mengambil tindakan serius.

Sudahkah Anda menyebutkan semua poin spesifik ini kepada manajer, dan dengan contoh-contoh spesifik untuk mendukungnya? Jika Anda hanya pergi kepadanya dan berkata, "Saya butuh petunjuk baru", dia tidak akan menganggap Anda serius dan menganggapnya sebagai "masalah antarpribadi" daripada masalah teknis. Reaksi banyak bos dalam situasi ini adalah mengabaikannya dengan harapan akan "berhasil dengan sendirinya".

Ini beberapa saran.

1. Jangan merasa cemas dengan situasi Anda - percobaan dengan api, meski tidak menyenangkan, mengajarkan Anda beberapa keterampilan riset kritis untuk nanti dalam karier Anda.
2. Mulailah mendorong pimpinan Anda untuk lebih terlibat. Lakukan ini dengan hati-hati dan penuh hormat . Terus mendorong dan gigih sampai dia menyerah (ini sebenarnya bekerja untuk banyak situasi dalam hidup).
3. Jika pemimpin Anda tidak terlibat, lihat apakah ada orang lain yang bisa membantu Anda. Kecuali jika Anda bekerja di toko keringat yang hanya mementingkan waktu memerah susu maka perusahaan Anda tidak akan keberatan dengan pengembang lain yang memiliki lebih banyak pengalaman yang menunjukkan kepada Anda beberapa tali dan meninjau kode Anda.
4. Mulailah mengawasi pekerjaan baru. Saya tidak akan mengatakan bahwa Anda berada dalam situasi "harus pergi" tetapi tidak akan merugikan karier Anda untuk berada di tempat yang menjadikan pengembangan Anda sebagai programmer lebih serius.

Jika Anda memiliki cara yang lebih baik untuk menyelesaikan masalah tertentu, lakukan saja .

Biarkan kode / solusi Anda menjadi argumen terbaik Anda. Kalau tidak berpegang teguh pada apa yang telah Anda diberitahu.

Inti masalah

ketika saya masih junior saya memiliki situasi di mana bagian kode tertentu bukan yang terbaik yang bisa. Bukan hanya berdebat tentang hal itu, saya hanya membaik itu KEMUDIAN menunjukkan hasil untuk senior saya. Dia menerimanya, karena kode itu selalu raja.

Tentu saja sebagai pengembang yang tidak berpengalaman, saya bisa saja salah dan caranya mungkin lebih baik jadi pertanyaan saya adalah cara apa yang bisa saya lakukan untuk menilai dengan lebih baik jika saran pengembang senior baik atau buruk / ketinggalan jaman.

Anda bisa menjadi pengembang yang berpengalaman. Sampai Anda melakukan itu, Anda tidak akan siap untuk menilai apakah intuisi Anda sebagai junior benar, dan pada saat itu tidak masalah.

Sementara itu, baca jawaban Joel Etherton.

Saya akan sangat menyarankan untuk tidak mencoba "tidak menerapkannya dengan caranya".

Sejauh ini, sepertinya Anda telah melakukan hal yang benar. Anda rendah hati dan dibesarkan tandingan. Saya tidak dapat mengatakan dari pertanyaan Anda apakah Anda hanya tidak setuju dengan metodenya, atau Anda tidak setuju dan memberikan alternatif. Intinya, selalu menawarkan alternatif yang jelas dan dipikirkan ketika Anda mencoba untuk menembak jatuh pendekatan orang lain . Seperti yang mungkin dia lihat, Anda punya ide bagus yang mungkin berhasil, dan dia punya ide yang berfungsi.

Dalam posisi apa pun, kita dipaksa untuk melakukan hal-hal yang tidak optimal setiap saat. Jika Anda benar-benar tidak menyukainya, maka Anda dapat melakukan apa yang Anda lakukan dan membawanya ke atas. Setelah itu, ini jalan bos atau jalan raya. Di sisi yang lebih cerah, Anda terisolasi dari banyak risiko keputusan yang buruk sebagai junior.

Pilih Anda pertempuran. Jika Anda berbicara tentang satu jam kerja Anda harus mengubah kode Anda sampai Anda menyelesaikannya. Lain kali Anda mendapatkan proyek besar, tanyakan terlebih dahulu kesempatan untuk mempresentasikan ide-ide Anda sebelum memulai. Luangkan waktu ekstra dan buat demo atau prototipe yang luar biasa.

Cukup mengejutkan apa yang saya lakukan adalah berhenti bertanya. Ketika diberi pilihan lain saya hanya ngelantur dan melakukannya dengan caranya tetapi menambahkan bakat saya sendiri untuk itu. Gunakan itu sebagai pengalaman belajar untuk membangun kemampuan Anda dan tetap menenangkan kebutuhannya untuk mempertahankan sekolah itu.

Pada akhirnya tidak semua pengembang senior memperhatikan cara-cara baru dalam melakukan sesuatu. Mereka kadang-kadang memiliki cara jadul yang bagus untuk bahasa yang mereka mulai pada 20 tahun yang lalu tetapi dianggap sebagai peretasan, atau "memiliki bau busuk" di dunia saat ini.

Ini mungkin terdengar seperti cara yang mengerikan untuk terus berjalan, dan memang begitu. Tapi saya juga belajar banyak dari senior saya dalam melakukan sesuatu. Tapi ini benar-benar hanya pendapat saya. Pada akhirnya Anda harus bahagia dengan pekerjaan Anda dan menjaga konsentrasi dan ketegangan tetap rendah. Dan dengan tidak menolak hal-hal yang Anda akan melihat stres turun.

Jangan percaya orang tua karena senioritas di sana. Tantang otoritas sesering mungkin. Otoritas yang kompeten harus mampu menjawab pertanyaan dengan meyakinkan. Itulah yang membuatnya menjadi otoritas, bukan?

Karena seseorang memegang kepercayaan takhayul seumur hidupnya tidak berarti ia benar. Ingat, di abad pertengahan orang-orang percaya bahwa bumi itu datar dan beberapa dari orang-orang yang sok suci itu bahkan merasa dibenarkan membunuh para peragu. Ternyata para peragu itu benar. Banyak ulasan buruk.

Jangan pernah takut akan ulasan buruk. Apakah Anda percaya pada orang buta yang menilai warna?

jawaban yang baik di atas, akan menambahkan bahwa respons seperti "praktik terbaik" atau "lebih dapat dipertahankan" adalah kesempatan untuk mempelajari sesuatu . Anda berkata, "Bisakah Anda memberi saya contoh mengapa cara itu yang terbaik agar saya bisa memahami perbedaannya?" atau "Dalam situasi apa cara ini lebih bisa dipertahankan daripada cara lain, sehingga saya bisa belajar untuk merencanakan ke depan seperti itu?"

Jika seniornya benar, memberi Anda contoh akan mudah. Jika dia burung beo ... berikan dia kerupuk untuk menghentikan pemerasan, dan lakukan apa yang menurutmu terbaik. Sampai diperintahkan sebaliknya.

Jika peran senior adalah menjadi mentor, ia akan menjelaskan mengapa ketika ditanya.

Seperti yang dikatakan HLGEM dan Jarrod sebelumnya, ini adalah berkah tersembunyi. Kedua jawaban mereka sangat bagus dan saya ingin menambahkan beberapa poin.

Karena lead Anda tidak ada dalam domain Anda, Anda harus mengambil beberapa keputusan penting untuk bagian aplikasi Anda karena lead Anda tidak tahu banyak tentang middleware. Anda juga memiliki penutupan dengan manajer Anda tentang bagaimana aplikasi harus pergi, apa yang diinginkan pengguna produk dan bagaimana manajer Anda ingin mengatasi situasi yang disajikan kepadanya oleh tim produk. Katakan berapa banyak orang yang akan mendapatkan pengetahuan semacam itu pada aplikasi.

Ketika Anda berada di tim besar, Anda pasti akan mendapat bantuan dari rekan satu tim dan / atau pemimpin Anda, tetapi Anda tidak akan memiliki pengetahuan tentang bagaimana manajer Anda berpikir atau tim produk berpikir karena hal-hal semacam itu umumnya melewati pimpinan Anda dan mungkin beberapa devs senior dalam sebuah tim. Saya setuju satu proyek orang agak sulit untuk dilakukan tetapi jika sisi lain dari koin begitu hebat mengapa kehilangan kesempatan. Pelajari apa yang bisa Anda pelajari, nikmati selagi bisa dan jika terlalu sulit meyakinkan manajer Anda seperti yang dikatakan Jarrod atau temukan pekerjaan / proyek baru tergantung pada situasinya.

Anda akan berhadapan dengan orang-orang seperti itu sepanjang karier Anda. Dan akan ada banyak dengan siapa Anda akan tidak setuju tentang pendekatan terbaik untuk setiap masalah pengkodean. Hal terbaik yang saya pikir telah berhasil bagi saya selama bertahun-tahun adalah bahwa jika mereka terus menekan suatu masalah, bersikap jujur ​​di depan mereka dan memberi tahu mereka bahwa Anda telah mempertimbangkan solusi mereka di antara berbagai solusi yang mungkin dan bahwa Anda merasa bahwa solusi Anda diselesaikan adalah yang Anda rasakan adalah pendekatan terbaik dalam situasi ini.

Sekarang, jika Anda memilih menentang nasihat mereka setiap waktu, maka kadang-kadang Anda mungkin perlu menyerah dan menggunakan "nasihat" mereka dari waktu ke waktu hanya untuk menghaluskan beberapa bulu yang acak-acakan. Selama mereka tidak merasa Anda menolak masukan mereka setiap saat, maka itu akan sangat membantu menjaga kedamaian di antara Anda.

Pertimbangkan juga bahwa mereka adalah pengembang senior dan telah bekerja di lingkungan itu lebih lama dari yang Anda miliki. Pengkodean kehidupan nyata seringkali tidak sesuai dengan praktik terbaik atau standar yang diterima masyarakat. Mungkin ada alasan mengapa mereka merekomendasikan Anda melakukan sesuatu dengan cara tertentu sehingga mereka tidak dapat mengartikulasikan sepenuhnya. Jadi, bahkan jika Anda tidak setuju dengan mereka, pastikan Anda tidak mengabaikan saran mereka hanya berdasarkan fakta bahwa Anda percaya solusi Anda lebih baik.

Ini semua tentang keseimbangan. Dan bukan hanya keseimbangan kode, tetapi keseimbangan tim. Banyak proyek gagal bukan karena pengembang tidak mampu melakukannya, tetapi karena mereka tidak dapat menemukan cara untuk bekerja sama secara damai.

Saya ingin memberikan beberapa hal dari pengalaman pribadi saya, yang harus dianggap sebagai jawaban tambahan untuk satu diposting di sini oleh jzd ...

1. Tanyakan pengembang senior lain,
2. Lakukan riset sendiri.

Dalam satu pertemuan profesional, saya seharusnya dibimbing oleh seseorang yang senior. Dia tahu beberapa hal tetapi sejujurnya tidak sebanyak itu, sayangnya dia tidak mengetahuinya, jadi dia sangat percaya diri dengan jawabannya. Saya entah bagaimana merasa bahwa apa yang dia katakan salah. Saya memiliki beberapa bukti ketika hal-hal yang dia lakukan bertentangan dengan praktik terbaik yang disebutkan dalam sertifikasi MS yang saya ambil :-). Setelah itu saya mulai bertanya kepada orang lain yang bekerja di perusahaan lain (stackexchange tidak berdiri dan berjalan saat itu) dan mulai membaca blog untuk membandingkan jawaban.

Akan lebih bagus jika saya salah, karena saya hanya mengubah perilaku saya, tetapi saya tidak melakukannya.

Saya telah memperhatikan sesuatu selama beberapa tahun terakhir, hampir setiap perusahaan tempat saya bekerja, dengan hampir setiap proyek tempat saya bekerja, dengan hampir setiap karyawan baru (terlepas dari tingkat keahlian / pengalaman) ingin melakukan sesuatu yang 'berbeda'.

Mungkin standar pengkodean atau arsitektur keseluruhan atau bahasa atau metodologi. Tapi selalu ada sesuatu. Sering kali, itu hanya menyatakan yang sudah jelas, 'Bukankah semuanya harus didokumentasikan dengan lebih baik, untuk pengguna akhir kita?'

Saran saya untuk Anda adalah jangan menjadi pria itu .

Suatu hari, Anda akan menjadi pria tingkat senior yang dipekerjakan dan dibayar untuk membuat keputusan itu. Ketika hari itu tiba, pergilah ke sana! Hingga hari itu, sadarilah apa posisi Anda. Saya punya bos, sejauh yang saya tahu seluruh pekerjaan saya adalah untuk membuat bos saya bahagia. Ini bukan untuk menebak keputusan yang dibuat di luar tingkat gaji saya. Jika Anda benar-benar tidak yakin, bicarakan dengan atasan / atasan Anda dan cari tahu.

Namun secara umum, jauh lebih baik untuk memiliki semua orang di papan dengan pendekatan yang ketinggalan jaman daripada setengah dari tim mengikuti pendekatan yang sudah ketinggalan zaman, 1/4 dari tim mengikuti beberapa pendekatan baru dan 1/4 dari tim berusaha untuk mengembangkan yang mutakhir , pendekatan baru.

Ada arus bawah untuk semua ini yang saya pikir harus dibawa keluar dengan jelas: jangan agresif . Pertahankan hubungan Anda dengannya. Sangat bagus untuk menerima sarannya dengan sebutir garam dan memvalidasinya dalam buku-buku dan situs-situs seperti ini, tetapi jangan menyerangnya. Jika dia adalah pengembang senior dan telah melalui banyak proyek, dia bukan idiot, dan ada banyak yang bisa dipelajari darinya. Karena sepertinya sudah dilakukan, ungkapkan keinginan Anda untuk memahami sudut pandangnya. Bahkan jika Anda yakin dia salah dan Anda benar, terimalah kemungkinan yang sebaliknya (sepertinya Anda sudah memahami ini). Cobalah untuk memperjelas bahwa Anda berdebat karena Anda ingin memahami sudut pandangnya dengan lebih baik, bukan karena Anda berusaha membuktikannya salah.

Jika dia tidak segera kembali kepada Anda ketika Anda mengajukan pertanyaan kepadanya, atau jika jawabannya tidak jelas dan / atau tidak membantu, jangan menganggap dia membuat Anda marah. Seperti yang telah disebutkan di sini, dia mungkin sibuk dan / atau stres.

Senang rasanya juga sabar. Simpanlah daftar hal-hal di kepala Anda yang menurut Anda harus dilakukan secara berbeda, dan presentasikan pada waktu yang tepat. Pastikan Anda memiliki justifikasi untuk saran di samping "itu praktik terbaik." Dan berhati-hatilah untuk melakukan hal-hal yang benar dan tidak membuat kesalahan, sehingga Anda memiliki kredibilitas ketika Anda membuat argumen di kemudian hari.

Sejauh ini saya telah mencoba untuk menghindari masalah dengan mendengarkannya, menaikkan titik balik, dia menaikkan titik aslinya lagi (sebagian besar waktu dia akan mengatakan praktik terbaik, lebih dapat dipertahankan tetapi tidak melangkah lebih jauh), I. .. pikirkan di rumah, tapi ... saya masih belum yakin. Tetapi baru-baru ini dia ... melihat kode saya dan bertanya kepada saya mengapa saya belum mengubahnya dengan sarannya. Ini adalah yang ketiga kalinya dalam 2-3 minggu.

(Sedikit diedit untuk tindakan.)

Bagian ini menjadi perhatian saya. Salah satu cara Anda dapat melihat apakah Anda benar atau tidak adalah memahami apa yang dia katakan. Apa yang saya baca (dengan sejarah saya sendiri, orang lain mungkin berbeda) adalah pengembang junior yang tidak memahami apa yang dikatakan mentor, dan tidak meminta klarifikasi. Salah satu cara Anda bisa mengetahuinya adalah memintanya untuk menjelaskan: bagaimana ini praktik yang lebih baik dari itu? Atau Mengapa ini lebih mudah dikelola daripada itu untuk kode kita? Jika Anda tidak tahu jawabannya, Anda benar-benar tidak tahu apakah dia memberikan nasihat yang baik atau tidak.

Bagian yang benar-benar membuat saya khawatir adalah dia meminta Anda untuk mengubahnya berkali-kali, dan Anda belum mengubahnya. Ini adalah salah satu cara yang terlihat dari sisinya: dia meminta Anda melakukan perubahan, Anda bertanya mengapa, ia memberi Anda alasan (yang sah, menurut pikirannya), dan Anda menolak untuk melakukan perubahan. Anda tidak meminta klarifikasi, jadi dia menganggap Anda mengerti alasannya, dan terlalu malas atau terlalu keras kepala untuk mengubahnya - tidak ada yang baik bagi pengembang senior untuk memikirkan Anda. Percayalah, jauh lebih baik mengajukan pertanyaan daripada mendapatkan reputasi dengan cara ini.

Beberapa pemikiran:

1 / Apakah berhasil? Apakah caranya bekerja atau tidak? Apakah ada alasan objektif mengapa jalannya lebih rendah?

Dengan alasan obyektif, maksud saya sesuatu yang dapat diukur tanpa ambiguitas (kinerja, bug, panjang kode ...) Jika solusinya bekerja dan tidak ada metrik objektif yang menunjukkan itu adalah solusi yang buruk, lakukan dengan caranya. Caranya lebih baik ... karena mungkin lebih konsisten dengan sisa basis kode dan karena akan lebih mudah baginya untuk menggunakan / menggunakan kembali pekerjaan Anda. Anda mungkin tidak menyukainya, tapi bukan itu masalahnya, bukan?

Jika tidak berhasil, atau berkinerja buruk pada metrik penting, implementasikan, bandingkan solusinya dengan solusi Anda, kemudian katakan padanya bahwa Anda telah mencoba caranya, tetapi Anda tidak dapat menjalankannya dengan baik (berikan metrik) dan tanyakan padanya jika Anda membuat kesalahan dalam implementasi Anda atau jika ada persyaratan yang tidak Anda sadari

2 / Pemrogram bintang mengatakan ... Mengapa peduli? Anda akan menemukan programmer terkenal sangat berselisih satu sama lain pada banyak mata pelajaran mendasar seperti perencanaan, desain, OOP vs prosedural, pengujian unit, penanganan pengecualian, kontrol sumber, terus dan terus.

Jika satu-satunya perbedaan dalam kemampuan kerja antara 2 solusi adalah siapa yang menyukainya, lewati saja. Anda mungkin mendapat manfaat dari latihan mental yang dibutuhkan dengan bekerja dalam paradigma yang tidak Anda sukai

Berdasarkan gagasan bahwa Anda hanya boleh menerima nasihat dari orang yang Anda inginkan, jawabannya adalah nasihat senior itu baik jika Anda ingin menjadi seperti dia.

Sebagian besar masalah saya telah saya urutkan berdasarkan posting ke forum dan mendapat balasan dari orang lain, dan saya telah bertahan selama sekitar 1 tahun seperti ini.

Apa yang harus saya lakukan dalam situasi seperti itu?

Sejujurnya, inilah yang banyak pekerjaan teknis suka. Anda harus menjadi seorang pemula yang dapat memecahkan masalah yang sulit sendiri (dengan bantuan jika internet dan penghuninya) jika Anda harus.

Dari sudut pandang mendapatkan ulasan kode dan mendapatkan bantuan dengan desain arsitektur, bahkan ketika saya memiliki manajer yang baik, saya tidak pernah memiliki banyak ulasan kode di luar "variabel statis harus diawali dengan s_".

Ambil kesempatan untuk belajar dan belajar cara belajar; itu akan menjadi keterampilan yang dapat Anda gunakan di masa depan.

Jika Anda berpikir sejenak bahwa manajemen tidak memahami seberapa mampu Anda BENAR-BENAR menyelesaikan pekerjaan, maka Anda mungkin salah. Manajemen mungkin juga memahami bahwa kepemimpinan Anda saat ini akan sama sekali tidak berguna jika dia menggantikan Anda dan mengambil alih pekerjaan Anda.

Alasan NYATA mereka belum merelokasi Anda adalah karena terlepas dari semua tantangan yang Anda hadapi kepada mereka, Anda tetap merupakan orang terbaik untuk pekerjaan itu. Mereka jelas sangat menghargai pekerjaan Anda sehingga berisiko menyerahkannya kepada orang lain.

Jangan meremehkan kecerdasan manajemen ...

Mereka jauh lebih pintar daripada kebanyakan pengembang memberi mereka kredit. Saya tidak mengerti ini sampai saya mulai mengelola. Mereka mungkin juga menyadari betapa tidak bergunanya kepemimpinan Anda, tetapi mereka mungkin tidak berdaya untuk mengatasi masalah itu.

Biarkan saya melukis gambar untuk Anda, Pimpin A dengan 5 tahun pengalaman di perusahaan tidak kompeten. Manajer mengetahui hal ini, merekomendasikan kepada manajer atasnya untuk memberhentikan Pimpinan A. Manajer atas bertanya mengapa dia tidak berurusan dengan tahun lalu jika dia tidak kompeten. Manajer terlihat buruk sekarang terutama karena Pimpinan A memiliki gaji besar yang dibayarkan tanpa imbalan ...

Berikut adalah skenario potensial lainnya, Pimpinan A adalah teman dekat dengan seseorang yang penting. Dia terlalu panas secara politis untuk menghadapi,

Either way, dengan kesalahan berjalan lama seperti itu lebih mudah bagi organisasi besar untuk menyapu orang tidak kompeten di bawah permadani, memberi mereka pekerjaan yang sibuk dan kekuatan palsu yang sesuai dengan "pengalaman" bertahun-tahun mereka di mana mereka tidak dapat melakukan TERLALU BANYAK kerusakan . Sayangnya banyak organisasi lebih suka melakukan ini daripada benar-benar menangani masalah.

Tentu saja alasan untuk ini adalah bahwa manajer dalam organisasi semacam ini selalu lebih baik untuk jangka pendek untuk menghadapi talenta buruk dengan cara ini daripada untuk mengatasi masalah jangka panjang yang dapat dibawa oleh orang-orang semacam ini ke organisasi.

Jadi, meskipun pandangannya pendek dan berpotensi tidak etis, Anda harus mengakui bahwa itu sedikit lebih pintar daripada banyak pengembang yang benar-benar memberikan penghargaan.

ughh ahhh. Pertanyaan ini mengingatkan saya pada banyak hal. Pertama-tama saya akan mengatakan saya tidak bisa bergaul dengan salah satu manajer di tempat kerja terakhir saya. Itu bukan masalah kepribadian. Itu masalah komunikasi. Saya katakan XYZ dan manajer spesifik itu akan mengganggu apa yang saya katakan sebagai ABC. Saya tidak akan dapat berkomunikasi dengan baik kecuali saya bekerja dengan manajer itu selama lebih dari setahun.

Akhir pekan yang lalu. Seorang pria berdebat / tidak setuju dengan saya tentang lajang. Saya mengatakan mereka tidak baik dan tidak akan pernah digunakan dan sama sekali tidak ada alasan untuk menggunakannya. Saya menautkannya ke http://www.gmannickg.com/?p=24 dan artikel yang lebih mendalam yang terhubung dengannyabeberapa hari setelah pertengkaran. Hari programmer lain (DudeB) menyebutkan dia hanya menggunakan lajang ketika itu sesuai (yang saya tambahkan dengan 'tidak pernah'). DudeB tidak mengatakan apa-apa tentang itu tetapi DudeB mengatakan bahwa DudeB berada dalam proyek yang memiliki pertentangan memori karena semua utas mengakses singleton. Setelah menyebutkan ini, menunjukkan artikel dan menyebutkan pertarungan memori orang yang saya ajak berargumen mengatakan kita harus setuju untuk tidak setuju yang saya setuju karena saya tidak suka berbicara tentang lajang (belum saya menulis ini d'oh)

Intinya adalah. Kadang-kadang Anda bisa salah seperti orang ini (mungkin seseorang akan tidak setuju tentang lajang dengan saya dalam komentar). Dalam situasi saya dengan manajer saya yang merupakan programmer senior saya, saya hanya melakukan apa yang secara eksplisit diminta untuk saya lakukan dan saya tidak menganggap serius kualitas di tempat kerja itu lagi. Saya memang melakukan apa yang saya inginkan ketika diizinkan tetapi selalu melakukan apa yang diminta, tetapi jika saya tidak setuju saya akan membawanya setidaknya sekali.

Saya memiliki pendapat yang sangat berbeda / kontroversial mengenai hal ini.

Sering kali orang kehilangan jejak tujuan akhir yang bagi sebagian besar industri adalah tentang memaksimalkan keuntungan dan meminimalkan kerugian. Saya tahu ini terdengar tidak berperasaan (karena itu poin negatifnya) tetapi pengalaman dan kebijaksanaan sangat kecil artinya jika Anda tidak akan membuahkan hasil.

Orang-orang dapat terjebak dengan hal-hal kecil yang sangat tidak langsung untuk berdalih tentang hal itu memiliki dampak yang sangat kecil pada hasil langsung perusahaan.

Jika Anda pikir Anda benar tentang sesuatu Anda terbaik adalah untuk menunjukkan bagaimana yang akan menghasilkan terukur baik hasil .

Saya awalnya akan mencoba dan bertahan, pada akhirnya perlawanan terhadap senior kemungkinan akan sia-sia setidaknya sampai Anda mendapatkan lebih banyak pengalaman dan rasa hormat. Gunakan ini sebagai pengalaman belajar dan dalam waktu 2+ tahun jika Anda masih merasakan hal yang sama - pindahlah ke perusahaan lain. Saat itulah Anda dapat menggunakan kombinasi ide-ide bagus Anda dan senior Anda untuk mengesankan majikan baru Anda. Tentu saja Anda mungkin mulai menyadari beberapa alasan untuk apa yang Anda anggap sebagai keputusan buruk sebelumnya dalam karier Anda dan pada titik tertentu Anda mungkin memiliki pengembang junior yang bekerja untuk Anda.

[Repost: karena saya entah bagaimana membuat akun kedua di sini]

Tetapi baru-baru ini, dia mendekati saya lagi, melihat kode saya dan bertanya kepada saya mengapa saya belum mengubahnya dengan sarannya .

Anda harus jelas apakah ini saran atau perintah / instruksi / arahan / apa pun.

Saran = Saya pikir lebih baik melakukannya dengan cara ini; tapi itu pilihanmu.

Memesan / dll = Saya ingin itu dilakukan dengan cara ini; dan itu adalah pilihanKU.

Jika itu benar-benar sebuah saran, lakukan seperti yang Anda inginkan dan biarkan kode Anda bertahan. Jika ini perintah (dan mentor ini memiliki otoritas atas Anda dengan cara ini) - lakukan seperti yang mereka katakan.