Ispirare un collega ad adottare migliori pratiche di codifica?

Nella domanda sulla gestione del mio antiquato collega , varie persone hanno discusso delle strategie per trattare con i colleghi che non sono disposti a integrare il loro flusso di lavoro con quello del team.

Vorrei, se possibile, apprendere alcune strategie per "insegnare" a un collega che è semplicemente ignorante delle tecniche e degli strumenti moderni, e forse un po 'apatico.

Ho iniziato a lavorare con un programmatore che fino a poco tempo fa ha lavorato in un relativo isolamento, in una parte diversa dell'azienda. Ha una vasta conoscenza del dominio e, soprattutto, ha dimostrato buone capacità di risoluzione dei problemi , cosa che sembra mancare a molti candidati.

Tuttavia, il codice attuale (C #) che ho visto è un ritorno ai giorni VB6. Struttura procedurale, notazione ungherese, variabili globali (abuso di static), nessuna interfaccia, nessun test, non utilizzo di Generics, lancio System.Exception... si ottiene l'idea.

Questo programmatore è un po 'più vecchio di me e, almeno per le prime impressioni, non cerca attivamente un cambiamento positivo. Non dirò resistente al cambiamento, perché penso che sia in gran parte un problema di come l'argomento viene affrontato e voglio essere preparato.

I programmatori tendono ad essere persone testarde, e andare avanti con le pistole infuocate e istituendo revisioni del codice da brivido e politiche rigorosamente applicate molto probabilmente non produrrà il risultato finale che desidero. Se questo fosse un nuovo assunto, un programmatore junior, non ci penserei due volte a prendere una posizione da "mentore", ma sono estremamente diffidente nel trattare un dipendente esperto come un principiante all'oscuro (cosa che non è - semplicemente non ha tenuto il passo con alcuni progressi nel campo).

Come potrei fare per aumentare lo standard di qualità del codice di questo sviluppatore alla maniera di Dale Carnegie, attraverso una leggera persuasione e incentivi non materiali? Quale sarebbe la migliore strategia per attuare cambiamenti sottili e graduali, senza creare una situazione contraddittoria?

Altre persone, in particolare i principali sviluppatori, si sono già imbattute in questo tipo di situazione? Quali strategie hanno avuto successo nello stimolare l'interesse e nel creare una dinamica di gruppo positiva? Quali strategie non hanno avuto successo e sarebbe meglio evitare?

chiarimenti:

Sento davvero che molte persone rispondono in base ai sentimenti personali senza realmente leggere tutti i dettagli della domanda. Si prega di notare quanto segue, che avrebbe dovuto essere implicito ma ora sto esplicitando:

• Questo collega è solo il mio "anziano" in virtù dell'età. Non ho mai detto che il suo titolo, la sfera di influenza o gli anni nell'organizzazione superino il mio, e in effetti nessuna di queste cose è vera. È un programmatore LOB che è stato assorbito nel negozio di sviluppo principale. Questo è tutto.

• Non sono un nuovo assunto, un programmatore junior o un altro idiota ingenuo con grandi progetti per trasformare l'azienda durante la notte. Fondamentalmente sono responsabile del processo del software, ma lo sapranno tutti coloro che hanno lavorato come "lead", le responsabilità non sempre sono correlate esattamente all'organigramma.

• Sto non chiedere alla gente come ottenere il mio modo, venite inferno o l'acqua alta . Potrei farlo se volessi, con il risultato netto che questa persona diventerebbe risentita e / o abbandonata. Per favore, cerca di capire che sto cercando un metodo sociale e cooperativo per guidare il cambiamento.

• La menzione di "... variabili globali ... nessun test ... lancio System.Exception" aveva lo scopo di dimostrare che i problemi non sono solo superficiali o estetici . Le pratiche che possono funzionare per app CRUD relativamente piccole non funzionano necessariamente per le app di grandi aziende e, in effetti, finora nessuno dei codici ha superato i test di integrazione.

Per favore, prova a prendere la domanda al valore nominale, accetta che io sappia davvero di cosa sto parlando e rispondi alla domanda che ho effettivamente posto o vai avanti.

PS La mia più sincera gratitudine a coloro che hanno offerto consigli costruttivi piuttosto che litigare con la premessa. Ho intenzione di lasciarlo aperto per un po 'di più mentre spero di sentire di più nel modo delle esperienze del mondo reale.

Il punto di partenza è conoscere il tuo pubblico . Sembra che tu lo capisca già perché conosci la differenza tra tutorare un collega junior e influenzare un collega senior.

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 insegnare / insegnare agli altri, potresti affrontare un problema ponendo domande del tipo "perché lo fai in questo modo?" Questo può far andare una finestra di dialogo in cui puoi chiedergli di valutare nuovi approcci e dare la sua opinione.

Se il problema persiste, puoi segnalare i bug che possono essere evitati utilizzando le pratiche o gli stili che vorresti che adottasse. Questo richiede molto più lavoro perché devi trovare i bug e mostrare come i comportamenti che desideri incoraggiare potrebbero aiutare.

Se sembra disposto ad aiutare gli altri, puoi appellarti al suo desiderio di aiutare i neofiti . Spiega che "i bambini di oggi" non sono abituati a vedere il suo stile di programmazione e sarà più probabile che lo infrangano a causa di ciò.

A volte potresti dover solo metterlo in faccia e forzare il problema. Devi scegliere attentamente queste battaglie. Assicurati di iniziare con un argomento in cui sai che puoi provare a lui che hai un modo migliore.

Penso che tu abbia l'atteggiamento giusto. Assicurati solo di dire tutte le cose carine che hai già detto - Grandi capacità di problem solving, conoscenza approfondita del business, ecc. E chiedigli solo un po 'del suo tempo per mostrargli gli standard attuali che il gruppo è usando e dargli la possibilità di porre alcune domande su di loro.

Quando ti riunisci, portagli un caffè o qualcosa del genere e fagli sapere che lavorare secondo gli standard gli porterà benefici facilitando il supporto del tuo codice esistente e facilitando anche la possibilità che qualcuno lo aiuti se viene coperto nel lavoro (un grande vantaggio per qualcuno che ha lavorato in isolamento), ecc.

Assicurati che sia fidanzato e riceva buone spiegazioni del 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 farle spiegare a te. Renditi disponibile in seguito se ha domande e segui alcuni punti a cui può fare riferimento per esempi dei tuoi standard.

Se non è interessato dopo, puoi fare riferimento alla prima domanda che hai collegato.

È davvero il lavoro del tuo manager

1. Renditi conto che l'azienda deve avere uno standard di codifica. Ogni azienda in qualche modo professionale ha questo, indipendentemente dalle dimensioni dell'azienda.
2. Chiedi a tutti di sedersi insieme e iniziare 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 è qualificato per il proprio lavoro. E in tal caso, dovresti dare loro alcuni colpetti sopra i due sopra. I vantaggi di avere uno standard di codifica sono tanti, non ci sono davvero argomenti contro averne uno. (Se alcuni programmatori pensano di essere "artisti" e non dovrebbero essere limitati dai limiti della professionalità, dovrebbero invece trovare un lavoro facendo belle arti.)

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

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

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

Se, tuttavia, c'è un motivo tecnico per questo, allora dovresti considerare di avvicinare detta persona con qualcosa del tipo:

Ho un suggerimento su come risparmiare tempo noioso per te e denaro per l'azienda. Sei interessato?

Essere consapevoli del fatto che si tratta di frutti a bassa pendenza perché molto probabilmente richiederanno il cambiamento delle abitudini esistenti che richiedono sempre uno sforzo extra.

Anche se hai milioni di suggerimenti, basta sceglierne uno o due e dimostrare che sarà un cambiamento in meglio.

O funzionerà e ti verrà chiesto se hai più suggerimenti, oppure no e il danno è limitato a uno o due suggerimenti.

Nota che è molto importante che diventi un successo e lo fa rapidamente.

Inoltre devi stare attento. Ci potrebbe essere molto buone ragioni per fare le cose nel modo in cui sono fatte, ma che sei troppo nuovo di aver visto perché. Quindi, sii rispettoso con il tuo anziano e chiedi prima di assumere che il tuo suggerimento sia migliore. Potresti imparare una cosa o due.

Vorrei scoraggiarti gravemente dal metterti in faccia perché ciò peggiorerebbe molto rapidamente la situazione. Mi rendo conto che è stato sollevato come un ultimo tipo di misura, ma nella mia esperienza, a questo punto, lo sviluppatore ha funzionalmente smesso di partecipare.

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

Se questo individuo ha veramente conoscenza del dominio di cui hai bisogno / desideri, fagli documentare quella conoscenza.

A partire dal romperlo delicatamente: non so quanto tu sia esperto e esperto nel dare feedback. Potresti già sapere, impiegare o addirittura aver rifiutato quanto segue, ma qui va comunque. Ci sono alcune linee guida su come dare feedback quando vuoi cambiare il comportamento di qualcuno. La struttura della conversazione che ho pensato, e cerco ancora di impiegare in 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 molte variabili statiche nel tuo codice"
2. Descrivi come ciò influisce su te / la tua squadra. Esempio: "Trovo difficile mantenere tale codice"
3. Offri un ragionevole soluzione . (le possibili soluzioni sono menzionate in altre risposte e mi dilungherò in me stesso più avanti questa risposta.)
4. Dagli l'opportunità di discutere la soluzione. Chiedigli cosa ne pensa della soluzione. Prendi la sua risposta al valore nominale. Gli hai dato la tua opinione ed è libero di accettarla o meno. *

Una rapida risorsa sul feedback è ad esempio disponibile su http://managementhelp.org/communicationsskills/feedback.htm (sebbene ci sia una pletoria di questo tipo di cose sul web)

Ora, per quanto riguarda la soluzione, da quello che sto leggendo nella tua risposta, mi accorgo che è molto intelligente e ha la giusta mentalità, ma è solo dietro le buone pratiche moderne. Questi richiedono tempo e fatica per padroneggiare, a parte l'apprendimento reale su di loro in primo luogo, quindi dovrai fornirgli l'opportunità di farlo. Ciò probabilmente significa raccogliere risorse di apprendimento (web, riviste, libri, qualunque cosa) come punto di partenza e fornirgli tempo libero per studiarle. Potrei immaginare di dargli ogni venerdì pomeriggio per allargare i suoi orizzonti sullo stile di programmazione, dove può fare tutto ciò che crede promuove tali obiettivi. Le persone vogliono intrinsecamente migliorarsi. Fornire i materiali e il tempo e ne faranno buon uso.

Forse ancora più importante, non aspettarti un cambiamento durante la notte. Ha fatto le cose a modo suo per molto tempo e probabilmente è diventato abbastanza bravo. Ci vorrà del tempo per diventare bravo in un nuovo modo di fare le cose, e per un po 'probabilmente non vedrà molto valore in nuovi modi, 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 propria, quindi anche se sembra bello sulla carta, tende a confondersi un po '.

Spiega come vuoi che le cose vengano fatte e mostragli come funziona con le scelte di progettazione e architettura che hai fatto per il progetto all'inizio del progetto su cui lo farai lavorare. Siediti uno a uno (e privatamente) 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 utilizzare la revisione del codice come strumento per convincerlo a modificare i suoi metodi di lavoro. Pianifica un lungo periodo di tempo per il primo e parla davvero del motivo per cui preferisci questo e lascia che gli spieghi il suo ragionamento. Assicurati di ascoltarlo davvero, le persone sono più suscettibili di cambiare quando sentono che le loro preoccupazioni sono state affrontate. Aspettati nella tua pianificazione (ma non dirglielo) di avere una nuova elaborazione del primo compito e non accettarlo fino a quando non soddisfi gli standard del tuo team. Una volta che sa cosa ti aspetti e che non lo lascerai scivolare nell'interesse del tempo, probabilmente verrà al tuo modo di lavorare. Ma potresti usare la revisione del codice come strumento educativo per diverse iterazioni. Non devi essere cattivo di non accettare il lavoro fino a quando non soddisfi i tuoi standard, ma devi essere sicuro e coerente. Don'

La domanda da $ 64.000 è se sta consegnando i suoi progetti in tempo e soddisfacendo i requisiti di funzionalità. Se è così, lo sta facendo bene. Non esiste un obiettivo giusto o sbagliato nello sviluppo del software. In definitiva si tratta di risolvere i problemi. E se i problemi sono risolti per la soddisfazione del cliente / cliente, quindi per definizione lo sviluppo del software viene eseguito correttamente.

Ovviamente diventa un problema completamente diverso se i suoi progetti non sono disponibili vengono completati. A quel punto i supervisori devono apportare modifiche, magari con il tuo contributo. Ma solo perché sta violando il tuo personale senso dell'estetica del codice o la saggezza convenzionale di oggi non significa che ciò che sta facendo sia "sbagliato". Non sei l'arbitro della definizione di "buon codice". Dopotutto, potrebbe avere una bassa opinione del tuo codice.

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

Dopotutto, potrebbe venire qui e pubblicare una domanda simile su come trattare con uno sviluppatore meno esperto che è più interessato a tenere il passo con le mode piuttosto che a finire i progetti. Si tratta di prospettiva.

Come sviluppatore junior che parla con uno sviluppatore senior, è troppo rischioso per te provare ad avvicinarlo con idee migliori delle sue.

Il modo migliore per affrontare questo è cercare di convincere il proprio capo di una pratica migliore e vedere se decreterà che tutto il codice deve seguire standard specifici e essere applicato a tali standard attraverso revisioni del codice peer.

Una parte considerevole di persone è (anche se a un livello subcosciente) vendicativo, egotistico e difensivo, anche se sono completamente inconsapevoli dei propri motivi subconcisi, si offenderanno se si tenta di cambiarli o implicano che si sbagliano Comunque.

La catena di comando è il modo più sicuro di procedere perché DEVE ascoltare il suo capo, né gli deve piacere. Lascia che il capo sia il cattivo, ecco a cosa serve.

Se non riesci a vendere il capo o lui è il capo, risolvi i suoi bug, ma dai 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 mentre ho cercato di farlo spesso nella mia carriera e ogni volta il risultato finale è che il mio status diminuisce agli occhi dell'azienda; Sono stato anche licenziato o abbandonato per la frustrazione dopo che non è successo nulla, semplicemente per aver cercato di migliorare la cultura dello sviluppo intorno a me alle pratiche moderne.

Se il tuo collega non fosse ignorante, potresti mostrarlo. Dal momento che sono, tuttavia, non c'è nulla che tu possa fare poiché non sono in grado o si preoccupano abbastanza del software come artigianato per sforzarsi di adottare migliori pratiche di codifica. È probabile che se ci provi, lo ignoreranno o si muoveranno senza davvero capire, che dai suoni di ciò è ciò che stanno già facendo ("Sviluppo di tentativi ed errori", ovvero solo hackerare il codice fino a quando gli errori si fermano) .