Quanta libertà dovrebbe avere un programmatore nella scelta di una lingua e di un framework?

Direi che devi parlare con il leader della squadra e dire qualcosa del tipo:

I know you guys are a .NET shop, but I was actually hired for my Java/JRubyRails skills. I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?

Ciò solleva il problema di "abilità-tu-sei- (presumibilmente) -hired-for" vs. "skill-you-need-now" e mostra anche che sei disposto ad apprendere le nuove abilità, ma che impiegherà più tempo a sviluppare la nuova applicazione man mano che si è nuovi in questo set di strumenti. E tu fai vuoi dimostrare che sei disposto ad apprendere nuove abilità. Non essere aperto all'apprendimento di nuove competenze è un buon modo per garantire che il tuo impiego cessi quando le tue capacità non sono più necessarie.

Per quanto riguarda la tua domanda alla fine:

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

Di solito dipende dalla compagnia. Se un'azienda acquista strumenti MS e standardizza tutto sulla piattaforma VisualStudio e .NET Framework, potrebbe diventare molto imbarazzante se uno sviluppatore insiste a utilizzare Linux e C. Questo è normale. Potrebbero esistere delle eccezioni in cui la compagnia è meno esigente riguardo gli editori, come lasciare che gli sviluppatori scelgano Vi vs. Emacs, a patto che l'output sia lo stesso. So che alcune aziende consentono agli sviluppatori di scegliere Windows o Linux, ma la lingua in cui lavorano ha un ottimo supporto e autonomia per entrambi i sistemi operativi.

Perché le aziende fanno questo? La coerenza è una delle ragioni. Può essere molto difficile eseguire il debug delle cose quando l'applicazione è un patchwork di binari costruiti nelle lingue / framework preferiti di vari sviluppatori, costruiti in strumenti diversi e testati su sistemi molto diversi. Se tutti gli sviluppatori lavorano su principalmente impostazioni simili, questi tipi di problemi sono risolti.

Nel tuo caso, sembra che sei stato assunto per lavorare in una tecnologia non standard in questa azienda. Questo mi sembra strano, e potresti voler parlare con la persona che ti ha ingaggiato su perché lo volevano.

At what point should a developer be allowed to choose his tools?

Quando non influenzano la tua squadra.

Am I looking at this the wrong way?

Assolutamente.

Sì, hai una scadenza breve. Sì, puoi farlo fare più velocemente in Rails. Ma l'azienda nel suo complesso deve implementare e mantenere l'applicazione. Se la società ha una stabile di buoni sviluppatori C #, allora probabilmente sarà più economico (e produrrà una migliore qualità) avere un'app C # da mantenere.

I tuoi DBA e altri membri dello staff sono probabilmente familiari con lo stack e hanno processi in atto per distribuire e aggiornare quello stack. Anche se riesci a ottenere il codice più velocemente, potrebbe essere necessario più tempo dopo aver tenuto conto di tutto il sovraccarico necessario per installare e avviare un'applicazione Web professionale.

Ricorda che trascorrerai più tempo a mantenere la tua app che a scriverla. Ottimizza per quel costo.

1. Sei apparentemente assunto a causa della tua capacità di adattarsi alle "nuove" tecnologie. C # non è diverso, a questo proposito. Sei sicuro di non voler cogliere l'occasione per imparare qualcosa di nuovo?

2. ASP.NET MVC è molto simile a Ruby on Rails, in molti modi.

3. Non sarai a passo di lumaca per sempre. Se già conosci ROR, ASP.NET MVC sarà un gioco da ragazzi per te. Il trucco sta nell'apprendimento di C #.

Argomenti per rimanere con Java / JRuby

È probabile che il tuo capo voglia che tu produca. Ti hanno assunto per poter aggiungere valore alla compagnia. Assicurati che capiscano che obbligandoti a utilizzare un framework che non ti è familiare, ti ti indurrà a:

1. Produce risultati più lenti
2. Crea un codice di qualità inferiore

Anche i migliori programmatori richiedono tempi di riscaldamento con nuovi linguaggi / framework.

Argomenti per l'apprendimento di MVC4 e C #

Imparare nuove lingue è buono. Investire nelle tue capacità di programmatore è solo un rischio se la lingua / piattaforma che stai imparando scomparirà nel prossimo futuro, e con Microsoft che si muove, non penso che questo sia un problema. Sia C # che MVC hanno avuto aggiornamenti recenti che li hanno migliorati entrambi, con ancora più aggiornamenti nella pipeline.

Rendendoti, personalmente, uno sviluppatore più completo ti impedirà di ricominciare da capo in questa situazione. La parte migliore? Il tuo capo ti pagherà per imparare queste cose, il che significa che vieni pagato per farti guadagnare più soldi.

The Bottom Line

Potresti finire per vincere questa lotta, ma ti ritroverai a lavorare con colleghi scontenti. Basta spiegare i pro e i contro di ciascuno al tuo manager e poi uscirai entrambi dall'altra parte più felici.

At what point should a developer be allowed to choose his tools?

Quando detto sviluppatore è il lead del software.

Certamente, puoi (e dovresti) cercare di utilizzare il diverso toolkit se sei preoccupato per la produttività, ma preparati a una risposta che non ti piacerà. Potrebbe esserci una dannata buona ragione per cui il tuo lead vuole che tu usi un toolkit specifico, sia che si tratti di compatibilità con l'architettura attuale, problemi di manutenzione, problemi di licenza, ecc.

BTW, la frase

with a focus on getting a lot of stuff done in a short amount of time

è responsabile di più bruciori di stomaco e caos nel settore del software rispetto a qualsiasi altra cosa.

Ho notato che non dici di essere stato assunto come programmatore JRuby o Java.

Ecco perché hai detto che sei stato assunto: "[B] perché ho molta esperienza nella creazione di applicazioni web e perché mi rivolgo a nuove tecnologie come JRuby su Rails o nodejs."

In altre parole, a loro piace la tua esperienza web e la tua volontà di apprendere nuove tecnologie

Ora ti chiedono di utilizzare la esperienza web e di imparare una nuova tecnologia.

Quindi la domanda è, hai intenzione di farlo, o no?

Le maggiori spese nel software sono nella manutenzione di esso

Ho letto che la spesa maggiore (80%) è nella manutenzione del software. Lo sviluppo iniziale è solo il 20% del costo totale dello sviluppo.

Ho letto un caso su uno sviluppatore che ha sviluppato codice e commenti nella sua lingua madre (non in inglese) e quando gli altri membri del team sono andati a migliorare e mantenere il codice, era quasi impossibile perché la lingua (non un linguaggio di programmazione ) era estraneo a loro.

Allo stesso modo, se sviluppi codice in un linguaggio di programmazione di tua scelta, sarebbe difficile per gli altri membri del team mantenere.

Soluzione: abbina programmazione

Considera chiedere ai tuoi datori di lavoro di associarti con qualcun altro che conosce il linguaggio di programmazione richiesto e puoi lavorare insieme. Puoi imparare gli uni dagli altri, e se uno di voi lascia l'azienda, l'altro conoscerà il codice.

Articolo di Wikipedia su "Pair Programming": link

Molte aziende preferiscono semplicemente attenersi a ciò che hanno sempre fatto o che cosa è "sicuro". C'è una ragione per cui Java e PHP sono ancora molto popolari. Al momento, la ricerca di "COBOL" su Indeed.com restituisce 2144 schede ... che dovrebbero davvero parlare da sole. L'industria non si cura del buon codice, si preoccupa del codice che può mungere il più a lungo possibile (ciò non implica che C # sia cattivo, in realtà non lo è).

Pensaci su questo: il codice ti supererà. C'è una buona probabilità che qualcun altro manterrà il tuo codice e C # è una scommessa più sicura di Node.js e Rails. Non mi sorprenderebbe se tra 5 o 6 anni il numero di programmatori di Ruby si dimezzasse, dopo che lo stesso è accaduto a Perl ea qualsiasi altra lingua che è stata considerata ad un certo punto il linguaggio web "it". Javascript non è destinato a scomparire, ma stiamo già iniziando a vedere che viene usato come una sorta di ASM (o anche C) del web - una lingua intermedia che altre lingue possono compilare in modo da scrivere codice lato server in esso potrebbe molto bene diventare obsoleto.

La mia principale preoccupazione per gli sviluppatori che scelgono come implementare i propri obiettivi è che normalmente presuppongono solo che modificheranno il codice. Guardalo in questo modo, 12 mesi dopo potrebbero aver bisogno di cambiamenti; non sei disponibile (hai lasciato l'azienda o sei veramente impegnato in un'altra attività), e un altro sviluppatore deve controllare il tuo codice. Se è un negozio C #, usare il set di strumenti è un buon lavoro di squadra. Le nuove tecnologie dovrebbero essere studiate e implementate, ma solo quando il lead pensa che sia il momento giusto, poiché hanno gli occhi su molti obiettivi non solo su uno.

Giralo, per favore. Immagina che tu fossi quello che assumeva uno sviluppatore Ruby, e loro insistono nell'implementare il loro lavoro in Asp.net/MVC.

Cosa diresti loro? Questo è il nostro stack, amico. Impara a conviverci.

La regola d'oro, ecco, lei che ha l'oro fa le regole.

Ci sono una serie di obiettivi in conflitto e il problema è trovare il miglior compromesso. Abbiamo la scadenza, abbiamo un team leader che richiede un certo set di strumenti, e abbiamo uno sviluppatore inesperto con questo set di strumenti, ma destinato a produrre qualcosa entro un lasso di tempo (ovviamente breve).

È importante capire che la guida del team ha probabilmente alcune buone ragioni per cui esige esattamente questo set di strumenti (uno dei quali potrebbe essere davvero quello di farti abituare a questo set di strumenti per qualche motivo che potresti non sapere ancora). La cosa migliore che puoi fare al primo tentativo è scoprire quali sono esattamente queste ragioni.

Inseritevi nella vostra posizione, proverei a parlare con il capo della squadra e cercherò di spiegare la situazione, come è a vostro avviso, e le opzioni e il risultato (inclusi gli effetti economici a breve ea lungo termine) sarà generato seguendo ognuna di queste opzioni. Ad esempio, un altro sviluppatore più esperto potrebbe essere assegnato per istruirti, magari con alcune sessioni di programmazione o simili.

A meno che il tuo team non sia un vero deficiente, dovresti essere in grado di trovare un consenso che abbia senso per quanto riguarda il progetto e gli obiettivi generali dell'azienda.

Bah. Tutti hanno torto.

Essere uno sviluppatore migliore di quelli con una piattaforma unica e avrai molte più opzioni interessanti di quanto non lo saranno mai. Quindi, per ora, impara MVC. E nel tuo tempo libero, scopri di più sulle piattaforme che ti interessano davvero. Costruisci le tue abilità nel nodo. Impara un po 'di Django. Presta attenzione a qualsiasi jenavigma Java o pre MVC .NET a cui sei esposto e poi scappa, ma almeno impara abbastanza per essere in grado di criticare e spiegare quanto hai pensato nel tuo pregiudizio dell'odio bruciante a malapena nascosto di quelle piattaforme. (okay, forse sto proiettando lì)

E ora per l'importante consiglio. Se continui ad affinare le tue specialità e allo stesso tempo diversifichi le tue competenze in altre aree, alla fine sarai in un posto dove puoi trovare nuovo lavoro in qualsiasi momento dell'anno in meno di due settimane in qualsiasi città importante facendo cose che sono per lo più interessante almeno la metà delle volte. Quando ti trovi in questo posto, non sopportare questi lavori in cui dicono di volere questo e di giorno in due ti fanno fare QUESTO senza alcuna speranza di una tregua prevedibile nel futuro a lungo termine. Spiega gentilmente e scusa ma non hai davvero voluto farlo e hai detto tutto al tuo colloquio e poi! @ # $ Smettila e vai avanti quando trascorrono un paio di settimane e inevitabilmente non hanno fatto nulla per il fatto che hanno interpretato male la posizione e si rifiutano di riconoscerlo.

Ma credimi, trovare un nuovo concerto è sempre meglio che essere seriamente irritato e infelice per un periodo di tempo superiore ai 5 minuti. Ma ovviamente, prima devi pagare i tuoi debiti per poterlo fare. Alcune persone non lo faranno mai. Ecco perché vogliono tutto nelle cose che sanno meglio. E ovviamente altre risposte non sono veramente sbagliate. È logico che .NET acquisti .NET se è necessario mantenere la cosa stupida.

Naturalmente, ciò che non ha senso è il motivo per cui si diversificano con un dev di Rails / JS / UI e gli hanno solo fatto app per MVC. Ma per ora. Potrebbe essere necessario prenderlo e pagare le quote. E come ho detto nei commenti MVC non è poi così male. Una scelta davvero brutta data tutte le opzioni ma certamente non la peggiore. È piuttosto semplice, non getta 10.000 strati di astrazione oltre a tutto ciò che sta realmente accadendo, e non si stravolge così tanto sul lato client che malediresti i nomi degli ingegneri MS responsabili se qualcuno potesse essere disturbato per impararli.

Quindi vai in quel posto dove puoi andartene quando vuoi se non lo hai già fatto e potresti anche scoprire di avere un occhio più scettico sulle cose che ti piacciono attualmente. Potresti anche scoprire di non amare i binari tanto quanto me. Non che ci sia qualcosa di sbagliato in Ruby (a parte il suo interprete, ovviamente).

A seconda della situazione, potrebbe essere pericoloso presumere il motivo per cui ti hanno assunto, e ancora di più per supporre che il tuo manager lo sappia e accetta che assumere persone con le tue capacità sia una buona idea.

Vorrei chiedere il consiglio di cui sopra e fare un business case perché dovresti andare con JRuby su C #, forse la tua argomentazione e le scadenze significano rompere con i vecchi modi. Non penserei solo che sia ok o meno, dare al manager o condurre i fatti e lasciare che prendano la decisione, è quello per cui sono stati pagati i grandi guadagni, oltre a un po 'di CYA.

Secondo la mia onesta opinione, una delle cose che separa i bravi sviluppatori è la loro capacità di adattarsi alle nuove tecnologie. Viviamo in un mondo frenetico in cui la tecnologia top di oggi diventerà obsoleta domani. Quindi, uno sviluppatore che non è disposto ad adattarsi è di uso limitato per l'azienda. Questo andrebbe bene, se non fosse per un piccolo fatto che trovare e assumere brave persone è davvero molto difficile da fare e quando un'azienda trova la sua gemma, sta pianificando a lungo termine.

Ho visto le aziende assumere il loro ambito tecnologico e lo fanno per lo stesso motivo. Vogliono mettere le mani su grandi sviluppatori, anche se questo significa aspettare che si adattino alle nuove tecnologie.

Ora per la tua situazione. Come nuovo membro del gruppo, starei molto attento a ciò che dico e non dire ai miei superiori. Certo, te ne andrai molto partendo dal presupposto che sei ancora in un processo di adattamento al tuo nuovo ambiente. Tuttavia, l'indebolimento dell'autorità e la tenace perseveranza con la tua tecnologia preferita faranno solo pensare ai tuoi superiori che hanno fatto un errore a ingaggiarti e che non sei disposto a lasciare la tua zona di comfort.

Quello che sceglierai dipende da te, ma ti suggerirei di provare a imparare nuove tecnologie. Non farà male, lo prometto.

Assumerò che eri onesto di fronte durante la tua intervista sulla tua mancanza di conoscenza di C #, perché se non lo fossi allora potresti trovarti in una posizione molto precaria da un punto di vista legale.

I buoni programmatori conoscono la programmazione. Mentre nessuno può ovviamente essere esperto in tutte le lingue e le strutture, c'è una considerevole comunanza tra la maggior parte di loro. A meno che non ti venga chiesto di lavorare in un linguaggio che è molto diverso da quello che costituisce il mainstream in questi giorni (Lisp, ad esempio), allora un buon programmatore dovrebbe essere in grado di adattarsi.

Naturalmente c'è una curva di apprendimento. Se il datore di lavoro ti assolda, deve essere sicuro delle tue capacità di seguire quella curva in un ragionevole lasso di tempo (anche in questo caso, supponendo che tu fossi onesto per quanto riguarda non sapere C #). Il linguaggio C # prende in prestito pesantemente da Java e, più in generale, la maggior parte dei linguaggi di programmazione basati su classi sono fondamentalmente abbastanza simili (hai menzionato node.js, che si basa su ECMAScript, che è un linguaggio basato su prototipi, quindi sei ovviamente comodo con altri paradigmi di programmazione.

I bravi programmatori dovrebbero, oltre a essere flessibili, essere desiderosi di apprendere nuove cose. Nello sviluppo del software generalmente stai imparando o diventando irrilevante.

Ovviamente il tuo datore di lavoro, presumendo di sapere che non conoscevi C #, deve incontrarti a metà strada. Se mostri desiderio di imparare, devono darti il tempo e le risorse per farlo. Buttarti alla fine è ingiusto e inutilmente stressante. Devi sederti e avere una discussione calma e razionale con il tuo superiore. Se lo vogliono in C #, devono essere pronti ad accettare che sarai su una curva di apprendimento mentre ci lavori e sarebbe ingiusto per loro imporre scadenze ravvicinate. Se le scadenze non sono flessibili e se hanno un'importanza strategica elevata, devono essere pronte a concederti un po 'di libertà per portare a termine il lavoro entro tale scadenza. Se hanno bisogno che sia nella lingua più comunemente usata nel loro ufficio, allora puoi forse richiedere di implementarlo ora in ciò che conosci per rispettare la scadenza, e poi come il tuo prossimo progetto re-implementarlo in C # come esercizio di apprendimento e per allineare il software ai requisiti interni una volta che soddisfa quelli esterni. Come ho detto, la maggior parte delle lingue più comunemente usate oggi ha molto in comune, quindi si riferisce principalmente ai dettagli di implementazione.

Devi essere pronto ad accettare prima o poi che lavori in un negozio C # e quindi hai bisogno di avere C # sotto la cintura.

Forse non sono soddisfatti del modo in cui tutti utilizzano MVC nell'ambiente .NET. Potrebbe trattarlo troppo come un webform. Questo non è diverso quando qualcuno con un background procedurale inizia in OOP, mette tutto in una grande classe e procede con gli affari come al solito.

Questo primo progetto non è la situazione ideale perché lo desiderano così rapidamente. Ottieni la massima velocità su .NET il più possibile e inizia a sfornare le funzionalità il più velocemente possibile. Non ti piacerà il modo in cui stai facendo le cose, prova solo a tenere a mente che inizierai a ridefinire queste cose e ad applicare le tue abilità in un'altra lingua.

Speriamo che il tuo modo di usare MVC4 (supponendo che tutti gli altri non lo facciano proprio bene) in un altro stile di Ruby catturerà e allontanerà tutti dalla mentalità di Webforms.