Come posso incoraggiare le persone a leggere i messaggi di errore? [duplicare]

Non aiutare subito. Fai in modo che il collega junior attenda per almeno 15 minuti, dopo uno o due di questi cicli di 15 minuti, lui / lei inizierà a guardare il problema da solo. Basta non dire direttamente "aspetta 15 minuti", usa qualcosa come "Sono occupato, lasciami finire x, poi ti aiuto".

Se lo aiuti immediatamente, questo è il percorso più breve che ha per la soluzione del problema, quindi ovviamente utilizzerà questa strada. Ma, se dici, ti aiuterò e risolverò il problema, ma per favore, aspetta 15 minuti prima che possa aiutarti, durante questo periodo fisserà lo schermo per vedere cosa potrebbe provare in questo "tempo di attesa" probabilmente controllerà i messaggi di errore da solo. : -)

Se non iniziano a cercare l'errore da soli, allora puoi dire che la persona è priva di iniziativa o esperienza. Se il problema è l'iniziativa, è difficile da risolvere. Se è esperienza dopo una o due analisi insieme, dovrebbero iniziare a capirlo.

Trovo gli sviluppatori senior colpevoli dello stesso errore; è per questo che penso che questo sia un segno di essere sopraffatto invece di "non importa".

La mia reazione è sempre la stessa: quando sento "non funziona", chiedo: "Che messaggio di errore ricevi?" (e cerco di essere educato).

La risposta poi mi dirà se la persona ha bisogno di sfogarsi un po 'prima di poter ricominciare a pensare - se qualcuno è in questo stato, nessun consiglio nel mondo funzionerà poiché semplicemente non possono ascoltare; calmati, prima.

Se erano solo pigri, insistono sul fatto che tornano indietro e leggono il messaggio di errore. Se pensi che dovrebbero sapere cosa significa / come risolverlo, inizia a fare domande: come "Cosa pensi che potrebbe causare questo?", "Che cosa significa foo qui?", "Che cosa hai cambiato subito prima errore è successo? " Fare domande è un buon modo per avviare il cervello di qualcun altro poiché la maggior parte delle persone cerca di essere d'aiuto quando viene richiesto. Quindi questo è ricevuto come supporto positivo anche se in realtà non li "aiuti".

Se sono semplici, non capiscono cosa sta succedendo, si siedono con loro e spiegano loro come correggere l'errore. Tendo a far sì che correggano l'errore da soli per due motivi:

1. Il cervello ricorda meglio le cose che hai fatto tu stesso (invece di guardare qualcun altro farlo)
2. Se non capiscono la spiegazione, ciò dà loro la possibilità di chiedere.

Se correggo personalmente l'errore, c'è sempre il pericolo che ora abbiano un codice funzionante ma non so perché.

PS: questo vale per tutti gli sviluppatori senior: scrivi messaggi di errore migliori. Un buon messaggio di errore spiega come risolvere un problema ; una cattiva è una variante di "C'erano errori".

Quindi anziché File not found , diciamo File ...path... not found . Invece di Glabarfel couldn't be initialized , dì Glabarfel wasn't initialited properly; missing Foo. See http://.../docs/setup/glabarfel/foo.html for details.

Questa è una piccola domanda di modifica del comportamento, ma deve essere affrontata in un ambiente del team di sviluppo. I tuoi sviluppatori minori devono fare supporto o qualsiasi tipo di correzione dei bug? Chiedi loro come si sentono quando qualcuno dice loro "Ho ricevuto un errore" senza altre informazioni. Possiamo evitare tutte le chiamate di nomi che probabilmente si verificano quando devono confrontarsi con utenti stupidi.

Quando ti dicono che c'è un errore, chiedi loro qual era il messaggio di errore. Possono includerli in una email o registrarsi in una sorta di bug tracker / team information / wiki system. In questo modo, gli altri utenti possono cercare una soluzione per questo messaggio di errore quando si ripresenta.

Devi essere diligente. Chiedi il messaggio. Chiedi se hanno cercato il messaggio per le soluzioni precedenti (proprio come dici agli utenti.). Non vuoi essere percepito come non di aiuto, quindi se è un nuovo problema, dovresti cercare di affrontarlo nel modo più conveniente possibile. Complimenti coloro che contribuiscono alla documentazione di questi errori.

Come squadra, devi affrontare i problemi delle interruzioni. Può sembrare più conveniente chiedere semplicemente alla persona che conosce la risposta subito, ma lasciarsi trascinare dal codice crea altri problemi e ritardi nel lungo periodo. Gli sviluppatori junior devono imparare questo.

"Quando la compilazione fallisce" ... in questi casi, andrei da loro come per aiutare con un errore nuovo di zecca, difficile, da richiedere ... Eseguirò i passaggi di base di "mostrami" e poi vorrei leggere il messaggio di errore che è stato mostrato dal compilatore, e se fosse davvero un caso di fare-cosa-l'-errore-messaggio-dice, avrei messo il mio meglio "tu sei un "faccia da bambino", chiedi loro perché non avrebbero potuto leggerlo da soli e poi andarsene.

Non puoi davvero non aiutarli quando ti chiedono, ma puoi disprezzarli se stanno perdendo tempo.

1. I tell them to check error messages when compilation fails.
2. I sit and check the error messages with them.
3. When they ask me for help, I ask if they have checked the error or not.

Da quello che stai scrivendo, sembra che i tuoi junior non capiscano davvero le tue soluzioni e non sono in grado di applicarle in altre situazioni che non sono identiche al 100% a quelle precedenti, o hanno imparato che tu Sei la fata magica e quello che ti infastidisce è il modo più rapido per far sparire i loro problemi.

Fortunatamente, il più delle volte, puoi aiutarli nello stesso modo: guidali con domande analitiche piuttosto che con la tua conoscenza.

• "Qual è il problema?" A volte, solo cercando di spiegarti il problema, gli farai capire la risposta. Come minimo, ti permette di dare uno sguardo al loro quadro di riferimento e, non sottovalutato per importanza, ti dice che cosa percepiscono il problema.

• "Che cosa dice la documentazione / Google / che cosa vuoi dire?" Supponi che abbiano almeno provato a capirlo. Se non lo fanno, resta con loro per un po 'mentre lo cercano (non saltare avanti e dare loro la soluzione). Se la soluzione è lì, dai un amichevole addio, felice di aiutarti e torna al lavoro. In caso contrario, o se non è realmente applicabile, vai al prossimo bit:

• Passa attraverso la ricerca del problema sottostante. Funzione già definita? Chiedi loro dove altrimenti la funzione può essere definita; indirizzarli verso le funzioni di ricerca, se necessario. Variabile non definita? Chiedi loro di verificare dove lo hanno definito e di controllare l'ortografia. % Inatteso% co_de? È davvero l'inizio di una nuova affermazione? Hai terminato il precedente?

  (Non c'è bisogno di essere pedanti o di insegnare Aristotele 660 su di loro, ma devi guidarli attraverso i passaggi necessari per trovare una soluzione, e devi essere aperto e paziente.)

Una volta trovata la fonte del problema, si spera che la soluzione sia banale; se non lo è, allora il tuo sviluppatore minore ha riscontrato un intoppo reale che non è ovvio per chi non lo sapesse.

Ma tutto questo non richiede più tempo del tuo precedente approccio? Probabilmente. I principi dell'approccio sono triplici:

1. Insegni alle persone come trovare una soluzione ai loro problemi. In particolare, analizzare il feedback dalle loro azioni (messaggi di errore) è cruciale per trovare una soluzione. Non solo migliorerà la loro indipendenza, ma anche il loro pensiero analitico, in definitiva li renderà più a loro agio in un ambiente automatizzato o, per lo meno, meno probabilità di ostacolare attivamente gli altri.

2. Non presumi che siano idioti o pigri; questo li renderà più propensi ad ascoltarti e seguire il tuo esempio. Affrontate il loro problema come un problema reale, in buona fede, che deve essere risolto. Chissà, forse lo è.

3. Aiutate a stabilire uno standard culturale (di squadra) che sia giusto chiedere aiuto per risolvere problemi che non si riescono a capire, che siete disposti a istruire e aiutarli a trovare e imparare una soluzione, ma anche che non sei la fata magica della soluzione dell'ufficio, e che ci deve essere almeno uno sforzo simbolico da parte loro. Cercando di capire le informazioni che hai, come un messaggio di errore, è il passo più semplice.