Ispirare un collaboratore ad adottare migliori pratiche di codifica?

Il punto di partenza è conosci il tuo pubblico . Sembra che tu capisca già questo perché conosci la differenza tra il mentore di un giovane collaboratore e l'influenza di un collega anziano.

Hai ancora bisogno di capire cosa motiverà questo particolare individuo. Ciò che funziona su un vecchio geezer (come me) potrebbe non funzionare per il tuo vecchio geezer.

Se gli piace mentore / insegnare agli altri, puoi affrontare un problema con facendo domande come "perché lo fai in questo modo?" Ciò può portare ad un dialogo in cui puoi chiedergli di valutare nuovi approcci e dare la sua opinione.

Se ciò non funziona, puoi segnalare bug che possono essere evitati utilizzando le pratiche o gli stili che desideri adottare. Questo richiede molto più lavoro perché devi trovare i bug e mostrare come i comportamenti che vuoi incoraggiare potrebbero aiutare.

Se sembra disposto ad aiutare gli altri, potresti fare appello al suo desiderio di aiutare i neofiti . Spiega che "i bambini di oggi" non sono abituati a vedere il suo stile di codifica e saranno più propensi a romperne il codice a causa di ciò.

A volte devi semplicemente mettergli la faccia e forzare il problema. Devi scegliere attentamente queste battaglie. Assicurati di iniziare con un argomento in cui sai che puoi dimostrargli che hai un modo migliore.

Penso che tu abbia l'atteggiamento giusto. Assicurati solo di indicare tutte le cose belle che hai già detto - Ottime capacità di problem solving, suberb capisci il business, ecc. E chiedigli solo un po 'del suo tempo per mostrargli gli standard correnti che il gruppo sta usando e dandogli la possibilità di fare alcune domande su di loro.

Quando vieni insieme, portagli un caffè o qualcosa del genere, e fagli sapere che lavorare agli standard lo avvantaggerà rendendo più facile per lui supportare il tuo codice esistente e anche rendere più facile per qualcuno essere in grado di aiutarlo fuori se viene coperto nel lavoro (un grande vantaggio per qualcuno che ha lavorato in isolamento), ecc.

Assicurati di essere impegnato e ottenere buone spiegazioni sul perché fai le cose che fai e non concentrarti sul perché non dovrebbe fare le cose che stava facendo, coinvolgere altre persone se necessario e farglielo spiegare a te. Renditi disponibile in seguito, se ha delle domande e fai il follow-up con alcuni punti a cui può fare riferimento per esempi dei tuoi standard.

Se non ti interessa dopo, puoi fare riferimento alla prima domanda che hai collegato.

È davvero compito del tuo manager

1. Comprendi che la azienda deve avere uno standard di codifica. Ogni azienda un po 'professionale ha questo, indipendentemente dalle dimensioni dell'azienda.
2. Fai sedere tutti e comincia a elaborare uno standard. In questo modo, tutti possono dire la loro, e saranno quindi più motivati a seguire lo standard.

Se il tuo manager non se ne rende conto da solo, non sono qualificati per il loro lavoro. E se è così, dovresti dare loro qualche spunto sopra i due precedenti. I vantaggi di avere uno standard di codifica sono così tanti, non c'è davvero alcun argomento contro l'averne uno. (Se alcuni programmatori sentono di essere "artisti" e non dovrebbero essere limitati dai limiti della professionalità, dovrebbero invece ottenere un lavoro facendo belle arti).

Lo standard di codifica in sé dovrebbe innanzitutto focalizzarsi sul divieto di pratiche pericolose e sulle funzioni di biblioteca pericolose. Lavora verso un sottoinsieme più sicuro e più puro della lingua che stai utilizzando. Mantenere lo standard di codifica libero da "stile di codifica", perché lo stile di codifica è molto più difficile da concordare e non altrettanto importante. È piuttosto classico che un'azienda decida di fare uno standard di codifica e poi si blocca immediatamente in una discussione senza senso su dove posizionare le parentesi graffe.

Per riferimento, guarda come vengono scritti gli standard MISRA-C / C ++ e CERT C / C ++ / Java.

Prima di tutto devi chiarire PERCHÉ vuoi cambiare il modo di lavorare di queste persone. Se è solo per ragioni estetiche, penso che dovresti riconsiderare, perché questa persona ha dimostrato che il suo modo di lavorare funziona davvero.

Se, tuttavia, esiste una ragione tecnica per questo, dovresti prendere in considerazione l'approccio a detta persona con qualcosa del tipo:

I have a suggestion for how you can save tedious time for you, and money for the company. Are you interested?

Tieni presente che questa dovrebbe essere una frutta a basso impatto perché molto probabilmente richiederanno il cambiamento delle abitudini esistenti che richiedono sempre uno sforzo extra.

Anche se hai gazillions di suggerimenti, scegli uno o due e dimostra che cambierà per il meglio.

O funzionerà, e ti verrà chiesto se hai altri suggerimenti, altrimenti non lo farà e il danno è limitato a uno o due suggerimenti.

Si noti che è molto importante che diventi un successo e lo faccia rapidamente.

Inoltre devi stare attento. Potrebbero esserci molto buoni motivi per fare le cose nel modo in cui sono fatte, ma che sei troppo nuovo per aver visto perché. Quindi, sii rispettoso verso il tuo anziano e chiedi prima che tu pensi che il tuo suggerimento sia migliore. Potresti imparare una cosa o due.

Vorrei strongmente scoraggiarti da mettergli la faccia in faccia in quanto ciò potrebbe far peggiorare la situazione molto rapidamente. Mi rendo conto che è stato proposto come un tipo di misura di ultima istanza, ma in base alla mia esperienza, a questo punto, lo sviluppatore ha smesso di partecipare.

Forzare il problema potrebbe trasformare l'individuo in un nemico dove stanno combattendo con ogni tua azione. Ciò avrebbe davvero un impatto negativo sulla squadra e non finirà fino a quando qualcuno non si licenzi o viene licenziato.

Se questo individuo possiede veramente una conoscenza di dominio che è necessario / desidera, allora chiedigli di documentare tale conoscenza.

Iniziando col dirlo gentilmente a lui: non so quanto tu abbia esperienza e quanto sia bravo nel dare feedback. Potresti già sapere, impiegare o addirittura respingere quanto segue, ma qui va comunque. Ci sono alcune linee guida su come dare un feedback quando si vuole cambiare il comportamento di qualcuno. La struttura della conversazione che ho pensato, e che comunque cerco di impiegare nelle situazioni in cui voglio dare un feedback (perché funzionano) sono le seguenti:

1. Descrivi il comportamento che vedi. Questo deve essere un comportamento concreto. Esempio: "Vedo che stai usando un sacco di variabili statiche nel tuo codice"
2. Descrivi come ciò influisce su di te / sulla tua squadra. Esempio: "Trovo difficile mantenere tale codice"
3. Offri una soluzione ragionevole . (le possibili soluzioni sono menzionate in altre risposte, e in seguito mi diletterò in alcune di queste risposte.)
4. Dagli l'oppertunità per discutere la soluzione. Chiedigli cosa pensa della soluzione. Prendi la sua risposta al valore nominale. Gli hai dato la tua opinione, ed è libero di accettarlo o meno. *

Una risorsa veloce sul feedback può essere trovata ad esempio sul link (anche se c'è una pletoria di questo genere di cose sul web)

Ora sulla parte della soluzione, da quello che sto leggendo nella tua risposta, ho capito che è molto intelligente e ha la mentalità giusta, ma è solo indietro nelle buone pratiche moderne. Quelli richiedono tempo e fatica per padroneggiare, a parte l'apprendimento effettivo su di loro in primo luogo, quindi dovrete fornirgli l'opportunità di farlo. Ciò significa probabilmente raccogliere risorse di apprendimento (web, riviste, libri, qualunque cosa) come punto di partenza e dargli tempo libero per studiarle. Potrei immaginare di dargli ogni venerdì pomeriggio per allargare i suoi orizzonti sullo stile di programmazione, dove può fare qualunque cosa crede che migliori tali obiettivi. Le persone vogliono migliorare se stesse. Fornisci i materiali e il tempo e ne faranno buon uso.

Forse, cosa più importante, non aspettarti cambiamenti da un giorno all'altro. Ha fatto le cose a modo suo per molto tempo, e probabilmente è diventato abbastanza bravo. Ci vorrà un po 'di tempo per ottenere un nuovo modo di fare le cose, e per un po' probabilmente non vedrà molto valore in modi nuovi, perché all'inizio non ce n'è. Il suo vecchio modo sarà probabilmente più efficace per un po '.

* Nota: la cosa divertente delle conversazioni è che sono molto difficili da modellare. Hanno una vita tutta loro, quindi anche se sembra bello sulla carta, tende a sporcarsi un po '.

Spiega come vuoi che le cose vadano e mostragli come funziona con le scelte progettuali e architettoniche che hai fatto per il progetto all'inizio del progetto a cui lo farai lavorare. Siediti uno a uno (e in privato) e spiega i problemi che hai visto nella sua precedente codifica e perché sono un problema per questo progetto. Chiedigli cosa deve avere per migliorare, ma chiarisci che non migliorare non è un'opzione.

Quindi usa la revisione del codice come strumento per fargli aggiustare i suoi metodi di lavoro. Pianifica un buon tempo per il primo e parla davvero del perché preferisci questo e lascia che spieghi il suo ragionamento. Assicurati di ascoltarlo davvero, le persone sono più disponibili a cambiare quando sentono che le loro preoccupazioni sono state affrontate. Aspettatevi nella vostra pianificazione (ma non dirglielo) di avere una rielaborazione sulla prima attività e non accettarla fino a quando non rispetta gli standard della vostra squadra. Una volta che sa cosa ti aspetti e che non lo lascerai scivolare nell'interesse del tempo, probabilmente tornerà al tuo modo di lavorare. Ma potresti usare la revisione del codice come strumento educativo per diverse iterazioni. Non devi essere antipatico per non accettare il lavoro fino a quando non soddisfi i tuoi standard, ma devi essere coerente e coerente. Non lasciarlo scorrere a volte e non altri.

La domanda da $ 64.000 è se sta consegnando i suoi progetti in tempo e soddisfando i requisiti di funzionalità. Se è così, lo sta facendo bene. Non vi è alcun obiettivo oggettivo o errato nello sviluppo del software. In definitiva, è sulla risoluzione dei problemi. E se i problemi vengono risolti con soddisfazione del cliente / cliente, allora per definizione , lo sviluppo del software viene eseguito correttamente.

Diventa ovviamente un problema completamente diverso se i suoi progetti arent vengono completati. A quel punto le modifiche devono essere apportate dai supervisori, forse con il tuo contributo. Ma solo perché sta violando il tuo personale senso di codice estetico o la saggezza convenzionale di oggi non significa che quello che sta facendo è "sbagliato". Non sei l'arbitro della definizione di "codice buono". Dopo tutto, potrebbe avere una bassa opinione del tuo codice.

Quindi ... a meno che non ci sia effettivamente un problema con il suo lavoro (che non hai indicato che ci sia), non fare nulla. Parte di essere uno sviluppatore di successo sta imparando a fondere il tuo codice con gli stili di altri sviluppatori.

Poteva, dopo tutto, venire qui e pubblicare una domanda simile sul rapporto con uno sviluppatore meno esperto che è più interessato a stare al passo con le mode che a finire i progetti. È tutto sulla prospettiva.

In quanto sviluppatore junior che parla con uno sviluppatore senior, è troppo rischioso per te provare a contattarlo con idee migliori del suo.

Il modo migliore per affrontare questo è cercare di convincere il proprio capo di una pratica migliore, e vedere se farà un decreto che tutto il codice deve seguire standard specifici ed essere applicato a quegli standard attraverso recensioni di peer code .

Una considerevole porzione di persone è (anche se a livello subconcious) vendicativa, egoista e difensiva, anche se sono completamente inconsapevoli delle proprie motivazioni subconcio, si offenderanno se si tenta di cambiarle o implicare che esse sono in qualche modo sbagliati.

La catena di comando è il modo più sicuro di andare perché deve ascoltare il suo capo, né gli deve piacere. Lascia che il capo sia il cattivo, questo è quello che è lì per.

Se non riesci a vendere il capo o è il capo, allora gestisci i suoi bug ma conduci l'esempio nel tuo codice.

Non puoi.

Non puoi ispirare le persone a fare cose di cui non sono a conoscenza nello sviluppo del software. Parlo per esperienza, come ho provato a farlo spesso nella mia carriera, e ogni volta il risultato finale è che il mio stato personale diminuisce agli occhi della compagnia; Sono persino stato licenziato o smesso di frustrazione dopo che non è successo niente, semplicemente per cercare di migliorare la cultura dello sviluppo intorno a me alle pratiche moderne.

Se il tuo collega non era ignorante, puoi mostrarlo. Dal momento che lo sono, tuttavia, non c'è nulla che tu possa fare, dal momento che non sono capaci o preoccupati abbastanza del software-come-arte per sforzarsi di adottare migliori pratiche di codifica. Le probabilità sono che se ci provi, lo ignoreranno o rimarranno a bocca aperta senza una vera comprensione, che dai suoni di ciò che stanno già facendo ("Trial and Error Development", cioè semplicemente hackerando il codice finché gli errori non si interrompono) .