Berapa banyak kebebasan yang harus dimiliki seorang programmer dalam memilih bahasa dan kerangka kerja?


67

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?


45
"Menentang pesanan" pada sesuatu seperti ini mungkin merupakan langkah membatasi karier.
Dan Pichelman


39
Perusahaan suka melakukan standarisasi pada alat karena mengurangi biaya baik dari sudut pandang pembelian Aplikasi tetapi juga dalam mengelola sumber daya perusahaan. Manajemen lisensi sebenarnya cukup memakan waktu. Selain itu, jika setiap orang menggunakan bahasa / alat pilihan mereka sendiri, maka mampu mengacak orang di antara pekerjaan menjadi jauh lebih sulit. Akhirnya, keluhan Anda tentang timah hitam Anda identik dengan alasan Anda ingin menggunakan alat pilihan Anda. Anda tidak terbiasa dengan mvc4 atau tidak menyukainya. Pemimpin sw adalah pemimpin, jadi itu adalah panggilan mereka kecuali Anda dapat mengajukan argumen yang dapat mengubah pikiran mereka.
Dunk

22
Ini semua harus diatasi selama wawancara kerja Anda.
user16764

30
Apakah Anda seorang programmer atau programmer Ruby ? Bahasa harus seperti alat. Beberapa memiliki kekuatan atau kelemahan, tetapi tergantung pada pengrajin untuk memanfaatkannya sebaik mungkin. Perusahaan telah mendikte toolset standar karena alasan yang jelas.

Jawaban:


98

Saya katakan Anda harus berbicara dengan pimpinan tim dan mengatakan sesuatu seperti:

Saya tahu kalian adalah toko .NET, tetapi saya sebenarnya disewa untuk keterampilan Java / JRubyRails saya. Saya dapat membangun aplikasi baru ini dalam jumlah waktu X menggunakan alat-alat yang sudah saya ketahui. Aku bisa belajar C # / mvc4 seperti yang Anda inginkan, tetapi akan memakan >> X jumlah waktu. Apa yang kamu inginkan?

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:

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?

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.


31
"Aku bisa membangun aplikasi baru ini dalam jumlah waktu X menggunakan alat-alat yang sudah aku tahu. Aku bisa belajar C # / mvc4 seperti yang kamu inginkan, tetapi akan membutuhkan >> jumlah X waktu. Apa yang kamu inginkan?" - Jawaban yang bagus. Bingkai itu dalam bentuk tradeoff biaya.
Christian Ternus

Sepakat. Ini semua tentang ekonomi. Setelah Anda melakukan putaran ekonomi pada sudut pandang Anda, SETIAP pimpinan yang nyata, akan mendengarkan Anda dan mempertimbangkan kembali pendirian mereka. Buat tradeoff eksplisit: Mis .: Semakin banyak waktu menyiratkan hal-hal akan datang kemudian menyiratkan tenggat waktu mungkin terlewatkan menyiratkan hit pendapatan . Terkadang, mereka perlu menunjukkan jalan menuju tujuan 'trade off' pada intinya.
PhD

6
+1. Satu-satunya cara jawaban ini tidak memuaskan saya adalah sedikit mengurangi aspek pembelajaran. Seorang pengembang yang ingin belajar adalah aset yang jauh lebih berharga daripada orang yang tahu segalanya tentang satu hal dan tidak akan berubah .
Corey

7
+1 Saya juga akan menekankan poin (tersirat) bahwa jika pemimpin memilih untuk pergi dengan MVC, OP berkewajiban untuk bekerja keras dan melakukan proyek di MVC.
Dan Lyons

"Beberapa perusahaan bahkan membiarkan pengembang memilih Windows vs Linux" - dan Anda juga akan sering menemukan pengguna Mac juga di dunia Ruby. (Perusahaan saya sebagian besar adalah toko Ruby, tetapi tidak ada batasan pada editor atau OS - dan kami memiliki pengembang menggunakan Linux dan Mac sekarang, saat ini tidak ada pengembang dengan mesin Windows).
Ben Lee

140

Pada titik apa seorang pengembang diizinkan memilih alatnya?

Ketika mereka tidak memengaruhi tim Anda.

Apakah saya melihat ini dengan cara yang salah?

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.


19
Jawaban yang bagus 'Terbaik' dalam hal ini mungkin tidak berarti mengoptimalkan yang tercepat untuk pengembangan awal , khususnya untuk programmer awal . Dari perspektif bisnis, aplikasi kemungkinan akan menghabiskan lebih banyak waktu dalam mode pemeliharaan dan didukung oleh seluruh tim , jadi itulah yang harus mendorong keputusan kerangka kerja.
Eric King

4
Saya pikir ini saran yang bagus. Saya tidak memilihnya sebagai jawaban karena, dalam kasus khusus saya, banyak masalah tidak berlaku. Saya akan bertanggung jawab untuk mengatur penyebaran dan penerapan aplikasi. Saya pasti setuju dengan bagian perawatannya, ini adalah masalah yang valid. Siapa yang tahu di mana saya akan berada dalam beberapa tahun ketika seseorang perlu memperbarui kode.
Spencer

2
Kemungkinannya adalah bahwa Anda sebenarnya TIDAK direkrut untuk keterampilan JRuby / Rails Anda tetapi Anda direkrut untuk pengalaman Anda dalam membangun Aplikasi Web dan apa yang sebenarnya mereka cari adalah memanfaatkannya dalam konteks MVC4 dan C #.
Jay Stevens

Meskipun Anda membuat poin bagus, tetap saja tidak masuk akal untuk memiliki pria yang tidak memiliki pengalaman dalam tumpukan itu, dan mungkin tidak tertarik untuk melakukannya. Mengapa tidak meminta salah satu dari C # untuk melakukannya? Yang akan mereka lakukan adalah membuat orang ini merasa seperti dia tidak memiliki kepemilikan atas proyeknya, dan membuatnya merasa terbakar, dan menyebabkan dia meninggalkan perusahaan.
s73v3r

@ s73v3r - Saya berharap OP tahu apa yang dia hadapi. Jujur, jika Anda memiliki muatan kapal C # devs (dan basis kode) maka itu harus jelas bagi pria Rails selama wawancara. Jika dia mengambil pekerjaan itu dan kemudian menolak keras untuk melakukan apa yang dia pekerjakan ...
Telastyn

41
  1. 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?

  2. ASP.NET MVC sangat mirip dengan Ruby on Rails, dalam banyak hal.

  3. Anda tidak akan berada pada kecepatan siput selamanya. Jika Anda sudah tahu ROR, ASP.NET MVC akan mudah bagi Anda. Caranya adalah belajar C #.


18
+1, mengikat diri sendiri ke satu bahasa / kerangka kerja itu konyol. Ambil kesempatan untuk mendapat bayaran untuk mempelajari hal-hal baru. Dan .NET memiliki banyak perkembangan aktif dan menarik yang sedang terjadi.
jozefg

Saya setuju bahwa mereka serupa tetapi ada perbedaan signifikan yang dapat menambah banyak jam. Mengingat jumlah jam yang terbatas untuk proyek ini, saya pikir kereta api adalah pilihan yang jelas. Saya tidak menentang mempelajari hal-hal baru seperti yang saya sebutkan dalam pertanyaan.
Spencer

Butir # 1 tidak jelas - OP mengatakan bahwa mereka dipekerjakan karena pengalaman Java / JRuyb / Rails / nodejs mereka: 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 simpuljs. OP tidak berbicara tentang kemampuan beradaptasi mereka atau bahwa kemampuan beradaptasi mereka adalah alasan mengapa mereka dipekerjakan.
FrustratedWithFormsDesigner

2
+1, setuju, saya tidak pernah mengerti argumen dari genre "Saya tahu benar bagaimana melakukan A dalam bahasa L1 tapi saya sama sekali tidak dapat melakukannya dalam bahasa L2".
Shivan Dragon

2
@Spencer: Ketika Anda meminta saran kepada kami, dan setiap orang memberi Anda saran yang sama, Anda mungkin harus menerima saran itu. Tidak ada gunanya membantah jawaban ketika Anda mengakui, tetapi mengajukan pertanyaan, bahwa Anda tidak tahu apa jawaban yang benar.
Andrew Coonce

21

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:

  1. Menghasilkan hasil pada tingkat yang lebih lambat
  2. Buat kode kualitas lebih rendah

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.


11
+1, "artinya Anda dibayar untuk membuat diri Anda lebih berharga" bingo!
GrandmasterB

Sebagaimana ditunjukkan (dan beberapa jawaban), ada pertukaran antara penciptaan awal pada waktu Anda dan penerapan / pemeliharaan oleh semua orang. Buat upaya yang layak (tapi hormat) untuk melihat apakah Runcing-Rambut bersedia melakukan perdagangan itu, tetapi jika tidak hanya menghormati keputusan mereka dan menikmati dibayar untuk mempelajari sesuatu yang baru di waktu perusahaan.
brichins

@brichins: Saya pikir salah satu masalah besar dengan jawaban ini adalah bahwa sebenarnya tidak menunjukkan apa yang Anda katakan!
ruakh

@ruakh Saya mengalami kesulitan mencari tahu jawaban untuk membiarkan komentar ini aktif - Anda benar, jawaban ini tidak membahas pengorbanan khusus tersebut (meskipun ini menunjukkan ketegangan di tempat kerja yang mungkin terjadi). Saya mungkin seharusnya juga secara khusus mengatakan bahwa OP harus yakin dia telah berbicara dengan semua pembuat keputusan (tanpa melewati kepala siapa pun) sehingga jika / ketika proyek tidak memenuhi batas waktu, dia dapat dengan sopan menyampaikan "Saya sudah memberi tahu Anda di depan mungkin. Mungkin untuk proyek selanjutnya kita bisa mencoba Ruby sebagai gantinya?
brichins

18

Pada titik apa seorang pengembang diizinkan memilih alatnya?

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

dengan fokus untuk menyelesaikan banyak hal dalam waktu singkat

bertanggung jawab atas mulas dan kekacauan yang lebih besar dalam industri perangkat lunak daripada hal lainnya.


2
+1 "Ketika dikatakan pengembang adalah pemimpin perangkat lunak." Persis. Terkadang, ketika Anda memperdebatkan poin Anda dan Lead Anda tidak setuju dengan Anda, itu karena Lead Anda memiliki pandangan yang lebih baik tentang gambaran besar. Ini adalah salah satu situasi itu.
Andrew Coonce

Tidak setuju. Dengan begitu Anda mengarahkan bawahan Anda ke hal lain selain pengikut yang akan lupa bagaimana membuat keputusan dan bertanggung jawab atas mereka. Jika Anda menginginkannya - baiklah. Saya pikir ada tempat-tempat di mana orang akan lebih pintar daripada Anda sebagai pemimpin tim. Tapi ya, beberapa orang punya masalah dengan itu, dan itu tragis.
JensG

Saya benar-benar menertawakan tanggapan Anda untuk "bertanggung jawab atas mulas dan kekacauan yang lebih besar di industri perangkat lunak daripada apa pun." ... terima kasih! Tidak bisa mengutarakannya lebih baik!
Alexus

11

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?


9

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


3
Jika Anda menulis sesuatu yang hanya Anda mengerti, maka Anda akan terjebak mempertahankannya selamanya.
jwernerny

6

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.


4
Meskipun ini benar, praktik rekrutmen C # shop yang sangat buruk untuk menyewa pengembang Ruby yang tidak mengenal C #, tanpa membuatnya jelas bahwa pekerjaan yang ia pekerjakan terutama melibatkan pengembangan C #.
Carson63000

5

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.


3

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.


1
Tetapi mengapa Anda mempekerjakan seseorang yang bersikeras menggunakan .NET untuk peran Ruby?
Bobson

3
@ Bobson karena mereka adalah programmer muda yang cerdas yang tampaknya mampu mengatasi masalah dengan sejumlah teknologi berbeda, menyelesaikan masalah pemrograman umum secara memuaskan, dan mereka melamar pekerjaan itu.

2
@ Bobson: Jadi sekarang Anda berpendapat bahwa perusahaan tidak boleh mempekerjakan pengembang yang tidak memiliki pengalaman dalam bahasa pilihan perusahaan. Semua orang tampaknya berpendapat arah lain, di mana mereka mengklaim mereka dapat mempelajari bahasa baru dengan sangat cepat sehingga perusahaan tidak boleh meneruskan pengembang yang baik hanya karena mereka bukan ahli dalam bahasa tertentu .... belum.
Dunk

2
" 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." - ini tidak disewa sebagai pengembang XYZ, ini "disewa sebagai pengembang web dengan pengalaman dalam teknologi yang lebih baru" (bahwa perusahaan mungkin tertarik untuk memperbarui hal-hal di masa depan).

3
@ Bobson: Ketika saya dipekerjakan di perusahaan baru, saya tidak hanya tahu apa yang saya bawa, tetapi saya juga tahu proyek apa yang akan saya kerjakan dan apa yang mereka harapkan saya lakukan pada proyek itu. Jika OP tidak dapat diganggu untuk menemukan informasi ini maka malu padanya. Dengan mengatakan itu, saya pikir ini benar-benar kasus perusahaan mempekerjakan seseorang yang mereka percaya adalah pengembang yang baik dengan pengetahuan domain yang relevan untuk datang dan membantu tim, dengan harapan bahwa mengambil barang-barang mvc4 adalah rintangan kecil. Mungkin perusahaan itu tidak menjelaskan dengan baik, tetapi OP juga tidak melakukan bagiannya.
Dunk

2

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.


2

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).


1

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.


1

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.


1

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.