Quanti juniores dovrebbero avere un mentore senior? [chiuso]

Ovunque da 0 a 5 o 7 (o così).

Argomenti per il lato inferiore:

• Non tutti sono determinati a diventare mentori. Ho lavorato con alcuni sviluppatori che erano così burberi che avrebbero spaventato qualcuno in una nuova carriera.
• Se ti aspetti che gli sviluppatori senior mantengano lo stesso livello di output, tieni il numero basso.

Argomenti per un importo superiore:

• Alcuni sviluppatori hanno la capacità di essere altrettanto produttivi guidando il lavoro degli altri. La programmazione delle coppie sarebbe un esempio. Se hai quei tipi magici di sviluppatori senior, vai avanti e dagli altri.
• Se sei disposto a ridurre l'output atteso dallo sviluppatore senior, puoi assegnare ad altri sviluppatori junior.
• Se hai uno sviluppatore che è veramente bravo nell'insegnare loro perché è di governance, allora puoi esplicitamente voler prendere un colpo nella produttività di quel senior dev e dare loro degli sviluppatori più giovani. L'idea qui è un costo a breve termine (perdita di produzione) per un guadagno / investimento a lungo termine (migliore conformità agli standard di sviluppo della squadra).

Vorrei incoraggiare una conversazione con gli sviluppatori senior e vedere con cosa sono a loro agio. Non tutti vogliono essere mentori. Ricorda inoltre di utilizzare l'analogia "full bookshelf": i loro carichi di lavoro sono al momento completi. Se hai intenzione di aggiungere al loro carico di lavoro facendoli diventare mentori, allora devi prendere qualcos'altro dallo scaffale per fare spazio.

Non più di due per sviluppatore senior, se stai assumendo persone direttamente al college. I neolaureati con cui ho avuto a che fare in passato hanno una buona conoscenza delle basi, ma non avevano idea di cosa significasse programmare nel mondo degli affari. Dovrai dedicare del tempo a insegnare loro come programmare professionalmente, è piuttosto uno shock quando si rendono conto che dovranno sostenere il codice scritto per tutto il tempo in cui sono con la compagnia, non più incarichi di svolta e andare avanti. Ma dovrai anche dedicare del tempo a insegnare loro il tuo business (e tutte le sue regole), insegnare loro come codificare la tua architettura, rivedere il loro codice, insegnargli come testare e rispondere a domande dopo domanda dopo domanda. Entrambe le volte in cui mi è stato chiesto di essere mentore di un junior ho trascorso almeno metà del mio tempo alla loro scrivania per i primi due mesi.

Se hai un sacco di juniores in arrivo, diciamo > 30, potrebbe valere la pena dedicare uno sviluppatore senior a fare da mentore a tempo pieno. Al mio primo impiego hanno assunto molti di noi appena usciti dal college e avevano un membro del team dedicato che ci aiutava a imparare le corde per i primi 6 mesi. Ha reso la transizione molto più semplice e ci ha insegnato molto.

Non solo è più efficiente avere una persona che gestisce il lavoro, potrebbe esserci una singola persona nel tuo ufficio che sai sarebbe un mentore perfetto. Un buon programmatore non è necessariamente un buon insegnante.

Tanti più che possono, pur essendo in grado di portare a termine il proprio lavoro in tempo.

La risposta, quindi, dipende da quanto sia efficace l'anziano sia come sviluppatore sia come insegnante.

Non parli del tipo di lavoro del progetto che nella mia esperienza ha un enorme impatto su dove dovrebbe essere quel rapporto.

Su una scala di ripetizione di cookie-cutter che potrebbe essere quasi automatizzata per cose sperimentali che lo sviluppatore non è nemmeno sicuro funzionerà, devi assicurarti di mantenere gli jr devs a sinistra a meno che tu non abbia un rapporto veramente basso e ancora più rigorosamente a sinistra se gli sviluppatori di sr stanno cercando di fare qualcosa che considerano alla fine sperimentale dello spettro perché di solito non saranno altrettanto efficaci mentre vanno in gregge su una squadra di jr devs se si stanno impegnando a fondo allo stesso tempo.

Dipende dal lavoro tanto quanto le persone secondo me.

Il mentoring è meno formale della gestione. I mentori non sono direttamente coinvolti nell'assunzione, licenziamento, revisione e disciplina. L'ambiente sarà un fattore importante. Ecco i fattori da considerare:

• qualità di sr. e jr. devs
• il modo in cui viene gestita / gestita la società dai programmatori (ciò aggraverà gli altri problemi)
• sr. dev carico di lavoro corrente
• le aspettative del management su quanto velocemente il jr. gli sviluppatori devono diventare produttivi
• altre risorse di formazione (corsi con istruttore, materiali di riferimento, requisiti di certificazione)
• affitto per adattarsi al team. Molte volte in questo sito le persone hanno menzionato l'importanza della squadra necessaria per ottenere un lungo periodo e poter lavorare insieme. Qualcuno con un livello di abilità più alto potrebbe aver bisogno di più tutoraggio se non si adatta.

Il mentoring di solito comporta un certo livello di legame e non credo che la maggior parte delle persone possa costruire qualsiasi tipo di relazione interpersonale con più di 3-5 persone in un dato setting.

Idealmente un junior lavora con un mentore su un progetto. In questo modo l'anziano può assegnare compiti secondari e lavorare con loro verso il completamento di un progetto. Più junior il Senior deve gestire meno lavoro gli anziani saranno in grado di completare da soli. Non vorrei più di 1 o 2 junior che lavorano con un senior in qualsiasi momento. Anche se l'anziano può continuare a guidare altri programmatori dopo 2 o 3 mesi, un programmatore decente dovrebbe aver bisogno di molto meno tempo rispetto a quello che aveva inizialmente. Quindi un anziano potrebbe concepibilmente avere 20 o più persone per le quali è mentore, ma in realtà solo 2 o 3 che richiedono davvero molto del loro tempo.