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

Risposta breve:

Coinvolgili (metti il puzzle nella loro mente), potenziali (fidati delle loro risposte).

It is the question that drives us! - Matrix.

In generale, nelle mie osservazioni, i junior hanno il loro mondo - la loro visione limitata di come pensano e in parte il loro entusiasmo / i preferiti / le opinioni sulle cose.

Non c'è nulla di sbagliato nel dire loro che hai torto, ma la cosa migliore è che tu li faccia riflettere. 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 realizzare molti problemi. Ci vuole un certo investimento di tempo - ma nel tempo tendono a visualizzare i limiti e le carenze del loro modo di pensare. Iniziano a vederlo più come "Non ci ho pensato!" che è molto meglio che tornare a casa con la sensazione che "Mi sono sbagliato!" o persino peggio "Mi è stato detto / provato male anche quando avevo punti di vista validi" .

In generale, i bambini molto piccoli tenderanno ad essere più abili in relazione ai problemi tecnici (come ad esempio quale modello di progettazione funziona meglio!) sui problemi process , ma nel tempo quando li alleni, funziona.

However they rarely if ever disagree or ask why. And lately I've been noticing more blatant signs that they are blindly agreeing with my statements and not forming opinions of their own.

In genere questo è un risultato che fai prende i loro suggerimenti, ma in seguito li cancella e non sono altrettanto convinti delle tue opinioni; solo perché sei anziano stanno evitando una rissa!

La cosa migliore che ho imparato da uno dei miei ex boss: chiederà ai membri del team di discutere per primo (si sentono abbastanza equi qui), e spero che dopo aver esaurito tutti gli argomenti, entrerebbe nella stanza con una sola domanda - "Quali erano i punti di disaccordo?" - Il punto è che alle persone piace sempre partecipare a dibattiti e discussioni, ma se i loro punti (validi) non vengono adottati in azione la volta successiva sentono che non vale la pena partecipare alla discussione.

Non solo nel software, ma ovunque alla fine solo i membri del team più potenti oseranno osare a rispondere, tanto meno a mettere in discussione il sistema.

Se vuoi che i tuoi juniores pensino da soli, non correggerli: portali a correggersi .

Invece di dire loro cosa pensate che sia sbagliato riguardo alla loro soluzione, ponete loro domande pertinenti a riguardo. Nel tuo esempio, potresti chiedere a loro chi deve utilizzare il metodo di estensione per creare il lambda. Continua a fare domande come questa fino a quando loro suggeriscono che è un problema. In questo modo, sai che hanno capito perché la loro soluzione potrebbe essere un problema e inoltre sono più propensi a 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), realizzeranno quanto sia ben radicato ed è molto più probabile che imparino dal loro errore.

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

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

Apri chiedendo al gruppo "In quale altro modo il problema può essere risolto?" e consenti agli altri sviluppatori minori 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 alla tua idea.

Poi 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 costruttore di fiducia per gli sviluppatori junior potresti iniziare con alcuni casi in cui hanno scelto quella che ritieni fosse l'opzione migliore e rendere la tua alternativa un uomo di paglia che ha un difetto semi-ovvio e indirizzare la discussione sul motivo per cui l'implementazione originale è migliore.

Quando ho iniziato a lavorare in un lavoro di programmazione, ho fatto esattamente la stessa cosa che hai descritto: quando ho parlato di qualcosa che potrei fare, sarei sempre d'accordo. Era 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é la tua squadra possa pensare da solo, ha bisogno di sapere realmente quali problemi possono sorgere da cose come il codice "eccessivamente complesso e contorto" e l'unico vero modo che scopriranno è attraverso l'esperienza.

Un buon modo per facilitare il pensiero individuale è farli guardare in siti Web di programmazione come Stack Overflow o Programmers SE. So che questo mi ha aiutato a conoscere le diverse tecniche che erano là fuori e mi ha permesso di discutere con i membri più anziani della squadra, invece di accettare ciecamente con loro.

Il punto è che senza esperienza, i suggerimenti dei membri più anziani saranno sempre giusti per loro.

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

Ho rubato spudoratamente copiato questo trucco dal mio insegnante 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 didattico, quando parlavo di software design e quando avevo 8 anni quando parlavo dei suoi compiti scolastici.

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

I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. Do you see how this complex lambda forces others to know too much certain things about the method's implementation?

Questa domanda è impossibile rispondere correttamente senza comprendere il problema che stai cercando 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à feedback che ho bisogno di apportare correzioni.

Di solito quando le persone non dicono quello che vuoi, significa che devi lavorare sul tuo ascolto. Ascoltare significa ascoltare i motivi del loro design prima di giudicare. Significa non solo dire loro che è giusto dissentire, ma dimostrarlo considerando onestamente cosa hanno da dire, e non solo correggendoli. Cerca le cose belle della loro soluzione e modifica la tua soluzione per incorporare quelle cose.

Devi anche dare l'esempio. Non intendo scrivere codice super-fantastico, voglio dire chiedendo loro la loro opinione sui tuoi progetti. Non aspettare le revisioni del codice dopo il fatto, ma lavorare insieme per tutto il tempo. Pronuncia cose come "La mia interfaccia sembra troppo complessa, ma non sono sicuro che sia il modo migliore per semplificarlo". E dare loro il tempo di rispondere senza prima spingerli alle proprie idee.

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

You know, that's a really creative solution which I would never have thought of. How does it scale?/Do you think there might be an approach which is conceptually simpler, to make development faster or maintenance easier?/Unfortunately, I don't think it really fits in with the rest of the project's architecture./What will the configuration look like?

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 hanno fatto brillare juniores era il peso della responsabilità personale. Quando uno si rende conto che le sue azioni possono implicare su di lui a un certo punto, lui / lei di solito commette un pochino - più di se stesso in quello che fa. Per non parlare del fatto che quando sentono il loro lavoro, i buoni risultati sono molto più soddisfacenti.

Non mi preoccuperei troppo del fatto che ti seguono ciecamente, questo è quello che dovrebbero fare come juniores. Il fatto è che probabilmente non capiranno le vere ragioni degli articoli che indirizzi nelle revisioni del codice finché non se ne andranno e lavoreranno da qualche altra parte che ha degli sviluppatori software terribili, una gestione terribile e un codice terribile.

A quel punto avranno imparato le buone pratiche per abitudine e dovranno sopravvivere agli errori di codifica e progettazione che gli altri fanno e sono FORZATI per far sì che ora debbano lavorare su software mal progettato e implementato.

Questa sarà un'eventualità finale a un certo punto della loro carriera. Stai facendo loro un ottimo servizio facendoli abituare a standard e pratiche di codifica validi. Sfortunatamente molti di noi hanno dovuto imparare nel modo più duro.

Sulla base dell'esempio dato, direi che seguire i tuoi commenti con le domande sarebbe probabilmente il modo migliore per andare. Se fai una domanda insieme ai tuoi commenti, non li lascia semplicemente in accordo o in disaccordo, ma devono almeno pensare a come implementare qualcosa.

es. "Mi piace la tua idea di creare un metodo di estensione, ma non mi piace come hai passato un grande lambda complesso come parametro.Il lambda costringe gli altri a conoscere troppo l'implementazione del metodo. Riesci a pensare a un modo migliore per implementare questo metodo di estensione che non espone quante più informazioni? "

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