"Mentore" un programmatore o collega anziano senza insulti

Personalmente, non posso sopportare domande che iniziano con "Perché non tu" ... Come "Perché non usi i farmaci generici per questo?". Come dovrei rispondere? O "perché ho una buona ragione per non farlo", o "perché non sono intelligente come te e non ci ho pensato".

Invece, mi piacciono i suggerimenti "Hai provato ...". "Hai provato a rendere quella classe generica?". Quindi la risposta è "no non ho, dimmi di più".

Chiedere in questo modo non presuppone nulla. Non stai presumendo di conoscere la risposta giusta o di essere in grado di guidare l'altra persona. Stai semplicemente iniziando una conversazione.

Modifica

Vorrei chiarire qualcosa in risposta ad alcuni commenti e ad altri post. L'idea qui è più di una semplice riformulazione di una domanda per evitare di premere i pulsanti di qualcuno. L'idea è di iniziare una conversazione con un collega piuttosto che affrontarlo con una differenza di opinioni. Ci sono molti modi sottili per farlo. Come ha sottolineato qualcun altro, riformulare una domanda da "Why not not" a "Why you you" ha lo stesso effetto. Stai facendo una domanda legittima su una decisione presa dall'altra persona, invece di far valere le tue idee. Ricorda - potrebbe esserci una buona ragione per cui l'altra persona ha fatto qualcosa in un certo modo, e tu potrebbe essere quello che sta imparando qualcosa di nuovo oggi.

Certamente dovremmo essere altrettanto consapevoli di questo quando siamo dall'altra parte della scrivania. Quando un pari chiede ciò che interpretiamo come una questione di confronto, dovremmo rispondere in modo costruttivo. Non dare per scontato che tutti gli altri facciano lo stesso.

La chiave non deve essere nella "mentalità di mentoring". Con questo intendo, se provi un sentimento di umiltà riguardo alle tue idee e ai tuoi suggerimenti, allora non lo chiameresti mentoring, lo chiameresti discutere. C'è una presunzione lì che tu sei l'insegnante e loro lo studente. Se ti avvicini alla situazione con una mentalità egualitaria come un pari, le tue idee saranno molto più appetibili.

Inoltre, non mi piace molto la risposta più popolare attuale qui .. Cambiare la formulazione di come dici qualcosa in modo da apparire meno conflittuale (cioè "Hai provato ..." vs "Perché non ...") è molto più fastidioso del semplice essere diretto. È passivo-aggressivo. Ugh. Gli sviluppatori di software vedono esattamente questo tipo di cose.

Credo che il mio punto sia che se la tua umiltà non è sincera, allora non importa quello che fai, sarà offensivo. Più cerchi di indirizzare intorno a questo, più fastidioso sarà per il ragazzo che stai "mentoring".

Preferisco il metodo più semplice possibile. Adoro la frase "Why do not you .." perché arriva al punto. Tu, il recensore, guarda il codice e crea la domanda nella tua mente. "Perché non l'ha fatto come avrei fatto io?" Quindi, lo sviluppatore può rispondere alla vera domanda "Perché non l'hai fatto in modo XYZ?" e può semplicemente spiegare perché ha scelto di farlo in modo diverso, piuttosto che dover fare l'inventario di tutte le cose che potrebbe o non potrebbe aver provato, senza alcuna spiegazione sul motivo per cui dovrebbe anche pensarci o provarlo ...

Quando mi trovo in questa situazione, ad esempio, in una revisione del codice, o quando incontro un codice Elses di qualcuno che non è quello che mi aspetto, mi assicuro di sapere perché mi oppongo prima. Mi assicuro di avere una serie di motivi e un'opinione su una soluzione migliore coerente con tale ragionamento. Poi dirò "Ho notato che stai facendo XYZ nella classe ABC. Questo non sembra il modo migliore per farlo, a causa di [ inserire i motivi qui ]. Per evitare questo problema , Di solito faccio [ inserire opinioni qui ]. Cosa ne pensi? C'è una ragione per cui invece stai facendo in quel modo? "

Quindi ora il mio collega ha delle ragioni, una soluzione e un'opportunità per spiegarmi perché la mia soluzione potrebbe non avere lo stesso senso del loro. Ciò potrebbe comportare una lunga conversazione in cui scopriamo che ho sbagliato, che avevano torto o che entrambe le soluzioni erano sbagliate. Nel processo impariamo tutti qualcosa.

Quindi, suppongo che la mia risposta su una sola riga sia: "Non fare da mentore, spiegare o dire a qualcuno cosa fare, offrire le tue osservazioni e soluzioni e discuterle da pari a pari". Se non riesci a entrare in quella mentalità, farai incazzare la gente, non importa quanto tu sia giusto.

finché il tuo ego è investito nel tuo codice, non sarai né un buon mentore né apprezzerai il mentoring degli altri

l'umiltà è una virtù, specialmente negli altri; -)

seriamente, se non vuole essere mentorato non puoi farglielo accettare. Se devi fare "suggerimenti utili", fallo tranquillamente e solo una volta, poi lascia perdere. Se lo studente è pronto, tornerà per altri.

EDIT: Approvo caldamente l'ammonimento di Troy a non essere nella "mentalità di mentoring" perché questo ti colloca su un piano sopra il tuo collaboratore, il che può essere negativo per le relazioni di squadra, anche se è fatto solo nella tua testa e temporaneamente . "Discutere questioni tecniche come uguali" è un eccellente consiglio. A questo aggiungo "scegli le tue battaglie", cioè non prendere in considerazione ogni piccola cosa, ma concentrati solo sugli errori potenzialmente gravi o sulle tecniche discutibili.

Se pensi che qualcosa non va, fai una domanda su quel pezzo di codice dove, per il quale la risposta include l'errore. Fallo in modo educato e onesto e non prendere in giro la risposta. Preparati a fare un'altra domanda quando il tuo collega non ha capito il punto.

D: Perché stai usando un Hashmap qui?

A: Perché qui è ... ehm ... aspetta un minuto ... questo è sbagliato!

In questo modo sei molto sicuro. Se ti sbagliavi, sembra che tu abbia appena fatto una domanda e che tu abbia ottenuto l'anser in modo da poter pensare e parlare dell'argomento. Se avevi ragione, hai anche una risposta e un'opportunità per capire insieme la soluzione.

I commenti iniziano i litigi. Le domande iniziano le conversazioni.

Direi che hai fatto il primo passo: riconoscere che buone relazioni con altri sviluppatori sono importanti. Molti sviluppatori non se ne rendono conto e molti decidono che non vale la pena di imparare come fare da mentore / diretto.

Ho avuto l'opportunità di lavorare con molti sviluppatori nel corso degli anni, alcuni dei quali senior, soprattutto junior. Penso che ogni sviluppatore senior abbia a che fare con il riflesso "Non ho tempo per questo n00b" durante il tutoraggio.

Sarò il primo ad ammettere che non ho sempre fatto un buon lavoro durante il tutoraggio. Ho trovato il successo con alcune abilità di comunicazione di base:

1. ASCOLTARE. Il tuo compito come mentore è capire il livello della comprensione del tuo pari e identificare dove la sua comprensione è incompleta.
2. Guida con l'esempio. Se disponi di un esempio di codice che offre una soluzione, fornisci una spiegazione.
3. Conosci i limiti del tuo pari. Se non sono ricettivi alle tue critiche, non offrirlo. Se sono un rapporto diretto e non rispondono in modo coerente alle recensioni del codice, potresti aver preso una decisione ingannevole.
4. Evita le dichiarazioni "tu" - "hai fatto un errore", "devi risolvere questo problema". Questo può sembrare cliché e sciocco, ma aiuta a esprimere la tua critica in generale: "Questo dovrebbe essere X anziché Y." "X è un errore comune, Y funziona meglio."
5. Condividi i tuoi metodi. Se sei particolarmente bravo in qualcosa, cioè modelli di design, ricerca, un particolare framework, documentalo e mandalo in giro. Aiuta se sei la PMI riconosciuta per l'argomento.
6. Sii specifico. Non dire semplicemente "non funzionerà", spiega perché pensi che un modo diverso sarebbe meglio.

Rimanere aperti alle critiche può essere difficile- penso che questo sia dovuto al fatto che, come stiamo discutendo, è difficile offrire critiche costruttive senza sembrare condiscendenti. Penso che sia molto utile ricevere critiche se hai già onestamente e forse criticato duramente il tuo stesso lavoro. Quando qualcun altro indica un difetto che hai già identificato (e sappiamo tutti che non esiste software impeccabile!) È molto meno emotivo. Oltre a ciò, cerco di valutare con calma le critiche che ricevo, decidere se ha qualche merito e andare avanti di conseguenza. Non devi essere d'accordo con i tuoi critici, e non devi sempre dirgli quando non sei d'accordo. Sorridi e annuisci, tutti sono critici! :)

Questa è una preoccupazione comune, e giustamente. È una sensazione strana dover dare un feedback a qualcuno nell'ambiente di lavoro. Questi non sono sempre i tuoi amici, con i quali puoi scherzare. Molte persone prendono molto sul serio il feedback, poiché potrebbero sentirsi minacciati o preoccupati di perdere il lavoro.

È molto importante stabilire relazioni positive con i tuoi colleghi di lavoro. Fare questo richiederà uno sforzo da parte tua. Avrai bisogno di avere una comprensione generale della personalità di ogni persona. Io stesso sono relativamente tranquillo; Continuo a me stesso per la maggior parte. Alcuni dei miei più stretti collaboratori sono esattamente l'opposto: sono persone molto estroverse. Se capisci come vogliono essere trattati, questo ti permetterà di stabilire buone relazioni.

Alcune persone entrano nelle riunioni e vogliono entrare nel business. Dammi i fatti, risparmia la peluria. Altre persone (e queste potrebbero essere persone nello stesso incontro) sono molto orientate alle persone e hanno difficoltà a concentrarsi prima di fare il loro 'come è stato il tuo fine settimana'. A ciascuno il suo. Spesso è abbastanza difficile cercare di riunire queste persone per raggiungere un programma comune.

Quello che sto cercando di dire è questo: non esiste una formula per come trattare le persone o dare loro un feedback. Me? Mi piacerebbe sentire "hey man, capisco che tu sei una risorsa preziosa, ma potresti provare a fare il tuo lavoro in questo modo invece che in quel modo. Ecco perché." Tuttavia, alcune delle persone a cui ho avuto la mente avevano bisogno di essere più coinvolte in una conversazione. "Bob, potresti spiegarmi perché lo stai facendo in questo modo? Aiutami a capire la logica implicata qui, non l'ho mai visto prima." Quindi, magari, suggerisci modi diversi, se pensi che i tuoi metodi siano migliori.

Ultimo e più importante: se qualcuno ti sta frustrando, fai una passeggiata lungo il corridoio! Sembra ovvio ma funziona. Niente più pugni in faccia!

Quindi questa domanda sembra avere tre parti:

1. Come fai a criticare le persone senza offenderle? Si tratta di renderlo sicuro per l'altra persona. Dare loro spazio per salvare la faccia, se appropriato, e fare domande invece di fare dichiarazioni ferme. Se è estremamente precario, chiedi il permesso: "Ho qualcosa di cui vorrei parlarti è un po 'delicato, ma penso che ne valga la pena. Va bene?"

Se iniziano a sentirsi offesi, a fare marcia indietro e a metterlo sul sicuro. "Posso vedere che ti sto sfregando la strada sbagliata qui. Non è quello che sto cercando di fare. Io sto cercando di darti un po 'di critica costruttiva - va bene?"

2. Come fai a rimanere aperto in modo da poter continuare a crescere e ricevere da quelli che ti circondano? Sii consapevole di quando e come reagisci, prima di tutto. Se vuoi veramente collaborare e imparare dagli altri, e se puoi impedire al tuo ego di essere coinvolto, questo andrà a posto.

C'è un grande libro su questi argomenti chiamato Crucial Conversations e un altro - e questo è ancora meglio - chiamato Confronti cruciali. Consiglio vivamente il secondo. Tra le altre cose, si tratta di imparare come impedire al tuo ego di ferire le tue relazioni ... In particolare nelle situazioni più importanti in cui c'è molto in gioco e forse sei nel bel mezzo di una scarica di adrenalina.

3. Come faccio a rimanere competitivo con le persone che stanno uscendo da scuola in questo momento? Esperienza! La maggior parte delle persone che hanno appena finito il college hanno un sacco di idealismo e fuoco, ma nessuna esperienza del mondo reale. Hanno un sacco di cose da imparare, alcune delle quali potrebbero essere molto dolorose.

Resta curioso e sii disposto a imparare da loro e ricorda il valore dell'esperienza.

Lascia cadere la parola "mentore" dal tuo vocabolario e dal tuo pensiero, e farai molta strada per essere meno condiscendente.

Io amo trovare il modo migliore per fare qualcosa. Vorrei amare per far condividere a qualcuno consigli sulla programmazione e sulla progettazione.

Mi batterò se penso che il design che mi dai non sia buono come quello che ho in mente, o se penso che il tempo necessario per implementare la tua idea (o il tempo necessario a discutere la tua idea!) non ne vale la pena. Dovresti aspettarti questo; è il modo in cui arriviamo alla verità del soggetto. Se non riesci a gestirlo, allora non penso che tu debba iniziare conversazioni sull'argomento. :) Questo sarà sicuramente un dibattito e forse anche un po 'contraddittorio, ma ciò non significa che sto prendendo le cose personalmente o che dovresti, e ciò non significa che non sono aperto all'input. Inoltre, non significa che non possiamo goderci l'una l'altra l'amicizia, se siamo amici.

I buoni programmatori vogliono collaborare con buoni programmatori, anche se non sempre sono d'accordo. Se hai qualcosa di produttivo da suggerire, basta suggerirlo. Come un pari, non come il mio "mentore". E sii disposto a essere corretto, da un pari. :)

Se vuoi fare da mentore a qualcuno, prima dimostrati degno di essere un mentore.

Come programmatore ed educatore ora piuttosto "senior", ho visto molto più della mia condivisione di "hot shots" e "know it all" ad ogni livello.

Tuttavia, una cosa sembra non cambiare mai, e questa è la curva di apprendimento universale:

1. principiante - solo apprendimento, pieno di domande, piuttosto umile, desideroso e assetato di più.
2. principiante avanzato - ha imparato alcune cose, ma sa ancora che c'è molto da imparare.
3. intermedio - guadagnando fiducia in alcune aree, ma sa ancora che ci sono delle lacune.
4. avanzato: fiducioso in molte aree, disposto a imparare cose nuove ma piuttosto solide.
5. esperto - conosce tutto, vede tutto. Niente di più da imparare - visto e fatto tutto.
6. principiante - ho appena scoperto quanto lui / lei non conosce. Ritorna al # 1.

Tristemente, troppi si fermano quando raggiungono il n. 5 e diventano dolori inestetici per tutti quelli con cui lavorano.

Quindi se vuoi aiutare gli altri (anche a me non piace il termine "mentore" - sembra una specie di zecca), assicurati di non operare al livello 5.

Saluti,

-Richard

Trovo gli sviluppatori molto obiettivi. Quindi puoi davvero iniziare una discussione razionale. Basta essere onesti e semplificare i fatti.

Se vai dall'altra parte, se non stai provando a imparare tutto il tempo, allora non sei un grande sviluppatore.

• ammettere l'ignoranza. a molte (la maggior parte?) domande non trival si risponde meglio con "non sono sicuro, ma penso di sì e così. scopriamolo!"
• la maggior parte dei problemi è una buona scusa per imparare, imparerà da te, imparerai mentre fai qualcosa di nuovo con un approccio nuovo.
• continua a produrre. se gli altri rispettano il tuo lavoro, non si sentiranno insultati.
• se un punto è una domanda banale o un errore evidente, prova ad appellare come un puzzle: "quale fonte di errori sto supervisionando?" "C'è qualche ambiguità nei documenti?"

Uno degli approcci migliori che abbia mai visto è mostrare che sei entusiasta di qualcosa. "Vuoi vedere qualcosa di interessante .." o "Guarda questo ..." è un ottimo modo per condividere informazioni.

Se non vuoi sembrare che tu stia bersagliando una singola persona, puoi farlo anche nelle sessioni settimanali degli sviluppatori (se li hai) e presentare le cose al gruppo nel suo complesso. Le probabilità sono, rafforzerà la comprensione di tutti di qualcosa.

Tuttavia, chiunque può sviluppare abilità sociali. Ci vuole tempo e lavoro. Uno dei maggiori ostacoli ad avere forti capacità di interazione sociale sta avendo un strong senso di autostima. Se hai un problema in un ambiente sociale, o ritieni che sia qualcosa su cui devi lavorare, concentrati prima sulla tua autostima. Le persone possono dire quando non sei sicuro di te stesso e in realtà lo prendi come un segno che non sei affatto sicuro di ciò che stai cercando di trasmettere.

La prima cosa che faccio durante il mentoring è recitare quanto segue agli studenti:

There are no stupid questions...just stupid people who ask questions.

Sto scherzando !!! :)

Ho fatto un po 'di mentoring nei miei anni di attività e ho ricevuto alcune osservazioni lungo la strada:

• Non tutti imparano allo stesso modo. Regola la tua metodologia di insegnamento per la persona, non farla regolare a te.
• Non puoi liberare un pesce dall'acqua. Se qualcuno non vuole imparare, non puoi forzarlo. Aspetta che chiedano aiuto.
• Utilizza metafore e illustrazioni il più possibile. I programmatori tendono a pensare visivamente.
• Sii paziente! Le persone imparano al loro ritmo. Il tuo lavoro come mentore è quello di aiutarli a imparare, non di essere un martinet tirannico!
• Sii entusiasta, contagioso

Il mentoring è un'abilità che si sviluppa con la pratica, ma la personalità è integrata!

Ottima domanda, e una a cui non ho davvero una risposta.

L'unica volta che ho trovato che posso avere qualche effetto è se ho una proposta molto concreta che ha un vantaggio dimostrabile.

Ad esempio, nell'ottimizzazione delle prestazioni, i nostri programmatori sono come la maggior parte in quanto a) parlano della profilazione, b) procedono a indovinare e correggere le loro ipotesi. Potrei usare la mia tecnica di arresto e poi dirglielo, ad esempio "A proposito, il programma sta inizializzando la struttura X tre volte durante l'avvio, e ciò rappresenta il 40% delle volte." Poi dicono "Oh, ok, probabilmente posso sistemarlo"

Anche allora, potrebbero semplicemente non farlo. Quindi è meglio stare zitti e mantenere la pace.

Lo fai con l'esempio. Se riesci a trovare un modo per farlo, fai del volontariato per lavorare sullo sviluppo congiunto di un progetto con l'altra persona. Accetto le API, rivedere il codice degli altri, passare il codice avanti e indietro. Non criticare il loro lavoro, lasciare che commettano errori e lasciare che realizzino l'errore e correggerlo da soli. Lascia che contribuiscano. Aspetta che ti chiedano "Come faccio a migliorare questo". Sii aperto a ciò che sanno, potresti anche imparare da loro.

Questa non è una cosa facile da fare, e richiede soprattutto pazienza. Devi stabilire fiducia e imparare a lavorare solo con l'altra persona per prima cosa, se dici semplicemente "stai facendo male", la lezione non si fermerà. Alcune persone (forse) non sono d'aiuto, convinte di avere sempre ragione, non volendo imparare. Ma la maggior parte delle persone vuole davvero imparare e insegnare (basta dare un'occhiata a questo sito per dimostrarlo), hanno solo bisogno di un ambiente sicuro per farlo.

Questa è una cosa difficile da fare, come hai notato tu e molti altri, ma ti aiuta se scegli il momento giusto per fare le cose e per presentare le cose in modo non negativo. Scegliere il momento giusto per fare le cose significa che non dovresti dire qualcosa che potenzialmente potrebbe chiamare qualcuno (ad esempio esporre la loro ignoranza) in un contesto di gruppo. Nelle impostazioni di gruppo, anche la persona più obiettiva e aperta al feedback potrebbe reagire in modo un po 'difensivo se le stai chiamando in un gruppo. A meno che tu non debba chiamarli di fronte al gruppo, prova ad evitarlo e trascinarli di lato più avanti.

Nel regno della presentazione del "tutoraggio" - tutto dipende da cosa stai discutendo e con chi stai parlando. In alcuni casi, non importa quello che dici, sbaglierai. A proposito dell'unica cosa che puoi fare a quel punto, fai alzare qualcuno (ad es. Capo, collaboratore ben rispettato, il tuo mentore) per andare a parlare con la persona. Se la persona è aperta alla discussione, quindi cerca di non venire giudicata o arrogante in merito a ciò che stai discutendo, probabilmente lo farai fuori dalla persona. Dalle mie esperienze personali, il modo migliore di avvicinare qualcuno è in una questione più "giusta i fatti" in cui si presenta un modo migliore di fare qualcosa. La maggior parte delle persone nell'IT capisce che le cose cambiano molto velocemente e non ci vuole molto tempo per non essere aggiornati su qualcuno. Se ti avvicini alle cose da quell'angolazione, la maggior parte delle persone ascolterà ciò che hai da dire.

Come vincere amici & Influenza persone http://ecx.images-amazon.com/images/I/51JDKW8TV1L._SS500_.jpg

link

La scelta delle parole ha una certa importanza. Ma quello che sento è più importante è il tono che usi per esprimere i tuoi sentimenti. Non essere mai rumoroso e scattante. È possibile utilizzare la frase più cordiale e gridare "HAI CONSIDERATO SCRITTO DI UNO SCRIPT PER RIMUOVERE RECURSIVAMENTE TUTTI I FILE .BAK IN TUTTE LE DIRETTIVE DI REGISTRAZIONE?" e farlo sembrare davvero ostile. Ovviamente, non importa quanto gentile sia il tuo tono, usare "idiota" o "ritardato" non ti aiuterà.

Il mio stile di persuasione è quello di avere una conversazione mentre rallenti sorseggiando il tè .

La realtà spesso fa miracoli qui. Quando la loro stupida idea fallisce miseramente, sottolinea educatamente e con umiltà che hai avuto un suggerimento alternativo che avrebbe funzionato se ti avessero ascoltato. Potrebbero discutere con te nel tentativo di salvare la faccia. In effetti, se è così, dovresti lasciarli vincere questo argomento. Ma non saranno in grado di sfuggire al fatto che avevi sempre ragione e probabilmente saranno più disposti ad ascoltare in seguito.

I don't have great social skills. Like many programmers I know, social skills are >something that is worked on and developed over time because it's not a natural and >'inborn' trait.

Le abilità sociali sono sviluppate nel tempo per tutti . Perché è un malinteso così comune che gli sviluppatori non debbano o debbano lavorare duramente per sviluppare abilità sociali?

Da Richards rispondi a IMHO quelli che

knows all, sees all. Nothing more to learn - seen it and done it all

non esistono, tranne che nelle loro menti ... è la bellezza di questo lavoro che ci siamo ritrovati nel fatto che gli strumenti / ambiente / mercato sono in continua evoluzione ... quindi la capacità di apprendimento è sempre lì ... la prossima grande cosa è dietro l'angolo e non sei così lontano dal diventare un dinosauro FORTRAN se ti siedi ancora ...

Quindi un piccolo consiglio che vorrei avere è quello di imparare dagli altri della tua squadra ... lo troviamo tutti simpatico quando viene presentato un problema / una sfida da affrontare e risolvere da soli, ancora più facile ora con il web (ad es. stackoverflow) disponibili ... ma chiedendo ai tuoi colleghi opinioni o aiuto, saranno probabilmente più aperti a chiedere aiuto / guida la prossima volta che ne avranno bisogno ... o ad essere più aperti a consigli / orientamenti non richiesti ..

Se non hanno la risposta puoi anche cercare insieme ed entrambi imparano, se si sente collaborativo saranno più ricettivi.