Come correggere un junior, ma incoraggiarlo a pensare da solo? [chiuso]

Sono il capo di un piccolo team in cui ognuno ha meno di un anno di esperienza nello sviluppo di software. Non mi definirei affatto un guru del software, ma ho imparato alcune cose in pochi anni in cui ho scritto software.

Quando eseguiamo revisioni del codice, insegno e correggo un bel po 'di errori. Dirò cose come "Questo è eccessivamente complesso e contorto, ed ecco perché" o "Cosa ne pensi di spostare questo metodo in una classe separata?" Sono molto attento a comunicare che se hanno domande o opinioni dissenzienti, va bene e dobbiamo discutere. Ogni volta che correggo qualcuno, chiedo "Cosa ne pensi?" o qualcosa di simile.

Tuttavia raramente non sono mai d'accordo o chiedono perché. E ultimamente ho notato segni più palesi che sono ciecamente d'accordo con le mie dichiarazioni e non formano opinioni proprie.

Ho bisogno di una squadra che possa imparare a fare le cose in modo autonomo, non solo seguire le istruzioni. Come si corregge uno sviluppatore junior, ma lo incoraggia ancora a pensare da solo?

Modifica: ecco un esempio di uno di questi segni evidenti che non stanno formando le loro opinioni:

Io: mi piace la tua idea di creare un metodo di estensione, ma non mi piace come hai passato un grande lambda complesso come parametro. La lambda obbliga gli altri a conoscere troppo l'implementazione del metodo.

Junior (dopo avermi frainteso): Sì, sono totalmente d'accordo. Non dovremmo usare i metodi di estensione qui perché costringono altri sviluppatori a conoscere troppo l'implementazione.

C'è stato un malinteso, e questo è stato risolto. Ma non c'era nemmeno un'UNIONE di logica nella sua affermazione! Pensava di rigurgitare di nuovo la mia logica, pensando che avrebbe avuto senso quando davvero non aveva idea del perché lo stesse dicendo.

Risposta breve:

Coinvolgeteli (mettete in mente il puzzle), potenziateli (fidatevi delle loro risposte).

È la domanda che ci guida! - Matrice.

Generalmente, nelle mie osservazioni, i giovani hanno il loro mondo - la loro visione limitata di come pensano e in parte il loro entusiasmo / favoriti / opinioni sulle cose.

Non c'è niente di sbagliato nel dire loro direttamente che hai torto - ma la cosa migliore è che tu li fai pensare. Perché? Ci sono altri modi? Ci sono modi migliori per fare la stessa cosa? Uno degli aneddoti che uso sempre è: "Dammi tre soluzioni (a questo problema)!"

Quando pensano a queste soluzioni, iniziano a rendersi conto di molti problemi. Richiede loro un certo investimento di tempo, ma col tempo tendono a visualizzare i limiti e le carenze del loro pensiero. Cominciano a vederlo più come "Non ci avevo pensato!" che è molto meglio che tornare a casa con la sensazione che "mi sbagliavo!" o peggio ancora "mi è stato detto / dimostrato sbagliato anche quando avevo punti di vista validi" .

In generale, i bambini molto piccoli tenderanno ad essere più abili in relazione a problemi tecnici (come quale modello di progettazione funziona meglio!) Su problemi di processo , ma col tempo quando li istruisci, funziona.

Tuttavia raramente non sono mai d'accordo o chiedono perché. E ultimamente ho notato segni più palesi che sono ciecamente d'accordo con le mie dichiarazioni e non formano opinioni proprie.

Questo in genere è un risultato che si fa prendere i loro suggerimenti, ma in seguito overrule loro e sono altrettanto convinto circa i vostri punti di vista; solo perché sei più anziano stanno evitando una rissa!

La cosa migliore che ho imparato da uno dei miei capi precedenti: Chiederà ai membri del team di discutere prima (si sentono abbastanza uguali qui), e si spera che dopo aver esaurito tutte le discussioni, entrerebbe nella stanza con una sola domanda: "Cosa erano i punti di disaccordo? " - Il punto è che alla gente piace sempre partecipare ai dibattiti e alle discussioni, ma se i loro punti (validi) non vengono portati all'azione la prossima volta sentono che non ne vale la pena partecipare alla discussione.

Non solo nel software, ma ovunque alla fine solo i compagni di squadra più potenti oseranno rispondere per non parlare del sistema.

Se vuoi che i tuoi ragazzi pensino da soli, non correggerli: falli correggere .

Invece di dire loro cosa pensi che sia sbagliato sulla loro soluzione, fai loro delle domande pertinenti a riguardo. Nel tuo esempio, potresti chiedere loro ciò che qualcuno che usa il metodo di estensione dovrebbe sapere per creare il lambda. Continua a fare domande come questa fino a quando non suggeriscono che si tratta di un problema. In questo modo, sai che hanno capito perché la loro soluzione potrebbe essere un problema e inoltre hanno maggiori probabilità di imparare da essa - se semplicemente dici loro che la loro soluzione è sbagliata, questo è un giudizio esterno e facilmente ignorato. Se arrivano alla realizzazione da soli (con un piccolo suggerimento), si renderanno conto di quanto sia fondato e avranno molte più probabilità di imparare dal loro errore.

Inoltre, questo dà ai tuoi ragazzi la possibilità di difendere il loro design - forse hanno pensato al problema e hanno una buona giustificazione che affronta la tua preoccupazione, il che significa che non è necessario che tu faccia alcuna correzione. Ciò riduce qualsiasi percezione (per quanto non intenzionale) che stai governando dalla fiat esecutiva.

Dal momento che hai più sviluppatori junior eseguono revisioni del codice come gruppo non 1 uno 1.

Apri chiedendo al gruppo "In quale altro modo il problema potrebbe essere risolto?" E consenti agli altri sviluppatori junior di suggerire prima le loro implementazioni. Aggiungi la tua implementazione solo dopo che gli altri membri del team hanno parlato e se nessuno ha suggerito qualcosa di simile a ciò che la tua idea è.

Quindi fai una tavola rotonda sui vantaggi e gli svantaggi relativi delle diverse implementazioni con l'intento di guidare gli sviluppatori junior a scegliere la migliore implementazione senza che gli venga detto di cosa si tratta.

Come generatore di fiducia per gli sviluppatori junior potresti iniziare con alcuni casi in cui hanno scelto quella che ritieni fosse l'opzione migliore e hanno reso la tua alternativa un uomo di paglia che ha un difetto semi-ovvio e indirizzano la discussione sul perché l'implementazione originale è la migliore.

Quando ho iniziato a lavorare in un lavoro di programmazione, ho fatto esattamente la stessa cosa che hai descritto: quando mi è stato detto qualcosa che potrei fare, sono sempre d'accordo. Principalmente perché non avevo abbastanza esperienza per dire il contrario.

Ciò che mi ha dato la possibilità di discutere effettivamente di metodologie e idee è stato imparare dall'esperienza e leggere diversi approcci e nuove tecnologie. Affinché il tuo team possa pensare da solo, devono effettivamente sapere quali problemi possono sorgere da cose come il codice "troppo complesso e contorto" e l'unico vero modo che scopriranno è attraverso l'esperienza.

Un buon modo per facilitare il pensiero individuale è farli esaminare i siti Web di programmazione come Stack Overflow o Programmers SE. So che questi mi hanno aiutato a conoscere le diverse tecniche esistenti e mi hanno permesso di discutere con i membri più anziani del team, invece di concordare ciecamente con loro.

Il punto è che senza esperienza, i suggerimenti dei membri senior suoneranno sempre giusti per loro.

L'interazione dal tuo post dimostra un principio chiave per insegnare quasi tutto: chiedi loro di spiegare ciò che pensano di aver detto e di ascoltare attentamente la risposta: ti dirà esattamente cosa deve essere corretto.

Ho spudoratamente rubato questo trucco dal mio tutor di matematica circa 25 anni fa, e da allora non mi ha deluso. L'ho usato in classe durante il mio breve periodo come assistente di insegnamento, al lavoro quando parlavo di progettazione di software e con il mio bambino di otto anni quando parlava dei suoi compiti scolastici.

Ovviamente non puoi sempre essere schietto nel chiedere loro di ripetere ciò che hai appena detto, quindi devi adattare la tua strategia. Ad esempio, ecco come vorrei riformulare la tua dichiarazione di follow-up dall'OP come una domanda di "sondaggio":

Mi piace la tua idea di creare un metodo di estensione, ma non mi piace come hai passato un grande lambda complesso come parametro. Vedi come questa complessa lambda costringe gli altri a conoscere troppe cose certe sull'implementazione del metodo?

È impossibile rispondere correttamente a questa domanda senza comprendere il problema che si sta tentando di evidenziare. Ho scoperto che terminare le mie spiegazioni con una domanda che richiede l'analisi di ciò che ho appena detto accelera il processo di apprendimento e mi dà un feedback di cui ho bisogno per apportare correzioni.

Di solito, quando le persone non dicono ciò che vuoi, significa che devi lavorare sul tuo ascolto. Ascoltare significa ascoltare le ragioni del loro disegno prima di giudicare. Significa non solo dire loro che va bene dissentire, ma dimostrarlo onestamente considerando ciò che hanno da dire e non solo correggerli. Cerca gli aspetti positivi della loro soluzione e modifica la soluzione per incorporare tali elementi.

Devi anche dare l'esempio. Non intendo scrivendo un codice super fantastico, intendo chiedendo loro la loro opinione sui tuoi progetti. Non aspettare le revisioni del codice dopo il fatto, ma lavorare insieme lungo la strada. Dì cose come "La mia interfaccia sembra troppo complessa, ma non sono sicuro del modo migliore per semplificarla". E dai loro il tempo di rispondere senza distorcere prima le tue idee.

Quando ho avuto a che fare con questo, ho detto (onestamente) cose come:

Sai, è una soluzione davvero creativa a cui non avrei mai pensato. Come si ridimensiona? / Pensi che potrebbe esserci un approccio concettualmente più semplice, per rendere lo sviluppo più veloce o più semplice per la manutenzione? / Sfortunatamente, non penso che si adatti davvero al resto dell'architettura del progetto. la configurazione sembra?

Questo di solito è stato sufficiente per indirizzare le persone verso una nuova direzione.

La responsabilità è una cosa che può aiutarli.

Ho guidato una squadra o due in passato e una delle cose che ha fatto brillare i giovani è stata l'onere della responsabilità personale. Quando uno si rende conto che le sue azioni possono implicare su di lui ad un certo punto, di solito commette un po 'più di se stesso in quello che fa. No, per dire che quando sentono il loro lavoro, i buoni risultati sono molto più soddisfacenti.

Non mi preoccuperei troppo del fatto che ti seguano ciecamente, questo è ciò che dovrebbero fare come junior. Il fatto è che probabilmente non capiranno le vere ragioni degli articoli che affronti nelle recensioni del codice fino a quando non se ne saranno andati e funzioneranno da qualche altra parte che ha terribili sviluppatori di software, gestione terribile e codice terribile.

A quel punto avranno imparato le buone pratiche per abitudine e dovranno sopravvivere agli errori di codifica e di progettazione che altri commettono e sono costretti a fare in modo che ora debbano lavorare su software mal progettato e implementato.

Questa sarà un'eventuale inevitabilità ad un certo punto della loro carriera. Stai facendo loro un ottimo servizio abituandoli a buoni standard e pratiche di codifica. Purtroppo la maggior parte di noi ha dovuto imparare nel modo più duro.

In base all'esempio fornito, direi che dare seguito ai tuoi commenti con domande sarebbe probabilmente il modo migliore di procedere. Se fai una domanda insieme ai tuoi commenti, ciò non lascia che siano semplicemente d'accordo o in disaccordo, almeno devono pensare a come implementare qualcosa.

ad es. "Mi piace la tua idea di creare un metodo di estensione, ma non mi piace il modo in cui hai passato una lambda complessa di grandi dimensioni come parametro. La lambda costringe gli altri a conoscere troppo sull'implementazione del metodo. Riesci a pensare a un modo migliore per implementare questo metodo di estensione che non espone più informazioni? "

Ciò consente loro di vedere i difetti in ciò che stanno sviluppando, offrendo allo stesso tempo l'opportunità di risolvere il problema che hanno introdotto nell'applicazione.