Gérer la frustration lorsque les choses ne fonctionnent pas
Vous essayez de mettre en œuvre quelque chose de simple, mais pour une raison étrange, cela ne fonctionne pas.
Vous essayez donc une solution possible, mais quelque chose d'autre ne fonctionne pas. Vous continuez d'essayer différentes solutions de contournement, mais chaque fois que quelque chose de différent ne fonctionne pas.
Chaque fois que vous vous rapprochez, vous obtenez également un (ou plusieurs) pas de plus pour résoudre ce problème et cela fait maintenant 3 heures que cela devrait vous prendre 10 minutes. Et ce n'est toujours pas résolu.
Personne dans votre entreprise ne peut vous aider et vous êtes sur le point de passer votre poing à travers votre écran.
À ce stade, vous êtes tellement frustré que vous ne pouvez plus penser clairement au problème. Que devez-vous faire à ce stade? Ou que pouvez-vous faire pour éviter d'en arriver là?
Bien que ce soit un vrai problème, il n'est pas spécifique à la programmation. Cependant, il est si important à mon humble avis qu'il mérite une place sur ce forum.
Mes suggestions: faites une pause. Allez vous promener, méditez, dormez, faites de l'activité physique * - faites quelque chose de complètement différent de laissez votre cerveau se détendre et sortir de l'ornière mentale, tout en laissant votre subconscient travailler en paix sur le problème. Habituellement, il fournit des résultats étonnamment rapides - il suffit de vous en informer. Mais alors que votre esprit conscient répète désespérément les mêmes cycles de pensées encore et encore, il ne pourra rien écouter d'autre.
que pouvez-vous faire pour éviter d'en arriver là?
Les techniques de relaxation et de pleine conscience sont essentielles pour surmonter les réactions de stress et permettre à votre esprit de se concentrer clairement. Et la pratique de ceux-ci est vraiment payante. Quand quelqu'un est expérimenté dans ces domaines, il peut déjà remarquez que le niveau de stress augmente avant que la frustration ne prenne le dessus. Ensuite, on peut interrompre le cycle des pensées, par exemple en prenant quelques respirations profondes ou en faisant quelques minutes de relaxation. C'est peut-être tout ce qui est nécessaire à ce stade.
* embrasse ton partenaire, caresse ton animal - suggestions de ma femme :-)
cela fait maintenant 3 heures que cela aurait dû vous prendre 10 minutes.
Le mot magique est devrait. Supprimez cela de votre vocabulaire.
Qui a dit que cela devrait prendre 10 minutes? Qui spécifiquement? Quel était le fondement factuel de leur allégation?
Si vous l'avez fait en 3 fois auparavant, et chaque fois que vous étiez près de 10 minutes, vous avez une base rationnelle pour un devrait.
Si vous ne l'avez jamais fait auparavant, dire devrait ne fait que vous préparer à l'échec. Vous devez cesser d'utiliser devrait aujourd'hui.
Trouver quelqu'un à utiliser comme caisse de résonance
Même si personne n'a d'expertise sur ce sur quoi vous travaillez, c'est une bonne idée de parler de ces choses fréquemment. Le simple fait d'utiliser quelqu'un comme caisse de résonance peut faire tourner la tête. Vous vous retrouverez à penser à de nouvelles choses à essayer. Cela atténuera également votre stress pour vous évacuer un peu et éventuellement vous faire un nouvel ami. C'est aussi juste sain en général que l'équipe se sente à l'aise de partager et de compatir les uns avec les autres pour créer une atmosphère d'équipe pour résoudre ce genre de problèmes.
Éloignez-vous un moment et faites autre chose. Dormez bien et revenez au problème le matin.
Aussi, ne vous battez pas. Votre estimation de dix minutes n'est clairement pas correcte, et cela arrive tout le temps.
J'ai quelques étapes quand j'arrive à ce point. Normalement, je peux trouver une solution si je prends le temps de prendre du recul et de réfléchir.
Étape 1: Éloignez-vous du problème et nettoyez votre tête. Revenez quand vous n'êtes pas frustré et que vous pouvez le regarder avec un esprit neuf.
Étape 2: Revenez au code et voyez s'il y a quelque chose que vous avez manqué. Demandez à quelqu'un de venir et d'être une deuxième paire d'yeux si vous ne pouvez tout simplement pas en faire la tête ou la queue.
Étape 3: supprimez le code de l'équation. Quel est le problème que vous essayez de résoudre? Écrivez-le sur un morceau de papier ou un tableau blanc. Discutez du problème avec quelqu'un pour obtenir son opinion sur le problème et la solution.
Étape 4: Contactez la communauté pour voir si elle a une solution ou si quelqu'un d'autre a déjà heurté le même mur.
Fondamentalement, ceux-ci peuvent être résumés comme "Arrêtez le piratage et éloignez-vous du code".
Je voudrais poser une question ici et demander à la communauté de vous aider à le résoudre. Moins stressant de cette façon.
J'ai un nom spécial pour ce genre de situation: bataille de programmation épique.
Si je n'en ai pas eu au moins un bataille de programmation épique avec un langage ou un outil de programmation spécifique et résolu le problème, je ne peux pas me dire que je peux utiliser un tel langage ou outil de programmation.
Il y a donc ma solution: la mentaliser comme un combat et un test de courage et d'endurance. Si je ne peux pas résoudre le problème, alors je "vivre pour combattre un autre jour".
Cela peut sembler un peu ridicule, mais ce sera plus amusant et gratifiant d'y penser en ces termes (comme si c'était une sorte de jeu que vous devez gagner) au lieu de souffrir complètement parce que vous devez faire face à la fait que vous ne savez pas tout.
J'ai un autre type de solution - DORMIR !!
Lorsque vous êtes frustré par un problème, vous ne pouvez pas facilement en sortir. Il est donc préférable que vous deveniez si fatigué en essayant de résoudre le problème et que vous vous endormiez.
Lorsque vous vous réveillez, vous ressentez une nouvelle sensation et vous pouvez à nouveau penser clairement au problème. Je le fais parfois.
Trouver quelque chose pour aider à restaurer une certaine confiance est ce que j'ai tendance à faire lorsque j'arrive à ce point. Cela pourrait être de résoudre un puzzle Sudoku ou Kenken, d'effectuer une tâche administrative simple et insensée comme remplir ma feuille de temps ou sortir pour une promenade. La clé ici est pour moi d'avoir un sentiment d'accomplissement quelle que soit cette petite distraction latérale pour m'aider à me gonfler suffisamment pour remonter sur le cheval et monter dans le bleu sauvage là-bas, pour y mélanger quelques métaphores.
Quant à éviter de devenir si mauvais, je suggérerais probablement d'avoir une stratégie de trucs de boxe de temps pour que si vous croyez que quelque chose prenne 10 minutes et que c'est soudainement une heure plus tard avec pas beaucoup de progrès, je m'arrêterais et j'aurais une petite pause plutôt que d'essayer de me cogner la tête contre le mur.
Eh bien ... je pense que vous avez besoin d'une nouvelle carrière ou d'un tout nouveau jeu d'attentes. Bien que ce ne soit certainement pas fréquent, prendre 3, 4, 8, 10 ou 40 heures pour faire ce que vous pensiez initialement être un travail de 10 minutes n'est certainement pas rare dans le secteur des logiciels. Je suis sûr que la plupart des développeurs qui travaillent sur n'importe quoi de complexité même modérée ont vu leurs tâches de 2 jours se transformer en tâches de 1 mois une fois qu'elles s'y sont plongées et ont compris le problème.
Être un bon développeur implique en partie d'être patient, sinon l'ordinateur va gagner et vous finirez par incorporer une sorte de hack de correction rapide qui semble à peine fonctionner mais qui cassera inévitablement quelque chose auquel vous ne pensiez pas. Si des retards mineurs vous causent autant de stress, vous ne devriez probablement pas être dans cette ligne de travail.
Deux suggestions:
La personne la plus intelligente que je connaisse, qui a deux doctorats et qui a le titre de "Research Fellow", dans une petite entreprise privée, dit ceci
Si vous y réfléchissez depuis 15 minutes et que vous n'avez pas la réponse, vous vous trompez.
Arrêtez d'y penser.
Faire une sieste. (allez vous promener ou quelque chose)
La réponse sera là lorsque vous vous réveillerez.
Obtenez le livre de David J Agan "Debugging". Il vous en apprendra probablement plus sur le débogage afin que lorsque les choses ne fonctionnent pas, vous puissiez le déboguer rapidement.
Chaque fois que je suis confronté à quelque chose qui ne fonctionne pas, je me souviens toujours de cette citation:
Lorsque vous êtes en enfer, continuez à marcher car c'est la meilleure chose à faire à ce moment-là.
Faites une pause, essayez de vous rafraîchir et concentrez-vous sur le problème avec un nouveau niveau d'énergie.
faisant écho aux recommandations des autres:
- cette situation est presque toujours quelque chose de trivial que vous ne voyez tout simplement pas; prendre une pause
- une autre paire d'yeux ou même simplement expliquer le problème à votre chat peut aider
et en ajoutant:
- réexaminez vos hypothèses, en particulier celles qui ne sont pas exprimées; vous avez probablement aboyé le mauvais arbre
- inverser la situation: supposer que le comportement actuel est le résultat souhaité, alors que devez-vous faire pour que cela se produise?
- écrire du code de test (assertions ou journalisation, ou points d'arrêt conditionnels - restez simple) pour vérifier vos hypothèses le long du chemin d'exécution
La fatigue ou le manque de sommeil ne me dérange jamais. Je suis plus frustré par le manque d'organisation au sein de l'industrie dans son ensemble et, dans l'ensemble, par les faibles normes que nous nous sommes fixées. Voici cinq choses qui me frustrent:
Des API dont la conception est compliquée. C'est comme apprendre un tout nouveau langage de programmation. En fait, certaines API sont beaucoup plus difficiles à apprendre qu'à apprendre de nouveaux langages de programmation. J'admire votre intelligence, mais vous auriez pu gagner du temps en mettant dans la documentation que j'avais besoin d'un doctorat en génie logiciel ou en informatique pour le comprendre.
Manque de bonne documentation. Je ne peux jamais surmonter le fait que tant de concepteurs d'API passent beaucoup de temps à créer une API uniquement pour la publier avec une documentation minimale. Merci, mais comment l'utiliser? que-faire dans cette situation? etc.
Implémentations propriétaires. Une mise en œuvre propriétaire est correcte, mais si des normes existent, pour le bien de l'humanité, veuillez suivre ces normes. Rien de plus frustrant que de passer du temps à se demander pourquoi quelque chose ne fonctionne pas seulement pour découvrir que l'implémentation ne suit pas les normes normales.
Environnements bac à sable/restrictions. Ok, peut-être que cela aide à garder les mauvaises personnes à l'écart, mais à mon avis, les restrictions sur ce qu'un programmeur peut faire ne font que limiter la créativité et le progrès technologique. Beaucoup d'idées géniales que j'ai eues ont été jetées après avoir découvert que je ne pouvais pas faire quelque chose. L'industrie de la programmation est vraiment faite pour produire des applications quotidiennes, pas des logiciels innovants. Donc, si vous décidez d'être programmeur, vous choisissez vraiment d'être un grognement moderne, à moins que vous ne vouliez devenir un universitaire solitaire.
Discussions modernes. Aujourd'hui, les gens discutent encore de la laideur des parenthèses LISP, ou du mérite de la propreté des Pythons, ou de la façon dont certaines langues comme Cobol ou Fortran disparaissent, etc., etc. Vraiment? C'est de cela que nous débattons? Parlons du parallélisme, ou de meilleures façons de concevoir des systèmes plus sûrs, ou de la façon dont la programmation logique peut améliorer nos vies. Arrêtons de penser comme des codeurs et commençons à penser comme des designers du monde de demain.
Donc, personnellement, je ne programme plus autant à cause de ces frustrations. Jusqu'à ce que l'industrie décide qu'elle veut faire plus que simplement créer le prochain Facebook ou réinventer le traitement de texte que je suis prêt. Je vous laisse les gars. Honnêtement, aucune infraction ne signifiait, c'est beaucoup d'argent.
Parfois, il est préférable de ne pas simplement essayer de contourner un problème. Prenez le temps et écrivez en pseudo-code ce que vous devez faire. Je sais qu'il y a une pression pour que les choses se fassent le plus rapidement possible, mais d'après ce que j'ai vu, ce style de codage mène au type de situation que vous décrivez. Si quelqu'un écrit du code qui ne fonctionnera que dans un petit ensemble de conditions et qui changera, le code se cassera ou fera des choses inattendues.
Aussi (je déteste admettre que mes professeurs avaient raison sur ce point ...), la documentation et les tests unitaires aident. Cela permettrait de savoir plus facilement ce qu'une section de code mettra en fonction de l'ensemble des entrées. Ensuite, il serait plus facile de voir quel effet entraînera un changement dans l'entrée des sections.