Come faccio a convincere la gente a smettere di andare in bicicletta (concentrandosi sulle trivialità)?

Penso che il problema sia il compito: "Sono stato incaricato di insegnare ad altri team un nuovo codice base".

Ti è stato assegnato un lavoro sbagliato, o forse hai interpretato erroneamente il lavoro che ti è stato dato.

Presentando a livello di codice, inviti a pensare a livello di codice.

Inizia a livello di sistema e presenta il design e le scelte progettuali che sono state fatte. Non consentire discussioni estese: non lo stai rivedendo. Consenti domande: vuoi che capiscano il sistema. Se la gente "lo avrebbe fatto diversamente", va bene. Forse sono d'accordo. O no. Ma andare avanti. È come è adesso.

Quando arrivi al livello di codice, li avrai già innescati con la terminologia di sistema. I nomi (presumo) avranno un senso. Come sopra: nessuna discussione estesa, domande per la comprensione. Continua.

Ora imposta alcuni problemi di classe su cui lavorare. Come possiamo migliorare X? Scegli qualcosa di non banale che "accompagni il flusso" del design del sistema e che lavori attraverso ciò che cambieresti. Dovrebbero avere la logica del sistema ora. Scegli un altro miglioramento che potrebbe rompere il sistema se fatto male, e mostrare come può essere fatto bene. Questo dovrebbe essere un momento per Ah Ha . Alcuni potrebbero addirittura batterti!

È un concerto difficile, soprattutto dopo la falsa partenza che hai avuto. Sembra che tu abbia già investito molto tempo e sforzi, e forse c'è un po 'di me rispetto a loro. 'Fess up, e ricominciare. Assumiamo che siano persone intelligenti. Dai loro la sfida di pensare al livello più alto. E spezza i gruppi che esistono già selezionando diverse sezioni trasversali di team per le nuove sessioni.

"Parcheggiali". All'inizio della lezione, spiega cosa discuti e spiega chiaramente cosa è considerato Off Topic. Se ti viene fatta una domanda che è chiaramente OT, dillo e vai avanti. Se tornano su di esso, scrivi la domanda su una lavagna (Questo è fondamentale) per una discussione successiva e vai avanti. Alla fine della lezione, quando sono a tempo debito, non i tuoi, guarda quanto velocemente queste domande vengono risolte.

Stabilisci le aspettative correttamente e sii onesto, aperto e in anticipo.

Assicurati che i tuoi obiettivi siano aperti e trasparenti.

Inizia le discussioni con la visualizzazione di alto livello promossa da andy256 (+1), ma assicurati anche di includere gli obiettivi, ad es.

"... mentre guardiamo a questo problema, assicuriamoci di non focalizzarci su x, yez. Assicuriamoci anche di non esaminare i dettagli dell'implementazione come a, b, c o dettagli insignificanti come j, k, 1. So che ci sono molti dettagli nel codice e dettagli che potrebbero essere affrontati, migliorati o resi più standard, ma proviamo a vedere cosa sta realmente ottenendo in un prima livello più alto "

So how do you educate other programmers enough that they stop fixating on trivialities and can meaningfully contribute to the design?

Per prima cosa, non pensare alle loro preoccupazioni come a "banalità" o "bikehedding". Quelle sono parole giudicanti e insultano. Le loro preoccupazioni sono valide. Al momento non sono importanti.

La chiave di ogni buon incontro è che tutti sappiano:

• perché stai organizzando una riunione e
• cosa speri di ottenere da esso
• quanto tempo dovrebbe durare

Afferma queste cose in anticipo, esplicitamente e spiega gli obiettivi.

Ad esempio, potresti dire: "Questo incontro è per me per familiarizzare con il pacchetto Foo e come è usato nel nostro modulo di segnalazione. Il mio obiettivo è farti capire abbastanza su Foo da poter lavorare sui Bar Reports progetto in arrivo la prossima settimana. Mi piacerebbe che venissimo fatti nei prossimi 90 minuti. "

Quindi, quando viene visualizzato un argomento, potrebbe essere simile a questo:

New person: "Why is FooWidget implemented as a facade pattern?"

You: "Well, I think it's because (short explanation of design decision)" or "I don't know."

Se la risposta è sufficiente, è grandioso. In caso contrario, e continua:

NP: "Don't you think it would be better done as a singleton?"

You: "I hadn't really thought about it, but I'd like to keep moving ahead with explaining how FooWidget works."

NP: "But if it's done as a singleton then we can--"

You: "I'm sorry to interrupt, but I need to keep this focused on how FooWidget works. This meeting is only scheduled until 11:00 and we have a lot to get through. The design discussion will have to wait for another time."

Dopo averlo esaminato una o due volte, puoi abbinarlo a "Questo è al di fuori dello scopo di questo incontro."

Nota che non stai dicendo "Che stupido preoccuparti" o "Non importa" o "Stai zitto" o "Sei troppo nuovo per avere un input". Stai semplicemente concentrando l'incontro su ciò che deve essere fatto e il tempo necessario.

In alcune organizzazioni non sarai mai in grado di raggiungere questo obiettivo. Molte organizzazioni considerano la lotta politica e la scalata delle scale molto più della capacità intellettuale, della diligenza e della lealtà. E perché non dovrebbero loro. L'arrampicata sulla scala mette le persone nelle posizioni di potere, permette loro di migliorare le loro vite personali con un reddito più discrezionale e in realtà non diventa mai obsoleto.

Confrontate questo potente conflitto con l'effettiva risoluzione dei problemi, il pensiero astratto e prendendo decisioni su questioni difficili che potrebbero essere responsabili delle conseguenze successive, e molti dipendenti pesano molto sul lato del tentativo di andare in bici il più possibile.

L'unico consiglio che ti suggerisco è di renderlo chiaro, nel contesto della tua organizzazione, se possibile, che questi partecipanti destino personale dipendono dalla loro comprensione, contributo e impegno per il vero problema che stai cercando di risolvere. Se questa è l'architettura aziendale, espressa in questo -errant-codebase e tutti gli errori, è tutto. Fai capire loro che devono fornire un input significativo e significativo su che . Non un'altra casualità, che sembra essere un pet-peeve di un anziano o di qualcuno e otterrà loro dei bei punti brownie concordando con qualcuno di cui sopra.

Questo è spesso difficile da fare, dato che i senior solitamente non capiscono la tecnologia in corso, non sono interessati e sfortunatamente controllano le materie prime: tempo impiegato; noleggio e amp; fuoco, conferenze, politica, promozioni, ecc., ecc. sul serio, eccetera.

Ciò che chiamate bikehedding, chiamerei convertire il flusso di pensieri di qualcuno nel nostro. Discutendo di nomi, schemi, arrivano a capire il codice nei loro termini e non c'è modo di prevenirlo, è necessario.

Inoltre, non c'è alcun bisogno di fare una dettagliata spiegazione di un intero codice base, perché i dettagli saranno dimenticati molto prima che possano iniziare a lavorarci.

Sulla base di queste due idee, suggerirei di suddividere il codice base in unità e gli studenti in gruppi di due persone. Per ogni unità di codice, ogni gruppo avrà, diciamo 25 minuti (dipende dalle LOC ovviamente), per essere in grado fare una passeggiata di 5-10 minuti del codice agli altri. Tre minuti di domande e ripetere con l'unità successiva. Spiegare è la parola chiave; devono assicurarsi che gli altri abbiano capito tutto.

Saresti lì solo per far rispettare il tempo, senza argomenti e controllare che l'unità sia stata sufficientemente capita. Saranno attori del loro apprendimento e saranno più concentrati sulla spiegazione agli altri che sul ciclismo.

Potresti richiedere uno schema disegnato a mano di alto livello da parte dell'unità di codice, che verrà copiato e conservato sui documenti condivisi dal team, in modo che abbiano qualcosa di tangibile a cui fare riferimento in futuro. Va bene anche per ancorare i ricordi.

Scusa se l'hai già provato ...

Hai provato a fare pre-lezioni che le persone guardano singolarmente?

Realizza brevi video o presentazioni che spieghino il contenuto, come funziona il codice o in pratica tutto ciò che vuoi insegnare in un formato in cui devono guardarlo da soli e apprendere le informazioni che stai cercando di insegnare loro .

Quindi utilizzi le sessioni basate sul team per discutere questioni relative al contenuto. Devi identificare distintamente che le sessioni del team sono per discutere e risolvere i problemi relativi al solo contenuto.

Se fornisci le lezioni alle persone su base individuale, potresti essere in grado di evitare quella altra questione sociale in cui una singola questione può diventare la voce del gruppo come una collettività e distogliere lo scopo effettivo dalle lezioni.

Prova a insegnare loro il design del codice base, guidali intorno all'architettura, PRIMA di iniziare a guardare esempi specifici. In questo modo potrebbero vedere come gli esempi di codice che guardi rientrano nel quadro generale. Pensa a come è strutturato il tuo programma di allenamento. E includi la motivazione aziendale dietro al design.

Ho trascorso diversi anni ad addestrare altri sviluppatori, e non sono mai entrato nel codice prima di mostrare loro come il sistema si adattava insieme. Poi, quando li ho fatti fare esercizi di codice nel framework, le domande erano strutturate e in argomento.