Combattre l'effet Einstellung [fermé]

L' effet Einstellung fait référence à "la prédisposition d'une personne à résoudre un problème donné d'une manière spécifique, même s'il existe des méthodes" meilleures "ou plus appropriées pour résoudre le problème".

En tant que programmeur avec une expérience décente, comment peut-on lutter contre cette tendance à toujours aborder la résolution de problèmes à partir de chemins "éprouvés et réels" à partir de l'expérience passée?

Pour donner deux exemples très concrets, je construis des applications Web depuis longtemps, suffisamment longtemps pour précéder une large utilisation des cadres Javascript (par exemple jQuery) et de meilleurs cadres d'applications Web (par exemple ASP.NET MVC). Si je travaille avec un client où je suis confronté à une crise de temps ou à des problèmes urgents du domaine problématique ou des règles commerciales, j'ai tendance à utiliser ce que je sais pour essayer de trouver une solution. Cela implique des choses très laides comme

document.getElementById 

ou en utilisant ASP.NET avec des contrôles liés aux modèles (DataList / Repeater) plutôt que de trouver comment réorganiser les choses avec une approche ASP.NET MVC.

Une technique que j'ai utilisée dans le passé est d'avoir des projets personnels qui existent simplement pour explorer ces nouvelles technologies mais c'est difficile à maintenir. Quelles autres approches pourraient être recommandées?

c'est une excellente question. Et je pense que ce n'est pas seulement les programmeurs seniors qui se heurtent à cela - y remédier tôt peut être un excellent moyen pour un apprenant d'accélérer son développement de compétences.

Il y a deux côtés à cette question - une qui est mauvaise et une qui est en fait bonne .

Mauvais - Choisir la mauvaise solution

Voici un exemple - en tant que développeur inexpérimenté, vous devrez peut- être que vraiment résolu deux problèmes avant, les problèmes A et B . À ce stade, vous savez qu'il ya des problèmes que vous ne savez pas, mais étant donné l'objectif de votre propre expérience, beaucoup de ce que vous voyez ressemble à cela pourrait être un ou B .

Vient ensuite un nouveau problème. Pour vous, ce nouveau problème ressemble problème A , donc vous résoudre la façon dont vous résoudre habituellement A . Quelque chose ne se sent pas bien, et il prend plus de temps, et que vous vous travaillez finissent par réaliser c'est un nouveau problème, C . C'est une variation de A dont vous ignoriez l'existence.

Alors, que faites-vous pour ne pas refaire cette erreur? Deux choses:

1. Découvrez ce qui était différent dans ce nouveau problème. Découvrez quelles approches peuvent avoir fonctionné différemment et pourquoi.
2. Cataloguez ce problème et passez à la résolution de nouveaux problèmes.

Cela devrait vous aider à résoudre naturellement ce problème. Au moment où vous avez 10 ans d'expérience, vous connaissez les problèmes de A à Z et votre répertoire de solutions est vaste.

Bon - efficacité

Dans le monde réel, avec des délais et des ressources limitées, utiliser ce que vous savez n'est pas toujours mauvais:

1. Au début du processus de résolution de problèmes, vous comparez le nouveau problème à tous les problèmes que vous connaissez.
2. Vous allez essayer de reconnaître les signes et de décider à quel problème cela ressemble.
3. Si une correspondance à 100% ne peut pas être établie, un développeur expérimenté évaluera le risque de passer plus de temps à la découverte par rapport aux risques d'une exécution potentiellement défectueuse. Si le risque de perte de temps est trop élevé, vous n'avez qu'à aller de l'avant avec ce que vous savez.

Ce n'est pas une mauvaise chose - il utilise l'analyse des risques pour choisir l' efficacité plutôt que la précision à 100%. C'est fait tous les jours et nous serions tous liés à des choses qui ne nous mèneraient nulle part si nous ne le faisions pas.

Donc, pour répondre à votre question:

En tant que programmeur avec une expérience décente, comment peut-on lutter contre cette tendance à toujours aborder la résolution de problèmes à partir de chemins "éprouvés et réels" à partir de l'expérience passée?

1. Continuez à chercher et à cataloguer de nouveaux problèmes
2. Mieux à sélectionner la bonne solution pour le problème; au lieu de simplement savoir quelle solution, sachez pourquoi elle est juste.
3. Pratiquez et perfectionnez vos compétences en prise de décision. Parfois, l'efficacité est le bon choix, et mieux reconnaître ces temps entraînera des avantages mesurables dans le monde réel.

Réservez 20% de votre temps de travail pour améliorer vos compétences / faire les choses correctement plutôt que rapidement. Sinon, vous commencez lentement à prendre du retard. Cela peut signifier que vous faites moins de travail à court terme, mais à long terme, cet investissement sera payant.

La partie difficile résiste à la pression de couper les coins ronds à ce sujet. Jusqu'à ce que l'habitude soit ancrée, ne coupez pas ce coin. Une fois que vous êtes au point où vous considérez cet investissement dans vos compétences comme «normal», vous pouvez alors choisir de vous précipiter de temps en temps dans un projet. En attendant, ne considérez pas ce temps comme facultatif et formez vos estimations en conséquence.

À mon avis, le développement de logiciels ne consiste pas toujours à trouver la * meilleure * solution absolue , mais à faire avancer les choses. Alors peut-être que si vous ne résolvez pas toujours le problème de la meilleure façon, ce n'est pas la fin du monde.

Cependant, si vous pensez que faire les choses de la meilleure manière est important, je pense que le meilleur pari serait de faire partie d'une équipe. Discutez de la conception et faites des revues de code avec vos collègues. Étant donné que les gens ont normalement des antécédents et des préférences différents, entre deux ou trois personnes, vous devriez avoir plusieurs points de vue différents sur les problèmes et les solutions.

En tant que programmeur avec une expérience décente, comment peut-on lutter contre cette tendance à toujours aborder la résolution de problèmes à partir de chemins "éprouvés et réels" à partir de l'expérience passée?

Refonte régulièrement. La refactorisation nécessite que nous examinions le code que nous avons écrit dans le passé. Nous pouvons utiliser ce temps pour voir l'ancien code avec une nouvelle perspective. Tant que vous suivez les changements technologiques majeurs, vous pouvez effectuer des mises à jour si vous le jugez nécessaire.

Si je travaille avec un client où je suis confronté à une crise de temps ou à des problèmes urgents du domaine problématique ou des règles commerciales, j'ai tendance à utiliser ce que je sais pour essayer de trouver une solution.

Bien. Vous vous concentrez sur les besoins du client plutôt que sur vos propres objectifs. Marche à suivre.

Cela implique des choses très laides comme

document.getElementById

ou en utilisant ASP.NET avec des contrôles liés aux modèles (DataList / Repeater) plutôt que de trouver comment réorganiser les choses avec une approche ASP.NET MVC.

Il n'y a rien de mal avec les formulaires Web. MVC n'est pas destiné à remplacer les formulaires Web. Ce n'est pas le moment non plus d'apprendre une nouvelle technologie. Rappelez-vous le triangle. Refactorisez quand vous avez le temps. Voir également la première déclaration.

Une technique que j'ai utilisée dans le passé est d'avoir des projets personnels qui existent simplement pour explorer ces nouvelles technologies mais c'est difficile à maintenir. Quelles autres approches pourraient être recommandées?

Qu'est-ce qui est difficile à maintenir? J'espère que vous ne maintenez pas de projets conçus pour que vous appreniez. Si tel est le cas, jetez les exemples de projets. Il n'y a rien de mal à créer des projets uniques à des fins d'apprentissage. C'est une très bonne chose. Voir la première déclaration.

Essayé et vrai! = Mauvais. L '«effet Einstellung» est ici un peu hors contexte. Les tests se réfèrent à des personnes optimisant "l'ouverture d'un pot". Les méthodes utilisées par les utilisateurs pour "ouvrir un pot" sont limitées et ne s'améliorent pas au fil du temps (à l'exclusion de tout ce qui concerne la science-fiction). Dans le logiciel, la meilleure façon de "réaliser la tâche X" change avec le temps.

Quelque chose qui aide à sortir des sentiers battus est d'avoir une pratique réelle pour le faire. Edward De Bono a écrit de nombreux livres sur la pensée latérale et les sujets connexes.

Mais à un point de décision donné, ce qui importe le plus, c'est d'évaluer et d'embrasser le risque. Valse avec des ours de De Marco et Lister est l'un des meilleurs livres sur le sujet lorsqu'il est appliqué au développement de logiciels.

La programmation extrême et d'autres méthodologies agiles proposent que l'on devrait simplement aller de l'avant et expérimenter les nouvelles solutions (pointes) comme une question de routine. Je fais des expériences avec différentes technologies lors des démarrages de projets, ce qui m'a évité à plusieurs reprises de tomber sous le charme des vrais et des essayés, et parfois de découvrir un nouveau bijou technologique.

En équipe, vous pouvez changer le groupe en reconnaissant la génialité révolutionnaire. J'utilise souvent de nouvelles personnes pour cela, car elles ne sont pas brisées dans la façon normale de faire les choses. C'est un peu une réponse managériale - mais même en tant qu'ingénieur expérimenté, je pense que vous pouvez réaliser que le point de vue de quelqu'un d'autre peut être moins biaisé et envisagez donc avec un classement d'au moins autant de poids que votre propre opinion (peut-être même plus).

Êtes-vous sûr que ce n'est pas seulement ce que vous mettriez à la place de document.getElementById qui est vraiment une perte de temps, peu importe à quel point vous y êtes accommodé?

Edit: Je viens de réaliser, vos deux exemples concernent les outils, cela pourrait être parce que vous envisagez de changer vos outils comme le plus grand jalon de votre développement de compétences. Un bon codeur a besoin d'un peu plus qu'un langage complet de Turing pour faire ses merveilles, ce qui ne veut pas dire que les outils ne sont pas importants, mais ce que vous utilisez déjà n'est pas exactement un ensemble d'outils extrêmement bas. Si le passage d'un outil à un autre est le plus grand progrès auquel vous pouvez penser, il se peut que vous ayez essentiellement calé dans les domaines les moins quantifiables.

En tant que programmeur avec une expérience décente, comment peut-on lutter contre cette tendance à toujours aborder la résolution de problèmes à partir de chemins "éprouvés et réels" à partir de l'expérience passée?

Connaissance de soi

Soyez conscient de vos tendances, de vos faiblesses et de vos forces.

Décisions conscientes

Rendez vos décisions explicites et conscientes. Ne sautez pas pour faire quelque chose sans réfléchir consciemment à la façon dont vous allez le faire.

Apprenez et postulez

Continuez à apprendre de nouvelles techniques et à déterminer où elles peuvent être appliquées. Lorsque vous rencontrez une situation où il peut être appliqué, effectuez une analyse coûts-avantages. Parfois, l'avantage d'essayer quelque chose de nouveau l'emporte sur l'avantage d'une solution connue.