Che cosa dovresti fare se il tuo junior non ha adottato il tuo suggerimento? [chiuso]

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

Questo approccio è importante per i seguenti motivi:

• Vuoi che stiano facendo il cambiamento a causa di solidi motivi commerciali / tecnici. È importante essere chiari su cosa siano (ricordati che tu potrebbe anche essere sbagliato, 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 juniores sentiranno che stanno imparando delle buone intuizioni da te.
• Non sarai rispettato se utilizzi la tua anzianità e non puoi dimostrare di avere effettivamente dei buoni motivi.
• Il tuo capo vorrebbe presumibilmente essere sicuro che stai usando il tempo dei tuoi junior in cose che creano valore reale, non solo "facendo a modo mio" per il gusto di farlo.

Se sei intelligente, puoi anche convincerli a rispondere alla domanda semplicemente facendo domande . Fatto bene, i tuoi giovani arriveranno alla conclusione corretta essi stessi (e quindi saranno molto più disposti ad attuarlo). Domande di esempio:

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

EDIT : se riesci a persuadere il tuo junior che la cosa giusta da fare è seguire il tuo suggerimento, ma sono ancora riluttanti di quanto non ci sia qualche consiglio in più:

• Esplora perché sono riluttanti. È possibile che abbiano bisogno di capire personalmente che non importa se si butta via il codice, purché si ottenga il risultato. O potrebbe essere che si sentono sotto pressione a causa di una scadenza. Devi sapere, altrimenti non puoi aiutarli .....
• Puoi dimostrare di poter trattare il cambiamento come un modo per migliorare le loro capacità di refactoring. Una volta che le capacità di refactoring sono abbastanza buone, dovresti essere in grado di rielaborare anche una base di codice abbastanza ampia e complessa in tempi relativamente brevi.
• Devi sottolineare che tutto sarà nel controllo del codice sorgente, in modo che possano sempre tornare a una vecchia versione, se necessario.

Odiavo l'atteggiamento prepotente del mio ultimo Team Leader, ma lo rispetto per il fatto che aveva una conoscenza tecnica superiore e mi ha insegnato molto senza tenere conferenze. 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. Cercava scappatoie e aspettava la mia spiegazione sul motivo per cui non è una scappatoia o è una soluzione meno costosa. Mi chiederà se ci sono soluzioni alternative e proporre alcune idee se non ne avessi. Avrei dovuto valutare le sue idee e che il suo piano non era ottimale o Se era convinto che il mio piano fosse giusto o almeno avesse lo stesso rapporto rischio-rendimento del suo, avrebbe dato il via libera. Se avessi fallito 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 permettere che i tuoi juniores lo violino. Devi essere educato ma fermo con loro che una volta che hanno provato il loro algoritmo e non l'hanno fatto funzionare, hanno il dovere di ascoltarti. Prova con l'esempio che conosci le tue cose. Ma, altrettanto importante farli imparare, non insegnarli.

Se è un requisito, annotalo come quello. Se è solo un suggerimento, come si nota, allora dovrebbero essere liberi di farlo diversamente. Alcune domande vorrei chiedere:

• Hai l'autorità per spingere per soluzioni specifiche?
• Qual è l'estensione dell'autorità?
• C'è una soluzione cattiva o semplicemente diversa?

Sono sicuro che potresti chiedere di più, ma i primi due si concentrano sulla tua autorità e l'ultimo sul fatto che il problema meriti davvero di essere spinto.

La seguente risposta ha alcuni grandi punti in più e vorrei aggiungere che è necessario trattarla più come un processo collaborativo in cui si lavora almeno con alcuni di questi con il proprio "team" piuttosto che dettare semplicemente dei dettami. Impareranno mentre affrontano i problemi con te più che semplicemente a dire "pensa di farlo in questo modo".

L'apprendimento avviene solo dove si verificano i guasti, perché il fallimento è un motivatore e fornisce indicazioni sulla memoria per il richiamo in futuro. Questo è essenzialmente ciò che chiamiamo esperienza, e una buona esperienza sul posto di lavoro verrà dall'avere fallito e imparato dai fallimenti. Se i tuoi junior fossero in grado di ottenere tutto correttamente la prima volta, o non avrebbero imparato nulla, o non sarebbero stati juniores.

Se hai troppi juniores che incasinano le cose, forse la tua azienda ha uno staff non corretto, con troppi sviluppatori di livello junior in cui i limiti di tempo richiedono persone con esperienza migliore per ridurre al minimo i rischi, ma anche allora puoi avere problemi e ritardi, come senior gli sviluppatori fanno anche degli errori da imparare.

I tuoi juniores dovranno imparare e acquisire esperienza per essere in grado di affrontare un ambiente in cui le scadenze sono strette. Come capo squadra, è il tuo lavoro dare l'esempio e incoraggiare i tuoi juniores a lavorare in modo efficiente, tuttavia la realtà è che devi mettere da parte le preoccupazioni di orgoglio personale e preoccupazioni per i tuoi impegni stretti se vuoi che i tuoi juniores imparino qualcosa e quindi è necessario consentire loro di fallire. Pertanto, è il tuo lavoro effettuare una chiamata. A volte è necessario dare allo junior 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 mettere il piede in basso, ma farlo in un modo che ti permetta di dimostrare che farlo è fuori da un bisogno genuino che non riflette in modo negativo sulle abilità del tuo junior per se stesso. Se invece vai giù per questa strada, devi aspettarti una certa dose di mano e quindi spetta a te decidere se il carico extra sul tuo tempo ne valga la pena, o se sarebbe meglio lasciare il tuo junior per fallire e imparare.

Per quanto riguarda la questione delle scadenze ravvicinate, è qui che devi pianificare e assegnare il tuo lavoro in base ai punti di forza e ai punti deboli relativi all'interno del tuo 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 fatto in circostanze difficili. Il modo in cui tieni tutti dalla tua parte scende a parlare alle persone attraverso le tue preoccupazioni e i tuoi problemi, spiegando in modo ragionevole perché hai bisogno che i membri del tuo team facciano qualcosa in un modo particolare.

Dalle mie esperienze personali, devi riservare un periodo di tempo prestabilito al tuo junior per discutere i punti di forza e di debolezza di entrambe le idee e poi cercare in collaborazione la soluzione migliore che risolverà il problema, anche a rischio di permettendoti di essere smentito - e poi vai avanti. Se entrambi non riescono a raggiungere un consenso entro la fine del tempo assegnato, a quel punto è necessario concludere l'incontro con una sintesi che tenga conto delle preoccupazioni discusse e rileva che non è stato raggiunto alcun consenso. Indipendentemente dall'esito del tuo incontro, ringrazia il tuo junior per il tempo speso e indica che tornerai con la tua decisione a breve. Dopo un'attenta considerazione della tua discussione, avrai la possibilità di dedicare ulteriore tempo per ulteriori discussioni o di istruire il minore a procedere con qualsiasi piano tu abbia deciso in base al risultato del tuo incontro.

Sì, il tempo è prezioso a volte, tuttavia quando scegli di affrontare juniores devi accettare che ti stai assumendo la responsabilità di investire e coltivare il loro sviluppo professionale, e devi accettare che di conseguenza per un po 'almeno ti costa tempo.

Vorrei chiedermi se in realtà stai presentando il tuo suggerimento in un modo non condiscendente. Quando utilizzi frasi come:

my solution is vastly superior than theirs

e

deep in my heart I know very well that my algorithm is much better than theirs and they should just adopt it.

mi fa pensare che potresti provare un atteggiamento di "la mia strada è superiore". A nessuno piace essere dato quell'atteggiamento. Quando l'ho ricevuto in passato, mi sono attivamente impegnato a utilizzare un algoritmo diverso per dimostrare che la persona si sbagliava. Potrebbe essere che i tuoi juniores facciano 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 junior non ha sicuramente funzionerà, quindi spiegagli perché non funzionerà. Quali parti sono errate o coinvolgeranno le riscritture in un secondo momento o non si adattano al modello di business. Assicurati di avere una buona comprensione delle tue ragioni. Quindi spiega loro il tuo algoritmo, sottolineando i pezzi in cui avrebbe funzionato e il loro codice avrebbe fallito.

Prima di tutto, conosci la vera ragione per cui il tuo junior non ha adottato il tuo suggerimento?

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

Suggerirei di provare ad avvicinare i tuoi juniores senza alcuna (o poca) "aura" di un anziano, cerca di parlare in termini di livello con loro, mostra curiosità nel codice che hanno scritto. Fai domande, ascolta le loro risposte. Non chiedere in modo accusatorio come:

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

invece chiedi

"Mi stavo solo chiedendo, e se qualcuno dovesse ... il tuo codice riuscirà a gestirlo? ... Penso che un modello di strategia possa aiutarti qui. Cosa ne pensi?"

Credo che questo ti aiuterà ad impegnarti in conversazioni più salutari con loro che come un professore / docente che li guarda come se li conoscesse tutti. Ti aiuterà anche a vedere meglio i loro ragionamenti e le loro prospettive.

Controlli l'accesso push al repository?

Nell'open source, l'accesso push è sempre controllato da un gatekeeper che ha il compito di applicare la qualità. Se stai monitorando attivamente i commit che stanno spingendo, dovresti essere perfettamente consapevole di dove possono migliorare.

Arrivano a hackerare o migliorare il tuo codice. Se hanno la possibilità di vedere gli interni su come funziona il codice, possono imparare ad adattarsi meglio al tuo stile. Se stai spingendo i tuoi suggerimenti senza accettare suggerimenti 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, provare a stabilire (o applicare) una politica aziendale in modo che capiscano che lo stile del codice deve essere adattato per essere coerente con la base di codice principale. Utilizzare una linea guida di stile già consolidata (come la guida di stile di Microsofts per C #) è il modo migliore per andare, soprattutto per i nuovi sviluppatori del team.

Se stai facendo affermazioni generiche sulle loro tecniche di codifica, ci sono buone probabilità che tu non capisca completamente il ragionamento dietro le loro scelte. Solo il tono della tua domanda ti fa sembrare arrogante. Cosa guadagni / sacrifichi spingendo il tuo approccio verso gli sviluppatori più giovani?

La domanda chiave che devi porsi è, i tuoi suggerimenti mirati a mantenere / migliorare la qualità della base di codici o ad affermare la tua posizione dominante / superiorità sui tuoi pari? La prima è semplice controllo di qualità e può essere giustificato in quanto tale, la scala è dannosa per la squadra dinamica o meno il tuo diritto.

In ogni caso, se vuoi spingere la tua soluzione sui tuoi colleghi dovresti avere la prova concreta che è, in effetti, superiore. Un aumento della magnitudo delle prestazioni dovrebbe essere abbastanza facile da migliorare, qualsiasi cosa di meno non ne vale la pena (eccetto le applicazioni critiche per le prestazioni). Forzare il tuo lavoro sugli altri per giustificare il tuo personale senso di superiorità finirà con il fatto che sarai considerato come il "vecchio burlone".

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

Beh, questo sembra interessante e molto naturale con i giovani programmatori molto attaccati al codice che hanno scritto, forse hanno passato parecchio tempo ad arrivare allo stesso o lo hanno scelto da qualche buon sito (SO in effetti, Hey Jon skeet ha scritto quest'uomo!!).

Tuttavia, la stringa di base allegata qui è l'allegato con il codice che è dove dovresti concentrarti e penso che avresti bisogno di fare uno sforzo considerevole per far capire che l'esecuzione e il risultato atteso sono più importanti allora il loro nome viene inciso sui repository di origine per spingere in questo codice. Dovrai disegnare le linee come il motivo per cui il tuo codice è migliore ed è anche buono in termini di manutenzione per i lavori futuri.

Prendi in considerazione che alcuni errori sono eminenti (hai bisogno di poche interruzioni cardiache per qualsiasi attaccamento) ma con uno sforzo graduale penso che sarebbero venuti in giro e sarebbero in grado di apprezzare meglio i tuoi sforzi. Un po 'di tempo e pochi fallimenti è ciò che penso che tu abbia bisogno. Costringerlo su di loro sarebbe un altro modo per superare alcune storie di successo e poi il giorno del giudizio e la rivolta.

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

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 grossolanamente inefficiente (+1 ordine di grandezza, non un'istruzione qua o là), o crea un buco di sicurezza, quindi spiega il tuo problema e perché. Se è un commento "Avrei fatto questo", beh, è fantastico, avresti fatto "quello" e lei ha fatto "qualcos'altro", ma il problema è ancora risolto a sufficienza (vedi i punti precedenti). Passa alla funzione o alla correzione successiva.

Parte dell'apprendimento di essere un buon leader è imparare a riconoscere ciò che conta davvero e ciò che realmente non funziona. Inoltre, rimuovi te stesso come potenziale collo di bottiglia per le prestazioni del tuo gruppo se devono controllare tutto tramite te.

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

Come alcuni degli altri hanno sottolineato, se stai solo provando i giovani sviluppatori con suggerimenti e sono formulati come tali allora non hai molti motivi per essere infastidito da loro se non lo seguono perché potrebbero non vedere molte ragioni per farlo. Allo stesso modo, non puoi davvero rimproverarli per non aver seguito il tuo suggerimento perché non sono la vera direzione per fare le cose in un certo modo.

Riguardo al tentativo di convincere gli sviluppatori junior a fare le cose come preferiresti farle:

• Controlla la tua terminologia, facendo un suggerimento non è come fare una raccomandazione che non è assolutamente la stessa di fornire direction . Utilizza la terminologia di conseguenza per ottenere il tuo punto di vista e se pensi che il tuo modo di fare qualcosa sia un modo migliore per farlo, digli che è la tua raccomandazione a farlo. Allo stesso modo, se è assolutamente fondamentale che le cose vengano fatte in un certo modo (cioè non può resistere a un ritardo temporale), basta essere schiette e orientarle nel modo in cui dovrebbe essere fatto.
• Gli sviluppatori junior stanno ancora attraversando il processo di apprendimento indipendentemente da come si stanno formando le cose, forniscono sempre una sorta di ragionamento dietro ciò che si sta dicendo loro, a meno che non vi sia un motivo specifico che non è possibile. Anche in questo caso, la maggior parte delle persone capirà se tu dici qualcosa sulla falsariga di "deve essere fatto in questo modo, non mi interessa 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 è andata. Se non pensi che sia il caso, allora siediti con lo sviluppatore e fai una revisione del codice e del concetto in modo che possano giustificare la loro soluzione. Può essere che una volta che iniziano a spiegarlo a qualcun altro - e tu poni le domande giuste - vedranno un modo migliore e vogliono ricodificare le cose da sole.
• Non cavilli sui dettagli se la loro soluzione è simile a quella che hai suggerito in origine, potrebbe essere che hanno preso in considerazione ciò che hai detto loro e hanno fatto le cose in modo leggermente diverso o hanno cambiato il loro concetto originale sulla base del tuo suggerimento.

Questa è un'introduzione perfetta al test delle unità. Se i tuoi sviluppatori junior hanno una soluzione, dovrebbero essere testabili. Fagli produrre un test unitario per sottolineare il loro codice. Quindi controlla il test dell'unità . Se è possibile visualizzare i fori nel test, è facile farli ripetere il test e vedere la loro soluzione rompersi sotto la pressione.

Questo ti permette di mostrare loro perché la tua soluzione è migliore, ti fornisce un test unitario che puoi riutilizzare quando il codice cambia, e offre agli sviluppatori junior una preziosa esperienza di apprendimento. E chi lo sa, 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 l'uno con l'altro. 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 serve a niente come loro capo. Cambia il tuo ruolo nel team come risorsa e non come autorità se non hai intenzione di usarlo. A un certo punto devi spedire il miglior codice possibile in base ai limiti di tempo disponibili e non puoi discutere, ricercare e discutere di nuovo 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 loro no.