Combatiendo el efecto Einstellung [cerrado]

El efecto Einstellung se refiere a "la predisposición de una persona a resolver un problema dado de una manera específica a pesar de que existen métodos" mejores "o más apropiados para resolver el problema".

Como programador con una cantidad decente de experiencia, ¿cómo se puede combatir esta tendencia a abordar siempre la resolución de problemas desde caminos "probados y verdaderos" de la experiencia pasada?

Para dar dos ejemplos muy concretos, he estado construyendo aplicaciones web durante mucho tiempo, lo suficiente como para ser anterior al amplio uso de frameworks Javascript (por ejemplo, jQuery) y mejores marcos de aplicaciones web (por ejemplo, ASP.NET MVC). Si tengo trabajo de cliente en un momento en el que tengo problemas de tiempo o problemas urgentes del dominio del problema o de las reglas comerciales, tiendo a usar lo que sé para tratar de lograr una solución. Esto implica cosas muy feas como

document.getElementById 

o usar ASP.NET con controles de plantilla (DataList / Repeater) en lugar de descubrir cómo volver a diseñar cosas con un enfoque ASP.NET MVC.

Una técnica que he usado en el pasado es tener proyectos personales que existen simplemente para explorar estas nuevas tecnologías, pero esto es difícil de mantener. ¿Qué otros enfoques se pueden recomendar?

Esta es una gran pregunta. Y creo que no son solo los programadores senior los que se enfrentan a esto: abordarlo temprano puede ser una excelente manera para que un alumno acelere el desarrollo de sus habilidades.

Hay dos lados de este problema: uno que es malo y otro que es realmente bueno .

Malo: elegir la solución incorrecta

He aquí un ejemplo - como un desarrollador inexperto, es posible que sólo es realmente resuelto dos problemas antes, problemas Un y B . En este punto, usted sabe que hay problemas que no conoces, pero dada la lente de su propia experiencia, una gran cantidad de lo que se ve parece que podría ser una o B .

A lo largo viene un nuevo problema. Para usted, esta nueva apariencia problemáticas como problema A , por lo que resuelven de la manera que por lo general resolver una . Algo no se siente bien, y se tarda más tiempo, y mientras trabaja se termina dando cuenta de que esto es un problema nuevo, C . Es una variación de A que no sabías que existía.

Entonces, ¿qué haces para no volver a cometer este error? Dos cosas:

1. Descubre qué era diferente acerca de este nuevo problema. Averigüe qué enfoques pueden haber funcionado de manera diferente y por qué.
2. Catalogue este problema y avance para resolver más problemas nuevos.

Esto debería ayudarte a resolver este problema de forma natural . Para cuando tenga 10 años de experiencia, ya está familiarizado con los problemas de la A a la Z y su repertorio de soluciones es extenso.

Bueno - Eficiencia

En el mundo real, con plazos y recursos limitados, usar lo que sabes no siempre es malo:

1. Al comienzo del proceso de resolución de problemas, compara el nuevo problema con todos los problemas que conoce.
2. Intentará reconocer los signos y decidir a qué conjunto de problemas se parece.
3. Si no se puede hacer una coincidencia del 100%, un desarrollador experimentado sopesará el riesgo de pasar más tiempo en el descubrimiento frente a los riesgos de una ejecución posiblemente defectuosa. Si el riesgo de pérdida de tiempo es demasiado alto, simplemente continúe con lo que sabe.

Eso no es malo: está utilizando el análisis de riesgos para elegir la eficiencia por encima del 100% de precisión. Se hace todos los días y todos estaríamos atados a cosas que no nos llevarían a ninguna parte si no lo hiciéramos.

Entonces, para responder a su pregunta:

Como programador con una cantidad decente de experiencia, ¿cómo se puede combatir esta tendencia a abordar siempre la resolución de problemas desde caminos "probados y verdaderos" de la experiencia pasada?

1. Sigue buscando y catalogando nuevos problemas
2. Mejore al seleccionar la solución correcta para el problema; en lugar de simplemente saber qué solución, saber por qué es correcta.
3. Practica y perfecciona tus habilidades para tomar decisiones. A veces, la eficiencia es la elección correcta, y mejorar en el reconocimiento de esos tiempos dará lugar a ventajas medibles en el mundo real.

Reserve un 20% de su tiempo de trabajo para mejorar sus habilidades / hacer las cosas bien en lugar de rápido. De lo contrario, lentamente comienza a quedarse atrás. Esto podría significar que realiza menos trabajo a corto plazo, pero a largo plazo esa inversión dará sus frutos.

La parte difícil es resistir la presión de cortar esquinas en esto. Hasta que el hábito esté arraigado, simplemente no corte esa esquina. Una vez que esté en el punto en que considera que esta inversión en sus habilidades es "normal", puede optar por apresurarse ocasionalmente en un proyecto. Mientras tanto, no considere este tiempo opcional y forme sus estimaciones en consecuencia.

El desarrollo de software, en mi opinión, no siempre se trata de encontrar la solución absoluta * mejor *, sino de hacer las cosas. Entonces, si no siempre resuelve el problema de la mejor manera, ese no es el fin del mundo.

Sin embargo, si sientes que hacer las cosas de la mejor manera es importante, entonces creo que la mejor apuesta sería desarrollar como parte de un equipo. Discuta el diseño y haga revisiones de código con colegas. Dado que las personas normalmente tienen diferentes antecedentes y preferencias, entre dos o tres personas, debe tener varias opiniones diferentes sobre los problemas y las soluciones.

Como programador con una cantidad decente de experiencia, ¿cómo se puede combatir esta tendencia a abordar siempre la resolución de problemas desde caminos "probados y verdaderos" de la experiencia pasada?

Refactorizar regularmente. La refactorización requiere que analicemos el código que escribimos en el pasado. Podemos usar este tiempo para ver el código antiguo con una nueva perspectiva. Siempre que se mantenga al día con los principales cambios tecnológicos, se pueden realizar actualizaciones según lo considere necesario.

Si tengo trabajo de cliente en un momento en el que tengo problemas de tiempo o problemas urgentes del dominio del problema o de las reglas comerciales, tiendo a usar lo que sé para tratar de lograr una solución.

Bueno. Se está centrando en las necesidades del cliente en lugar de sus propios objetivos. Camino a seguir.

Esto implica cosas muy feas como

document.getElementById

o usar ASP.NET con controles de plantilla (DataList / Repeater) en lugar de descubrir cómo volver a diseñar cosas con un enfoque ASP.NET MVC.

No hay nada malo con los formularios web. MVC no está destinado a reemplazar formularios web. Este tampoco es el momento de aprender una nueva tecnología. Recuerda el triangulo. Refactorizar cuando tengas tiempo. Además, vea la primera declaración.

Una técnica que he usado en el pasado es tener proyectos personales que existen simplemente para explorar estas nuevas tecnologías, pero esto es difícil de mantener. ¿Qué otros enfoques se pueden recomendar?

¿Qué es difícil de sostener? Esperemos que no esté manteniendo proyectos diseñados para que pueda aprender. Si es así, deseche los proyectos de muestra. No hay nada de malo en crear proyectos únicos con fines de aprendizaje. Esta es una cosa muy buena. Ver primera declaración.

Probado y verdadero! = Malo. El "efecto Einstellung" se toma un poco fuera de contexto aquí. Las pruebas se refieren a personas que optimizan "abrir un frasco". Los métodos de las personas para "abrir un frasco" son limitados y no mejoran con el tiempo (excluyendo cualquier cosa de ciencia ficción). En software, la mejor manera de "lograr la tarea X" cambia con el tiempo.

Algo que ayuda a pensar fuera de la caja es tener una práctica real para hacerlo. Edward De Bono ha escrito muchos libros sobre pensamiento lateral y temas relacionados.

Pero en cualquier punto de decisión dado, lo que más importa es evaluar y aceptar el riesgo. Waltzing with Bears de De Marco and Lister es uno de los mejores libros sobre el tema cuando se aplica al desarrollo de software.

La programación extrema y otras metodologías ágiles proponen que uno debería seguir adelante y experimentar con las nuevas soluciones (de punta) como una cuestión de rutina. Hago experimentos con diferentes tecnologías durante los inicios del proyecto, y eso me ha salvado varias veces de caer en la exageración a favor de lo verdadero y probado, y a veces descubrir una nueva joya tecnológica.

Como equipo, puedes cambiar el grupo al reconocer la genialidad que rompe patrones. A menudo uso personas nuevas para esto, porque no están divididas en la forma normal de hacer las cosas. Esta es una respuesta gerencial, pero incluso como ingeniero experimentado, creo que puedes darte cuenta de que la opinión de otra persona puede ser menos sesgada y, por lo tanto, considera con una clasificación de al menos tanto peso como tu propia opinión (tal vez incluso más).

¿Estás seguro de que no es solo lo que pondrías en lugar de document.getElementById es realmente una pérdida de tiempo sin importar cuán acomodado estés?

Editar: Me acabo de dar cuenta, sus dos ejemplos son sobre herramientas, esto podría deberse a que considera cambiar sus herramientas como el mayor hito en el desarrollo de sus habilidades. Un buen programador necesita poco más que un lenguaje completo de Turing para hacer sus maravillas, es decir, las herramientas no son importantes, pero lo que está utilizando ya no es exactamente un conjunto de herramientas de fondo. Si pasar de una herramienta a otra es el mayor progreso en el que puede pensar, puede ser que básicamente se haya estancado en las áreas menos cuantificables.

Como programador con una cantidad decente de experiencia, ¿cómo se puede combatir esta tendencia a abordar siempre la resolución de problemas desde caminos "probados y verdaderos" de la experiencia pasada?

Conciencia de sí mismo

Sé consciente de tus tendencias, tus debilidades y tus fortalezas.

Decisiones conscientes

Haz tus decisiones explícitas y conscientes. No saltes para hacer algo sin pensar conscientemente en cómo lo harás.

Aprende y aplica

Continúe aprendiendo nuevas técnicas y considere dónde se pueden aplicar. Cuando se encuentre con una situación en la que se pueda aplicar, haga un análisis de costo-beneficio. A veces, el beneficio de probar algo nuevo supera el beneficio de una solución conocida.