¿Cómo trato con la parálisis de análisis?

Dos reglas simples:

1. Haz lo más simple que podría funcionar.
2. Refactorizar continuamente.

A medida que comience a hacer cada una de estas cosas, ganará confianza de que puede tomar decisiones simples ahora sin comprometer su capacidad de responder al cambio más adelante.

Recuerde que las pruebas futuras significan hacer que el código sea fácil de cambiar, no intentar anticipar todas las formas posibles en que su código deba cambiar.

Por lo general, cuando me siento de esa manera significa que debo intentarlo:

1. Levántese, camine y asegúrese de que toda la biología esté funcionando bien.
2. Ir a una pizarra y dibujar hasta que tenga una sensación de confianza.
3. Busque un "amigo de quejas de diseño" con quien pueda hablar del problema.

Si el problema involucra la sintaxis y las piezas pequeñas, entonces:

1. Satisfaga que, aunque sea feo, esté bien encapsulado en algún lugar y represente un tipo de crucero puramente local.
2. Agregue marcadores de TODO o solo comentarios que expliquen por qué el código lo molesta.
3. Pasa a la siguiente tarea.

Es muy fácil pensar en la inacción. Incluso si logras, de alguna manera, encontrar la mejor solución en este momento que pueda cambiar fácilmente antes de completar el proyecto, ¿y luego qué?

Es mejor elegir una solución decente y correr con ella, que sentarse y deambular sobre cuál sería la solución mejor . La mejor solución es esquiva y peor, subjetiva. Si los requisitos cambian levemente, su solución puede resultar peor que una solución que descartó porque no era la mejor en ese momento.

También estoy aprendiendo a evitar la parálisis del análisis, así que felicitaciones a nosotros =) Esto sucede a menudo porque queremos hacer el "mejor diseño". En realidad, "mejor" está en el ojo del espectador . Mi fórmula para evitar la parálisis del análisis es aplicar el principio de diseño suficientemente bueno . ¿Cómo hago eso? Traigo variables como restricciones de tiempo, programo y me pregunto cuál es el diseño más simple que puede hacer el trabajo (esto no significa lo más fácil) sin comprometer la calidad, pero al mismo tiempo, me aseguro de que sea verificable y un diseño abierto para extensión cerrada para modificación (OCP) también. ¿Qué quiero decir con verificable y OCP? Bueno, en lugar de buscar lo que consideré mejor, consideré un diseño que me puede decir cuándo las cosas van mal y trato de hacer solo el código suficiente que me permita refactorizar y mejorar más adelante. Además, intente separar el código que cambiará con el código que permanece igual. La refactorización se vuelve más fácil, porque el código que se supone que debe cambiar es más seguro para usted o alguien más en el futuro.

¿Qué tal si dejas que tu instinto de inteligencia decida por una de las opciones? Eso debería ir bastante rápido y combinarse bien con timeboxing , que también munQ propuesto . Puede intentar un límite de 1 minuto si las opciones ya están establecidas, o 2 minutos si tiene que definirlas primero. O lo que parezca apropiado (definido de antemano). Cuando aprendas a escuchar tu instinto, tu elección intuitiva se volverá más rápida y mejor con la práctica .

En caso de que te preocupen las preocupaciones sobre la posibilidad de elegir de forma no perfecta, he aquí algunos pensamientos para solucionarlo:

• Si hubiera una opción con una clara ventaja sobre las otras, no se preguntaría cuál elegir. Por lo tanto, según ese razonamiento, cuando no está decidido a tomar una decisión sobre un tema no demasiado complicado, eso indica que las opciones son, en general, bastante iguales; así que no hay mucho que perder simplemente optando por cualquiera de ellos.
• Dicho esto, intuición no es aleatoria en absoluto, sino una suposición bastante buena y educada para la solución óptima. A menudo, es mejor que lo que uno podría encontrar a través de una búsqueda sin fin.
• Abordando el perfeccionismo, uno podría valorar la rapidez de la decisión más alta que la óptima elección cuando se evalúa de manera semi-consciente el desempeño de la persona. Lo que tiene sentido completo con elecciones sin importancia, pero no es trivial a tener en cuenta.

¡Buena suerte! :)

Creo que se va con un poco de experiencia. La mayoría de mi parálisis ocurre porque trato de imaginar cómo se verá la base del código mucho más adelante de lo que lo necesito, así que para superarlo, simplemente hago lo más simple posible que funcionará y luego seguiré adelante. Una vez que el proyecto tiene alguna forma definida, las unidades de código repetitivas comienzan a destacarse y es bastante fácil abstraer los patrones repetitivos y simplificar el código.

Para superar su renuencia a decidir, aplique timeboxing : configure un reloj de alarma para despegar en pocos minutos; atormenta tu mente hasta entonces, pero cuando suena la alarma, elige la mejor opción que hayas encontrado hasta entonces.

Crea un prototipo. Recuerde, un prototipo está hecho para ser desechado, por lo que no importa qué funciones, nombre de variable o incluso la gran arquitectura que use. Solo lo construyes para demostrar que funciona.

Una vez que lo hayas creado y desechado, estaría dispuesto a apostar que te será más fácil tomar esas decisiones.

Yo también sufro este problema. Lo que diría es que no tienes suficiente incentivo para completar.

Por ejemplo, cuando estaba escribiendo el código de representación, tenía un gran incentivo para completar porque sabía que si lo hacía, vería el sistema en acción y pensaría en lo increíble que era para texturizar Un quad, o transformando un vert. Pero ahora que estoy re-factorizando (intento 4, si quieres saber), entonces estoy sufriendo porque es mucho trabajo e incluso si termino, voy a ver el mismo quad viejo. Y realmente no quiero tener que refactorizar de nuevo y estoy cansado de ver el mismo quad viejo una y otra vez, y ya no es una recompensa para mí.

Necesitas dividirlo en componentes y recompensarte a ti mismo por terminarlos, incluso si solo con una consola de entrada / salida muestra que está funcionando.

Estaba leyendo su pregunta y pensando las cosas en la línea de los otros carteles: no está preparado para este trabajo; date un límite de tiempo; hacer algo mas por un momento Después de una reflexión, no estoy seguro de que alguna de las respuestas sea realmente útil

El problema con problemas mentales como este es que no son fáciles de resolver, son parte de ti y, obviamente, te preocupas (quizás demasiado) por tu trabajo, no tienes la confianza para estar de acuerdo contigo mismo , son demasiado inexpertos para considerar que su primera elección fue correcta todo el tiempo, o se preocupan demasiado por hacerlo perfectamente bien. ¡¿Por qué otra cosa te preocuparías por tales trivialidades ?!

Ahora tengo problemas similares, pero no con el código tanto ... por lo general es lo que hay para cenar ... pizza o curry ... hmm ... pizza pero luego el curry es bueno, pero ¿me siento como un curry? La pizza es más barata, pero luego tienes más curry, pero ... y así sucesivamente. :)

Así que pensé: ¿por qué no tengo problemas similares con la codificación y creo que es simplemente porque tengo un conjunto de patrones que uso regularmente? Si necesito una definición de función, es fácil ... estará en la misma línea que cualquier otra definición de función que haya codificado. Si necesito un flujo de control, primero decido si necesito un bucle for o un bucle while y luego creo el mismo código antiguo que usé la última vez que necesité una de estas cosas. Lo mismo ocurre con todo, ¿quiero una cola? Claro, vamos a cortar y pegar mi código de cola 'estándar' (archivado desde el último proyecto en el que trabajé, o cualquiera que recuerdo haber usado una de estas cosas). Resultado final ... solo me preocupo por cosas nuevas, y para ser honesto, es un placer.

Por lo tanto, mi consejo es comenzar a construir una biblioteca de fragmentos de código: solía enviarlos por correo electrónico a mí mismo y ponerlos en una carpeta, pero lo que sea con lo que trabajes es mejor, y luego comenzarás a saber qué hacer cada vez. . Siempre irá al código anterior que ha escrito y eliminará el problema, listo para el siguiente problema. Descubrirá que se convertirá en un desarrollador mucho más rápido (en serio, esta es la única forma de aumentar la productividad del programador) y, con suerte, encontrará tiempo para los momentos divertidos, no para las cosas cotidianas que ya ha resuelto muchas veces. encima.

Por supuesto, la última parte de todo eso también es importante: cuanto más trabajo tenga, menos lujo tendrá para pasar el tiempo pensando.

Aquí hay una estrategia que combina las sugerencias de Rein Henrichs ( start simple, refactor ) and ammoQ ( caja de tiempo ):

1. Dese un límite de tiempo bastante estricto para una primera solución que simplemente funcione. P.ej. 30 segundos para un nombre de variable. Primero podrías encontrar algo como x , luego refinarlo a string , luego name hasta que se acabe el tiempo.
2. Luego continúe con otras tareas durante un tiempo específico, por ejemplo. 10 minutos.
3. Solo entonces, permítete otra casilla de tiempo para mejorar aún más tu decisión, por ejemplo. codificar%

Posibles beneficios de este enfoque:

• el conocimiento de volver a esto más adelante puede facilitar el abandono del problema por ahora
• mientras continúas con otras tareas, puedes encontrar una buena solución satisfactoria sin tener que investigar mucho tiempo
• después de haber dejado ir después del paso 1 y de estar en el flujo del paso 2 , puede ser fácil mantener el paso 3 realmente rápido, ya que desea continuar con el paso 2, y, por lo tanto, felizmente, elija una solución decente y acéptelo

Cuando he realizado la investigación y no tengo una opción clara, Me doy un límite de tiempo (generalmente 5 minutos) para elegir uno, y luego seguir adelante. Incluso cuando te topas con obstáculos, en este punto, no hay garantía de que no hubieras golpeado un obstáculo igual al tomar una decisión diferente. No puedo pensar en un momento en que lamenté mi decisión.

Por lo general, la razón por la que no puede decidir es que la diferencia es insignificante, o no tiene suficiente información.

En el caso a) Establezca un límite de tiempo para encontrar opciones razonables a considerar. No decidas cuál todavía. Al final del tiempo, elija una (al azar si no hay preferencia clara) de las opciones identificadas, y otro límite de tiempo. Si no se toma una decisión clara al final del tiempo, la ya elegida es. Comience a codificar, y refactorice si claramente lo ha entendido mal. Si el jefe pregunta por qué, diga "lancé una moneda, ¿tienes una mejor manera?"

En el caso b): necesita más información, y sentarse en su gran grasa A ... todo el día no la va a proporcionar. Salga del modo de diseño y entre en el modo de recopilación de información. Prototipos, hacer preguntas, leer revistas técnicas. Lo que sea que hagas, no te duermas demasiado tiempo.

A menudo, la mejor solución es intentar explicar su decisión a un colega. Sin embargo, dado que no desea hacer esto muy a menudo, lo mejor que puede hacer es pensar en papel, ya sea con un papel o un bolígrafo, o con una ventana vacía en el bloc de notas.

Comience escribiendo absolutamente cualquier cosa, solo para entrar en el ritmo de la escritura. En una ventana del bloc de notas puede escribir "Estoy pensando en el papel" y luego continuar con una corriente de conciencia. Después de unos segundos estará en el ritmo de la escritura, así que presione Entrar varias veces y comience a explicar su dilema.

Indique el problema, luego indique las posibles soluciones, lo bueno de cada una, etc.

Aunque no siempre funciona, el proceso de sacar pensamientos de su cabeza (RAM) y colocarlos en medios externos (el documento de la libreta de notas) le da más libertad para hacer nuevas conexiones y ver la decisión desde diferentes perspectivas.

Sufro del mismo problema. Para problemas pequeños, la forma en que trato de lidiar con eso es ir con el primer diseño que pienso que no es estúpido. No tiene sentido tratar de encontrar un diseño óptimo; es difícil, si no imposible, razonar sobre todos los matices de cualquier diseño que puedas imaginar sin tener que escribirlo. A medida que codifique, descubrirá que puede realizar pequeñas mejoras. Bien hecho, creo que es bastante fácil converger en una solución razonablemente buena de esta manera.

Para problemas más grandes, creo que hay un mérito en pensar primero en tus opciones, pero en la caja de tiempo. Los grandes problemas tienen grandes espacios de solución, no puedes evaluar todas las posibilidades, ni deberías intentarlo.

TLDR; Elija una solución razonable y mejore a medida que avanza.

Esto también es relevante:

  

El profesor de cerámica anunció el día de la inauguración que estaba dividiendo el   clase en dos grupos. Todos los del lado izquierdo del estudio, él.   dicho, se calificaría únicamente en la cantidad de trabajo que produjeron,   Todos los de la derecha únicamente por su calidad. Su procedimiento fue   simple: el último día de clase traería su baño   escala y pesa el trabajo del grupo de "cantidad": cincuenta libras de macetas   calificado como "A", cuarenta libras a "B", y así sucesivamente. Aquellos que son calificados en   Sin embargo, la "calidad" era necesaria para producir una sola maceta, aunque sea perfecta.   uno - para obtener una "A".

     

Bueno, llegó el tiempo de calificación y surgió un dato curioso: las obras de   La mejor calidad fue producida por el grupo que fue calificado para   cantidad. Parece que mientras el grupo de "cantidad" estaba agitándose   a montones de trabajo - y aprendiendo de sus errores - la "calidad"   El grupo se había sentado teorizando sobre la perfección, y al final tuvo poco   más para mostrar por sus esfuerzos que las teorías grandiosas y una pila de   arcilla muerta.

de enlace .

Nunca he entendido esto. Cuando era instructor, decía algo como:

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

No es demasiado complicado, podría pensar, y el 95% de las personas escribieron algo como:

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

Pero ocasionalmente habría alguien que se sienta como un conejo paralizado en los faros. Me gustaría preguntar con simpatía cuál era el problema y me decían "¡No sé cómo llamarlo!".

Estas son las personas que deberían buscar otra carrera. Como tal vez debería usted.