Cosa dovresti fare se tuo figlio non avesse adottato il tuo suggerimento? [chiuso]

Sto guidando un team di 3-4 sviluppatori junior. Il mio lavoro, oltre a scrivere codice, è quello di fornire supervisione e guida per i giovani.

Ma capisco perfettamente quanto gli sviluppatori apprezzino l'autonomia nel loro lavoro e non voglio distruggere la loro motivazione intrinseca alimentandoli con i miei pensieri e i miei algoritmi; Voglio che esplorino il problema a modo loro, ci pensino da soli e vengano da me solo quando si trovano ad affrontare problemi insormontabili.

Quando vengono da me, a volte dovrei proporre un algoritmo completamente diverso per risolvere il problema perché il loro algoritmo non è abbastanza robusto (ricorda, io sono il senior e ho visto più di loro). Naturalmente lo spiegherei in modo carino per non ferire i loro sentimenti, e vorrei delineare delicatamente come la mia soluzione è enormemente superiore alla loro, nessun tono condiscendente o parole di condanna.

Tuttavia, a volte sono riluttanti ad accettare il mio suggerimento, in parte perché hanno investito così tanto nel proprio algoritmo, o in parte a causa della paura che l'uso di un nuovo metodo comporterebbe più tempo di apprendimento e li faccia sembrare al management come se stessi non vanno da nessuna parte. Ma nel profondo del mio cuore so benissimo che il mio algoritmo è molto meglio del loro e dovrebbero semplicemente adottarlo.

Cosa devo fare se non hanno adottato il mio suggerimento? Devo solo chiedere loro di seguire la mia strada, o dovrei semplicemente lasciarli sbattere la testa sul muro molte altre volte e aspettare che tornino da me? Fare il primo mi rende un dittatore, ma fare il secondo ci costerebbe tempo prezioso per lo sviluppo e costi di correzione dei bug. Sono davvero in un dilemma qui.

Aiutali a capire perché dovrebbero apportare le modifiche suggerite. E ascoltali se hanno una buona ragione per non apportare il cambiamento. Discuti e raggiungi un accordo sulla base di qual è la cosa migliore da fare.

Questo approccio è importante per i seguenti motivi:

• Volete che stiano apportando il cambiamento a causa di solide ragioni commerciali / tecniche. È importante essere chiari su cosa siano (tutti ricordano che potresti anche sbagliarti, quindi sii umile ....).
• Vuoi davvero trasmettere il ragionamento alla base del tuo suggerimento - in questo modo il destinatario imparerà a risolvere problemi simili in futuro. Avrai anche una relazione migliore se i tuoi ragazzi sentono che stanno imparando alcune buone intuizioni da te.
• Non sarai rispettato se usi la tua anzianità e non riesci a dimostrare di avere delle buone ragioni.
• Il tuo capo vorrebbe presumibilmente essere sicuro che stai usando il tempo dei tuoi junior in modo efficace su cose che creano valore reale, non solo "facendo a modo mio" per il gusto di farlo.

Se sei intelligente, puoi anche farli arrivare alla risposta solo facendo domande . Fatto bene, il tuo junior arriverà alla conclusione corretta (e quindi sarà molto più disposto a implementarlo). Domande di esempio:

• Il codice presuppone l'accesso al database di produzione. Come possiamo cambiarlo in modo che funzioni ancora e possa essere correttamente testato da JUnit in un ambiente di sviluppo disconnesso? (potenziale risposta: ah! dovremmo usare l'iniezione di dipendenza ....)
• Cosa succederà se un utente malintenzionato ha inviato deliberatamente un codice SQL abilmente costruito nel modulo di immissione dei dati online? (potenziale risposta: ah! forse non dovremmo costruire istruzioni SQL concatenando testo non verificato dagli internet)

EDIT : Se riesci a persuadere il tuo giovane che la cosa giusta da fare è seguire il tuo suggerimento, ma sono ancora riluttanti rispetto a qui ci sono alcuni consigli aggiuntivi:

• Scopri perché sono riluttanti. È possibile che debbano giungere alla realizzazione personale che non importa se si elimina il codice, a condizione che si ottenga il risultato. O potrebbe essere che si sentano sotto la pressione del tempo a causa di una scadenza. Devi sapere, altrimenti non puoi aiutarli .....
• Puoi sottolineare che possono considerare il cambiamento come un modo per migliorare le loro abilità di refactoring. Una volta che le abilità di refactoring sono abbastanza buone, dovresti essere in grado di riutilizzare relativamente rapidamente anche una base di codice abbastanza grande e complessa.
• Dovresti sottolineare che tutto sarà nel controllo del codice sorgente, quindi possono sempre tornare a una versione precedente, se necessario.

Odiavo l'atteggiamento prepotente del mio ultimo Team Leader, ma lo rispetto per il fatto che avesse una conoscenza tecnica superiore e mi ha insegnato molto senza farmi lezioni. Soprattutto non mi ha mai costretto ad andare con il suo piano. Avrebbe interpretato l'avvocato del Diavolo con il mio piano, costringendomi a dimostrare che il mio piano era impeccabile. Cercherebbe scappatoie e aspetterebbe la mia spiegazione sul perché non è una scappatoia o è una soluzione meno costosa. Mi chiederebbe se ci sono soluzioni alternative e proporrebbe alcune idee se non ne avessi. Avrei dovuto valutare le sue idee e che il suo piano non era ottimale o Se fosse convinto che il mio piano fosse giusto o almeno avesse lo stesso rapporto rischio-rendimento del suo, avrebbe dato il via libera. Se fallissi con la mia idea avrei dovuto provare la sua soluzione.

Ci deve essere un compromesso tra libertà e scadenze. Non hai il lusso di prolungare la scadenza e non puoi lasciare che i tuoi ragazzi la violino. Devi essere educato ma deciso con loro che una volta che hanno provato il loro algoritmo e non lo hanno fatto funzionare, hanno il dovere di ascoltarti. Dimostra per esempio che conosci le tue cose. Ma, altrettanto importanti, farli imparare, non insegnare loro.

Se è un requisito, annotalo come quello. Se è solo un suggerimento, come noti, allora dovrebbero essere liberi di farlo diversamente. Alcune domande che vorrei porre:

• Hai l'autorità per chiedere soluzioni specifiche?
• Qual è l'estensione per tale autorità?
• C'è una soluzione sbagliata o semplicemente diversa?

Sono sicuro che potresti chiedere di più, ma i primi due si concentrano sulla tua autorità e l'ultimo su se vale davvero la pena spingere il problema.

La seguente risposta ha alcuni grandi punti aggiuntivi e aggiungerei qui che è necessario trattarlo più come un processo collaborativo in cui si lavora attraverso almeno alcuni di questi con il proprio "team" piuttosto che emettere semplicemente dei dettami. Impareranno mentre risolvono i problemi con te più che semplicemente sentirsi dire "considera di farlo in questo modo".

L'apprendimento avviene davvero solo dove si verificano fallimenti, perché il fallimento è un fattore motivante e fornisce segnali di memoria per il richiamo in futuro. Questo è essenzialmente ciò che chiamiamo esperienza, e la buona esperienza sul posto di lavoro verrà dall'aver fallito e imparato dai fallimenti. Se i tuoi juniors fossero in grado di ottenere tutto correttamente la prima volta, o non imparerebbero nulla o non sarebbero juniors.

Se hai troppi ragazzi che rovinano le cose, forse la tua azienda ha un personale in modo errato, con troppi sviluppatori di livello junior in cui i vincoli di tempo richiedono persone con esperienza migliore per ridurre al minimo i rischi, eppure anche in questo caso si possono avere problemi e ritardi, poiché gli sviluppatori senior commettono errori anche da cui imparare.

I tuoi junior dovranno imparare e acquisire esperienza per poter far fronte in un ambiente in cui le scadenze sono strette. Come team leader, è il tuo lavoro dare l'esempio e ispirare i tuoi ragazzi a lavorare in modo efficiente, tuttavia la realtà è che devi mettere da parte preoccupazioni di orgoglio personale e preoccupazioni per i tuoi programmi ristretti se vuoi che i tuoi ragazzi imparino davvero qualcosa e quindi è necessario consentire loro di fallire. Pertanto, è tuo compito effettuare una chiamata. A volte devi dare ai ragazzi lo spazio per fallire, e poi portarli pazientemente attraverso un processo di revisione per mostrare loro dove potrebbero migliorare le loro idee. Altre volte, devi abbassare il piede, ma fallo in un modo che ti consenta di dimostrare che farlo è per un bisogno genuino che non si riflette male sulle capacità dei tuoi figli di per sé.

Per quanto riguarda il problema delle scadenze strette, è qui che è necessario pianificare e allocare il proprio lavoro in base ai punti di forza e di debolezza relativi all'interno del proprio team. Alla fine il dollaro si ferma con te. Quando sei responsabile degli altri non sei lì per essere amico di tutti, sei lì per fare un lavoro difficile in circostanze difficili. Il modo in cui tieni tutti dalla tua parte dipende dal parlare delle persone attraverso le tue preoccupazioni e le tue problematiche, fornendo un caso ragionevole per cui hai bisogno che i membri del tuo team facciano qualcosa in un modo particolare.

Dalle mie esperienze personali, è necessario riservare un determinato periodo di tempo con il proprio minore per discutere dei punti di forza e di debolezza di entrambe le idee e quindi cercare collaborativamente la soluzione migliore che risolverà il problema a portata di mano, anche a rischio di concedersi essere smentito - e poi andare avanti. Se entrambi non riesci a raggiungere un consenso entro la fine del tempo assegnato, a quel punto devi concludere la riunione con un riepilogo che tenga conto delle preoccupazioni discusse e nota che non è stato raggiunto alcun consenso. Indipendentemente dall'esito della riunione, ringrazi il tuo junior per il tempo trascorso e indichi che tornerai con la tua decisionein breve. Dopo un'attenta valutazione della discussione, avrai la possibilità di allocare tempo aggiuntivo per ulteriori discussioni, oppure di incaricare il junior a proseguire con il piano che hai deciso in base all'esito della riunione.

Sì, il tempo è prezioso a volte, tuttavia quando si sceglie di assumere juniores è necessario accettare che si sta assumendo la responsabilità di investire e coltivare il loro sviluppo professionale, e è necessario accettare che di conseguenza lo farà per un po ' almeno ti costa tempo.

Vorrei chiederti se in realtà stai presentando il tuo suggerimento in un modo che non è condiscendente. Quando usi frasi come:

la mia soluzione è di gran lunga superiore alla loro

e

nel profondo del mio cuore so benissimo che il mio algoritmo è molto meglio del loro e dovrebbero semplicemente adottarlo.

mi fa pensare che potresti imbatterti in un atteggiamento di "la mia strada è superiore". A nessuno piace avere questo atteggiamento. Quando l'ho ricevuto in passato, ho fatto di tutto per utilizzare un algoritmo diverso per dimostrare la persona sbagliata. Potrebbe essere che i tuoi ragazzi stiano facendo lo stesso.

Un modo migliore dovrebbe essere quello di sedersi con la persona e discutere il loro algoritmo. Fai notare perché non pensi che funzionerà e ascolta le risposte che ti danno con una mente aperta. Verifica se il loro algoritmo può essere modificato per funzionare correttamente.

Se quello che hai sicuramente non funzionerà, spiega loro perché non funzionerà. Quali parti sono errate o comportano riscritture in seguito o non si adattano al modello aziendale. Assicurati che abbiano una buona comprensione delle tue ragioni. Quindi spiega loro il tuo algoritmo, indicando i pezzi in cui funzionerebbe e il loro codice fallirebbe.

Prima di tutto, conosci il vero motivo per cui tuo figlio non ha adottato il tuo suggerimento?

A volte, sai, un junior può effettivamente scrivere qualcosa di meglio del suo senior a causa delle nuove prospettive e di una formazione CS più aggiornata. Anche se come senior potresti aver visto più esempi del mondo reale. Ma una brutta trappola in cui spesso vedo cadere i miei anziani è dimenticare che le migliori pratiche potrebbero cambiare nel tempo. Sono sicuro che questo non si applica a te in quanto ti stai aggiornando su siti come questi. ;)

Suggerirei di provare ad avvicinarti ai tuoi ragazzi senza alcuna (o piccola) "aura" di un anziano, provare a parlare in termini di livello con loro, mostrare curiosità nel codice che hanno scritto. Poni domande, ascolta le loro risposte. Non chiedere in modo accusatorio come:

"Il tuo codice è piuttosto inflessibile, devi cambiarlo in questo ..."

invece chiedi

"Mi sto solo chiedendo, cosa succederebbe se qualcuno dovesse ... il tuo codice riuscirà a gestirlo? ... Penso che un modello di strategia potrebbe aiutare qui. Cosa ne pensi?"

Questo credo che ti aiuterà a impegnarti in conversazioni più salutari con loro che come un professore / conferenziere che li guarda come se lo sapesse tutto. Ti aiuterà anche a vedere meglio il loro ragionamento e le loro prospettive.

Controlli l'accesso push al repository?

In open source, l'accesso push è sempre controllato da un gatekeeper incaricato di far rispettare la qualità. Se stai monitorando attivamente gli impegni che stanno spingendo, dovresti essere profondamente consapevole di dove possono migliorare.

Possono hackerare o migliorare il tuo codice. Se hanno la possibilità di vedere gli interni su come funziona il tuo codice, possono imparare ad adattarsi meglio al tuo stile. Se stai spingendo i tuoi suggerimenti senza accettarli con una mente aperta, saranno meno inclini ad ascoltare la tua opinione.

Ci sono alcune circostanze in cui non esiste una risposta corretta (come le preferenze di stile di codifica). In tal caso, prova a stabilire (o applicare) una politica a livello aziendale in modo che comprendano che lo stile del codice dovrebbe essere orientato per essere coerente con la base di codice principale. Usare una linea guida di stile già consolidata (come la guida di stile Microsoft per C #) è il modo migliore di procedere, specialmente per i nuovi sviluppatori del team.

Se stai facendo affermazioni generali sulle loro tecniche di codifica, c'è una buona probabilità che tu non comprenda completamente il ragionamento alla base delle loro scelte. Solo il tono della tua domanda ti fa sembrare arrogante. Cosa guadagni / sacrifici spingendo il tuo approccio sugli sviluppatori più giovani?

La domanda chiave che devi porsi è: i tuoi suggerimenti sono orientati a mantenere / migliorare la qualità della base di codice o ad affermare il tuo dominio / superiorità sui tuoi pari? Il primo è un semplice controllo di qualità e può essere giustificato in quanto tale, la scala è dannosa per la dinamica della squadra indipendentemente dal fatto che tu abbia o meno i tuoi diritti.

Ad ogni modo, se vuoi spingere la tua soluzione sui tuoi coetanei, dovresti avere prove concrete che è, in effetti, superiore. Un aumento di grandezza delle prestazioni dovrebbe essere abbastanza facile da migliorare, niente di meno non vale lo sforzo (tranne le applicazioni critiche per le prestazioni). Forzare il tuo lavoro con gli altri per giustificare il tuo personale senso di superiorità si concluderà con il fatto di essere scelto come il "vecchio cattivo".

Nota: i programmatori migliori e più talentuosi che ho incontrato nel corso degli anni sembravano sempre quelli che erano disposti a fermarsi e spiegare la storia dietro a dove avevano originato il loro approccio.

Beh, questo sembra interessante e molto naturale con i giovani programmatori molto attaccati al codice che hanno scritto, forse hanno trascorso un bel po 'di tempo ad arrivare allo stesso o l'hanno scelto da qualche buon sito (Quindi, certo, Hey Jon Skeet ha scritto questo amico!!).

Tuttavia la stringa di base allegata qui è allegato al codice che è dove dovresti concentrarti e penso che dovresti fare uno sforzo considerevole per far loro capire che l'esecuzione e il risultato atteso sono più significativi del loro nome inciso sui repository di origine per aver inserito questo codice. Dovrai tracciare delle linee per cui il tuo codice è migliore ed è anche buono in termini di mantenimento per lavori futuri.

Prendi in considerazione che alcuni errori sono eminenti (hai bisogno di qualche spezzacuore per qualsiasi attaccamento) ma con uno sforzo graduale penso che verrebbero fuori e sarebbero in grado di apprezzare meglio i tuoi sforzi. Un po 'di tempo e pochi insuccessi è ciò di cui penso avresti bisogno. Costringerlo su di loro sarebbe il contrario di alcune storie di successo e poi del giorno del giudizio e della rivolta.

Ognuno ha uno stile diverso. Se trovi 10 persone diverse e le presenti un problema non banale, ti daranno 10 approcci diversi usando 10 stili di "standard di codifica" diversi.

Il punto è: scegli le cose che contano. Se qualcosa ti viene presentato da un junior che non produce la soluzione corretta, lo fa in modo gravemente inefficiente (ordine di grandezza +1, non un'istruzione qua o là) ​​o crea un buco nella sicurezza, quindi spiega il tuo problema e perché. Se si tratta di un commento "avrei fatto questo", beh, va benissimo, avresti fatto "quello" e lei ha fatto "qualcos'altro" ma il problema è ancora risolto sufficientemente (vedi i punti sopra). Passa alla funzione o correzione successiva.

Parte dell'apprendimento di essere un buon leader è imparare a riconoscere ciò che conta davvero e cosa no. Inoltre ti rimuovi come un potenziale collo di bottiglia per le prestazioni del tuo gruppo se devono controllare tutto attraverso di te.

MODIFICA: assicurati che i tuoi suggerimenti siano requisiti autentici e non velati. Un suggerimento è proprio questo: un suggerimento che si è liberi di seguire o meno. Se è un requisito, dichiaralo come tale.

Come alcuni altri hanno sottolineato, se stai davvero provando gli sviluppatori junior con suggerimenti e sono formulati come tali, allora non hai davvero molti motivi per infastidirli se non li seguono perché potrebbero non vedo molte ragioni per farlo. Allo stesso modo, non puoi davvero rimproverarli per non aver seguito il tuo suggerimento perché non sono la direzione reale per fare le cose in un certo modo.

Per quanto riguarda il tentativo di convincere gli sviluppatori junior a fare le cose come preferiresti fare loro:

• Controlla la tua terminologia, formulare un suggerimento non equivale a formulare una raccomandazione che non è in definitiva la stessa di fornire indicazioni . Usa la terminologia di conseguenza per far capire il tuo punto di vista e se pensi che il tuo modo di fare qualcosa sia un modo migliore per farlo, di 'loro che è una tua raccomandazione farlo. Allo stesso modo, se è assolutamente fondamentale che le cose vengano fatte in un determinato modo (cioè non riescano a resistere a un ritardo), allora basta essere schiette e dare loro la direzione su come dovrebbero essere fatte.
• Gli sviluppatori junior stanno ancora attraversando il processo di apprendimento, indipendentemente da come stai formulando le cose, fornisci sempre una sorta di ragionamento dietro ciò che stai dicendo loro a meno che non ci sia un motivo specifico che non puoi. Anche in quel caso, la maggior parte delle persone capirà se dici qualcosa del tipo "Deve essere fatto in questo modo, non me ne importa da solo, ma la decisione è già stata presa". tendono ad essere abbastanza ragionevoli.
• Se è veramente solo un suggerimento, assicurati che la tua idea sia effettivamente migliore di come è stata. Se non pensi che sia il caso, siediti con lo sviluppatore e fai una revisione del codice e dei concetti in modo che possano giustificare la loro soluzione. Può darsi che una volta che inizieranno a spiegarlo a qualcun altro - e tu farai le domande giuste - vedranno un modo migliore e vorranno ricodificare le cose da sole.
• Non scherzare sui dettagli se la loro soluzione è simile a quella che hai suggerito in origine, è possibile che abbiano preso in considerazione ciò che hai detto loro e abbiano fatto le cose in modo leggermente diverso o abbiano cambiato il loro concetto originale in base al tuo suggerimento.

Questa è una perfetta introduzione al test unitario. Se i tuoi sviluppatori junior hanno una soluzione, dovrebbe essere testabile. Invitali a produrre un test unitario per sottolineare il loro codice. Quindi rivedere il test unitario . Se riesci a mostrare buchi nel test, è facile farli ripetere il test e vedere la loro soluzione rompersi sotto la pressione.

Ciò ti consente di mostrare loro perché la tua soluzione è migliore, ti offre un test unitario che puoi riutilizzare quando il codice cambia e offre agli sviluppatori junior un'esperienza di apprendimento preziosa. E chissà, potresti scoprire che la loro soluzione va bene.

Ad un certo punto devi essere responsabile. Sembra che tu stia facendo uno sforzo per far loro esprimere le loro opinioni. I tuoi suggerimenti potrebbero non essere perfetti. Gli altri sviluppatori potrebbero non capire / essere d'accordo con te. Probabilmente non sono d'accordo. Se sei al comando, non è una democrazia. Lo sapevano quando hanno accettato il lavoro.

Se non ci sono situazioni in cui devono seguirti, non meriti e non servi a nulla come loro capo. Cambia il tuo ruolo nel team in modo che diventi una risorsa e non un'autorità se non prevedi di utilizzarlo. Ad un certo punto devi spedire il miglior codice possibile sotto i vincoli temporali disponibili e che non possono discutere, ricercare e discutere nuovamente ogni riga di codice fino alla fine dei tempi.

Dai gli ordini. Vivi con le conseguenze. Impara dall'esperienza. Il rispetto è una strada a doppio senso. Lo stai dimostrando e non lo sono.