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.