Come affermato dal titolo, qual è la differenza in anni di esperienza in un determinato linguaggio in termini di sviluppatori? Ad esempio, se uno sviluppatore ha avuto cinque anni di lavoro con la lingua A e l'altro sviluppatore ha avuto due anni di lavoro con la lingua B seguito da tre anni di lavoro con la lingua A, ci sarebbe una differenza percepibile tra di loro?
Risposte:
"dipende"
Esperienza <> conoscenza o comprensione.
Il programmatore 1 potrebbe essere molto bravo, anche un guru, oppure potrebbero essere qualcuno che armeggia con la lingua negli ultimi 5 anni.
Il programmatore 2 potrebbe essere qualcuno che capisce i concetti indipendentemente dalla lingua che stanno usando. O qualcuno che ha trovato la lingua B troppo difficile e spera che A sia più facile.
Vale la pena leggere "The Years of Experience Myth" di Coding Horror
Dipende.
Ho un amico che tende ad attenersi a una lingua, quindi se lo consideri "programmatore A", ha 1 anno di esperienza con quella lingua, cinque volte.
Lingue diverse ti consentono di fare cose diverse. Un saggio che mi piace particolarmente si chiama " Beating the Averages " di Paul Graham. In esso sta cercando di convincere le persone ad imparare lisp, ma fa anche alcuni punti molto utili:
I programmatori si affezionano molto alle loro lingue preferite e non voglio ferire i sentimenti di nessuno, quindi per spiegare questo punto userò un linguaggio ipotetico chiamato Blub. Blub cade proprio nel mezzo del continuum dell'astrattezza. Non è il linguaggio più potente, ma è più potente di Cobol o linguaggio macchina.
E infatti, il nostro ipotetico programmatore Blub non userebbe nessuno dei due. Ovviamente non avrebbe programmato in linguaggio macchina. Ecco a cosa servono i compilatori. E per quanto riguarda Cobol, non sa come si possa fare qualcosa. Non ha nemmeno x (funzione Blub di tua scelta).
Finché il nostro ipotetico programmatore Blub sta guardando in basso il continuum di potenza, sa che sta guardando in basso. Le lingue meno potenti di Blub sono ovviamente meno potenti, perché mancano alcune funzionalità a cui è abituato. Ma quando il nostro ipotetico programmatore Blub guarda nella direzione opposta, nel continuum di potenza, non si rende conto di guardare in alto. Ciò che vede sono solo lingue strane. Probabilmente li considera equivalenti in termini di potere a Blub, ma con tutte queste altre cose pelose gettate pure dentro. Blub è abbastanza buono per lui, perché pensa in Blub.
Quando passiamo al punto di vista di un programmatore che utilizza una delle lingue più in alto nel continuum di potenza, tuttavia, scopriamo che a sua volta guarda in basso su Blub. Come puoi fare qualcosa in Blub? Non ha nemmeno y.
In generale, il mio consiglio è di imparare più di una lingua e di sapere quali sono i punti di forza e di debolezza delle lingue.
Naturalmente, lo sviluppatore che ha più anni di esperienza in una lingua avrà una migliore comprensione delle librerie di base e delle idiosincrasie di quella lingua. Se le lingue abbracciano lo stesso paradigma (imperativo vs funzionale), non dovrebbero avere più problemi a imparare quella lingua oltre a impararla.
La mia più grande difficoltà nel prendere una nuova lingua è stata provando a passare da C # a Erlang, perché rappresentava non solo una nuova sintassi ma anche un nuovo modo di pensare alla programmazione.
Ecco cosa mi aspetterei / spero:
Le lingue non sono il problema. Puoi imparare un'intera lingua in un paio di giorni. Ciò che richiede più tempo per assorbire sono le convenzioni, le API e vari framework di terze parti. Quando le persone chiedono cinque anni di X, non si preoccupano della lingua, vogliono qualcuno che abbia molta esperienza nella risoluzione dei problemi in e con quella lingua in modo da non dover pagare per nessuna delle curve di apprendimento.
Competenza e pratica deliberata.
Se non ti alleni deliberatamente, non acquisirai esperienza. (È necessario esaminare i propri errori e correggerli, esercitarsi in ciò che si è deboli e anche avere un esperto per dirti che cosa si sta facendo di sbagliato aiuta.)
Se non provi a migliorare, puoi essere un novizio per sempre!
Dopo diecimila ore di pratica deliberata, otterrai competenza. (Questa scoperta dall'istruzione / formazione è su tutta la rete.)
Se il tuo programmatore A non si è allenato deliberatamente, non miglioreranno mai.
Se il tuo programmatore B non si è allenato deliberatamente, non miglioreranno mai.
Un'altra scoperta della stessa ricerca: che se ho 15000 ore e tu ne hai 10000, e continuo a esercitarmi e anche a te, non sarai mai migliore di me.
Conoscere due lingue probabilmente renderà B un programmatore migliore (soggetto alle regole di pratica).
E li stai usando per la lingua A, suppongo? (Chiaramente, ci sarebbe una differenza nella lingua B.)
Dipende in parte dalle differenze tra A e B (in particolare se abbreviamo l'esperienza del secondo sviluppatore con A). Se sono abbastanza simili, non ci sarà sostanzialmente alcuna differenza nell'esperienza. Se A ha concetti notevolmente diversi, tre anni è ancora abbastanza probabile per impararli. Data una biblioteca molto ampia e strumenti complicati, potrebbe esserci una differenza tra tre e cinque anni.
Naturalmente, ciò che conta di più qui è l'individuo. Un bravo sviluppatore può imparare a fondo una nuova piattaforma in tre anni, e quindi questo non dovrebbe essere un problema.
Concordo sul fatto che la lingua è lingua e i concetti sono concetti.
Il mio problema è che al giorno d'oggi ci sono molti programmatori che senza un IDE sofisticato non potrebbero programmare affatto. Non sono davvero programmatori ma sono molto più simili ai designer.
So per esperienza personale che ci sono molte persone che sono state sedotte dall'ambiente di sviluppo Microsoft ingannevole. Non è sbagliato che rilasciano una casella di testo sullo schermo, quindi impostano le proprietà con la procedura guidata e trascinano i dati da un'immagine del database, ma sono davvero programmatori in qualsiasi lingua se tutto ciò che fanno è impostare test di uguaglianza di base?
Quelle persone non saranno mai in grado di prendere i concetti che hanno imparato e applicarli in un'altra lingua.
Quando intervisto la gente, sono più interessato a come hanno fatto il loro sviluppo e quali framework hanno usato. Mi piace fare domande del tipo "Come si scrive un gestore eventi?", "Come si inseriscono esattamente i dati nel database?", O anche "Come si fa a trasformare questo particolare pulsante viola quando si fa clic su di esso?" questo eliminerà rapidamente i progettisti e lascerà i programmatori. Ho scoperto che 3 o 4 anni in realtà la programmazione con un anno nella mia lingua prescelta è sufficiente per ciò di cui ho bisogno.
Solo un'altra opinione
Tal
"Anni di esperienza in X lingua / piattaforma" è in gran parte una patologia di reclutamento ...
È aperto all'interpretazione e non è per nulla utile quanto sembra a prima vista. Come è stato detto, il mito degli anni di esperienza è una buona lettura.
Inoltre, la misurazione di "anni di esperienza" stessa può essere molto imprecisa. Ecco un esempio del mio attuale concerto: il mio compito principale è sviluppare e mantenere un'app Web Java. Tuttavia, questo esegue un back-end che è MFC / C ++ / SQL Server. Di conseguenza, ho a che fare con il codice C ++ anche su base praticamente giornaliera. MA - questa esperienza in C ++ è relativamente superficiale e orientata alla manutenzione, e in realtà non scrivo più interi componenti o programmi di grandi dimensioni da zero in MFC / C ++ (però ero solito nei ruoli precedenti).
Posso ancora considerare questi ultimi 5 anni come "5 anni di esperienza in C ++"? Può essere. Forse no. A seconda di come voglio venderlo per ottenere un ruolo particolare, posso facilmente esagerare senza mentire apertamente, o posso ammettere che non è stato davvero un solido "5 anni di esperienza in C ++". :) Sono sicuro che molti casi là fuori sono allo stesso modo aperti a questo tipo di problema di "imprecisione della misurazione". La profondità dell'esperienza può offuscare gravemente la qualità dell'esperienza. Quindi un "X tempo trascorso con C ++" non significa molto in sé.
Sì, il programmatore 1 non ha alcuna conoscenza della sintassi della lingua B.
I concetti di programmazione sono concetti di programmazione. La lingua è semplicemente sintassi.