Comment puis-je gérer la paralysie de l'analyse?

Très souvent, je suis coincé lors du choix de la meilleure décision de conception. Même pour de petits détails, tels que les définitions de fonctions, le flux de contrôle et les noms de variables, je passe des périodes anormalement longues à analyser les avantages et les compromis de mes choix.

J'ai l'impression de perdre beaucoup d'efficacité en passant mes heures à des détails insignifiants comme ceux-là. Même si, sachant au fond de moi, je peux changer ces choses si ma conception actuelle ne fonctionne pas, j'ai du mal à choisir fermement un choix.

Que dois-je faire pour lutter contre ce problème?

Deux règles simples:

1. Faites la chose la plus simple qui puisse fonctionner.
2. Refactor en continu.

En commençant à faire chacune de ces choses, vous aurez l’assurance que vous pourrez prendre des décisions simples maintenant sans compromettre votre capacité à réagir au changement plus tard.

Rappelez-vous que la vérification future signifie rendre le code facile à modifier, sans chercher à anticiper toutes les modifications possibles de votre code.

Habituellement, lorsque je ressens cela, cela signifie que je dois essayer:

1. Levez-vous, promenez-vous et assurez-vous que toute la biologie fonctionne correctement.
2. Passez au tableau blanc et dessinez jusqu'à ce que je ressente de la confiance.
3. Trouvez un «copain de réclamation pour la conception» avec lequel vous pouvez simplement parler du problème.

Si le problème implique une syntaxe et de petits morceaux, alors:

1. Assurez-vous que, même si c'est moche, il est bien encapsulé quelque part et représente un genre de cruauté purement locale.
2. Ajoutez des marqueurs TODO ou simplement des commentaires expliquant pourquoi le code vous pose problème.
3. Passez à la tâche suivante.

Il est très facile de penser à l'inaction. Même si vous parvenez, d'une manière ou d'une autre, à trouver la meilleure solution en ce moment, qui pourrait facilement changer avant la fin du projet, et ensuite?

Il est préférable de choisir une solution décente et de l'utiliser, plutôt que de s'asseoir et de dire la meilleure solution. La meilleure solution est insaisissable et pire, subjective. Si les exigences changent même légèrement, votre solution pourrait s'avérer pire qu'une solution que vous avez écartée car elle n'était pas la meilleure à l'époque.

J'apprends aussi à éviter la paralysie de l'analyse, donc félicitations à nous =). Cela arrive souvent parce que nous voulons faire le "meilleur design". En réalité, "le mieux" est dans l'oeil du spectateur . Ma formule pour éviter la paralysie de l'analyse consiste à appliquer le principe de conception suffisamment bon . Comment je fais ça? J'apporte des variables comme le temps, le calendrier-contraintes et je me demande quelle est la conception la plus simple qui peut faire le travail (cela ne signifie pas le plus facile) sans compromettre la qualité, mais en même temps, je vous assurer que est testable et une ouverture pour extension fermée pour modification (OCP)conception aussi bien. Qu'est-ce que je veux dire par testable et OCP? Au lieu de rechercher ce que j’ai considéré comme le meilleur, j’ai envisagé une conception qui permette de me dire quand les choses vont mal et d’essayer de faire juste assez de code pour me permettre de refactoriser et d’améliorer ultérieurement. Aussi, essayez de séparer le code qui va changer avec le code qui reste le même. La refactorisation devient plus facile, car le code qui n'est pas supposé changer est plus sûr de votre avenir, de votre part ou de la part de quelqu'un d'autre.

Que diriez-vous de laisser votre instinct décider pour l'une des options? Cela devrait aller assez vite et bien mélanger avec Timeboxing , qui ammoQ également proposé . Vous pouvez essayer une limite de 1 minute si les options sont déjà définies ou de 2 minutes si vous devez les définir au préalable. Ou ce qui semble approprié (défini au préalable). En apprenant à écouter votre instinct, votre choix intuitif deviendra plus rapide et meilleur avec la pratique .

Au cas où vous craignez de ne pas choisir parfaitement, voici quelques idées pour y remédier:

• S'il existait une option nettement supérieure aux autres, vous ne vous demanderiez pas laquelle choisir. Donc, par ce raisonnement, chaque fois que vous êtes indécis quant à un choix sur une question pas trop compliquée, cela indique que les options sont toutes très égales; il n'y a donc pas grand chose à perdre en optant pour l'un d'entre eux.
• Cela étant dit, l’ intuition n’est pas aléatoire du tout, mais une très bonne conjecture instruite pour la solution optimale. Souvent mieux que ce que l’on pourrait imaginer en fouillant sans fin.
• Au service du perfectionnisme, on pourrait attribuer à la rapidité de la décision une valeur supérieure à l’optimalité du choix lorsqu’on évalue sa performance de façon inconsciente. Ce qui est tout à fait logique avec des choix sans importance, mais n’est pas anodin à garder à l’esprit.

Bonne chance! :)

Je pense que ça part avec un peu d'expérience. La plupart de mes paralysies surviennent parce que j'essaie d'imaginer ce que la base de code aura l'air d'être beaucoup plus avancée que nécessaire, alors pour la surmonter, je fais simplement la chose la plus simple possible, qui fonctionnera puis passera à autre chose. Une fois que le projet a une forme définie, les unités de code répétitives commencent à se démarquer et il est assez facile d’abstraire les motifs répétitifs et de simplifier le code.

Pour surmonter votre réticence à décider, appliquez la fonction Timeboxing : définissez un réveil pour qu'il se déclenche dans quelques minutes; tourmentez votre esprit jusque-là, mais lorsque l'alarme se déclenchera, choisissez la meilleure option que vous ayez trouvée jusque-là.

Créer un prototype. Rappelez-vous qu'un prototype est fait pour être jeté, alors peu importe les fonctions, le nom de variable ou même la grande architecture que vous utilisez. Vous venez de le construire pour prouver que cela fonctionne.

Une fois que vous l'avez créé et mis à la poubelle, je serais prêt à parier que vous auriez plus de facilité à prendre ces décisions.

Je souffre de ce problème aussi. Ce que je dirais, c'est que vous n'avez pas assez d'incitation à l'achèvement.

Par exemple, lorsque j'écrivais du code de rendu, j'avais un important incitatif à l'achèvement parce que je savais que si je m'entendais bien, je pouvais voir le système en action et penser à quel point j'étais génial pour texturer un quad, ou transformer un vert. Mais maintenant que je re-factorise (tentative 4, si vous voulez savoir), je souffre parce que c'est beaucoup de travail et même si je termine, je vais juste voir le même vieux quad. Et je ne veux vraiment plus avoir à refacturer et j'en ai marre de voir le même vieux quad encore et encore, et ce n'est plus une récompense pour moi.

Vous devez le diviser en composants et vous récompenser de les avoir terminés, même si ce n’est qu’avec une console d’entrée / sortie qui montre que cela fonctionne.

J'étais en train de lire votre question et de réfléchir aux idées des autres affiches: vous ne vous adaptez pas à ce travail; donnez-vous une limite de temps; faire quelque chose d'autre pour un moment. Après réflexion, je ne suis pas sûr que les réponses soient vraiment utiles

Le problème avec les problèmes mentaux tels que celui-ci est qu’ils ne sont pas faciles à résoudre, ils font partie de vous, et évidemment vous vous souciez (trop peut-être) de votre travail, vous n’avez pas la confiance d’être d’accord avec vous-même, vous êtes trop inexpérimentés à considérer que votre premier choix était correct depuis le début, ou que le stress était trop important pour obtenir un résultat parfait. Pourquoi voudriez-vous vous inquiéter pour de telles banalités?!

Maintenant, j'ai des problèmes similaires, mais pas beaucoup avec le code .. généralement c'est quoi avoir pour le dîner .. pizza ou curry .. hmm ... pizza mais alors curry c'est bien, mais est-ce que je me sens comme un curry, la pizza est moins chère , mais alors vous obtenez plus de curry, mais ... et ainsi de suite. :)

Alors j'ai pensé - pourquoi n'ai-je pas des problèmes similaires avec le codage, et je pense que c'est simplement parce que j'ai un ensemble de motifs que j'utilise régulièrement. Si j'ai besoin d'une définition de fonction, c'est facile ... ce sera dans la même veine que toute autre définition de fonction que j'ai jamais codée. Si j'ai besoin d'un flux de contrôle, je décide d'abord si j'ai besoin d'une boucle for ou d'une boucle while, puis je crée le même ancien code que celui que j'avais utilisé la dernière fois où j'avais besoin de l'une de ces choses. La même chose vaut pour tout, est-ce que je veux une file d'attente? Bien sûr, allons couper et coller mon code de file d'attente 'standard' (archivé du dernier projet sur lequel j'ai travaillé ou de celui dont je me souviens en utilisant l'une de ces choses). Résultat final ... Je ne m'inquiète que de nouvelles choses et, pour être honnête, c'est un plaisir.

Mon conseil est donc de commencer à créer une bibliothèque d'extraits de code - j'avais l'habitude de les envoyer par courrier électronique à moi-même et de les mettre dans un dossier, mais quel que soit le type de travail avec lequel vous travaillez est préférable - et vous commencerez alors à savoir quoi faire à chaque fois. Vous irez toujours à l'ancien code que vous avez écrit et résoudrez le problème, prêt pour le problème suivant. Vous deviendrez un développeur beaucoup plus rapide (sérieusement, c’est le seul moyen d’améliorer la productivité des programmeurs) et espérons trouver du temps pour les éléments amusants, et non les tristes problèmes quotidiens que vous avez déjà résolus à maintes reprises. plus de.

Bien sûr, la dernière partie de tout ce qui est important aussi - plus vous travaillez, moins vous avez de temps à penser.

Voici une stratégie qui combine les suggestions de Rein Henrichs ( start simple, refactor ) et de ammoQ ( timeboxing ):

1. Donnez-vous un délai assez strict pour une première solution qui fonctionne. Par exemple, 30 secondes pour un nom de variable. Vous pouvez d’abord proposer quelque chose comme x, puis l’affiner string, namejusqu’à ce que le temps soit écoulé.
2. Passez ensuite à d’ autres tâches pendant une durée déterminée, par exemple 10 minutes.
3. Alors seulement, accordez-vous un autre délai pour améliorer votre décision, par exemple pouruserHandle

Avantages possibles de cette approche:

• la connaissance de revenir à cela plus tard peut aider à résoudre le problème pour l'instant
• Tout en continuant d'autres tâches, vous pouvez simplement trouver une solution satisfaisante et satisfaisante sans fouiller trop de temps.
• avoir relâché après l'étape 1 et être dans le flux de l'étape 2 , il peut s'avérer facile de garder l'étape 3 vraiment rapide, car vous souhaitez continuer avec l'étape 2, et donc choisir simplement une solution décente et l'accepter

Quand j'ai fait les recherches et qu'il ne me reste plus aucun choix, je me donne un délai (habituellement 5 minutes) pour en choisir un, puis je vais de l' avant. Même si vous rencontrez des obstacles, à ce stade, rien ne garantit que vous n'auriez pas rencontré le même obstacle en prenant une décision différente. Je ne peux pas penser à un moment où j'ai regretté ma décision.

Généralement, la raison pour laquelle vous ne pouvez pas décider est que la différence est insignifiante ou que vous ne disposez pas de suffisamment d'informations.

Dans le cas a) Fixez une limite de temps pour proposer des options raisonnables à considérer. Ne décidez pas lequel. À la fin du temps, choisissez une (au hasard si aucune préférence claire) des options identifiées et une autre limite de temps. Si aucune décision claire n’est prise à la fin du temps, c’est celui qui a déjà été choisi. Commencez à coder et à refactoriser si vous vous êtes clairement trompé. Si le patron demande pourquoi, dites "J'ai lancé une pièce de monnaie, vous avez un meilleur moyen?"

Dans le cas b) - vous avez besoin de plus d’informations et vous asseyez-vous sur votre grosse graisse .... tout au long de la journée ne vous la fournira pas. Sortez du mode conception et passez en mode collecte d'informations. Prototypes, poser des questions, lire des magazines techniques. Quoi que vous fassiez, ne dormez pas trop longtemps dessus.

Souvent, la meilleure solution consiste à essayer d’expliquer votre décision à un collègue. Cependant, comme vous ne voulez pas le faire très souvent, la meilleure chose à faire est de penser sur papier, avec un stylo / papier ou une fenêtre vide du bloc-notes.

Commencez par écrire absolument n'importe quoi - juste pour entrer dans le rythme de l'écriture. Dans une fenêtre du bloc-notes, vous pouvez simplement taper "Je réfléchis sur papier" et continuer avec un flot de conscience. Après quelques secondes, vous serez au rythme de l'écriture. Appuyez donc plusieurs fois sur Entrée et commencez à expliquer votre dilemme.

Énoncez le problème, puis indiquez les solutions possibles, les avantages de chacune d’elles, etc.

Bien que cela ne fonctionne pas toujours, le processus de récupération des pensées de votre tête (RAM) sur un support externe (le bloc-notes) vous donne plus de liberté pour établir de nouvelles connexions et voir la décision sous différents angles.

Je souffre du même problème. Pour les petits problèmes, la façon dont je tente de le gérer est d’utiliser le premier design auquel je pense qui n’est pas stupide. Il ne sert à rien d'essayer de trouver un design optimal; Il est difficile, voire impossible, de raisonner sur toutes les nuances d'un dessin auquel vous pourriez penser sans le rédiger. En codant, vous constaterez que vous pouvez apporter de petites améliorations. Bien fait, je trouve qu'il est assez facile de converger vers une solution raisonnablement bonne de cette façon.

Pour les plus gros problèmes, je pense qu’il est utile de réfléchir à vos options en premier lieu, mais à la chronologie. Les gros problèmes ont de grands espaces de solutions, vous ne pouvez pas évaluer toutes les possibilités, vous ne devriez pas non plus essayer.

TLDR; Choisissez une solution raisonnable, améliorez-la au fur et à mesure.

Ceci est également pertinent:

Le professeur de céramique a annoncé le jour de l'ouverture qu'il divisait la classe en deux groupes. Tous ceux du côté gauche du studio, a-t-il dit, seraient classés uniquement en fonction de la quantité de travail produit, tous ceux de droite uniquement en fonction de la qualité. Sa procédure était simple: le dernier jour de classe, il apportait sa balance de salle de bain et pesait le travail du groupe "quantité": cinquante livres de pots notés "A", quarante livres par "B", etc. Ceux qui sont classés sur la "qualité", cependant, n'ont besoin de produire qu'un seul pot - même s'il est parfait - pour obtenir un "A".

Et bien, le temps du classement est arrivé et un fait curieux a émergé: les œuvres de la plus haute qualité ont toutes été produites par le groupe classé pour la quantité. Il semble que pendant que le groupe "quantité" travaillait activement - et tirait des leçons de leurs erreurs - le groupe "qualité" avait théorisé la perfection et n'avait finalement guère plus à montrer de leurs efforts que des théories grandioses et un tas d'argile morte.

tiré de http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Je n'ai jamais compris cela. Quand j'étais instructeur, je disais quelque chose comme:

"OK, create an integer variable and assign the return value of strlen() to it."

Pas trop compliqué, vous pourriez le penser, et 95% des gens ont écrit quelque chose comme:

int x;   // or y, or len, or whatever
x = strlen( s );

Mais il y avait parfois quelqu'un assis comme un lapin paralysé par les phares. Je demanderais avec sympathie quel était le problème et ils diraient "Je ne sais pas comment l'appeler!".

Ce sont les personnes qui devraient chercher une autre carrière. Comme peut-être devriez-vous.