Pertanyaannya adalah ini dan detailnya sebagai berikut: apakah ada yang bisa saya katakan / angkat, sebagai seorang programmer, untuk membawanya ke pihak saya?
Saya ingin mendengar argumen yang sahih untuk kedua belah pihak mengenai hal ini, tetapi sebagian besar saran untuk cara membicarakannya.
Situasi saya adalah ini: Saya sedang mengerjakan proyek tim pada program gelar saya, membangun situs web menengah sebagai prototipe untuk universitas. Semua dianggap sama dalam kelompok dan tidak ada seorang pun pemimpin yang ditunjuk sehingga jawaban untuk masalah ini tidak bisa "tarik peringkat".
Semua sama, namun ada kesenjangan besar dalam pengetahuan antara anggota. Anggota tim yang dimaksud dan saya sama-sama pengembang yang cakap, meskipun ia tidak memiliki pengalaman industri. Tiga anggota lainnya kurang mampu, dan dua telah memilih keluar dari pengembangan sepenuhnya. Ketiganya telah menolak untuk mengomentari situasi karena kurangnya pengetahuan.
Sebagai sebuah kelompok, kami akan memutuskan teknologi apa yang akan digunakan dalam implementasi situs web; khusus, apakah akan menggunakan kerangka kerja PHP (Code Igniter) atau tidak.
Saya berdebat mendukung, dengan mengutip:
- Tidak menciptakan kembali roda
- Basis kode yang ditulis dan diuji dengan baik untuk bekerja
- Mulai (tenggat waktu lebih dekat dari yang kita inginkan)
- Kecepatan pengembangan
- Pola desain yang sehat dan dapat dipelihara serta praktik yang baik
Dia berdebat untuk bekerja dengan cara yang biasa dia lakukan:
- Menulis dipesan lebih dahulu, fungsi satu kali ke file "perpustakaan" seperti ketika ia membutuhkannya
- Fungsi untuk akses data dan rendering data halaman, mendapatkan / pengaturan ke dan dari sesi dan mendapatkan / memposting data dll
- Memiliki 1 file per halaman (sehingga tidak ada pemisahan kekhawatiran di antara kontrol, presentasi, dan data)
Alasannya menolak menggunakan kerangka kerja sebagian besar didasarkan pada dia tidak bisa melihat intinya: dia sudah bisa melakukan semua hal itu. Kerangka kerjanya tidak mengubah itu, itu hanya membuatnya lebih sulit karena dia harus belajar kerangka kerja; dia tidak ingin menggunakan kode yang belum dia tulis sendiri.
Dia juga mengatakan bahwa "tidak masalah kualitas basis kode, karena proyek ini hanya prototipe dan tidak akan pernah dipertahankan". Bagi saya, itu bukan alasan untuk menulis kode yang tidak dapat dipelihara.
Saya bisa melihat mengapa dia membuat argumen itu, tetapi saya mempersoalkan "kurangnya kepeduliannya terhadap pemeliharaan" dan "mengabaikan desain yang baik", atau bahkan pemisahan masalah. Namun, saya curiga dia tidak pernah mempelajari pola desain, jadi saya tidak tahu seberapa efektif menunjukkan mengapa metodenya bisa terbukti tidak dapat dipertahankan.
Saya ingin melanjutkan proyek ini, tetapi saya tidak ingin melakukannya tanpa memperhatikan semua yang telah saya pelajari selama bertahun-tahun. Seperti yang saya katakan sebelumnya, tidak ada kemungkinan menarik peringkat di sini, juga tidak ada anggota tim lain yang mau melakukan pitching. Haruskah saya mundur dan melakukan sesuatu dengan caranya? Apakah dia terlalu keras kepala dan tidak berpengalaman untuk tahu lebih baik? Atau apakah saya yang keras kepala di sini?
TL; DR Anggota tim yang tidak berpengalaman sedang keras kepala, bagaimana saya bisa memenangkannya?
sumber
he doesn't want to use code he hasn't personally written.
Dia lebih baik membuang sistem operasinya, IDE, telepon, lampu lalu lintas dll.I want to know exactly how everything works
adalah argumen yang valid ketika belajar, sedang menciptakan kembali roda sebenarnya dapat diterima. Mungkin, mungkin saja, Anda bisa membacanya sebagai teriakan minta tolong dan bukan sebagai keras kepala.since the project is only a prototype and will never be maintained
Akhir kata-kata terakhir :) Saya berharap saya punya satu dolar setiap kali saya membuat asumsi ini dan menemukan bahwa ketidaksabaran dan keserakahan jangka pendek dari para petinggi memutuskan bahwa prototipe ADALAH produk sekarang.Jawaban:
Anda tidak akan bisa membicarakannya dengannya. Ini disebut efek Dunning-Kruger . Dia terlalu bodoh untuk tahu apa yang tidak dia ketahui, dan terlalu takut kehilangan apa yang dia sebut sebagai keuntungan.
Ketika Anda tidak dapat mencapai konsensus, Anda harus mencapai kompromi. Mungkin Anda dapat membagi pekerjaan sehingga kebutuhannya untuk mempelajari kerangka kerja minimal. Mungkin Anda memiliki semacam "desain-off" di mana Anda masing-masing melakukannya dengan cara Anda selama beberapa minggu dan kemudian tim memilih mana yang terbaik. Mungkin Anda bisa melibatkan profesor yang mensponsori Anda atau siapa pun pelanggan dalam menyelesaikan ikatan.
sumber
Satu argumen yang mendukung Anda adalah usabilitas pengetahuan. Semua anggota tim yang mempelajari kerangka kerja yang terkenal dan banyak digunakan (seperti CodeIgniter) akan dapat menggunakan kembali pengetahuan mereka pada proyek berikutnya. Sedangkan pengetahuan tentang "perpustakaan" sembarangan tidak dapat digunakan kembali. Ini dapat beresonansi dengan baik dengan anggota tim lainnya, karena mereka mungkin lebih suka mendapatkan pengetahuan yang berguna dan dapat digunakan kembali pada proyek ini.
Argumen lain mungkin merupakan pengukuran konkret dari biaya pengembangan / pemeliharaan. Saya membayangkan bahwa seorang pengembang yang berpengalaman dalam CodeIgniter dapat mengembangkan lebih cepat daripada rekan Anda menulis semua fungsi milik sendiri. Ini dapat ditunjukkan dengan meminta Anda dan dia membuat halaman web yang identik - Anda dengan CodeIgniter, dia dengan caranya sendiri - dan mengukur waktu hingga selesai. Kemudian buat satu set modifikasi / ekstensi ke halaman, lagi mengukur waktu sampai selesai. Tentu saja, spesifikasi harus disiapkan oleh seseorang yang independen dari Anda berdua, untuk bertarung di tanah netral.
Lain - seperti yang Anda sebutkan - adalah kualitas kode. Setelah halaman web siap, jalankan serangkaian tes penerimaan yang sama pada masing-masing, dan bandingkan kepadatan bug.
Tentu saja, ketika Anda berada di bawah tekanan waktu, mungkin tidak ada kemungkinan untuk berhenti dan melakukan pengukuran seperti itu. Jadi Anda mungkin ingin resolusi cepat untuk dilema ini. Cobalah meyakinkan anggota tim lainnya (mis. Dengan meminta mereka membaca jawaban yang akan datang untuk posting Anda di sini :-), untuk meningkatkan tekanan kelompok kepadanya. Pada akhirnya, jika dia benar-benar tidak dapat diyakinkan, Anda mungkin ingin memotong proyek menjadi dua bagian, satu untuknya dan - idealnya - satu untuk anggota tim lainnya, menggunakan CodeIgniter. Fokus pada melakukan bagian Anda sendiri dengan kemampuan terbaik Anda dan biarkan dia melakukan apa pun yang dia inginkan. Hasilnya mungkin akan berbicara sendiri.
sumber
Saya merasa Anda perlu melibatkan 3 rekan satu tim lainnya. Anda berdua perlu menyampaikan argumen Anda kepada mereka dan menjelaskan sesuatu kepada mereka sehingga mereka mengerti. Pada akhirnya, mereka harus bekerja dengan basis kode ini juga. Dan jika semuanya sama, maka mereka harus memiliki beberapa pendapat tentang apa yang ingin mereka kerjakan.
Saya pikir pendekatan yang baik bagi Anda masing-masing untuk menguraikan manfaat dari solusi Anda masing-masing, dan tunjukkan kepada anggota tim lainnya mengapa Anda merasa itu adalah cara terbaik untuk melakukannya. Lalu biarkan mereka yang memutuskan. Ada 3 dari mereka sehingga akan menjadi pemutus dasi.
Satu hal yang ingin Anda tunjukkan adalah bahwa jika ini adalah proyek Sr Anda, dan anggota tim lainnya tidak memiliki pengalaman lain, proyek ini perlu mencerminkan pekerjaan yang dapat mereka lakukan untuk calon pemberi kerja. Jika Anda melakukannya dengan benar, ini bisa menjadi poin pembicaraan yang bagus dalam sebuah wawancara. Saya tahu saya meminta lulusan baru untuk menguraikan proyek senior mereka, dan bagaimana itu dirancang dan dikembangkan.
Jika mereka pergi dengan pendekatan orang lain, Anda harus menyedotnya. Tapi jangan menyerah. Munculkan desain yang bagus sehingga kekacauan yang ia tulis tidak akan memengaruhi segalanya. Jika Anda punya waktu, lakukan beberapa kode pembersihan dan perbaiki beberapa barangnya dan tunjukkan kepadanya bahwa ia tidak harus menemukan kembali roda setiap kali.
sumber
Saya merasa kuliah seperti kotak pasir. Sebagian besar barang yang Anda lakukan di sana tidak digunakan dalam penyebaran. Jadi itu memberi Anda lebih banyak kebebasan untuk bereksperimen dan keluar dari zona nyaman Anda. Jelajahi hal-hal baru karena gagal tidak akan terlalu berdampak. Juga dalam situasi Anda, anggota tim Anda memiliki keuntungan ekstra karena memiliki seseorang dengan pengetahuan sebelumnya membantu mereka.
Adapun anggota tim yang berpengalaman lainnya, dia tidak perlu datang ke perguruan tinggi jika dia tidak ingin belajar sesuatu yang baru. Ini adalah kesempatan bagus untuk mempelajari sesuatu yang baru dan menambahkannya ke kotak alatnya.
Dan untuk anggota tim yang tidak berpengalaman, peluang mereka untuk dipekerjakan / dipekerjakan lebih baik akan meningkat dengan kerangka kerja seperti CodeIgniter pada resume mereka (sebenarnya pengetahuan untuk membenarkan hal itu pada resume mereka).
sumber