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

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

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

In quello che ho imparato:

• Non digitare il codice per loro
• Cerca di insegnare al loro livello (se capiscono la sintassi, non spiegarlo a loro, questo li annoierà, insegnerà invece le classi / funzioni utilizzate)
• Non ignorarli o dire "capisci da soli". Quello che finirai con loro è che verranno da te più tardi, tranne che per ora le 3 linee di codice con cui hanno avuto problemi, sono ora 50 righe distribuite su 8 file che cercano di aggirare il problema.
• Insegnagli a 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 sullo stackoverflow". e darei loro un link alla domanda. Fai una pausa caffè e guarda un codice diverso. Quando sono tornati a chiedere "così come posso risolvere il problema", basta dire loro di cercare la loro domanda su SO (usando l'URL che gli hai dato). Ho scoperto che le masse di solito sono 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 linea. Se loro non possono, allora dica loro di ricercare le funzioni / classi usate. Se necessario, fornire spiegazioni per la classe e le funzioni
• Esegui le revisioni del codice per accertarti che stiano risolvendo il problema, non limitandoti a risolverlo perché possa essere visualizzato più tardi.
• Sii gentile. Quando qualcuno è appena iniziato nella base di codice senza documentazione, non limitarsi 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 la documentazione:)
• Sii umile. Non parlare del problema. Se non lo conosci, di 'che non lo fai e aiutali a cercarlo. Molte volte, solo conoscendo abbastanza il dominio per sapere quali parole chiave da cercare è sufficiente aiuto per poterle dare.

Metodo socratico, cioè poni loro domande che li inducano a pensare in una direzione positiva

[questo è utile anche quando non si conosce quale sia il problema, tanto meno la soluzione]

Ho imparato ad aiutarli con l'architettura e a fermarmi qui. Scegli gli strumenti giusti, disegna un disegno generale per un problema complesso o due e lasciali andare. Se tornano e chiedono consiglio, dagli a loro in piccoli pezzi. Se non lo fanno, lascia che siano.

Hai completamente ragione riguardo al "bruciato e frustrato". Saranno esattamente così se gestisci o sceglierai in modo univoco. Infine, aiuta molto a stabilire un rapporto di lavoro amichevole con i tuoi colleghi di lavoro. Il tempo trascorso guadagnando fiducia e rispetto reciproco si ripaga di 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 escano senza aiuto. Se, tuttavia, non hanno messo il tempo per qualcosa, allora è meglio che lo provino prima.

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

Se sono un buon programmatore, dovrebbero trovare il modo di farlo. Ora, in una situazione in cui è quasi impossibile trovare informazioni o una soluzione a un determinato problema, prestare una mano è apparentemente entro limiti ragionevoli, purché tu tieni ragione. Non dare 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 con le cose su cui sono davvero bloccato (come ho cercato e sperimentato per almeno un giorno, ma senza risultato). Vorrei anche fornire un controesempio: in una classe di programmazione, una volta uno studente mi ha chiesto di eseguire il debug del codice che non aveva nemmeno compilato!

Essenzialmente un buon programmatore, anche uno junior, dovrebbe essere in grado di sperimentare e ricercare soluzioni alla maggior parte dei problemi.

Io farò il mentore, ma me ne vado se vogliono che faccia il loro lavoro per loro. In genere solo alcuni consigli su come risolvere un problema, o riformulare la descrizione dell'attività può fare molto. Anche solo dire loro le parole che dovrebbero usare in google può essere abbastanza aiuto. 2 minuti al massimo.

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

Questa non è scuola. Non è barare se si fornisce rapidamente un fatto che potrebbero eventualmente trovare da soli. Al contrario, è ragionevole per gli affari risparmiare tempo e, nella mia esperienza, le abilità sono affilate molto poco per tentativi ed errori rispetto a un mentore che ti dà frequenti piccole spinte nella giusta direzione. Preferirei che imparassero 10 modi giusti per fare le cose con il mio aiuto di 9 modi sbagliati e uno giusto per conto proprio.

Se qualcosa può essere facilmente consultato, insegnagli come farlo. D'altra parte, se si tratta di qualcosa che puoi solo sapere dall'esperienza, come i file su cui indagare 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 che sta dietro. Per prima cosa, lo sviluppatore junior ha pensato molto più a fondo sul proprio compito specifico di quello che ha. Parlarne attraverso fa sì che non si salti alle conclusioni. Per un altro, impedisce loro di applicare ciecamente le 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, e dopo aver trascorso un paio d'ore a spiegare qualcosa più volte e aver esaminato diversi esempi, dopo di che lei ancora non conosceva la prossima dichiarazione digitare con alcuni suggerimenti molto importanti. A quel punto aveva poche speranze di mantenere il suo posto di lavoro senza un serio riapprendimento dei fondamentali, e abbastanza sicuro che è durata solo un paio di mesi.

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

Dico loro che sarei lieto di aiutarli, ma solo se prima si aiuteranno da soli. Da lì o vanno a cercare un altro laghetto per pescare cibo gratis, nel qual caso di solito vengono licenziati poco dopo. Oppure ci lavorano e colpiscono il jackpot quando tornano per più ... è più materiale da imparare piuttosto che più dello stesso!

Penso che il contesto sia importante.

Se abbiamo a che fare con un problema di supporto alla produzione critico in cui il tempo di risposta è importante, in realtà fornirò 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 i neofiti molto semplicemente assegnando compiti appropriati a livello di abilità, ma se è qualcosa che può essere risolto attraverso la ricerca, allora sono d'accordo con gli altri poster che guidarli senza dare la risposta esatta è un ottimo approccio .

Se fanno domande a cui è facile dare una risposta guardando altrove, li indirizzo a fare il proprio lavoro. Seguendo queste linee, se c'è un processo o una soluzione che è abbastanza razionale e c'è poco valore nel renderli schiavi per questo, allora vergognati se non hai un wiki a portata di mano da controllare.

Quando si tratta di trasferire la conoscenza del dominio che è personalizzata per il business, quindi io non tritare le parole. Tienilo dritto il prima possibile. I neofiti hanno bisogno di questo per aiutare con tutto ciò che viene dopo. Non esiste una cosa come essere educati sul business troppo velocemente o troppo facilmente. Ho avuto un boss una volta 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 & #; # @ $! Sto giocando con # @ & (* $%! Giochi? Gli utenti che cercano di ottenere le fatture sono in attesa di una risposta!"

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

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

Se non hanno la minima idea, prova a scomporlo su un livello molto basilare in cui non dai tutti i dettagli ma descrivi la soluzione sufficientemente da provare, ci sono strumenti molto utili per questo come algoritmi o diagrammi di flusso .

In conclusione, cerca di guidarli senza interferire con il processo di apprendimento, aiutandoli sempre a farli dipendere da te per ogni attività quindi vengono assegnati, che ti porteranno il tuo tempo ed è controproducente .

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

Quando si tratta di cose come spiegare il processo, o gli standard di codifica della nostra organizzazione / progetto, io uso la regola dei tre colpi. Penso davvero che una persona sia zoppa se deve essere spiegata tre volte. In effetti questo è anche uno dei criteri nella nostra valutazione.

Molto dispendi per lo studente. Mi aspetto che raccolgano alcune cose da sole. Se escono con: "Ho affrontato questo problema, ho provato i metodi A, B e C ma non ho potuto risolvere il problema", li aiuterò. Se si presentano semplicemente "sto affrontando questo problema" e non ho fatto nulla, chiederò loro di tornare sui libri e cercare una soluzione.

Come programmatore newbie io stesso (circa 9 mesi nel mio attuale lavoro utilizzando 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, io prova a mostrare quello che ho fatto fino ad ora, o nel caso di qualcosa che non funziona (ed essendo difficile da eseguire il debug), dove penso che il bug potrebbe mentire. Quando possibile, ho cercato di imparare a pescare.

Smetto di aiutarti nelle seguenti circostanze:

• Se sono abituato a canalizzare Google / Stack
• Se ho fornito documentazione e commenti adeguati, e stanno tagliando l'RTFM stage
• Se sono sporchi, no-comments, "Lo farò adesso e torna più tardi "& & £ >! $

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