Come posso convincere le persone a smettere di andare in bici (concentrandosi sulle banalità)?

Mi è stato assegnato il compito di insegnare ad altri team una nuova base di codice, ma continuo a riscontrare un problema. Ogni volta che vado a esaminare il codice con le persone, non andiamo molto lontano prima che l'intero esercizio si trasformi in un esercizio di bikeshedding (membri di un'organizzazione che dà peso sproporzionato a questioni banali). Dal momento che non conoscono la base di codice, ma pensano di dover contribuire a migliorarlo, si concentrano sulle cose che possono capire:

Why is that named that? _{(2 minuti per spiegare perché prende il nome, 10+ minuti discutendo un nuovo nome)}

Why is that an abstract base class rather than an interface? _{(2 minuti per spiegare, 10+ minuti discutendo i meriti relativi di questa decisione)}

...e così via. Ora, non fraintendetemi: sono importanti nomi validi e un design coerente e coerente, ma non possiamo mai discutere di ciò che il codice effettivamente fa o di come il sistema è progettato in modo significativo. Ho incontrato alcuni arbitri per incontrare le persone fuori da queste tangenti, ma se ne sono andati - distratti da ciò che il codice sarà / dovrebbe essere quando la loro banalità da compagnia viene risolta, e loro perdono il quadro generale.

Quindi riproviamo più tardi (o con una parte diversa della base di codice) e poiché le persone non hanno avuto abbastanza conoscenze per superare l'effetto del ciclismo, si ripete.

Ho provato gruppi più piccoli, gruppi più grandi, codice, lavagna, diagrammi visio, gigantesche pareti di testo, lasciando che discutessero a morte, abbreviando immediatamente gli argomenti ... alcuni aiutano più di altri, ma niente funziona . Diavolo, ho anche provato a farlo spiegare ad altre persone dal mio team perché pensavo che potrei essere solo cattivo a spiegare le cose.

Quindi, come si educano abbastanza gli altri programmatori che smettono di fissarsi sulle banalità e possono contribuire significativamente alla progettazione?

Penso che il problema sia il compito: "Mi è stato assegnato il compito di insegnare ad altri team una nuova base di codice".

Ti è stato assegnato un lavoro sbagliato o forse hai frainteso il lavoro che ti è stato assegnato.

Presentandoti 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 le stai recensendo. Consenti domande: vuoi che comprendano il sistema. Se la gente "l'avesse fatto diversamente", va bene. Forse d'accordo. O no. Ma vai avanti. È come è adesso.

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

Ora imposta alcuni problemi di classe su cui lavorare. Come possiamo migliorare X? Scegli qualcosa di non banale che "segue il flusso" della progettazione del sistema e lavora su ciò che vorresti cambiare. Ora dovrebbero ottenere la logica del sistema. Scegli un altro miglioramento che potrebbe rompere il sistema se fatto in modo sbagliato e mostra come farlo nel modo giusto. Quello dovrebbe essere un momento Ah Ah per loro. Alcuni potrebbero persino batterti!

È un concerto difficile, soprattutto dopo la falsa partenza che hai avuto. Sembra che tu abbia già investito molto tempo e molti sforzi, e forse c'è un po 'di me rispetto a loro. 'Preparati e ricomincia. Partiamo dal presupposto che sono persone intelligenti. Offri loro la sfida di pensare a un livello superiore. E spezza i gruppi già esistenti selezionando diverse sezioni trasversali delle squadre per le nuove sessioni.

"Parcheggiali". All'inizio della lezione, spiega di cosa stai discutendo e spiega chiaramente cosa è considerato fuori tema. Se ti viene posta una domanda che è chiaramente OT, dillo e vai avanti. Se ci ritornano, scrivi la domanda su una lavagna (Questo è fondamentale) per una discussione successiva e vai avanti. Alla fine della lezione, quando sono nel loro tempo libero, non nel tuo, guarda quanto velocemente queste domande vengono risolte.

Impostare le aspettative correttamente ed essere onesti, aperti e diretti.

Assicurati che i tuoi obiettivi siano aperti e trasparenti.

Inizia discussioni con la vista di alto livello promossa da andy256 (+1) ma assicurati anche di includere i tuoi obiettivi, ad es.

"... mentre esaminiamo questo problema, assicuriamoci di non concentrarci su x, ye z. Assicuriamoci anche di non guardare dettagli di implementazione come a, b, c o dettagli banali come j, k, l. So che ci saranno molti dettagli nel codice e dettagli cose che potrebbero essere affrontate, migliorate o rese più standard, ma cerchiamo di vedere cosa sta realmente raggiungendo ad un livello superiore prima "

Quindi, come si educano abbastanza gli altri programmatori che smettono di fissarsi sulle banalità e possono contribuire significativamente alla progettazione?

In primo luogo, non pensare alle loro preoccupazioni come a "banalità" o "bikeshedding". Queste sono parole di giudizio e sono offensive. Le loro preoccupazioni sono valide. Al momento non sono importanti.

La chiave per ogni buon incontro è che tutti sappiano:

• perché stai avendo una riunione e
• cosa speri di uscirne
• quanto dovrebbe durare

Dichiarare queste cose in anticipo, esplicitamente e spiegare gli obiettivi.

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

Quindi, quando compare un argomento, potrebbe andare così:

Nuova persona: "Perché FooWidget è implementato come modello di facciata?"

Tu: "Beh, penso che sia perché (breve spiegazione della decisione progettuale)" o "Non lo so".

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

NP: "Non pensi che sarebbe meglio fare come un singleton?"

Tu: "Non ci avevo davvero pensato, ma mi piacerebbe continuare ad andare avanti spiegando come funziona FooWidget."

NP: "Ma se è fatto come un singleton, allora possiamo ..."

Tu: "Mi dispiace interrompere, ma devo concentrarmi su come funziona FooWidget. Questo incontro è programmato solo fino alle 11:00 e abbiamo molto da superare. La discussione sul design dovrà attendere un'altra volta ".

Dopo averlo esaminato una o due volte, puoi abbreviarlo a "Questo è al di fuori dell'ambito di questa riunione".

Si noti che si sono non dicendo "Questo è stupido da preoccuparsi" o "Non ha importanza" o "Shut up" o "Sei troppo nuova per avere input." Stai semplicemente concentrando l'incontro su ciò che deve essere fatto e il tempo necessario.

In certe organizzazioni non sarai mai in grado di raggiungere questo obiettivo. Molte organizzazioni apprezzano la lotta politica e l'arrampicata su scala più della capacità intellettuale, della diligenza e della lealtà. E perché non dovrebbero. L'arrampicata su scala mette le persone in posizioni di potere, consente loro di migliorare la propria vita personale con un reddito più discrezionale e non diventa mai obsoleta.

Contrasta questo conflitto di potere con l'effettiva risoluzione dei problemi, il pensiero astratto e la decisione su questioni difficili di cui potrebbero essere responsabili per le conseguenze in seguito, e molti dipendenti pesano pesantemente sul lato del tentativo di pedalare il più possibile.

L'unico consiglio che suggerisco è che tu chiarisca chiaramente, nel contesto della tua organizzazione, se possibile, che il destino personale di questi partecipanti dipende dalla loro comprensione, contributo e sforzo verso il vero problema che stai cercando di risolvere. Se questa è l'architettura aziendale, espressa in questo -errant-codebase e in tutti i suoi errori, è tutto. Mettere in chiaro a loro che essi devono fornire sostanziale input significativo su quello . Non un'altra casualità, che sembra essere una pepata di un anziano qualcuno o altro e li guadagnerà dei bei punti brownie concordando con detto qualcuno su.

Questo è spesso difficile da fare, poiché il senior qualcuno di solito non capisce la tecnologia in corso, non è interessato e, sfortunatamente, controlla gli ingredienti grezzi: tempo dei dipendenti; noleggio e fuoco, politica in sala conferenze, promozioni, ecc. ecc. seriamente, eccetera all'ennesimo.

Quello che chiami bikeshedding, chiamerei convertire il flusso di pensieri di qualcuno nel nostro. Discutendo nomi, modelli, riescono a capire il codice nei loro termini e non c'è modo di impedirlo, è necessario.

Inoltre, non c'è bisogno di fare una guida molto dettagliata di un'intera base di codice, perché i dettagli saranno dimenticati molto prima che ci lavorino sopra.

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

Saresti lì solo per far rispettare il tempo, nessun fuori tema e il controllo dell'unità è stato compreso abbastanza. Saranno attori del loro apprendimento e saranno più focalizzati sulla spiegazione agli altri che sul ciclismo.

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

Scusa se l'hai già provato ...

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

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

Quindi si utilizzano le sessioni basate su team per discutere questioni relative al contenuto. È necessario identificare distintamente che le sessioni del team sono per discutere e risolvere i problemi relativi solo al contenuto.

Se offri le lezioni alle persone su base individuale, potresti essere in grado di evitare quell'altro problema sociale in cui una singola materia può diventare la voce del gruppo come collettivo e distogliere lo scopo reale delle lezioni.

Prova a insegnare loro la progettazione del codebase, guidali nell'architettura, PRIMA di iniziare a guardare esempi specifici. In questo modo potrebbero vedere come gli esempi di codice che guardi si adattano all'immagine più grande. Pensa a come è strutturato il tuo programma di allenamento. E includi la motivazione aziendale alla base del design.

Ho trascorso diversi anni a formare altri sviluppatori e non ho mai approfondito il codice prima di mostrare loro come si integrasse il sistema. Poi, quando li ho fatti fare esercizi di codice nel quadro, le domande erano strutturate e in tema.