Nuovi compiti per gli sviluppatori senior

21

Ho uno sviluppatore senior con otto anni di esperienza .NET a partire da domani per lavorare su un'applicazione di 11000 righe di codice. Nella squadra ci sono io e un altro programmatore. Abbiamo entrambi circa tre anni di esperienza ciascuno.

È il mio primo progetto come manager (sono anche uno sviluppatore del progetto) e questa è la prima volta che ho dovuto introdurre qualcuno a un codice base già stabilito. Ovviamente andrò su ciascun modulo, sul processo di distribuzione, ecc. E passerò loro il percorso del repository di controllo del codice sorgente, la documentazione (che non è la migliore), ecc.

Quanto tempo dovrei dargli prima che siano pronti per iniziare a scrivere nuove funzionalità e correggere bug?

    
posta MrBliz 09.05.2012 - 15:34
fonte

8 risposte

38

Assegnerei un paio di bug a bassa priorità il primo giorno, in questo modo nessuno sta urlando se non viene fatto subito dando al nuovo sviluppatore un po 'di tempo per familiarizzare con la base di codice.

La cosa più importante da fare è avere una revisione del codice di tutto il suo lavoro nelle prime due settimane. Non vuoi scoprire che il ragazzo sta andando nella direzione sbagliata o che non segue gli standard di codifica della compagnia per mesi. È meglio assicurarsi che sappia cosa ci si aspetta dall'inizio, e le revisioni del codice lo garantiscono. Naturalmente penso che le revisioni del codice siano valide per tutti i dipendenti (rivediamo il 100% del nostro codice prima della distribuzione), ma sono fondamentali per i nuovi dipendenti e dovrebbero essere fatte di persona dove è possibile rispondere alle domande e indirizzarle alla documentazione che potrebbero non avere visto ancora se necessario.

Ciò che non vuoi è un nuovo arrivato e usa uno stile diverso dal resto di te. Le persone spesso cercano di continuare a utilizzare lo stile del codice del loro precedente lavoro anche quando è in conflitto con lo stile del codice utilizzato nel nuovo posto che può creare confusione e fastidio da parte degli altri sviluppatori.

Una cosa che ho notato anche con sviluppatori esperti è che alcuni di loro non sono così buoni come sembravano essere nell'intervista, la revisione del codice ti aiuterà a scoprirlo velocemente, in modo da poterlo risolvere. Li incoraggerà anche a fare qualcosa, ho visto nuovi dipendenti che non sono stati sottoposti a revisione del codice trascinare un progetto senza mostrare quello che stavano facendo a nessuno e poi lasciare una settimana prima della scadenza che sapevano che non avrebbero colpito perché erano fuori di testa e non avevano effettivamente completato nessuna parte del progetto. Meglio controllare presto e spesso con nuove persone fino a quando non sei veramente sicuro che stiano funzionando.

Inoltre, è normale che il nuovo ragazzo sia sconvolto dallo stato del tuo progetto precedente. Non è progettato nel modo in cui pensa che avrebbe dovuto essere. Aspettalo, ascoltalo e non licenzia automaticamente tutto ciò che dice. In particolare, questa persona sembra avere più esperienza di te o degli altri sviluppatori, potrebbe vedere cose che non hai considerato. Tuttavia, come manager, devi bilanciare le modifiche proposte con il carico di lavoro e le scadenze attuali. Tutti voi vorrete investire un po 'di tempo nell'imparare come rifattorizzare il codice esistente e investire alcune ore nelle vostre stime di tempo per farlo, specialmente se il nuovo ragazzo ha delle preoccupazioni valide. Probabilmente non puoi supportare una riscrittura totale (molte persone che pensano che dovremmo ricominciare da capo e farlo meglio), ma puoi creare un piano di refactoring per risolvere il peggiore dei problemi se ce n'è uno che porta up.

Se avete un po 'di tempo in cui non ci si aspetta di essere pienamente contribuire (e completamente la contabilità per il suo tempo dal cliente), ma potrebbe anche essere un momento in cui si può iniziare su alcune di quelle cose refactoring che avete voluto fare ma non ho avuto tempo di fare. A volte, è una buona cosa usare il nuovo periodo di formazione della persona per affrontare alcune cose che non sono nel piano del progetto. Possono imparare la base di codice e se ciò che vogliono fare non funziona, non hai influenzato le pianificazioni esistenti perché non le avevi ancora inserite nel programma esistente. E se funziona, potresti avere una grossa vincita rendendo la manutenzione futura più facile o la sicurezza migliore o qualunque sia il problema.

    
risposta data 09.05.2012 - 16:11
fonte
18

Avvia subito le attività più piccole - cose che non richiedono l'immagine più grande.

Man mano che acquisiscono maggiore sicurezza e familiarità con il codebase, li diplomano in compiti sempre più grandi. Quanto velocemente ciò accade dipende principalmente da loro.

    
risposta data 09.05.2012 - 15:37
fonte
8

Mi piace sempre ottenere compiti assegnati a me a destra, con la consapevolezza che ci vorrà molto più tempo per scavare nel codice e molte domande verranno poste durante i primi giorni / settimane.

Trovo che non sono in grado di ottenere completamente la mia testa attorno a un progetto finché non devo effettivamente entrare e correggere o modificare qualcosa.

Inoltre ... Non importa quanto tu pensi di aver spiegato come funziona un progetto c'è sempre il "oh yeah ho dimenticato di dirtelo", "ci siamo imbattuti in questo problema, quindi abbiamo fatto questo" momenti che non sono preso in giro fino a quando non inizi effettivamente a lavorare.

    
risposta data 09.05.2012 - 15:38
fonte
3

How long?

Quanto è lunga una corda?

When he is comfortable: when he fixes his first bug -> he is ready.

    
risposta data 09.05.2012 - 15:38
fonte
3

Nella comunità open source, tutti coloro che volevano aderire al progetto si occupano prima di alcuni piccoli problemi. Se lui o lei è in grado di gestire il problema molto bene, l'attività più importante sarà assegnata a lui o lei. In questo modo, diventerebbero uno sviluppatore principale del progetto.

Questo sviluppatore senior ha otto anni di esperienza su .NET, quindi potresti assegnargli alcuni semplici bug da correggere. Se è facile per lui affrontarli, potresti assegnargli problemi complessi per aiutarlo a familiarizzare con l'intera applicazione. Dopo di ciò, potrebbe iniziare a scrivere nuove funzionalità e analizzare problemi strani. Fallo, non c'è tempo di configurazione!

    
risposta data 16.05.2012 - 09:23
fonte
2

8 anni di esperienza. Lo butterò dentro. Dovrebbe essere in grado di nuotare. Come altri hanno notato iniziano con piccoli compiti facili. Gli permetterà di armeggiare attraverso il processo di check-in / check-out del codice e qualsiasi altro processo di sviluppo che hai.

Ho cambiato lavoro molte volte e sono stato un contributore in tutti loro nella prima settimana. Il più difficile mi ha richiesto una settimana per ottenere il codice da compilare (almeno 100k + linee di codice). Una costruzione completa ha impiegato 8 ore per quel progetto.

Ho lavorato qualcosa come 80 ore la prima settimana (il progetto era seriamente in ritardo).

    
risposta data 09.05.2012 - 21:23
fonte
1

Per un'app di piccole dimensioni e uno sviluppatore che ho sperimentato, penserei che un giorno sia sufficiente per i bug di base. Bug o funzionalità complicate più vicine a una settimana (una volta che sono più chiari sul dominio del problema e sull'architettura).

    
risposta data 09.05.2012 - 15:38
fonte
1

La risposta è: dipende. Se vuoi che risolva un errore con qualcosa o modifichi il colore di un elemento della GUI, quindi circa 5 minuti (qui è dove conserviamo il nostro codice), se vuoi una riprogettazione totale dell'intera architettura dell'app che richiede un po 'di più.

Dipende molto dal compito che ti aspetti che esegua.

    
risposta data 16.05.2012 - 09:49
fonte

Leggi altre domande sui tag