Pourquoi ne pas penser à un bug vous aide parfois à le résoudre? [fermé]

Hier, j'ai passé une bonne partie de l'après-midi à essayer de corriger un bug, que je pensais être trivial. Je tournais en rond, sans avoir la moindre idée de ce qui n'allait pas. Réécriture de grandes parties du code. Vérification sur SO. Toujours pas de joie.

Alors je suis rentré chez moi, j'ai promené le chien, j'ai regardé une petite télé et juste avant de m'endormir, au bingo, j'ai réalisé l'erreur évidente que je faisais. Ce matin, il a fallu environ 10 minutes pour réparer.

Pendant que j'étais à la maison, je ne pensais pas activement au problème. Pourtant, me sortir de la situation m'a permis de la résoudre.

Ce n'est pas la première fois que cela se produit, et je sais que c'est une façon assez courante de résoudre un problème de programmation. J'ai même entendu des gens rêver les réponses.

Pourquoi ça marche?

Peut-être plus important encore, existe-t-il un bon guide pour savoir quand vous devez prendre une pause pour résoudre un problème, combien de temps la pause doit-elle durer et après combien de temps le fait de laisser un problème cesse-t-il d'être efficace?

Je suppose que j'essaie de trouver comment optimiser ce traitement subconscient (ou tout ce qui se passe)

Être trop concentré sur un problème vous empêche de prendre du recul. Lorsque vous déboguez votre code, vous avez tendance à répéter inutilement les mêmes tests.

Plus vous essayez, plus vous échouez et vous devenez très frustré. Le stress et la frustration accrus aggravent les choses.

C'est pourquoi très souvent, un collègue peut, par hasard, regarder par-dessus votre épaule et signaler le problème (et la solution) en quelques secondes.

Ils ne sont pas dans le même état mental que vous.

J'essaie souvent d'arrêter de m'occuper d'une certaine période de temps et de revenir avec un esprit plus calme quelques heures plus tard.

Mais la technique la plus puissante est juste ... de demander de l'aide .

Si vous travaillez sur un problème depuis un certain temps, votre esprit suit les modèles que vous avez définis pendant le développement. En d'autres termes, vous développez des "points noirs" temporaires pour des choses en dehors du cadre mental que vous avez défini.

Prendre votre esprit hors du problème pendant un certain temps aide à supprimer ce filtre et vous permet de réfléchir sur les choses sans que le filtre soit en place.

Ce qui m'a souvent aidé dans des cas comme ceux-ci, c'est d'expliquer à quelqu'un d'autre pourquoi cela devrait fonctionner (quand cela ne fonctionne pas) - normalement à mi-chemin de votre explication, vous vous rendrez compte où vous vous êtes trompé dans votre raisonnement ou quelle étape vous avez manquée.

En plus de développer un filtre mental pendant le travail de développement, votre cerveau est massivement multi-thread et continue souvent à résoudre un problème dans le cadre de processus inconscients. J'utilise parfois cela en apprenant tout ce que je peux sur un problème dans un après-midi, puis en laissant le problème reposer pendant un jour ou deux avant de travailler sur une solution.

Je ne suis pas psychologue, mais lorsque vous êtes trop concentré sur un seul problème (trouver le bug), vous avez tendance à perdre de vue le système plus large. Mais souvent, la réponse n'est pas «là-bas» là où vous le cherchez actuellement, mais ailleurs - que vous n'êtes pas en mesure de voir à ce stade.

Donc, ce que vous devez vraiment faire, c'est sortir des tranchées et commencer à regarder l'ensemble du système d'un point de vue plus général - encore une fois. On a tendance à ignorer ce fait en pensant "Je sais vraiment que c'est juste ici, je ne l'ai pas encore trouvé". Cela nous arrive à tous, tout le temps. J'arrive même au point où je sais "Je ne trouve pas le bogue en utilisant une bonne technique de débogage donc il doit être ailleurs" et je ne prends toujours pas la bonne chose et je fais une pause - le cerveau humain est un tel chose amusante.

Cependant, cela n'a pas vraiment d'importance ce que vous faites - que ce soit aller aux toilettes, parler à un collègue ou promener le chien. J'avais l'habitude d'aller dans un magasin voisin pour acheter des bonbons quand j'étais coincé et dès que je mettais ma veste, la solution me venait à l'esprit - presque à chaque fois. Cela peut aussi être une bonne chose de boire beaucoup d'eau pendant la programmation. Cela vous oblige à faire une pause de temps en temps pour visiter la salle de bain et zapper, c'est la raison qui vous oblige à sortir des tranchées.

D'après mon expérience personnelle et ce que j'ai vu chez les développeurs juniors que je forme, nous abordons tous un problème avec des hypothèses et des attentes. Nous supposons que la fonction x effectue la tâche y pour produire le résultat z. Il l'a toujours fait, alors pourquoi cela devrait-il changer? Comme nous nous concentrons de plus en plus sur un problème, nous supposons que nous avons couvert les bases et le problème doit en effet être beaucoup plus compliqué que lorsque nous l'avons abordé à l'origine. Attachez la fatigue à une liste croissante de choses que nous supposons être vraies mais que nous n'avons pas réellement vérifiées, et vous vous préparez pour un moment "WTF" complet plus tard.

Ce n'est que plus tard, lorsque vous vous êtes déconnecté du problème, que les hypothèses peuvent être rejetées et retracées. De plus, nous abordons généralement un problème sur le dos d'un problème différent que nous venons de résoudre. J'ai corrigé A mais il a cassé B, maintenant je dois réparer B. Nous avons donc déjà un élan et une direction dans laquelle nous voyageons (ce qui rend nos hypothèses encore plus difficiles à dissocier). Lorsque vous revenez à la résolution du problème B, le problème A n'est plus frais dans votre esprit, bloquant les possibilités potentielles. Vous êtes en mesure de résoudre le problème sans idées préconçues, ce qui ouvre de nouvelles voies de réflexion et de nouveaux angles de vue sur le problème.

Maintenant, chaque fois qu'un junior me demande de l'aide, il sait que la première question à laquelle il doit répondre est "Quelles sont vos hypothèses?". Même essayer de répondre à ce problème peut vous aider à vous retirer de vos blocages mentaux.

Je suppose que votre cerveau, comme les muscles, se fatigue. Faire une pause lui permet de se reposer, de faire le plein d'oxygène / de carburant, etc. et de recommencer à travailler.

Faire une promenade ou faire de l'exercice est souvent une bonne approche lorsque vous êtes vraiment coincé avec quelque chose. Même si vous n'avez pas de moment "eureka", cela peut souvent vous permettre de revenir et d'adopter une nouvelle approche pour résoudre le problème.

J'aime l'appeler le temps d' incubation des idées et des problèmes.

Votre sous-conscience continue de traiter le problème hors de votre conscience dans une approche non linéaire. C'est très similaire à ce qui se passe lorsque vous apprenez quelque chose de nouveau avant de faire une sieste. Votre esprit a le temps de «défragmenter» les informations de manière à pouvoir les aborder avec une plus grande flexibilité.

En outre, une autre astuce utile pour surmonter le blocage d'un bug, s'appelle le débogage confessionnel . C'est là que vous approchez une autre personne qui ne connaît pas le problème et vous commencez à expliquer le problème. Je trouve le plus souvent qu’en disant simplement le problème à voix haute, la solution me vient à l’esprit.

consultez ces liens psychologiques: conseils de créativité et résolution de problèmes

"Nous sommes tous parfois piqués par une rose . Malheureusement, lorsque nous nous concentrons tellement sur la douleur, nous oublions la beauté de la rose."

J'ai corrigé plusieurs bugs critiques dans ma carrière, pendant la douche.

Je ne suis pas psychologue mais je suppose que la différence est:

• assis devant l'ordinateur, je vois des codes sources, des points d'arrêt, des printfsorties ...

• dans la salle de bain, les codes me viennent à l'esprit.

J'ai vécu le même phénomène et je l'ai attribué au fait de regarder le problème avec une perspective différente pendant que je passe du temps loin de lui (plus de temps implique une perspective plus éloignée, approximativement).

Mais il y a une autre astuce que je trouve accomplit la même chose la plupart du temps: expliquer le code à un collègue. Ce n'est pas à eux d'attraper votre bug, bien qu'ils le puissent; c'est pour vous forcer à prendre du recul et à expliquer la logique du code à tous les niveaux pertinents. Je n'ai jamais (bien que juste avertissement - la taille de l'échantillon est limitée) réussi à résoudre inconsciemment un bogue qui a échappé à ce traitement de description à un collègue.

J'ai récemment utilisé la technique du pomodoro grâce à une suggestion de quelqu'un sur ce site, et je pense qu'elle fournit une bonne réponse à votre question sur le calendrier et la durée des pauses. Fondamentalement, cela vous fait travailler concentré sur un problème pendant 25 minutes, suivi d'une courte pause de 3 à 5 minutes, puis d'une pause plus longue tous les 4 cycles. Ils citent quelques études pour le confirmer, mais anecdotiquement, j'ai trouvé ces intervalles très efficaces.

J'avais pensé que la durée de 25 minutes m'empêcherait de pénétrer "dans la zone", ce qui, selon les gens, prend environ 15 minutes. Au contraire, avec ce timing, j'entre dans la zone presque immédiatement. Je pense que c'est parce qu'il est beaucoup plus facile de ne pas être distrait quand je sais que je n'ai qu'à le garder pendant 25 minutes. Il est également plus facile de reporter les interruptions externes pour seulement 25 minutes. C'était bien difficile avant quand j'essayais de m'arrêter pour 4 heures de travail avant le déjeuner.