I programmatori senior devono assumere e guidare un programmatore junior? [chiuso]

In un negozio che vuole essere affiatato e solidale, dovrebbe far parte della cultura che gli sviluppatori senior siano accoppiati con sviluppatori junior come mentori? O questo tutoraggio dovrebbe essere qualcosa di più organico e spontaneo, cioè non richiesto, ma che può svilupparsi senza incoraggiamento artificiale?

Penso che dovrebbe essere incoraggiato ma non richiesto; gli anziani non dovrebbero essere assegnati a ragazzi o cose del genere, altrimenti finirai nella terra di Dilbert. La relazione "mentore-allievo" richiede un certo livello di amicizia al suo interno, oltre a una buona dose di rispetto reciproco. Non lo capisci dicendo semplicemente alle persone di andare a "mentire".

dovrebbe far parte della cultura che gli sviluppatori senior siano associati a sviluppatori junior come mentori?

Sì.

organico e spontaneo, cioè non richiesto, ma permesso di svilupparsi senza incoraggiamento artificiale

Non succederà abbastanza spesso per aiutare davvero nessuno.

Le persone con relazioni esistenti nelle organizzazioni saranno percepite come cricche o elite da nuove persone. Le cricche non si rompono normalmente. Rimaniamo con le persone che conosciamo - è un elemento essenziale della natura umana.

Come consulente per oltre 30 anni (centinaia di impegni con i clienti) posso affermare che le nuove persone sono sempre estranee. Non è una caratteristica di "cultura" o "atmosfera". È una caratteristica essenziale di come le persone lavorano. I consulenti formano la propria cricca perché il personale stabilito non tende a includerli in nulla.

L'unico modo per stabilire il mentoring è quello di inserire nuove persone nelle cricche.

Il significato tradizionale di "mentore" in qualche modo sfida i compiti. Potresti anche provare ad assegnare amici.

Va bene, nella mia esperienza, assegnare a un nuovo membro del team di utilizzare un membro del team stabilito come contatto principale per domande durante la prima settimana, mese o così.

Gli sviluppatori senior dovrebbero essere tenuti a guidare gli sviluppatori junior?

Assolutamente no. Alcuni bravi sviluppatori senior diventeranno orribili mentori e l'abbinamento di personalità è un must per una nave mentore di successo. Penso, tuttavia, che gli sviluppatori senior dovrebbero essere tenuti a migliorare il team di sviluppo. Potrebbe essere la prototipazione di qualcosa sul lato, il miglioramento di un processo o di una pratica, il lancio di nuovi strumenti, la presentazione di materiale tecnico al gruppo, la guida di un team o qualcos'altro. In altre parole, dovrebbero avere la responsabilità di qualcosa di più grande della singola quota di lavoro.

O questo tutoraggio dovrebbe essere qualcosa di più organico e spontaneo, cioè non richiesto, ma che può svilupparsi senza incoraggiamento artificiale?

No, non sono d'accordo neanche con quello. Ho visto troppe situazioni in cui il mentoring dovrebbe essere "organico e spontaneo" e succede troppo raramente. Penso che le organizzazioni debbano assumersi la responsabilità di dare ai tutorati la possibilità di diventare contagiose, ma non possono essere forzate. È difficile, ma vale la pena. Penso che l'organizzazione potrebbe fare cose come:

• Incontri informali tra potenziali mentori e potenziali protetti
• Modi e opportunità suggeriti per il tutoraggio essere ufficialmente riconosciuti dall'organizzazione (ad esempio, se si è in un luogo che ha un numero di addebito per praticamente tutto, creare un numero di addebito per le riunioni della nave di guida - chiarendo che questo è una parte praticabile del lavoro )
• Formazione e supporto per i mentori
• guida ai proteges su come selezionare un mentore e cosa aspettarsi
• orientamento ai tutor su cosa aspettarsi e cosa offrire
• Schemi suggeriti (o applicati) per tutoraggi con modelli per la partecipazione - ad esempio, è molto più facile provarlo se sai in anticipo che il tuo obiettivo è un'esperienza di 3 mesi con incontri settimanali e l'obiettivo di aiutare un nuovo sviluppatore ad alzarsi e andare in compagnia. Per non dire che non si svilupperà in più ... ma dà un posto per iniziare la gente.

Penso che renderlo un requisito potrebbe potenzialmente ritorcersi contro, dato che alcune persone non sono cablate in questo modo e sarebbero molto disattivate dall'idea. Detto questo, dovresti identificare le persone che ritieni adatte a diventare mentori e affrontarle per assumere un ruolo più attivo nel tutoraggio (se non lo sono già). Questo approccio di esempio potrebbe prendere piede e ispirare un mentoring più spontaneo.

Potresti anche programmare attività di gruppo che si verificano regolarmente, che aiuteranno la squadra a gelare. Queste potrebbero essere attività completamente sociali, come un pranzo di gruppo, o attività che includono l'apprendimento della programmazione, come un club settimanale di libri di programmazione.

Potresti anche avere "mini postmortem" regolari sui sistemi, che funzionerebbero come una revisione del codice di gruppo. Uno dei vantaggi di fare la revisione in un ambiente di gruppo è che tutti possono trarre vantaggio dal feedback, piuttosto che solo dalla persona che ha scritto il codice originale. Potrebbe essere necessario trovare alcuni volontari che si sentano a proprio agio nel giudicare il proprio codice per iniziare le cose e assicurarsi di mantenere la propria civiltà.

Non mi sono mai piaciuti i termini programmatori Junior e Senior. Ad esempio, ho programmato per un po 'e anche se ho esperienza in alcune aree, sono molto verde in altre. Ad esempio, ci stiamo spostando su WPF e anche se ho tonnellate di esperienza nell'applicazione di Windows Form, WPF è ancora nuovo e mi è stato abbandonato. Quindi, sebbene io sia un programmatore "senior", potresti assumere qualcuno fuori strada con un'esperienza molto meno "totale" e probabilmente potrebbero programmare un'applicazione WPF migliore e più veloce di me a questo punto.

Per non dire che non ho molta esperienza nella progettazione di applicazioni e nell'architettura che potrebbe essere applicata all'applicazione WPF, ma conosco i miei limiti.

Immagino che devi essere disposto a diventare il mentore in alcune occasioni e l'allievo in altre.

Se hai membri del team che non hanno paura di essere il mentore quando hanno le conoscenze e un allievo agli altri quando hanno bisogno della conoscenza, avrai un'esperienza fruttuosa.

Se riesci a promuovere quel tipo di ambiente di sviluppo in cui gli sviluppatori sono umili e aperti a nuove idee e aiutano gli altri quando necessario, le relazioni sempai-kohai verranno fuori naturalmente.

Forzare il mentoring probabilmente creerà un sistema di caste che gli sviluppatori potrebbero risentirsi a vicenda. È meglio trattare tutti gli sviluppatori allo stesso livello.

Questo settore è molto diverso. La senorità non è sempre migliore.

A volte gli anziani devono essere guidati dai junior.

Sono stato in ambienti che fanno le cose in entrambi i modi.

Il primo lavoro che ho fatto fuori dalla scuola, mi è stato assegnato un mentore. Non mi piaceva il ragazzo, e certamente non ero d'accordo con lui su tutto. Mi sono risentito per essere stato costretto a lavorare con lui ed ero abbastanza sicuro che il mio datore di lavoro avesse commesso un errore, ma a posteriori ho imparato molto.

Velocemente avanti di qualche anno, e ora sto con un'azienda che tratta gli sviluppatori con un atteggiamento da uomo per sé. Gli sviluppatori hanno scadenze ravvicinate e pochi o nessun margine viene concesso agli sviluppatori che trascorrono del tempo a prendere gli altri sotto le ali per mostrare loro le corde. Penso sia un peccato. Vedo come gli sviluppatori junior lottano con le stesse cose che ho fatto, ma senza un mentore che li aiuti può impiegare molto più tempo.

Ho sviluppato la reputazione di "mentore" perché i nuovi assunti "sembrano apprezzare l'aiuto che sono in grado di fornire loro". Per quanto posso dire, questo è un modo stravagante per le risorse umane di dire che sono disposto a tollerare recensioni di produttività mediocri in modo da poter fare la cosa giusta, che è quella di consentire agli sviluppatori junior di svolgere il proprio lavoro in modo efficace e migliorare rapidamente.

Penso che sia quello che meritano i nostri dipendenti junior, e con il senno di poi e l'esperienza, penso che la prima azienda per cui ho lavorato, e quel ragazzo che mi ha guidato, avevano capito molto di più di quanto pensassi in quel momento.

Tutto questo è il lungo modo di dire che mentre vorrei che non dovessi assegnare mentori, è probabilmente l'unico modo giusto di diffondersi nel lavoro. Se non lo fai, dovresti dare alle persone che lo fanno il dovuto. Non è un lavoro facile; richiede sia capacità interpersonali che abilità ingegneristiche; ed è dispendioso in termini di tempo.

Gli sviluppatori senior dovrebbero andare oltre lo sfornamento del codice. Tuttavia, la direzione da seguire non dovrebbe essere la stessa per tutti gli sviluppatori senior.

Alcuni sono adatti al mentoring. Altri non lo sono e dovrebbero perseguire altri obiettivi di livello senior, sia che si tratti di pianificare e attuare miglioramenti dell'architettura, o di valutare nuove tecnologie, sia di pianificare e condurre miglioramenti di processo (ad esempio integrazione continua, TDD, ecc.)

Fondamentalmente, un anziano non dovrebbe essere solo qualcuno che ha tagliato il codice per alcuni anni in più rispetto ai junior. Dovrebbe essere qualcuno che è disposto e in grado di assumersi ulteriori responsabilità che contribuiranno al successo della squadra. Il mentoring junior è importante, ma non è l'unica cosa importante, e non è qualcosa per cui tutti sono adatti.

Mandare tale tutoraggio è controproducente perché gli esseri umani si sforzano in modo abbastanza naturale contro attività, azioni e relazioni forzate. Un approccio migliore è quello di premiare le persone che fanno un buon tutoraggio, inducendo così le persone a voler fare da mentore.

Ovviamente questo fa emergere il problema di misurare "buono" in questo contesto. Una soluzione imperfetta, ma facilmente implementabile potrebbe essere quella di far scrivere ai nuovi arrivati ​​dopo un anno (possibilmente in forma anonima) i nomi, diciamo, delle prime tre persone che li hanno aiutati a integrarsi nell'azienda e / o nella base di codice. Successivamente puoi premiare le persone i cui nomi vengono citati di più. I premi monetari non funzioneranno qui, tuttavia. È meglio trovare una sorta di ricompensa sociale.

il team guida la struttura, portando a revisioni del codice dovrebbe fare il trucco ...

Avresti un membro senior del tuo staff responsabile di uno o più junior. Non credo che dovrebbe essere un aiuto spontaneo, ma piuttosto un processo formale; nel senso che il membro senior sarà responsabile della qualità del lavoro prodotto dai nuovi arrivati. Questo approccio ha 2 vantaggi (almeno): istruire gli anziani sugli stili di gestione e assicurarsi che i giovani producano un codice di qualità.

In ogni cosa la programmazione dipende . Ma vorrei sicuramente che uno sviluppatore senior facesse da mentore a nuovi assunti, siano essi junior o meno, per ottenere loro la migliore formazione per il lavoro da svolgere.

No, perché ciò implicherebbe che il numero di sviluppatori senior e junior sarà sempre lo stesso. Potrei vedere incoraggiare quegli sviluppatori senior che vogliono diventare mentori, ma far rispettare un abbinamento potrebbe essere una pessima idea. L'idea di supportare le relazioni di tutoraggio è buona e non dovrebbe essere respinta qui.

L'incoraggiamento artificiale non è una cattiva idea qui. Dire a tutti gli sviluppatori junior e senior che saranno allievi e mentori, non importa cosa potrebbe essere un po 'religioso e fallire abbastanza rapidamente.

Se esiste un quadro noto all'interno dell'azienda su come gestire il tutoraggio sarebbe fantastico. Tuttavia, se ciò non esiste, la chiave diventa avere alcuni diversi tipi di momenti tra il mentore e l'allievo:

1. Stato attuale - Dove sono le cose adesso? Qual è la sfida attuale che il mentore può fornire assistenza nella risoluzione?
2. Stato futuro - Cosa si desidera: un suggerimento, una soluzione, domande da porre, chi porre?
3. Retrospettiva: cosa ha funzionato e non ha funzionato nel fare cambiamenti?
4. Cambiamenti futuri - Cosa verrà provato in futuro che potrebbe funzionare meglio di quanto fatto in precedenza?

Almeno quelli sono stati che posso vedere e dare un senso dal mio punto di vista ad adottare un approccio logico dall'alto verso il basso. Altri potrebbero desiderare qualcosa di molto più organico e in forma libera che possa funzionare anche. La chiave è avere un'idea di come far sì che ciascuna parte abbia alcune abilità che dovrebbero essere affinate attraverso la pratica di comunicare in questa relazione. Ciascuna parte dovrebbe ottenere qualcosa dalla relazione e dovrebbero esserci alcune regole di base comuni per avere questo tipo di relazione poiché il feedback è un grosso problema qui.

Quanto tempo si trascorre in questa è una domanda equa che realisticamente si deve guardare a ciò che viene fatto e fino a che punto è accettabile passare il tempo a sviluppare abilità e costruire relazioni. Ho potuto vedere alcune coppie che volevano un'ora alla settimana per passare attraverso questo mentre altri potrebbero desiderare un paio d'ore al giorno per coprire questo. Non dimenticare che possono esserci altre interazioni in cui un senior e un junior possono lavorare insieme anche se non all'interno di una relazione di mentoring formale.

Ho visto un paio di diversi tentativi di sistemi di tutoraggio. Quelli che mi piacevano di più erano quelli in cui lo sviluppatore senior aveva una serie specifica di compiti che svolgeva per aiutare lo sviluppatore junior, che ha spianato la strada al tutoraggio senza richiederlo. Ad esempio, un revisore dei codici uno a uno degli sviluppatori senior assegnato per i primi sei mesi potrebbe essere molto utile e potrebbe portare al tutoraggio. Quelli che non mi piacevano erano quelli che sembravano un lavoro extra e che non sembravano essere direttamente collegati al lavoro svolto - ad esempio, incontrare il tuo mentore assegnato per mezz'ora ogni settimana. Ciò è stato particolarmente fastidioso quando i due membri della relazione di tutoraggio generalmente non interagivano tra loro durante la settimana e non avevano nulla a che fare con i progetti reciproci. Sembrava molto forzato e permaloso piuttosto che concentrarsi sulla crescita professionale. L'ultima cosa che vuoi è che una relazione di tutoraggio si senta come una sessione di consulenza.

IME, non puoi fare affidamento sullo sviluppo di relazioni di tutoraggio, quindi fornendo un potenziale mentore accoppiando uno sviluppatore senior e uno sviluppatore junior per una serie di normali attività commerciali accoppiate (revisione del codice, debug, programmazione di coppia, ecc.), Almeno a in primo luogo, è un'ottima idea. Idealmente, il membro senior dovrebbe essere volontario per il ruolo e dovrebbe essere in grado di percepire alcuni benefici personali. Nella mia attuale azienda, gli sviluppatori senior sono quasi i lead per i loro progetti e il vantaggio è che stanno costruendo il proprio team di progetto. Nell'altra società, i mentori stavano spesso indagando sulla pista di gestione.

Penso che ogni azienda che assume giovani sviluppatori dovrebbe avere una sorta di programma di mentoring ragionevolmente efficace. Ma non sono sicuro che la posizione predefinita dovrebbe essere che ogni sviluppatore senior dovrebbe farlo per il semplice motivo che molti sviluppatori, indipendentemente da quanto siano bravi a sviluppare, sono pessimi nel mentoring. Si abbina purtroppo al territorio. Alcuni di noi non sono persone fantastiche, se vuoi.

D'altra parte, dove ci sono persone che sono brave a farlo, dovrebbero ottenerne il riconoscimento, e non punti neri perché il loro output di sviluppo reale diminuisce mentre stanno spiegando alcuni semplici problemi localizzati riguardanti, oh implementazione IDE per alcuni principianti che ha sempre utilizzato NotePad e Javac, ad esempio.

Ciò richiede una gestione equilibrata. Non sono sicuro che sia comune.

Affinché qualsiasi tutoraggio funzioni, è essenziale che la direzione riconosca che questo è importante e dedichi tempo a questo, e lo incoraggi attivamente!

Per chiunque al 100% prenotato con incarichi non c'è letteralmente tempo per fare o ricevere tutoraggio, e non accadrà.

Generalmente le navi mentore sono un buon trampolino di lancio per la transizione da un dirigente senior a un team leader o manager. È più efficace collegare il tutoraggio all'avanzamento in un PDP (piano di sviluppo personale) o qualsiasi piano di merito mai utilizzato dalla tua azienda. Legare il loro aumento di stipendio e lo sviluppo della carriera almeno in parte alla loro capacità di trasmettere conoscenze e governare i nuovi sviluppatori è la chiave per costruire un forte personale IT in grado di resistere ai cambiamenti nella gestione e nel turnover del personale. Fornire obiettivi chiave e lavorare con il personale per aiutarli a migliorare fa parte di quella crescita verso la leadership. Per coloro che pensano che non sia giusto legare una valutazione per anziani a una performance junior che fa parte della crescita. Nella maggior parte dei casi non stai parlando di un taglio delle retribuzioni ma piuttosto di un aumento ridotto o di un avanzamento rallentato.

Quando arrivai per la prima volta nella squadra, avevo il proprietario e uno sviluppatore principale che mi dava istruzioni. Potrei chiedere a nessuno dei due qualcosa ed entrambi risponderebbero. Tuttavia, ero abbastanza rispettoso da non continuare a disturbarli a meno che non riuscissi a capirlo in modo tempestivo.

Ha funzionato alla grande ma, di nuovo, probabilmente hai bisogno di persone simpatiche con un senso dell'umorismo per farlo funzionare.