Quando non dai aiuto ai programmatori meno esperti? [chiuso]

Pensi che sia una buona idea quando un programmatore junior ha bisogno di aiuto per saltare sempre dentro e cercare di educarli? O ignoreranno tutti i consigli "insegnando a pescare" che darai loro e si concentreranno solo sul "pesce" che hai appena portato loro? Li lasci sempre capire le cose da soli, sapendo che gli errori sono il modo migliore per imparare? O hai paura che diventino così bruciati e frustrati da perdere il desiderio di accelerare?

Quando scegli quando aiutare qualcuno più giovane di te e quando indietreggiare e farli imparare attraverso i loro errori?

In uno dei miei lavori, stavo imparando e insegnando (perché ovviamente non so tutto, ma ne so più di alcuni)

Non appoggiare le mani sulla tastiera a tutti i costi . Questo è frustrante sia per te che per la persona a cui insegni. Anche se dai loro istruzioni passo per passo, quando metti le mani sulla tastiera è l'equivalente di dare loro un pezzo di codice e dire "questo risolve".

In quello che ho imparato:

• Non digitare il codice per loro
• Cerca di insegnare al loro livello (se capiscono la sintassi, non spiegarglielo. Questo li annoierà semplicemente; insegnerà invece le classi / funzioni utilizzate)
• Non ignorarli o dire "capisci da solo". Quello che finirai con te è che ti verranno in seguito, tranne per il momento con le 3 linee di codice con cui hanno avuto problemi, ora sono 50 linee distribuite su 8 file che cercano di aggirare il problema.
• Insegna loro ad imparare da soli. Uno dei modi migliori è dire loro di usare StackOverflow. A volte, pur conoscendo la risposta, se me lo chiedessero. Direi "bene, ho intenzione di porre questa domanda su StackOverflow". e darei loro un link alla domanda. Fai una pausa caffè e guarda qualche codice diverso. Quando sono tornati chiedendo "quindi come posso risolvere quel problema", dì loro di cercare la loro domanda su SO (usando l'URL che hai dato loro). Ho scoperto che le masse sono di solito un insegnante migliore di me.
• Quando copiano e incollano il codice da Internet e chiedono perché non funziona, chiedi loro di spiegare cosa fa ogni riga. Se non ci riescono, dì loro di ricercare le funzioni / classi utilizzate. Se necessario, fornire spiegazioni per la classe e le funzioni
• Esegui revisioni del codice per assicurarti che stiano risolvendo il problema, non solo aggirare il problema affinché venga visualizzato in seguito.
• Sii gentile. Quando qualcuno sta appena iniziando nel tuo codebase senza documentazione, non limitarti a dire loro di leggere il codice sorgente. Fornire una panoramica riassuntiva di alto livello della funzione in questione. O, meglio ancora, inizia a scrivere documentazione :)
• Sii umile. Non BS riguardo al problema. Se non lo sai, dì di no e aiutali a cercarlo. Molte volte, conoscere il dominio abbastanza da sapere quali parole chiave cercare è un aiuto sufficiente per fornirle.

Metodo socratico, ovvero porre loro domande che li inducono a pensare in una direzione positiva

[questo è utile anche quando non sai qual è il problema, tanto meno la soluzione]

Ho imparato ad aiutarli come architetto e a fermarmi lì. Scegli gli strumenti giusti, elabora un progetto generale per un problema complesso o due e lasciali andare. Se tornano e chiedono un consiglio, daglielo in piccoli pezzi. Se non lo fanno, lasciali stare.

Hai perfettamente ragione sul "bruciato e frustrato". Saranno esattamente questo se gestisci i micro o scegli il nit. Infine, aiuta molto a stabilire un rapporto di lavoro amichevole con i tuoi colleghi. Il tempo speso per guadagnare fiducia e rispetto reciproco si ripaga da solo 10 volte.

Li aiuto quando ho davvero bisogno che le cose finiscano rapidamente, quando è chiaro che hanno colpito un muro di mattoni e quando è chiaramente irragionevole aspettarsi che lo capiscano senza aiuto. Se, tuttavia, non hanno dedicato tempo a qualcosa, allora è meglio che provino prima.

Per quanto riguarda il "pesce" invece di "insegnare a pescare", il modo migliore per farlo è quello di non risolvere i problemi delle persone per loro . Dai loro idee e lasciali correre con essa. Se corrono con esso e falliscono, aiutali di più. Se ci riescono, anche meglio.

Se sono un buon programmatore dovrebbero trovare un modo per farlo da soli. Ora, in una situazione in cui è quasi impossibile trovare informazioni o una soluzione a un determinato problema, dare una mano è apparentemente all'interno della ragione fintanto che la si mantiene all'interno della ragione. Non dar loro da mangiare la risposta.

Forse come esempio ho 18 anni e sto imparando da anni ormai da solo e ho scritto alcune cose pazze tra cui il mio compilatore e sono autodidatta. Cerco solo aiuto per le cose su cui sono veramente bloccato (come in cui ho cercato e sperimentato per almeno un giorno ma senza risultati). Vorrei anche fornire un contro-esempio: in una lezione di programmazione una volta ho avuto uno studente che mi chiedeva di eseguire il debug del codice che non aveva nemmeno compilato!

Fondamentalmente un buon programmatore, anche uno più giovane, dovrebbe essere in grado di sperimentare e ricercare soluzioni alla maggior parte dei problemi.

Farò da mentore ma me ne vado se vogliono che facciano il loro lavoro per loro. In genere solo alcuni consigli su come risolvere un problema o riformulare la descrizione dell'attività possono fare molto. Anche solo dire loro le parole che dovrebbero usare in Google può essere di aiuto. Massimo 2 minuti.

Di recente ho iniziato a utilizzare la tecnica pomodoro . Di conseguenza, se non riesco a rispondere a una domanda senza interrompere il mio flusso di pensieri sul mio compito attuale, ho iniziato a chiedere se posso rimandare una risposta fino alla fine del pomodoro, in media un ritardo di circa 15 minuti. Un interessante effetto collaterale di questo che ho scoperto è che quando passo dalla loro scrivania per rispondere alla domanda, spesso l'hanno già risolto da soli. Se non lo hanno fatto, a quel punto sono molto più preparato a dare loro tutta la mia attenzione.

Questa non è scuola. Non è un imbroglio se fornisci rapidamente un fatto che alla fine potrebbero trovare da soli. Al contrario, ha un buon senso dal punto di vista economico risparmiare loro tempo e, nella mia esperienza, le capacità sono affinate da prove ed errori molto poco rispetto a un tutor che ti dà frequenti piccole spinte nella giusta direzione. Preferirei che imparassero 10 modi giusti per fare le cose con il mio aiuto piuttosto che 9 modi sbagliati e uno giusto per conto proprio.

Se si può facilmente cercare qualcosa, insegnare loro come farlo. D'altra parte, se si tratta di qualcosa che si può conoscere solo dall'esperienza, ad esempio quali file esaminare per determinati sintomi di bug, non vedo assolutamente nulla di sbagliato nel dare una risposta inspiegabile.

Al contrario, le cose più soggettive come la guida all'architettura dovrebbero sempre essere accompagnate dal ragionamento alla base. Per prima cosa, lo sviluppatore junior ha pensato molto più in profondità al proprio compito specifico di quanto tu abbia fatto. Discuterlo ti assicura di non saltare alle conclusioni. Per un altro, impedisce loro di applicare ciecamente regole a situazioni future in cui potrebbero non essere applicabili.

Posso solo pensare a un caso in cui mi sono completamente rifiutato di continuare ad aiutare un collega, ed è stato dopo aver trascorso un paio d'ore a spiegare qualcosa più volte e aver esaminato diversi esempi, dopo di che letteralmente non sapeva ancora la prossima affermazione con cui scrivere alcuni suggerimenti molto importanti. A quel punto aveva poche speranze di mantenere il suo lavoro senza un serio apprendimento dei fondamenti, e sicuramente è durata solo un paio di mesi.

Smetto di aiutarli quando tornano con la stessa domanda per la terza volta.

Dico loro che sarei felice di aiutarli, ma solo se prima si aiutano da soli. Da lì o vanno in cerca di un altro stagno per pescare cibo gratis, nel qual caso di solito vengono licenziati poco dopo. Oppure ci lavorano e raggiungono il jackpot quando tornano per saperne di più ... è più roba da imparare piuttosto che più dello stesso!

Penso che il contesto sia importante.

Se abbiamo a che fare con un problema critico di supporto alla produzione in cui i tempi di risposta sono importanti, allora in realtà fornirei molto aiuto insieme a molte spiegazioni in modo che possano imparare il problema.

Se la scadenza è meno sensibile, la complessità diventa il driver. Ovviamente puoi aiutare molto i neofiti semplicemente assegnando compiti appropriati a livello di abilità, ma se è qualcosa che può essere risolto attraverso la ricerca, sono d'accordo con gli altri poster che guidarli senza dare la risposta esatta è un ottimo approccio .

Se pongono domande a cui è possibile rispondere facilmente guardando altrove, le indico a fare il proprio lavoro. Lungo queste linee, se c'è un processo o una soluzione che è piuttosto normale e che ha poco valore nel renderli schiavi, allora vergognati se non hai una wiki a portata di mano per loro da controllare.

Quando si tratta di trasferire conoscenze di dominio personalizzate per l'azienda, non trito le parole. Discutilo subito il prima possibile. I neofiti ne hanno bisogno per aiutare con tutto ciò che verrà dopo. Non è possibile essere istruiti sul business troppo rapidamente o troppo facilmente. Una volta ho avuto un capo che ha giocato tutti i tipi di trucchi per un'ora cercando di portarmi a una risposta. Ero nuovo di zecca, non sapevo ancora nulla sull'app o sul business e avevo a che fare con un problema di supporto alla produzione. Volevo urlare "Perché stai giocando a # @ & (# $ & (* $%!)? Gli utenti che cercano di emettere fatture stanno aspettando una risposta!"

Penso che la prima cosa che devi chiedere loro prima di aiutarli è hai indagato su questo? se sì, chiedi loro cosa hanno scoperto e indicali nella giusta direzione. Indagare è spesso sottovalutato, ma è una delle migliori pratiche che ho imparato, trovare informazioni su ciò di cui hai bisogno ti dà il potere di apprendere da solo, inoltre chiarirà che devono prima provare.

Se il problema è più complesso, cerca di non dire loro cosa fare ma condividi alcune idee, chiedi loro come pensano di poter affrontare il problema.

Se non ne hanno idea, prova a suddividerlo a un livello molto semplice in cui non fornisci tutti i dettagli ma descrivi la soluzione in modo che possano provare, ci sono strumenti molto utili per questo come algoritmi o diagrammi di flusso .

In conclusione, prova a guidarli senza interferire con il processo di apprendimento, aiutandoli sempre a farli dipendere da te per ogni compito che verrà assegnato, che richiederà tempo ed è controproducente.

Evito di aiutare su cose semplici come la sintassi che dovrebbero sapere, o se non sanno che dovrebbero essere in grado di capire da soli. Se è qualcosa di più complesso, non mi dispiace spiegare una volta.

Quando si tratta di spiegare il processo, gli standard di codifica della nostra organizzazione / progetti, ecc., Utilizzo la regola dei tre avvertimenti. Penso davvero che una persona sia zoppa se gli si devono spiegare le cose tre volte. In realtà questo è anche uno dei criteri nella nostra valutazione.

Molto dipendeva dallo studente. Mi aspetto che raccolgano alcune cose da soli. Se si presentano: "Ho affrontato questo problema, ho provato i metodi A, B e C ma non sono riuscito a risolvere il problema", li aiuterò. Se escogitano semplicemente "Sto affrontando questo problema" e non hanno fatto nulla, chiederò loro di tornare ai libri e cercare una soluzione.

Come programmatore principiante me stesso (circa 9 mesi nel mio attuale lavoro usando principalmente Perl e SQL e con a) nessuna conoscenza di Perl eb) alcuni mesi di armeggiare con SQL prima di questo lavoro), quando faccio domande di programmazione, provo a mostrare quello che ho fatto finora, o nel caso in cui qualcosa non funzioni (ed è difficile eseguire il debug), dove penso che il bug potrebbe risiedere. Quando possibile, ho cercato di imparare a pescare.

Smetto di aiutare nelle seguenti circostanze:

• Se vengo utilizzato per canalizzare Google / Stack
• Se ho fornito documentazione e commenti adeguati e stanno abbreviando la fase RTFM
• Se sono sporchi, non ci sono commenti, "Ora hackero questo e ci tornerò più tardi" & & £>! $

Se non ho fornito documenti adeguati o stanno lavorando con uno strumento / classe che ho creato, allora è mia responsabilità aiutarli