Come convertire un programmatore copia / incolla / spaghetti per vedere la luce?

Ti sei trovato il motivo: "So che sono capaci di imparare, sembra solo che ci sia una generale mancanza di motivazione."

Ci sono persone che sono appassionate del loro lavoro. E ci sono altri che, a volte abbastanza competenti, stanno lavorando solo per soldi . Conoscono le loro cose, ma non godono del loro lavoro. Non impiegheranno più tempo a fare ulteriori refactoring per rendere il codice leggibile o risolvere un problema intrigante quando un hacker veloce e brutto può fare il lavoro.

Questo fenomeno esiste in ogni lavoro. È solo che alcuni lavori non sono estremamente eccitanti (hai visto un contabile che ama il suo lavoro e lo ha già sognato quando era bambino?), Ma nella programmazione, ci sono molte persone che amano davvero quello che fanno (altrimenti Programmers.SE sarà abbastanza vuoto). Ciò significa che come sviluppatori appassionati, che parlano quotidianamente ad altri sviluppatori appassionati, abbiamo più possibilità di essere sorpresi nel vedere una persona che fa programmi solo per soldi.

Che cosa possiamo fare? Non troppo. In tutti i casi, non è per te, ma per le risorse umane scegliere persone veramente motivate¹. E licenzia le persone che non lo sono.

Puoi provare a motivare i tuoi colleghi, ma è estremamente difficile. Se dai loro libri da leggere, li restituiranno non aperti alcune settimane dopo. Se dai loro un consiglio, loro non ascolteranno, perché a loro non importa².

Puoi:

• Convinci il tuo capo a stabilire una serie di regole rigide nella tua azienda: linee guida di stile , ecc. Questo non motiverà le persone a fare un lavoro migliore, ma almeno non lo faranno essere in grado di commettere codice sorgente che non corrisponde ai requisiti.

• Lavora sui requisiti, in particolare requisiti non funzionali . Per quanto riguarda un requisito che indica che un progetto specifico deve contenere meno di 5 000 righe del codice IL (no, non sto parlando della LOC senza senso ) ³? Che dire della necessità di ottenere risultati specifici a complessità ciclomatica o accoppiamento di classe ?

• Aumenta il numero di ore che spendi nella tua azienda facendo recensioni del codice . Specificare cosa viene esaminato: se si dispone di una lista di controllo, aggiungere i punti relativi a refactoring, leggibilità, commenti puliti e utili, ecc. Se non si dispone di una lista di controllo, è necessario.

• Utilizza [altro] programmazione coppie . Può aiutare a migliorare la qualità del codice e motivare i colleghi meno motivati.

• Utilizza il sistema di compensazione simile a cosa è usato a Fog Creek.

^{¹ Ecco di che cosa parlano le interviste: prima di assumerti, le risorse umane devono mettere insieme non solo il tuo livello tecnico, ma anche la tua motivazione . Purtroppo alcune aziende dimenticano questa seconda parte dell'intervista e assumono persone che non amano programmare troppo. Fortunatamente, nella maggior parte dei casi, il lavoro in quelle società non è mai piacevole, e il test di Joel raramente supera 2.}

^{² Loro veramente non si preoccupano, anche se guadagnano meno denaro. Sono molto vicino a uno dei miei clienti (io sono un freelance) che crede che il suo lavoro sia quello di sviluppare siti Web per i propri clienti. Ha anche un designer. Ho detto loro molte volte in che modo possono aumentare la loro produttività di 2 o più. Se hanno appena assunto qualcuno competente, aumenterebbero le loro entrate di almeno 3. Ma hanno abbastanza soldi e non si preoccupano della qualità o di quanto costano ai clienti ignoranti, rispetto a qualcuno produttivo.}

^{³ Quello che intendo è il numero di righe del codice IL che vedi in Metriche del codice in Visual Studio , la metrica che in realtà significa qualcosa. La real LOC non ha importanza e non devi misurarla; è una delle metriche più stupide di sempre. Applicare le linee di codice IL significa che gli sviluppatori saranno costretti a fare effettivamente il codice refactoring, e non solo per comprimere dieci righe di codice in una singola riga illeggibile.}

"I'm done coding, just need to refactor and split into multiple classes to make DXM happy".

Quella linea di pensiero proprio lì è un cancro su qualsiasi squadra e ucciderà la motivazione di tutta la squadra se non curata immediatamente. Mi riferisco ovviamente al fatto che per anzianità e / o merito ti trovi in una posizione di autorità tecnica, dandoti il potere di influenzare e portare buone pratiche nella tua squadra.

Questo è tutto a posto, ma se la tua squadra è stata chiaramente venduta in questi processi, non ti escluderebbero in dichiarazioni come questa che mostrano chiaramente una mancanza di rispetto per il processo e una mancanza di rispetto nei tu. Considera ancora queste best practice come un ostacolo causato da te e non un processo di proprietà del team che la tua squadra difenderà dei propri meriti.

Nei precedenti commenti hai menzionato che altri membri del team stanno effettivamente seguendo bene queste pratiche e questi standard e li stanno applicando correttamente. Concentrate l'attenzione prima di rafforzare il sostegno da parte loro, chiedete loro cosa funziona, cosa non funziona, cosa gli piace e cosa vorrebbero vedere cambiato. Se lo fai e prendi sul serio le loro opinioni, si sentiranno in modo molto diverso rispetto agli standard come se fossero una decisione comunitaria invece di una procedura da loro impartita da un superiore.

Rafforza il supporto per le best practice e gli standard facendo notare al team come hanno migliorato il processo di sviluppo del software o la qualità del software.

Mantieni una votazione sulle questioni da discutere e documenta i risultati, idealmente ogni decisione dovrebbe essere unanime per motivi di legittimità, ma se hai a che fare con ostruzionisti intransigenti questo potrebbe essere impossibile e potrebbe semplicemente bloccare ogni problema. Utilizzare un voto a maggioranza in questa situazione. Se la maggioranza è contraria ai tuoi standard e alle tue pratiche proposte, hai già perso la stanza, abbandonala a quel punto.

Loro possiedono quegli standard e procedure e imporranno in modo che tu non debba farlo. Come leader tecnico non dovresti dichiarare editti e decreti, questo è un modo povero per essere un leader.

Una volta che il team ha la sensazione di possedere le procedure, i membri del team che iniziano a etichettarti su determinate procedure e best practice saranno illegittimi. Il tuo team ti aiuterà a correggere questo atteggiamento negli altri.

Buona domanda! Penso che la risposta dipenda dal perché le persone non vogliono migliorare le proprie capacità. Le risposte possibili sono:

• Pensano di essere troppo occupati per imparare qualcosa di nuovo o pensano che il nuovo modo di fare le cose (come scrivere tutti quei test) li richiederà più a lungo e non hanno tempo per quello. Quindi la risposta ovvia sarebbe: dargli più tempo. Imparare qualcosa o provare qualcosa come TDD quando hai sempre fatto le cose in modo diverso impiegherà più tempo il primo paio di volte. Se i tuoi programmatori non hanno quel tempo, non puoi biasimarli per non aver provato.
• Hanno una diversa percezione delle proprie capacità, cioè pensano di essere dei bravi programmatori che producono codice di alta qualità. Questo è un terreno psicologico difficile, perché distruggere quella credenza può essere molto demotivante. Forse una sorta di competizione informale può aiutare (chi produce il minor numero di difetti / funzionalità? Il codice più corto? Il minor numero di WTF / minuto in una revisione del codice?).
• Potrebbe esserci un vero problema di motivazione (cioè vogliono solo "fare il loro tempo e restare soli" fino all'orario di chiusura). Fortunatamente, questo è troppo generale / non correlato alla programmazione, perché in realtà non ho una risposta per questo.
• Sono principianti e non lo sanno meglio. In tal caso, formazione, revisioni del codice potrebbero aiutare o un "club del libro" in cui un membro del team deve discutere un nuovo libro tecnico ogni mese.
• Hanno già visto proiettili d'argento (e ne sono stati amaramente delusi) e pensano che qualunque cosa tu stia cercando di venderli è solo un'altra nuova parola d'ordine che suona bene in teoria ed è poco utile nella pratica. In tal caso, dimostrare i vantaggi durante le revisioni del codice e le sessioni di programmazione di coppia potrebbe funzionare. Cerca di non essere un saputello totale quando lo fai.

La soluzione migliore dipende in realtà dal problema principale: ad esempio, le linee guida, le metriche e le revisioni di codifica formali possono funzionare per i principianti, ma le persone nella "percezione errata delle proprie abilità" - la folla potrebbe lottare contro di loro o giocare le metriche perché li vedono come ostacoli burocratici controproducenti per portare a termine il loro lavoro.

The real question is how do you approach such a person/team and make them curious about better way of doing things? How do you inspire them to learn? Without that, it seems that all the teaching, meetings, lectures, discussions are useless if they are perfectly happy going back to their desk and doing what they've always done.

Questo è tutto! Questa è davvero una domanda reale.

Per dare qualche backgound, semplicemente non abbiamo il tempo di mettere un sacco di training formale - ma occasionalmente se lo faccio - non vede ancora alcuna luce. Ho anche fatto parte del aziende in cui la formazione formale diventa un processo vero e proprio e sono spesso testimone che difficilmente insegnano a loro come pensare.

Quindi la domanda che pongo loro non è come insegnarli - ma come farli apprendere? La differenza è sottile ma è ciò che sta per fare tutta la differenza.

Non so se ho ragione; ma spesso credo in una finestra di dialogo di Matrix del film - "È la domanda che ci guida! " La cosa più importante è farli riflettere, fargli chiedere perché! E, naturalmente, la maggior parte di quelli che pensano di sapere già tutto su alcuni modelli di progettazione perché hanno ottenuto buoni voti nei corsi universitari - sono i più difficili lì.

Come fai a fargli queste domande? Il mio approccio generale è "che li butta nello stagno se vuoi che imparino a nuotare" . Sono d'accordo che le persone potrebbero non essere d'accordo; e accetterò volentieri di non essere d'accordo con loro. Quando li lanci nello stagno - in realtà non imparano a nuotare automaticamente; ma scatena un istinto di sopravvivenza che li fa pensare - una volta che ciò accadrà, penseranno naturalmente a COME e PERCHE '.

Un esempio pratico che dò alla gente è di metterli in un progetto molto complesso rispetto a quello che speravano di ottenere uno su di esso e lasciarli combattere la propria battaglia. Quando hanno iniziato a sbrogliare il codice e hanno difficoltà a rintracciarlo, capisci che iniziano a fare una bella domanda.

Potrebbe sembrare un po 'estremista, potrebbe sembrare spreco di risorse . E sono sicuro che ci sono molti altri che mi daranno il consiglio di non farlo. Ma questo ha funzionato per me!

Indipendentemente dai pacchetti di pagamento e dai tag HR che assegni, non risolverai il problema della motivazione di base . Per questo solo percorso è che sono sfidati; Se scintilla di questo spirito umano di base, tutto il resto funziona. Se non lo fai, è una partita libera.

PS: per inciso ho postato una risposta qui link - e ho avuto tutti i colpi; principalmente la maggior parte della gente crede che in qualche modo le aziende non possono permettersi di sprecare risorse! Sono sicuro che questa risposta potrebbe ricevere un trattamento simile qui. Ma la verità è che far lavorare le persone e farle credere nel fare un buon lavoro è un argomento di psicologia umana su come costruire il programma del corso.

Ad ogni modo, il compito che stai descrivendo qui equivale ad accendere la passione interiore per fare grandi cambiamenti. E più grande diventa il sistema più difficile. Inizia con giovani che sono ancora integrati nello spirito di i-won-to-do-good-job e sfidano lo status quo.

Come fai notare, la sua motivazione. Non scambiarli per non aver cura di loro non sapendo. Sanno chiaramente cosa fare. A loro non interessa . Se questo è il caso, la vera domanda qui è ... qual è il tuo management che sta facendo torto che li tiene così immotivati? Sei il nuovo membro del team? Forse hanno passato tutto questo prima, portando solo a problemi dalla loro gestione. Quindi si limitano a fare la quantità minima di lavoro necessaria per mantenere il loro lavoro perché non penseranno che fare di più sarà risposto dal datore di lavoro.

Mi sembra che questo sia un problema di gestione e di leadership: se il tuo team quindi può lavorare per migliorare (personale e del codice) un attributo fondamentale della tua squadra, la domanda sarà supportata da < em> la tua gestione - perché vuoi fare cose che richiederanno del tempo (otterranno una vincita netta poiché dovresti ridurre il debito tecnico e rimborsare il debito tecnico esistente).

Quindi, asserisci che vuoi migliorare la squadra, ottieni il loro accordo sul fatto che questa è una buona cosa (che il team, nel suo insieme, lavori per migliorare la qualità del suo codice) e poi inizi su un programma per far si che questo accada - sembra così facile ... sono consapevole che no!

Penso che ci siano due parti in questo: educazione e pratiche di lavoro.

• Istruzione puoi iniziare un pranzo a settimana - tutti mangiano insieme, hai una presentazione di 20 ~ 30 minuti con Q & A. Inizi con le basi che desideri - SOLID può occupare le prime 2 ~ 4 settimane - nel corso del tempo la squadra parla a rotazione e puoi capire come decidere chi parla di cosa tra di voi. Consentire agli oratori un po 'di tempo di preparazione nel lavoro. Oltre a ciò, incoraggiare la partecipazione di gruppi di utenti locali (rendendola almeno parzialmente sociale, se possibile)
• Pratiche di lavoro ... beh dipende da cosa fai adesso e da quali strumenti hai, ma potresti voler guardare agli standard di codifica concordati, introdurre la revisione del peer code (è solida), test delle unità (non necessariamente prova prima), eseguendo un server di integrazione continua e osservando test più automatizzati (oltre ai test di unità). Ma questi devono essere introdotti sostanzialmente con il consenso / accordo (non con il server build / CI!) E si deve voler guidare la qualità in avanti come una squadra. Ci sono sempre cose che si possono migliorare (Kaizen)

Vale anche la pena guardare Kanban (che è visto come un driver per il cambiamento / miglioramento).

Un ultimo pensiero - Sono un programmatore vocazionale, e vorrei che il mio team fosse lo stesso ma che lavora più di 40 ore alla settimana non è in realtà una buona cosa, quindi l'obiettivo dovrebbe avere una squadra che riesca a svolgere il proprio lavoro in modo efficace e nella normale settimana lavorativa e, rispetto a ciò, l'argomento per migliorare la pratica lavorativa è che è più probabile ad esempio: aggiungere test unitari per dimostrare il caso di fallimento quando (prima) bug -Il fixing ti dà la certezza che è corretto; avere un server di build ti dà fiducia nella tua capacità di costruire le tue soluzioni in modo pulito - se anche questa build genera pacchetti di implementazione, significa che l'implementazione è drasticamente semplificata; Il codice SOLID è, per definizione, più facile da modificare; e su tutta la linea del debito meno tecnico che tu sostieni, meno devi ripagare ...

Sono caduto in programmazione per caso ~ 30 anni fa. Ero motivato ad apprendere i principi base dell'ingegneria del software essendo stato assegnato per mantenere / supportare il codice di altre persone. In questi incarichi, ho imparato come un lettore di codice sperimenta il codice - come entrare in empatia con il lettore di codice. Non volevo infliggere il dolore del mio codice scritto male agli altri!

Questa pratica di assegnare nuovi programmatori per mantenere / supportare il codice di altri popoli non è una bacchetta magica, e sembra fornire la motivazione per imparare a produrre codice solido il più delle volte.