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

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

Più provi, più fallisci e diventi molto frustrato. L'aumento dello stress e della frustrazione peggiorano le cose.

Ecco perché molto spesso, un collega può, per caso, guardare oltre le tue spalle e indicare il problema (e la soluzione) in pochi secondi.

Non sono nello stesso stato mentale come te.

Spesso cerco di smettere di cercare dopo un certo periodo di tempo e di tornare con una mente più tranquilla 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 "punti neri" temporanei per 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 rimediare a qualcosa senza che il filtro sia posizionato.

Ciò che mi ha spesso aiutato in casi come questi è spiegare a qualcun altro perché dovrebbe funzionare (quando non lo è) - 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 è massivamente multi-thread e spesso continua a superare un problema come parte di processi inconsci. A volte uso questo imparando tutto quello che posso su un problema in un pomeriggio, poi lasciando che il problema si trovi per un giorno o due prima di lavorare su una soluzione.

Non sono uno psicologo, ma quando sei troppo concentrato su un singolo problema (trovando il bug) tendi a perdere la vista per il sistema più grande. Ma spesso la risposta non è "laggiù" dove la stai attualmente cercando, ma da qualche altra parte - 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. Arriva persino al punto in cui so "Non riesco a trovare il bug usando una buona tecnica di debug, quindi ha di essere da qualche altra parte" e ancora non prendere la cosa giusta e fare una pausa - il cervello umano è una cosa così divertente.

Tuttavia, in realtà non importa molto quello che fai - se va in bagno, parla con un collega o cammina con il cane. Ero solito andare in un negozio vicino per comprare un po 'di caramelle quando ero bloccato e appena ho messo la mia giacca sulla soluzione mi è venuta in mente - quasi sempre. Potrebbe anche essere una buona cosa bere molta acqua durante il tempo che stai programmando. Ti costringe a fare una pausa ogni tanto per visitare il bagno e fare zapping, c'è la ragione che ti costringe a uscire dalle trincee.

Dalla mia esperienza personale e da quanto ho visto negli sviluppatori junior che mi alleno, tutti affrontiamo un problema con ipotesi e aspettative. Supponiamo che la funzione x esegua il compito y per produrre il risultato z. Lo ha sempre fatto, quindi perché dovrebbe questo cambiamento? Poiché ci concentriamo sempre di più su un problema, assumiamo che abbiamo trattato i concetti di base e il problema deve essere molto più complicato di quando lo abbiamo affrontato in origine. Attacca l'affaticamento a un elenco crescente di cose che consideriamo vere ma che in realtà non sono state verificate e ti imposti per un momento "WTF" più tardi.

È solo più tardi quando ti sei disconnesso dal problema che le ipotesi possono essere scartate e rintracciate. Inoltre, di solito affrontiamo un problema sul retro di un problema diverso che abbiamo appena risolto. Ho corretto A ma ha rotto B, ora devo correggere B. Quindi abbiamo già un momento e una direzione in cui stiamo viaggiando (il che rende ancora più difficile dissociare le nostre ipotesi). Quando ritorni a risolvere il problema B, il problema A non è più nuovo nella tua mente che blocca le potenziali possibilità. Sei in grado di affrontare il problema senza preconcetti e questo apre nuovi percorsi 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 le tue ipotesi?". Anche tentare di rispondere a questo problema può aiutarti a rimuoverti dai tuoi blocchi mentali.

Immagino che il tuo cervello, come i muscoli, si stia stancando. Prendersi una pausa permette di riposare, ricaricare ossigeno / carburante ecc. E riprendere a lavorare.

Andare a fare una passeggiata o fare esercizio è spesso un buon approccio quando si è davvero bloccati con qualcosa. Anche se non hai un momento "eureka", spesso puoi permetterti di tornare e adottare un nuovo approccio per risolvere il problema.

Mi piace chiamarlo il tempo incubazione su idee e problemi.

La tua subcoscienza continua a elaborare il problema fuori dalla tua consapevolezza in un approccio non lineare. Questo è molto simile a quello che succede 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 il blocco di un bug, è chiamato de-bugging confessionale . È qui che ti avvicini a un'altra persona che non conosce il problema e inizi a spiegare il problema. Trovo molto spesso che, solo dicendo ad alta voce il problema, la soluzione viene in mente.

dai un'occhiata a questi link psicologici: suggerimenti sulla creatività & napping dei problemi

"We all get pricked by a rose sometimes. Sadly when we concentrate so much on the pain we forget about the beauty of the rose."

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

Non sono uno psicologo, ma credo che la differenza sia:

• seduto davanti al computer, vedo i codici sorgente, i punti di interruzione,% usciteprintf ...

• nel bagno, i codici mi vengono in mente.

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

Ma c'è un altro trucco che trovo la stessa cosa la maggior parte delle volte: spiegare il codice a un collega. Non è per loro catturare il tuo bug, sebbene possano; è per costringere tu a fare un passo indietro e spiegare la logica del codice a tutti i livelli pertinenti. Non ho mai (anche se il giusto avvertimento - la dimensione del campione è limitata) è stato in grado di risolvere inconsciamente un bug che è sfuggito a questo trattamento descrittivo.

Recentemente ho utilizzato la tecnica pomodoro grazie a un suggerimento di qualcuno su questo sito e penso che fornisca una buona risposta alla tua domanda sui tempi e le lunghezze delle pause. Fondamentalmente, il tuo lavoro si concentra su un problema per 25 minuti, seguito da una breve pausa di 3-5 minuti, quindi una pausa più lunga dopo ogni 4 cicli. Citano alcuni studi per sostenerlo, ma aneddoticamente ho trovato quegli intervalli molto efficaci.

Avevo pensato che gli span di 25 minuti mi avrebbero impedito di ottenere "nella zona", che le persone sostengono impiegano circa 15 minuti. Al contrario, con questo tempismo arrivo quasi immediatamente nella zona. Penso che sia perché è molto più facile non farmi distrarre quando so che devo continuare per 25 minuti. È anche più semplice posticipare le interruzioni esterne per soli 25 minuti. Era molto difficile prima quando stavo cercando di crollare per 4 ore di lavoro prima di pranzo.