Nuove attività per sviluppatori senior

Ho uno sviluppatore senior con otto anni di esperienza .NET a partire da domani per lavorare su un'applicazione da 11.000 righe di codice. Nella squadra ci sono io e un altro programmatore. Entrambi abbiamo 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 mai dovuto presentare qualcuno a una base di codice già stabilita. Ovviamente esaminerò ogni modulo, il processo di distribuzione, ecc., E consegnerò loro la posizione del repository di controllo del codice sorgente, la documentazione (che non è la migliore), ecc.

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

Assegnerei un paio di bug a bassa priorità il primo giorno, in questo modo nessuno urla 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 non sta seguendo gli standard di codifica dell'azienda da mesi a cose. È 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 (esaminiamo il 100% del nostro codice prima della distribuzione), ma sono fondamentali per i nuovi dipendenti e dovrebbero essere fatte di persona in cui è possibile rispondere alle domande e indirizzarle alla documentazione che potrebbero non avere visto ancora se necessario.

Quello che non vuoi è un nuovo ragazzo che entra e usa uno stile diverso dal resto di te. Le persone spesso cercano di continuare a utilizzare lo stile di codice del loro lavoro precedente anche quando è in conflitto con lo stile di codice utilizzato nel nuovo posto, il 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 nel colloquio, la revisione del codice ti aiuterà a scoprirlo velocemente, quindi puoi risolverlo. Li incoraggerà anche a fare effettivamente qualcosa, ho visto nuovi dipendenti che non sono stati sottoposti a revisione del codice a trascinare fuori un progetto senza mostrare ciò che stavano facendo a nessuno e poi sono partiti una settimana prima della scadenza che sapevano che non avrebbero colpito perché erano sopra le loro teste e in realtà non avevano completato alcuna parte del progetto. Meglio controllare presto e spesso con nuove persone fino a quando non si è davvero sicuri che stiano funzionando.

Inoltre, è normale che il nuovo ragazzo rimanga sconvolto dallo stato del tuo progetto legacy. Non è progettato come pensa che avrebbe dovuto essere. Aspettati questo, ascoltalo e non respingere automaticamente tutto ciò che dice. In particolare, questa persona sembra avere più esperienza di te o degli altri sviluppatori, potrebbe vedere cose che non avevi considerato. Tuttavia, come manager, devi bilanciare le modifiche proposte con il carico di lavoro e le scadenze attuali. Tutti voi potreste voler investire un po 'di tempo nell'apprendimento del refactoring del codice esistente e investire alcune ore nelle vostre stime del tempo per farlo, specialmente se il nuovo ragazzo ha delle preoccupazioni valide. Probabilmente non puoi supportare una riscrittura totale (molte persone che arrivano nuove pensano che dovremmo ricominciare da capo e farlo meglio),

Se hai un po 'di tempo in cui non ci si aspetta che stia contribuendo completamente (e tenendo pienamente conto del suo tempo da parte del cliente), potrebbe anche essere un momento in cui può iniziare su alcune di quelle cose di refactoring che avresti voluto fare ma non hai avuto " non ho avuto tempo di fare. A volte, è una buona cosa usare il periodo di formazione per nuove persone 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 hai ancora incluse nella pianificazione esistente. E se funziona, potresti avere una grande vittoria rendendo la manutenzione futura più semplice o migliorando la sicurezza o qualunque sia il problema.

Avviali immediatamente per piccoli compiti, cose che non richiedono un quadro più ampio.

Man mano che acquisiscono maggiore sicurezza e familiarità con la base di codice, portali a compiti sempre più grandi. La velocità con cui ciò accade dipende principalmente da loro.

Mi piace sempre ottenere compiti assegnati a me subito, 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 farmi avvolgere completamente la testa attorno a un progetto fino a quando non devo davvero entrare e riparare o cambiare qualcosa.

Inoltre ... Non importa quanto pensi di aver spiegato come funziona un progetto, c'è sempre il "oh sì, ho dimenticato di dirtelo", "ci siamo imbattuti in questo problema, quindi abbiamo fatto questo" momenti che non vengono presi in giro fino a quando in realtà inizi a lavorare.

Per quanto?

Quanto dura una corda?

Quando si sente a suo agio: quando corregge il suo primo bug -> è pronto .

Nella comunità open source, tutti coloro che volevano unirsi al progetto prima affrontano alcuni piccoli problemi. Se lui o lei è in grado di gestire il problema molto bene, gli verrà assegnato il compito più importante. In questo modo, sarebbero diventati uno sviluppatore principale del progetto.

Questo sviluppatore senior ha otto anni di esperienza in .NET, quindi puoi assegnargli alcuni semplici bug da correggere. Se è facile per lui gestirli, potresti assegnargli problemi complessi per aiutarlo a familiarizzare con l'intera applicazione. Successivamente, potrebbe iniziare a scrivere nuove funzionalità e ad analizzare strani problemi. Fallo e basta, non c'è tempo di installazione!

8 anni di esperienza. Vorrei solo buttarlo dentro. Dovrebbe essere in grado di nuotare. Come altri hanno notato, iniziare 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 ho contribuito a tutti loro entro la prima settimana. Il più difficile mi ha richiesto una settimana per compilare il codice (almeno 100k + righe di codice). Una build completa ha richiesto 8 ore per quel progetto.

Ho lavorato per circa 80 ore la prima settimana (il progetto era seriamente indietro).

Per un'app così piccola e uno sviluppatore che ha sperimentato, penso che un giorno sia sufficiente per i bug di base. Bug coinvolti o piccole funzionalità più vicini a una settimana (una volta chiariti il ​​dominio e l'architettura problematici).

La risposta è, dipende. Se vuoi che risolva un off da un errore su qualcosa o cambi il colore di un elemento 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 davvero dal compito che ti aspetti che esegua.