Perché a volte non pensare a un bug ti aiuta a risolverlo? [chiuso]

Ieri ho trascorso buona parte del pomeriggio cercando di risolvere un bug, che pensavo fosse banale. Stavo girando in tondo, senza avere la minima idea di cosa non andasse. Riscrivere gran parte del codice. Verifica su SO. Ancora nessuna gioia.

Quindi sono tornato a casa, ho portato a spasso il cane, ho guardato un po 'di TV e poco prima di andare a dormire, il bingo mi sono reso conto dell'ovvio errore che stavo facendo. Questa mattina ci sono voluti circa 10 minuti per risolvere.

Mentre ero a casa, non stavo pensando attivamente al problema. Tuttavia, togliermi dalla situazione mi ha permesso di risolverlo.

Non è la prima volta che succede e so che è un modo abbastanza comune per risolvere un problema di programmazione. Ho persino sentito parlare di persone che sognano le risposte.

Perché funziona?

Forse ancora più importante, c'è una buona guida su quando dovresti prenderti una pausa da un problema, quanto dovrebbe durare la pausa e dopo quanto tempo lasciare un problema smette di essere efficace?

Suppongo che sto cercando di capire come ottimizzare questa elaborazione inconscia (o qualunque cosa stia succedendo)

Essere troppo concentrati su un problema ti impedisce di fare un passo indietro. Quando si esegue il debug del codice, si tende a ripetere inutilmente gli stessi test.

Più ci provi, più fallisci e diventi molto frustrato. Lo stress e la frustrazione aumentati peggiorano le cose.

Ecco perché abbastanza spesso, un collega può per caso, guardarsi alle spalle e sottolineare il problema (e la soluzione) in pochi secondi.

Non sono nello stesso stato mentale di te.

Cerco spesso di smettere di occuparmi di un certo periodo di tempo e di tornare con una mente più calma poche ore dopo.

Ma la tecnica più potente è solo ... chiedere aiuto .

Se hai lavorato su un problema per un po 'di tempo, la tua mente segue i modelli che hai impostato durante lo sviluppo. In altre parole, sviluppi temporaneamente "punti neri" per le cose al di fuori della cornice mentale che hai impostato.

Distogliere la mente dal problema per un po 'aiuta a rimuovere questo filtro e ti consente di rimuginare le cose senza il filtro in posizione.

Ciò che mi ha spesso aiutato in casi come questi è spiegare a qualcun altro perché dovrebbe funzionare (quando non funziona) - normalmente a metà della tua spiegazione ti renderai conto di dove hai sbagliato nel tuo ragionamento o quale passo ti sei perso.

Oltre a sviluppare un filtro mentale durante il lavoro di sviluppo, il tuo cervello è massicciamente multi-thread e spesso continua a superare un problema come parte di processi inconsci. A volte lo uso imparando tutto ciò che posso su un problema in un pomeriggio, quindi lasciandolo per un giorno o due prima di lavorare su una soluzione.

Non sono uno psicologo, ma quando sei troppo concentrato su un singolo problema (trovare il bug) tendi a perdere la vista per il sistema più grande. Ma spesso la risposta non è "laggiù" dove la stai attualmente cercando ma in qualche altro posto - che non sei in grado di vedere a quel punto.

Quindi quello che devi davvero fare è uscire dalle trincee e iniziare a guardare l'intero sistema da un punto di vista più generale - di nuovo. Si tende a ignorare questo fatto pensando "So davvero che è proprio qui, non l'ho ancora trovato". Succede a tutti noi, sempre. Sono anche arrivato al punto in cui so "Non riesco a trovare il bug usando una buona tecnica di debug, quindi deve essere altrove" e ancora non prendere la cosa giusta e fare una pausa - il cervello umano è un tale cosa divertente.

Tuttavia, in realtà non si adatta molto a ciò che fai, che si tratti di andare in bagno, parlare con un collega o portare a spasso il cane. Andavo in un negozio vicino per comprare delle caramelle quando ero bloccato e non appena mi mettevo la giacca sulla soluzione, mi veniva in mente, quasi ogni volta. Potrebbe anche essere una buona cosa bere molta acqua durante la programmazione. Ti costringe a fare una pausa ogni tanto per visitare il bagno e lo zap, c'è la ragione che ti costringe a uscire dalle trincee.

Dalla mia esperienza personale e da ciò a cui ho assistito negli sviluppatori junior che alleno, tutti affrontiamo un problema con ipotesi e aspettative. Partiamo dal presupposto che la funzione x esegue l'attività y per produrre il risultato z. Lo ha sempre fatto, quindi perché dovrebbe cambiare? Dato che ci concentriamo sempre di più su un problema, supponiamo di aver trattato le basi e che il problema debba in effetti essere molto più complicato rispetto a quando lo abbiamo affrontato inizialmente. Collega la fatica a un elenco crescente di cose che riteniamo essere vere ma che non abbiamo effettivamente verificato e in seguito ti preparerai per un completo "WTF".

È solo dopo che ti sei disconnesso dal problema che le ipotesi possono essere respinte e rintracciate. Inoltre, di solito affrontiamo un problema sul retro di un altro problema che abbiamo appena risolto. Ho risolto A ma ha rotto B, ora devo correggere B. Quindi abbiamo già un momento e una direzione che stiamo viaggiando (il che rende le nostre ipotesi ancora più difficili da dissociare). Quando torni a risolvere il problema B, il problema A non è più fresco nella tua mente che blocca le potenziali possibilità. Sei in grado di affrontare il problema senza preconcetti, e questo apre nuove strade di pensiero e nuovi angoli di osservazione del problema.

Ora, ogni volta che un junior mi chiede aiuto, sanno che la prima domanda a cui devono rispondere è "Quali sono i tuoi presupposti?". Anche tentare di rispondere a questo problema può aiutarti a rimuoverti dai tuoi blocchi mentali.

Immagino che il tuo cervello, come i muscoli, si stanchi. Fare una pausa consente di riposare, rabboccare con ossigeno / carburante ecc. E ricominciare a lavorare.

Fare una passeggiata o fare esercizio fisico è spesso un buon approccio quando si è davvero bloccati con qualcosa. Anche se non hai un momento "eureka", spesso ti consente di tornare indietro e adottare un nuovo approccio per risolvere il problema.

Mi piace chiamarlo il tempo di incubazione di idee e problemi.

La tua coscienza secondaria continua a elaborare il problema dalla tua consapevolezza in un approccio non lineare. Questo è molto simile a ciò che accade quando impari qualcosa di nuovo prima di fare un pisolino. La tua mente ha il tempo di "deframmentare" le informazioni in modi che possono essere affrontati con maggiore flessibilità.

Inoltre, un altro suggerimento utile per superare l'essere bloccati su un bug, è chiamato de-bugging confessionale . Qui è dove ti avvicini a un'altra persona che non conosce il problema e inizi a spiegarlo. Trovo più spesso che, semplicemente dicendo ad alta voce il problema, mi viene in mente la soluzione.

Dai un'occhiata a questi link psicologici: suggerimenti sulla creatività e sonnellini

"A volte siamo tutti puniti da una rosa . Purtroppo, quando ci concentriamo così tanto sul dolore, ci dimentichiamo della bellezza della rosa."

Ho risolto diversi bug critici nella mia carriera, durante la doccia.

Non sono uno psicologo ma immagino che la differenza sia:

• seduto di fronte al computer, vedo codici sorgente, punti di interruzione, printfuscite ...

• in bagno, i codici scorrono nella mia mente.

Ho sperimentato lo stesso fenomeno e l'ho attribuito a guardare il problema con una prospettiva diversa mentre trascorro il tempo lontano da esso (più tempo implica una prospettiva più distante, approssimativamente).

Ma c'è un altro trucco che trovo che compia la stessa cosa per la maggior parte del tempo: spiegare il codice a un collega. Non è per loro di catturare il tuo bug, anche se possono; è per costringerti a fare un passo indietro e spiegare la logica del codice a tutti i livelli pertinenti. Non ho mai (sebbene un equo avvertimento - la dimensione del campione è limitata) essere stato in grado di risolvere inconsciamente un bug che è sfuggito a questo trattamento da descrittore a collaboratore.

Recentemente ho usato la tecnica pomodoro grazie a un suggerimento di qualcuno su questo sito e penso che fornisca una buona risposta alla tua domanda su tempi e durata delle pause. Fondamentalmente, ti fa lavorare focalizzato su un problema per 25 minuti, seguito da una breve pausa di 3-5 minuti, quindi una pausa più lunga ogni 4 cicli. Citano alcuni studi per sostenerlo, ma aneddoticamente ho trovato quegli intervalli molto efficaci.

Avevo pensato che gli intervalli di 25 minuti mi avrebbero impedito di entrare "nella zona", che secondo la gente impiega circa 15 minuti. Al contrario, con questo tempismo arrivo nella zona quasi immediatamente. Penso che sia perché è molto più facile trattenermi dal distrarmi quando so di doverlo tenere in piedi solo per 25 minuti. È anche più facile posticipare le interruzioni esterne per soli 25 minuti. Era molto difficile prima quando stavo cercando di allacciarmi per 4 ore di lavoro prima di pranzo.