Combatiendo el efecto Einstellung [cerrado]

17

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?

learning David en Dakota
fuente
¿Trabajas en solitario?
Apalala
3
tenga cuidado con el carro "MVC", tiene su lugar. Si una solución de Webforms funciona, que así sea.
Darknight

Respuestas:

4

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.
Nicole
fuente
Me encanta esta respuesta, gracias por dedicar tiempo.
David en Dakota el
9

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.

Ethel Evans
fuente
2
Si tienes tiempo para ello, aumenta el 20%. Ni siquiera tengo esa experiencia, pero ya me di cuenta de esto: hacerlo bien siempre vale la pena al final. Además, cuanto más conocimiento tenga sobre cómo hacerlo bien, más rápido lo hará bien y eventualmente (bueno, eso es lo que espero; P) los dos se fusionarán y podrá hacer casi todo bien Y rápido.
stijn
Por cierto, lo que me pasa la mayoría de las veces: comenzar algo, sabiendo que no está del todo bien, luego 2 días después perder una cantidad de tiempo increíble porque lo que sabía que estaba mal en primer lugar ahora necesita una refactorización para hacerlo bien, después todos.
stijn
1
O 50% cuando el trabajo es bajo, o incluso más entre proyectos. Nada de lo que he estudiado ha sido desperdiciado. Todo se ha utilizado más temprano que tarde, aunque solo sea para tener una opinión informada cuando sea importante.
Apalala
5

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.

apoorv020
fuente
Mantenerse ocupado con el trabajo con frecuencia significa mantenerse tan productivo como el tipo que aprendió la próxima "mejor" tecnología. Estoy a punto de contar tres décadas en el comercio, y la mayoría de lo que recuerdo de todo es estudiar, estudiar y más estudiar.
Apalala
+1 para la programación (al menos la programación profesional) se trata de escribir código que haga el trabajo en lugar del código teóricamente perfecto que es una obra de arte.
Jwent
3

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.

P.Brian.Mackey
fuente
2

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.

Apalala
fuente
1

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).

bethlakshmi
fuente
1

¿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.

aaaaaaaaaaaa
fuente
1
No estoy seguro de lo que quieres decir; Me refería al uso de selectores jQuery como un mejor enfoque. Usar el DOM directo funciona bien, pero jQuery es un enfoque mucho mejor. Para ser claros, ambos funcionan, uno es simplemente mejor que el otro.
David en Dakota el
1
Bueno, $("#id")es más corto, pero en última instancia, solo es un alias document.getElementById("id")con algo de sobrecarga. ¿Sabes que mejorará tu flujo de trabajo? ¿O te acaban de decir que jQuery es mejor tantas veces que lo crees?
aaaaaaaaaaaa
1
@eBusiness - ¿Sabes que en $("#id")última instancia es solo un alias document.getElementById("id")? ¿O te lo han dicho tantas veces que lo crees? Espero que cada vez que lo use getElementByIdrecuerde manejar el caso en el que IE y Opera devuelven elementos por su nombre, así como el caso en que Blackberry 4.6 devuelve nodos que ya no están en el documento.
Nick Knowlson
Si está utilizando el mismo identificador para el nombre y la identificación de diferentes objetos o su código no puede 'recordar' qué objetos ha eliminado, entonces usar jQuery es práctico. De lo contrario, no es más que hinchazón lo que reduce la velocidad de su código. No digo que lo que hace jQuery esté mal, pero no es mejor para cada propósito.
aaaaaaaaaaaa
1
Sé que provoqué esto, pero creo que nos estamos moviendo demasiado lejos en una guerra de llamas jQuery versus JavaScript.
aaaaaaaaaaaa
1

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.

dietbuddha
fuente