Combate ao efeito Einstellung [fechado]

O Efeito Einstellung refere-se à "predisposição de uma pessoa para resolver um determinado problema de uma maneira específica, mesmo que haja métodos" melhores "ou mais apropriados para resolver o problema".

Como programador com uma quantidade razoável de experiência, como combater essa tendência de sempre abordar a solução de problemas a partir de caminhos "experimentados e verdadeiros" da experiência passada?

Para dar dois exemplos muito concretos, construo aplicativos da Web há muito tempo, tempo suficiente para anteceder o amplo uso de estruturas Javascript (por exemplo, jQuery) e melhores estruturas de aplicativos da Web (por exemplo, ASP.NET MVC). Se eu tenho um trabalho do cliente em que estou com problemas de tempo ou pressionando questões do domínio do problema ou das regras de negócios, costumo usar o que sei para tentar obter uma solução. Isso envolve coisas muito feias como

document.getElementById 

ou usando o ASP.NET com controles vinculados ao modelo (DataList / Repeater), em vez de descobrir como re-projetar coisas com uma abordagem do ASP.NET MVC.

Uma técnica que usei no passado é ter projetos pessoais que existem simplesmente para explorar essas novas tecnologias, mas isso é difícil de sustentar. Que outras abordagens poderiam ser recomendadas?

Esta é uma grande pergunta. E acho que não são apenas os programadores seniores que se deparam com isso - abordar isso com antecedência pode ser uma ótima maneira de um aluno acelerar o desenvolvimento de suas habilidades.

Existem dois lados dessa questão - um que é ruim e outro que é realmente bom .

Ruim - Escolher a solução errada

Aqui está um exemplo - como um desenvolvedor inexperiente, você pode ter apenas realmente resolveu dois problemas antes, problemas A e B . Neste ponto, você sabe que há problemas que você não conhece, mas dada a lente de sua própria experiência, muito do que você vê parece que pode ser uma ou B .

Junto vem um novo problema. Para você, isso novos olhares problemáticas como problema Um , para que resolvê-lo da maneira que você normalmente resolver A . Algo não se sente bem, e leva mais tempo, e como você trabalha você acaba percebendo que este é um problema novo, C . É uma variação de A que você não sabia que existia.

Então, o que você faz para não cometer esse erro novamente? Duas coisas:

1. Descobrir o que havia de diferente nesse novo problema. Descubra quais abordagens podem ter funcionado de maneira diferente e por quê.
2. Catalogue esse problema e prossiga para solucionar mais problemas novos.

Isso deve ajudá-lo a resolver naturalmente esse problema. Quando você tem 10 anos de experiência, já conhece os problemas de A a Z e seu repertório de soluções é extenso.

Bom - Eficiência

No mundo real, com prazos e recursos limitados, usar o que você sabe nem sempre é ruim:

1. No início do processo de solução de problemas, você compara o novo problema a todos os problemas que conhece.
2. Você tentará reconhecer os sinais e decidir com qual conjunto de problemas isso se parece.
3. Se uma correspondência de 100% não puder ser feita, um desenvolvedor experiente ponderará o risco de gastar mais tempo na descoberta contra os riscos de uma execução possivelmente falha. Se o risco de perda de tempo for muito alto, basta seguir em frente com o que sabe.

Isso não é uma coisa ruim - é usar a análise de risco para escolher a eficiência com mais de 100% de precisão. É feito todos os dias e todos nós estaríamos presos a coisas que não nos levariam a lugar algum se não o fizéssemos.

Então, para responder sua pergunta:

Como programador com uma quantidade razoável de experiência, como combater essa tendência de sempre abordar a solução de problemas a partir de caminhos "experimentados e verdadeiros" da experiência passada?

1. Continue procurando e catalogando novos problemas
2. Melhor na seleção da solução certa para o problema; em vez de apenas saber qual solução, saiba por que está certa.
3. Pratique e aprimore suas habilidades de tomada de decisão. Às vezes, a eficiência é a escolha certa, e melhorar o reconhecimento desses tempos levará a vantagens mensuráveis ​​do mundo real.

Separe 20% do seu tempo de trabalho para melhorar suas habilidades / fazer as coisas direito, em vez de rápido. Caso contrário, você lentamente começa a ficar para trás. Isso pode significar que você realiza menos trabalho no curto prazo, mas no longo prazo esse investimento será recompensado.

A parte difícil é resistir à pressão de cortar custos com isso. Até que o hábito esteja arraigado, apenas não corte esse canto. Quando estiver no ponto em que considera esse investimento em suas habilidades como "normal", você poderá optar por executar ocasionalmente um projeto. Enquanto isso, não considere esse período opcional e faça suas estimativas de acordo.

Desenvolvimento de software, na minha opinião, nem sempre é encontrar a solução * melhor * absoluta , mas fazer as coisas. Talvez, se você nem sempre resolva o problema da melhor maneira, esse não seja o fim do mundo.

No entanto, se você acha que fazer as coisas da melhor maneira é importante, acho que a melhor aposta seria desenvolver como parte de uma equipe. Discuta o design e faça revisões de código com os colegas. Como as pessoas normalmente têm antecedentes e preferências diferentes, entre duas ou três pessoas, você deve ter várias opiniões diferentes sobre problemas e soluções.

Como programador com uma quantidade razoável de experiência, como combater essa tendência de sempre abordar a solução de problemas a partir de caminhos "experimentados e verdadeiros" da experiência passada?

Refatorar regularmente. A refatoração exige que examinemos o código que escrevemos no passado. Podemos usar esse tempo para visualizar o código antigo com uma nova perspectiva. Contanto que você acompanhe as principais mudanças tecnológicas, pode-se fazer atualizações conforme necessário.

Se eu tenho um trabalho do cliente em que estou com problemas de tempo ou pressionando questões do domínio do problema ou das regras de negócios, costumo usar o que sei para tentar obter uma solução.

Boa. Você está focando nas necessidades do cliente e não nos seus próprios objetivos. Caminho a percorrer.

Isso envolve coisas muito feias como

document.getElementById

ou usando o ASP.NET com controles vinculados ao modelo (DataList / Repeater), em vez de descobrir como re-projetar coisas com uma abordagem do ASP.NET MVC.

Não há nada de errado com os Webforms. O MVC não se destina a substituir os Webforms. Também não é hora de aprender uma nova tecnologia. Lembre-se do triângulo. Refatorar quando tiver tempo. Veja também a primeira declaração.

Uma técnica que usei no passado é ter projetos pessoais que existem simplesmente para explorar essas novas tecnologias, mas isso é difícil de sustentar. Que outras abordagens poderiam ser recomendadas?

O que é difícil de sustentar? Espero que você não esteja mantendo projetos projetados para aprender. Nesse caso, jogue fora os projetos de amostra. Não há nada errado em criar projetos únicos para fins de aprendizado. Isso é uma coisa muito boa. Veja a primeira declaração.

Tentado e verdadeiro! = Ruim. O "Efeito Einstellung" é um pouco fora de contexto aqui. Os testes se referem a pessoas que otimizam "abrir um pote". Os métodos das pessoas de "abrir um pote" são limitados e não aumentam com o tempo (excluindo qualquer material de ficção científica). No software, a melhor maneira de "realizar a tarefa X" muda com o tempo.

Algo que ajuda a pensar fora da caixa é ter uma prática real para fazê-lo. Edward De Bono escreveu muitos livros sobre pensamento lateral e assuntos relacionados.

Mas em qualquer ponto de decisão, o que mais importa é avaliar e adotar riscos. Waltzing with Bears de De Marco and Lister é um dos melhores livros sobre o assunto quando aplicado ao desenvolvimento de software.

A programação extrema e outras metodologias ágeis propõem que se deve seguir em frente e experimentar as novas soluções (spike) como rotina. Faço experimentos com diferentes tecnologias durante a inicialização do projeto, e isso me salvou várias vezes de me apaixonar pelo que é verdade e provado, e às vezes para descobrir uma nova jóia tecnológica.

Como equipe, você pode mudar o grupo reconhecendo a grandiosidade que quebra padrões. Costumo usar pessoas novas para isso, porque elas não são invadidas pela maneira normal de fazer as coisas. Essa é uma resposta gerencial - mas mesmo como um engenheiro experiente, acho que você pode perceber que a visão de outra pessoa pode ser menos tendenciosa e, portanto, considerar com uma classificação com pelo menos o mesmo peso que sua própria opinião (talvez até mais).

Você tem certeza de que não é apenas o que você colocaria em vez de document.getElementById é realmente uma perda de tempo, não importa o quanto você esteja acomodado?

Edit: Acabei de perceber que os dois exemplos são sobre ferramentas, isso pode ser porque você considera que a alteração das ferramentas é o maior marco do desenvolvimento de suas habilidades. Um bom codificador precisa de pouco mais do que uma linguagem completa de Turing para trabalhar suas maravilhas, ou seja, as ferramentas não são importantes, mas o que você está usando já não é exatamente um conjunto de ferramentas do fundo do poço. Se passar de uma ferramenta para outra é o maior progresso que você pode imaginar, pode ser que você tenha basicamente parado nas áreas menos quantificáveis.

Como programador com uma quantidade razoável de experiência, como combater essa tendência de sempre abordar a solução de problemas a partir de caminhos "experimentados e verdadeiros" da experiência passada?

Autoconsciência

Esteja ciente de suas tendências, suas fraquezas e seus pontos fortes.

Decisões Conscientes

Faça suas decisões explícitas e conscientes. Não pule para fazer algo sem pensar conscientemente sobre como você o fará.

Aprenda e Aplique

Continue aprendendo novas técnicas e considere onde elas podem ser aplicadas. Quando você se deparar com uma situação em que ela possa ser aplicada, faça uma análise de custo-benefício. Às vezes, o benefício de tentar algo novo supera o benefício de uma solução conhecida.