Saya mulai bekerja di sebuah perusahaan yang terutama berorientasi pada C #. Kami memiliki beberapa orang yang menyukai Java dan JRuby, tetapi mayoritas programmer di sini seperti C #. Saya dipekerjakan karena saya memiliki banyak pengalaman dalam membangun aplikasi web dan karena saya condong ke teknologi yang lebih baru seperti JRuby on Rails atau nodejs.
Saya baru-baru ini memulai proyek membangun aplikasi web dengan fokus untuk menyelesaikan banyak hal dalam waktu singkat. Pimpinan perangkat lunak telah menentukan bahwa saya menggunakan mvc4 sebagai ganti rel. Itu mungkin OK, kecuali saya tidak tahu mvc4, saya tidak tahu C # dan saya satu-satunya yang bertanggung jawab untuk membuat server aplikasi web dan UI front-end.
Bukankah masuk akal untuk menggunakan kerangka kerja yang sudah saya kenal dengan baik (Rails) daripada menggunakan mvc4? Alasan di balik keputusan itu adalah bahwa pemimpin teknologi tidak tahu Jruby / rails dan tidak akan ada cara untuk menggunakan kembali kode.
Argumen balasan:
Dia tidak akan berkontribusi pada kode dan, sejujurnya, tidak diperlukan pada
proyek ini. Jadi, tidak masalah jika dia tahu JRuby / rails atau tidak.Kami benar-benar dapat menggunakan kembali kode karena kami memiliki banyak aplikasi java yang dapat diambil oleh JRuby dan sebaliknya. Bahkan, ia telah mendedikasikan beberapa sumber daya untuk mengkonversi perpustakaan Java ke C #, bukan hanya menjalankan perpustakaan Java pada aplikasi JRuby on Rails. Semua karena dia tidak suka Java atau JRuby
Saya telah membangun banyak aplikasi web, tetapi menggunakan sesuatu yang tidak dikenal menyebabkan spin-up dan saya tidak dapat membangun aplikasi yang luar biasa dalam waktu sesingkat yang biasa saya lakukan. Ini akan baik-baik saja; mempelajari teknologi baru adalah penting dalam bidang ini. Masalahnya adalah, untuk proyek ini kita harus menyelesaikan banyak hal dengan cepat.
Pada titik apa seorang pengembang diizinkan memilih alatnya? Apakah ini tergantung pada perusahaan? Apakah perusahaan saya payah atau ini dianggap normal? Apakah padang rumput yang lebih hijau ada? Apakah saya melihat ini dengan cara yang salah?
sumber
Jawaban:
Saya katakan Anda harus berbicara dengan pimpinan tim dan mengatakan sesuatu seperti:
Hal ini menimbulkan masalah "skill-you-were- (diasumsikan) -berusaha-untuk" vs "skill-you-need-now" dan juga menunjukkan bahwa Anda bersedia untuk mempelajari keterampilan baru, tetapi itu akan membutuhkan lebih lama untuk mengembangkan aplikasi baru karena Anda baru menggunakan perangkat ini. Dan kamu lakukan ingin menunjukkan bahwa Anda bersedia untuk belajar keterampilan baru. Tidak terbuka untuk mempelajari keterampilan baru adalah cara yang baik untuk memastikan pekerjaan Anda berakhir ketika keterampilan Anda tidak lagi dibutuhkan.
Adapun pertanyaan Anda di akhir:
Biasanya tergantung pada perusahaan. Jika sebuah perusahaan membeli alat MS dan menstandarkan semuanya pada platform VisualStudio dan .NET framework, itu bisa menjadi sangat aneh jika satu pengembang bersikeras menggunakan Linux dan C. Itu normal. Pengecualian mungkin ada di mana perusahaan kurang rewel tentang editor, seperti membiarkan pengembang memilih Vi vs Emacs, selama outputnya sama. Saya tahu beberapa perusahaan bahkan membiarkan pengembang memilih Windows vs Linux, tetapi bahasa tempat mereka bekerja memiliki dukungan dan runtime yang sangat baik untuk kedua OS.
Mengapa perusahaan melakukan ini? Konsistensi adalah salah satu alasannya. Bisa sangat sulit untuk men-debug hal-hal ketika aplikasi merupakan tambalan binari yang dibangun dalam bahasa / kerangka kerja favorit dari berbagai pengembang, dibangun di alat yang berbeda, dan diuji pada sistem yang sangat berbeda. Jika semua pengembang bekerja pada pengaturan yang hampir sama, masalah-masalah semacam itu diselesaikan.
Dalam kasus Anda, sepertinya Anda disewa untuk bekerja dalam teknologi yang tidak standar di perusahaan ini. Ini tampak aneh bagi saya, dan Anda mungkin ingin berbicara dengan orang yang mempekerjakan Anda tentang mengapa mereka menginginkannya.
sumber
Ketika mereka tidak memengaruhi tim Anda.
Benar.
Ya, Anda memiliki tenggat waktu yang singkat. Ya, Anda bisa menyelesaikannya lebih cepat di Rails. Tetapi perusahaan secara keseluruhan perlu menggunakan dan memelihara aplikasi. Jika perusahaan memiliki stabil pengembang C # yang baik, maka mungkin akan lebih murah (dan menghasilkan kualitas yang lebih baik) untuk mempertahankan aplikasi C #.
DBAs Anda dan staf admin lainnya mungkin akrab dengan tumpukan itu dan memiliki proses di tempat untuk menyebarkan dan memperbarui yang stack. Bahkan jika Anda dapat menyelesaikan kode lebih cepat, mungkin perlu waktu lebih lama setelah Anda menghitung semua biaya overhead yang diperlukan untuk menjalankan dan menjalankan aplikasi web profesional.
Ingat, Anda akan menghabiskan lebih banyak waktu untuk memelihara aplikasi Anda daripada menulisnya. Optimalkan untuk biaya itu.
sumber
Anda tampaknya dipekerjakan karena kemampuan Anda untuk beradaptasi dengan teknologi "baru". C # tidak berbeda, dalam hal itu. Apakah Anda yakin tidak ingin mengambil kesempatan untuk mempelajari sesuatu yang baru?
ASP.NET MVC sangat mirip dengan Ruby on Rails, dalam banyak hal.
Anda tidak akan berada pada kecepatan siput selamanya. Jika Anda sudah tahu ROR, ASP.NET MVC akan mudah bagi Anda. Caranya adalah belajar C #.
sumber
Argumen untuk tinggal dengan Java / JRuby
Kemungkinannya, bos Anda ingin Anda menghasilkan. Mereka mempekerjakan Anda sehingga Anda dapat menambah nilai bagi perusahaan. Pastikan mereka mengerti bahwa dengan memaksa Anda menggunakan kerangka kerja yang tidak Anda kenal mereka akan membuat Anda:
Bahkan programmer terbaik memerlukan waktu pemanasan dengan bahasa / kerangka kerja baru.
Argumen untuk Mempelajari MVC4 dan C #
Belajar bahasa baru itu bagus. Berinvestasi dalam keterampilan Anda sebagai seorang programmer hanya risiko jika bahasa / platform yang Anda pelajari akan menghilang dalam waktu dekat, dan dengan Microsoft yang terus berbincang, saya rasa itu bukan masalah. C # dan MVC keduanya memiliki pembaruan terkini yang meningkatkan keduanya, dengan pembaruan yang lebih banyak lagi dalam pipa.
Membuat Anda, secara pribadi, pengembang yang lebih berpengetahuan luas akan membuat Anda tidak lagi berada dalam situasi ini. Bagian terbaik? Bos Anda akan membayar Anda untuk mempelajari hal-hal ini, artinya Anda dibayar untuk membuat diri Anda lebih berharga.
Garis bawah
Anda mungkin akhirnya memenangkan pertarungan ini, tetapi Anda akan dibiarkan bekerja dengan kolega yang tidak puas. Cukup jelaskan pro dan kontra dari masing-masing kepada manajer Anda dan kemudian Anda berdua akan keluar dengan lebih bahagia.
sumber
Ketika dikatakan pengembang adalah pemimpin perangkat lunak.
Tentu saja, Anda dapat (dan seharusnya) membuat alasan untuk menggunakan toolkit yang berbeda jika Anda khawatir tentang produktivitas, tetapi bersiaplah untuk jawaban yang tidak Anda sukai. Mungkin ada alasan kuat mengapa lead Anda ingin Anda menggunakan toolkit tertentu, baik kompatibilitas dengan arsitektur saat ini, masalah tentang pemeliharaan, masalah lisensi, dll.
BTW, frasa itu
bertanggung jawab atas mulas dan kekacauan yang lebih besar dalam industri perangkat lunak daripada hal lainnya.
sumber
Saya perhatikan bahwa Anda tidak mengatakan Anda dipekerjakan sebagai JRuby atau programmer Java.
Inilah mengapa Anda mengatakan Anda direkrut: "Karena saya punya banyak pengalaman membangun aplikasi web dan karena saya condong ke teknologi yang lebih baru seperti JRuby on Rails atau nodejs."
Dengan kata lain, mereka menyukai pengalaman web Anda dan kemauan Anda untuk mempelajari teknologi baru.
Sekarang mereka meminta Anda untuk menggunakan pengalaman web Anda dan mempelajari teknologi baru.
Jadi pertanyaannya adalah, apakah Anda akan melakukan itu, atau tidak?
sumber
Pengeluaran Terbesar dalam Perangkat Lunak adalah Pemeliharaannya
Saya membaca bahwa biaya terbesar (80%) ada dalam pemeliharaan perangkat lunak. Pengembangan awal hanya 20% dari total biaya pengembangan.
Saya membaca sebuah kasus tentang pengembang yang mengembangkan kode dan komentar dalam bahasa aslinya (bukan bahasa Inggris) dan ketika anggota tim lainnya pergi untuk meningkatkan dan memelihara kode, itu hampir mustahil karena bahasa (bukan bahasa pemrograman) asing ke mereka.
Demikian pula, jika Anda mengembangkan kode dalam bahasa pemrograman pilihan Anda sendiri, akan sulit bagi anggota tim lainnya untuk mempertahankannya.
Solusi: Pair Programming
Pertimbangkan untuk meminta atasan Anda untuk memasangkan Anda dengan orang lain yang tahu bahasa pemrograman yang diperlukan dan Anda dapat bekerja sama. Anda dapat belajar satu sama lain, dan jika salah satu dari Anda meninggalkan perusahaan, yang lain akan mengetahui kode tersebut.
Artikel Wikipedia tentang "Pair Programming": http://en.wikipedia.org/wiki/Pair_programming
sumber
Banyak perusahaan lebih memilih untuk tetap dengan apa yang selalu mereka lakukan atau apa yang "aman". Ada alasan mengapa Java dan PHP masih sangat populer. Saat ini, mencari "COBOL" di memang.com mengembalikan 2144 listing ... yang seharusnya benar-benar berbicara sendiri. Industri tidak peduli dengan kode yang baik, ia peduli dengan kode yang dapat menghasilkan selama mungkin (ini tidak menyiratkan C # buruk, itu sebenarnya tidak).
Pikirkan tentang ini: kode ini akan bertahan lebih lama dari Anda. Ada kemungkinan besar bahwa orang lain akan mempertahankan kode Anda dan C # adalah taruhan yang lebih aman daripada Node.js dan Rails. Tidak akan mengejutkan saya jika dalam 5 atau 6 tahun jumlah programmer Ruby berkurang setengahnya, setelah semua yang sama terjadi pada Perl dan bahasa lain yang telah dianggap pada beberapa titik bahasa web "itu". Javascript tidak mungkin hilang tetapi kita sudah mulai melihatnya digunakan sebagai semacam ASM (atau bahkan C) dari web - bahasa perantara yang dapat dikompilasi oleh bahasa lain sehingga menulis kode sisi server di dalamnya sangat baik menjadi usang.
sumber
Perhatian utama saya dengan pengembang memilih bagaimana menerapkan tujuan mereka, adalah bahwa mereka biasanya menganggap hanya mereka yang akan mengedit kode. Lihatlah dengan cara ini, 12 bulan kemudian mereka mungkin perlu perubahan; Anda tidak tersedia (meninggalkan perusahaan atau benar-benar sibuk dengan tugas lain), dan pengembang lain harus memutar kode Anda. Jika ini adalah toko C #, maka menggunakan toolset mereka adalah kerja tim yang baik. Teknologi baru harus diselidiki dan diimplementasikan, tetapi hanya ketika pemimpin berpikir waktunya tepat, karena mereka memperhatikan banyak tujuan bukan hanya satu.
sumber
Tolong putar balik. Bayangkan Anda adalah orang yang mempekerjakan pengembang Ruby, dan mereka bersikeras untuk mengimplementasikan pekerjaan mereka di Asp.net/MVC.
Apa yang akan Anda katakan kepada mereka? Ini tumpukan kami, teman. Belajarlah untuk hidup dengannya.
Aturan emas, di sini adalah, dia yang memiliki emas membuat aturan.
sumber
Ada sejumlah tujuan yang saling bertentangan dan masalahnya adalah menemukan kompromi terbaik. Kami memiliki tenggat waktu, kami memiliki pimpinan tim yang meminta perangkat tertentu, dan kami memiliki pengembang yang tidak berpengalaman dengan perangkat itu, tetapi ditakdirkan untuk menghasilkan sesuatu dalam jangka waktu (jelas singkat).
Penting untuk dipahami, bahwa pemimpin tim mungkin memiliki beberapa alasan bagus mengapa dia menuntut set alat ini (salah satunya bisa membuat Anda terbiasa dengan alat ini karena beberapa alasan yang mungkin belum Anda ketahui). Hal terbaik yang dapat Anda lakukan pada putaran pertama adalah mencari tahu, apa sebenarnya alasan ini.
Masukkan ke posisi Anda, saya akan mencoba untuk berbicara dengan pemimpin tim dan mencoba menjelaskan situasinya, seperti yang Anda lihat, dan opsi serta hasil mana (termasuk dampak ekonomi jangka pendek dan jangka panjang) yang akan dihasilkan mengikuti setiap opsi ini. Misalnya, pengembang lain yang lebih berpengalaman dapat ditugaskan untuk melatih Anda, mungkin dengan beberapa sesi programmng pasangan atau sejenisnya.
Kecuali jika pemimpin tim Anda adalah orang tolol, Anda harus dapat menemukan konsensus yang masuk akal berkenaan dengan proyek dan tujuan keseluruhan perusahaan.
sumber
Bah Semua orang salah.
Jadilah pengembang yang lebih baik daripada orang-orang satu platform dan Anda akan memiliki lebih banyak opsi menarik daripada sebelumnya. Jadi, untuk saat ini, DO belajar MVC. Dan pada waktu Anda sendiri, pelajari lebih lanjut tentang platform yang benar-benar menarik minat Anda. Bangun keterampilan Node Anda. Pelajari beberapa Django. Perhatikan apa pun Java atau pra MVC. NET shenanigans yang Anda kenal dan kemudian melarikan diri, tetapi setidaknya cukup belajar untuk dapat mengkritik dan menjelaskan seberapa banyak Anda berpikir tentang prasangka kebencian yang membara di platform tersebut. (Oke, mungkin saya memproyeksikan di sana)
Dan sekarang untuk saran penting. Jika Anda terus mengasah spesialisasi Anda sambil juga mendiversifikasi keahlian Anda di bidang lain, pada akhirnya Anda akan berada di tempat di mana Anda dapat menemukan pekerjaan baru setiap saat sepanjang tahun dalam waktu kurang dari dua minggu di kota besar mana saja yang melakukan hal-hal yang kebanyakan menarik setidaknya separuh waktu. Ketika Anda menemukan diri Anda di tempat ini, jangan tahan dengan pekerjaan ini di mana mereka mengatakan mereka menginginkan ini dan pada hari kedua mereka telah Anda lakukan ITU tanpa harapan penangguhan hukuman yang dapat diramalkan di masa depan dalam jangka panjang. Hanya dengan sopan menjelaskan dan meminta maaf tetapi tidak, Anda benar-benar tidak ingin melakukan ITU dan berkata sebanyak itu di wawancara Anda dan kemudian! @ # $ Ing berhenti dan melanjutkan ketika beberapa minggu berlalu dan mereka sudah pasti tidak melakukan apa pun untuk mengakomodasi untuk fakta bahwa mereka salah mengartikan posisi untuk Anda dan menolak untuk mengakui hal itu.
Tapi percayalah, menemukan pertunjukan baru selalu jauh lebih baik daripada menjadi sangat kesal dan tidak bahagia untuk waktu berapa pun yang berlangsung lebih dari 5 menit. Tetapi tentu saja, pertama-tama Anda harus membayar iuran Anda sehingga Anda dapat melakukannya. Beberapa orang tidak akan pernah mau. Itu sebabnya mereka menginginkan semua hal yang mereka tahu paling baik. Dan tentu saja jawaban lain tidak benar-benar salah. Masuk akal untuk toko .NET untuk pergi dengan. NET jika mereka harus mempertahankan hal yang konyol.
Tentu saja, yang tidak masuk akal adalah mengapa mereka melakukan diversifikasi dengan pengembang Rails / JS / UI dan hanya menyuruhnya melakukan aplikasi MVC. Tetapi untuk sekarang. Anda mungkin perlu mengambilnya dan membayar iuran Anda. Dan seperti yang saya katakan di komentar, MVC benar-benar tidak terlalu buruk. Pilihan yang sangat buruk diberikan semua opsi tetapi tentu saja bukan yang terburuk. Ini cukup mudah, tidak melemparkan 10.000 lapisan abstraksi di atas semua yang sebenarnya terjadi, dan tidak menjadi begitu terpelintir dengan sisi klien sehingga Anda akan mengutuk nama-nama insinyur MS yang bertanggung jawab jika ada yang bisa diganggu untuk mempelajarinya.
Jadi pergilah ke tempat di mana Anda bisa pergi kapan pun Anda mau jika Anda belum melakukannya dan Anda bahkan mungkin mendapati Anda memiliki mata yang lebih skeptis terhadap hal-hal yang saat ini Anda sukai. Anda bahkan mungkin mendapati diri Anda tidak menyukai pagar seperti halnya saya. Bukan berarti ada yang salah dengan Ruby (selain penerjemahnya tentu saja).
sumber
Bergantung pada situasi Anda, bisa berbahaya untuk menganggap Anda tahu mengapa mereka mempekerjakan Anda, dan terlebih lagi menganggap manajer Anda tahu itu dan setuju bahwa mempekerjakan orang dengan keahlian Anda adalah ide yang bagus.
Saya akan meminta mengambil saran di atas dan membuat alasan bisnis mengapa Anda harus pergi dengan JRuby lebih dari C #, mungkin argumen Anda dan jadwal berarti melanggar dari cara lama masuk akal. Saya tidak akan hanya menganggap itu baik-baik saja atau tidak, memberikan manajer atau memimpin fakta dan membiarkan mereka membuat keputusan, itu adalah apa yang mereka bayar dengan uang besar, ditambah sedikit CYA.
sumber
Menurut pendapat jujur saya, salah satu hal yang memisahkan pengembang yang baik dari yang hebat adalah kemampuan mereka untuk beradaptasi dengan teknologi baru. Kita hidup di dunia yang serba cepat di mana teknologi top hari ini akan menjadi usang besok. Oleh karena itu, pengembang yang tidak mau beradaptasi adalah penggunaan terbatas untuk perusahaan. Ini akan baik-baik saja, jika bukan karena fakta kecil bahwa menemukan dan mempekerjakan orang baik benar-benar sangat sulit dilakukan dan ketika sebuah perusahaan menemukan permata mereka, mereka berencana untuk jangka panjang.
Saya telah melihat perusahaan mempekerjakan keluar dari ruang lingkup teknologi mereka dan mereka melakukannya untuk alasan yang sama persis. Mereka ingin mendapatkan pengembang yang hebat, bahkan jika itu berarti menunggu mereka untuk beradaptasi dengan teknologi baru.
Sekarang untuk situasi Anda. Sebagai orang baru di grup, saya akan sangat berhati-hati dengan apa yang saya katakan dan tidak katakan kepada atasan saya. Tentu, Anda akan lolos dengan banyak berdasarkan asumsi bahwa Anda masih dalam proses beradaptasi dengan lingkungan baru Anda. Namun, melemahkan otoritas dan ketekunan yang keras kepala pada teknologi pilihan Anda hanya akan membuat atasan Anda berpikir mereka melakukan kesalahan dalam merekrut Anda dan bahwa Anda tidak mau meninggalkan zona nyaman Anda.
Apa yang akan Anda pilih terserah Anda, tetapi saya sarankan Anda mencoba mempelajari teknologi baru. Tidak akan sakit, aku janji.
sumber
Saya akan berasumsi bahwa Anda jujur di depan selama wawancara Anda tentang kurangnya pengetahuan C # Anda, karena jika Anda tidak maka Anda mungkin berada dalam posisi yang sangat berbahaya dari sudut pandang hukum.
Pemrogram yang baik tahu pemrograman. Meskipun tidak ada yang bisa menguasai semua bahasa dan kerangka kerja, ada banyak kesamaan di antara mereka. Kecuali jika Anda diminta untuk bekerja dalam bahasa yang sangat berbeda dari apa yang menjadi mainstream saat ini (Lisp, misalnya), maka programmer yang baik harus dapat beradaptasi.
Secara alami ada kurva belajar. Jika majikan mempekerjakan Anda, maka mereka harus yakin dengan kemampuan Anda untuk mengikuti kurva itu dalam jumlah waktu yang wajar (sekali lagi, anggap Anda jujur di muka karena tidak mengetahui C #). Bahasa C # banyak dipinjam dari Jawa, dan lebih umum lagi, sebagian besar bahasa pemrograman berbasis kelas pada dasarnya sangat mirip (Anda menyebutkan node.js, yang dibangun di atas ECMAScript, yang merupakan bahasa berbasis prototipe, jadi Anda jelas nyaman dengan paradigma pemrograman lain.
Pemrogram yang baik harus, selain fleksibel, ingin belajar hal-hal baru. Dalam pengembangan perangkat lunak Anda umumnya belajar atau menjadi tidak relevan.
Tentu saja majikan Anda, dengan asumsi mereka tahu Anda tidak tahu C #, harus menemui Anda setengah jalan. Jika Anda menunjukkan keinginan untuk belajar maka mereka harus memberi Anda waktu dan sumber daya untuk melakukannya. Melempar Anda ke dalam adalah hal yang tidak adil dan membuat Anda stres. Anda perlu duduk dan berdiskusi dengan tenang, rasional dengan atasan Anda. Jika mereka menginginkannya dalam C # maka mereka harus siap untuk menerima bahwa Anda akan berada pada kurva belajar saat mengerjakannya dan itu tidak adil bagi mereka untuk memaksakan tenggat waktu yang ketat pada Anda. Jika tenggat waktu tidak fleksibel dan jika mereka memiliki kepentingan strategis yang tinggi, maka tenggat waktu itu harus dipersiapkan untuk memungkinkan Anda memiliki beberapa keleluasaan untuk menyelesaikan pekerjaan dalam tenggat waktu itu. Jika mereka membutuhkannya dalam bahasa yang lebih umum digunakan di kantor mereka, maka Anda mungkin dapat meminta untuk mengimplementasikannya sekarang sesuai keinginan Anda. Anda terbiasa untuk memenuhi tenggat waktu, dan kemudian ketika proyek Anda berikutnya mengimplementasikannya kembali dalam C # sebagai latihan pembelajaran dan untuk membawa perangkat lunak sesuai dengan persyaratan internal setelah memenuhi yang eksternal. Seperti saya katakan, sebagian besar bahasa yang lebih umum digunakan saat ini memiliki banyak kesamaan sehingga sebagian besar turun ke detail implementasi.
Anda harus siap menerima cepat atau lambat bahwa Anda bekerja di C # shop dan karenanya Anda perlu memiliki C # di bawah ikat pinggang Anda.
sumber
Mungkin mereka tidak puas dengan cara semua orang menggunakan MVC di lingkungan .NET. Mungkin ada terlalu banyak memperlakukannya seperti formulir web. Ini tidak berbeda ketika seseorang dengan latar belakang prosedural dimulai di OOP, menempatkan semuanya dalam satu kelas besar dan melanjutkan bisnis seperti biasa.
Proyek pertama ini bukan situasi yang ideal karena mereka ingin ini dilakukan dengan cepat. Dapatkan hingga kecepatan pada. NET sebanyak mungkin dan mulai cranking fitur secepat mungkin. Anda tidak akan menyukai cara Anda melakukan sesuatu, hanya perlu diingat Anda akan mulai memperbaiki hal ini dan menerapkan keterampilan Anda dalam bahasa lain.
Mudah-mudahan, cara Anda menggunakan MVC4 (dengan asumsi semua orang di sana tidak melakukannya dengan benar) dalam Gaya-Ruby yang lebih akan menangkap dan memisahkan semua orang dari mentalitas Webforms.
sumber