Presentazione di nuovi argomenti ai colleghi di lavoro

Per "provare" e quindi impiantare davvero un'idea nella testa di qualcuno, la teoria (parlare) non è mai abbastanza.

Devi usare quelle pratiche nel tuo codice e farle "scoprire" che ha risolto i problemi in modo carino.

Ciò implica che le tue pratiche devono essere efficaci e dovresti renderlo ovvio.

In questo modo, leggere il tuo codice li ispirerà come lo vedranno "in azione".

Non dare per scontato che solo raccontando come funziona sarà sufficiente.

Parlando dall'esperienza, se non sono disposti ad applicare ciò che stai cercando di insegnare loro, significa che a loro non importa. Probabilmente stai sprecando il tuo tempo cercando di presentare loro gli argomenti, perché se capivano i reali benefici di quegli argomenti avrebbero vogliono applicarli, non dare scuse sul motivo per cui non possono .

È proprio come cercare di introdurre qualcosa di meglio di ciò che viene attualmente utilizzato e ottenere sguardi vuoti o risposte immediate perché non è possibile farlo; è indicativo che l'altra persona non la veda come un beneficio (perché se fosse in grado di vedere il beneficio, non darebbe una scusa).

Triste ma vero. Forse la tua situazione è diversa, ma mi sono imbattuto in un paio di volte nel passato e alla fine è stato dolorosamente ovvio che nessuno tranne me era interessato a quegli argomenti; Alla fine ho preso la decisione di andarmene e cercare di trovare collaboratori che si prendono cura di loro; il tipo di persone che non hanno bisogno di me per introdurre gli argomenti (perché già li conoscono / li usano) o che accettano di accettarli, invece di dire come non possono farlo.

Ho visto molte "buone pratiche" fallire e non essere mai più utilizzate. Esistono molti tipi di progetti e tali tecniche non sono adatte a tutti i progetti. Assicurati che le cose che stai vendendo ti saranno di grande aiuto.

Se inizi a farlo e le persone vedono che sei più produttivo o produci un codice di qualità migliore, avranno un altro aspetto dopo. Pensaci bene, tutto il sovraccarico in più aiuterà davvero il tuo progetto? Non tutte le app ne hanno bisogno.

Se puoi motivare i tuoi colleghi a prendere parte, puoi organizzare Coding Dojos . Queste sono sfide di programmazione in cui i partecipanti si concentrano deliberatamente sul miglioramento della pratica. Forse, ad esempio, prendere parte a un dojo guidato dai test porterà i tuoi colleghi a vedere i benefici nel TDD.

In alternativa, a volte queste cose devono essere imposte dalla cultura. Mi sembra che la cultura della tua azienda non ne abbia bisogno.

Se diventano un'esigenza di chiusura del progetto (probabilmente una decisione da parte del management), vedrai delle difficoltà, ma almeno alcune applicazioni di tali strumenti e la cultura inizieranno a cambiare.

La migliore pratica è sul codice di produzione reale. I Katas sono una bella introduzione, ma nella mia esperienza, non mantengo lo stesso "Eureka!" Momenti di vederlo fatto per davvero .

Tuttavia, hai sottolineato che le linee temporali "non consentono sperimentazione". È davvero una soluzione semplice. Stai già facendo queste cose che stai cercando di insegnare, quindi lascia un invito aperto per metterti in contatto con te mentre stai implementando la nuova fantastica funzionalità X. Lascia che si siedano alla tastiera e digitano mentre sei " guida indietro ". Questo permetterà loro di costruire memoria muscolare e sicurezza.

Buona fortuna per i tuoi sforzi.