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

Con mucha frecuencia, estoy atrapado al elegir la mejor decisión de diseño. Incluso para pequeños detalles, como definiciones de funciones, flujo de control y nombres de variables, paso períodos inusualmente largos examinando los beneficios y compensaciones de mis elecciones.

Siento que estoy perdiendo mucha eficiencia al pasar mis horas en detalles insignificantes como estos. Aunque sé en el fondo de mi mente que puedo cambiar estas cosas si mi diseño actual no funciona, tengo problemas para decidir con firmeza una opción.

¿Qué debo hacer para combatir este problema?

Dos reglas simples:

1. Haz lo más simple que pueda funcionar.
2. Refactorizar continuamente.

A medida que comience a hacer cada una de estas cosas, ganará confianza en 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 tratar de anticipar todas las formas posibles en que su código deba cambiar.

Por lo general, cuando me siento así, significa que debo intentar:

1. Levántate, camina y asegúrate de que toda la biología funcione bien.
2. Ve a una pizarra y dibuja hasta que tenga una sensación de confianza.
3. Encuentre un "amigo de reclamo de diseño" con quien pueda hablar sobre el problema.

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

1. Satisfaga que, incluso si es feo, está bien encapsulado en alguna parte, y representa un tipo de crujía puramente local.
2. Agregue marcadores TODO o simplemente comentarios que expliquen por qué el código lo molesta.
3. Pase a la siguiente tarea.

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

Es mejor elegir una solución decente y ejecutarla, que sentarse y dudar sobre cuál sería la mejor solución. La mejor solución es evasiva y peor, subjetiva. Si los requisitos cambian incluso ligeramente, su solución puede resultar peor que una solución que descartó porque no era la mejor en ese momento.

Estoy aprendiendo a evitar la parálisis del análisis también, así que felicitaciones a nosotros =) Esto sucede a menudo porque queremos hacer el "mejor diseño". En realidad, "lo 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, programación 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 un producto comprobable y una abierta para la extensión de cerrado para la modificación (OCP)diseño también. ¿Qué quiero decir con comprobable y OCP? Bueno, en lugar de buscar lo que consideraba mejor, consideré un diseño que me puede decir cuándo las cosas van mal y tratar de hacer 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 no cambia es más seguro para usted o para otra persona.

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

En caso de que esté preocupado por la posibilidad de elegir de manera no perfecta, aquí hay algunas ideas para abordar eso:

• Si hubiera una opción con una ventaja clara sobre las demás, no te preguntarías cuál elegir. Entonces, según ese razonamiento, cada vez que no está decidido acerca de alguna elección en un asunto 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, la intuición no es aleatoria en absoluto, sino una conjetura bastante buena y educada para la solución óptima. A menudo, mejor de lo que uno podría llegar a través de hurgar sin fin.
• Al atender al perfeccionismo, uno podría calificar la rapidez de decisión más alta que la óptima elección al evaluar semi-conscientemente el desempeño de uno. Lo que tiene mucho sentido con elecciones sin importancia, pero no es trivial a tener en cuenta.

¡Buena suerte! :)

Creo que desaparece con un poco de experiencia. La mayor parte 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 necesito, así que para superarlo, simplemente hago lo más simple posible que funcione y luego sigo adelante. Una vez que el proyecto tiene una forma definida, las unidades de código repetitivo 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 una alarma para que suene en unos minutos; atormenta tu mente hasta entonces, pero cuando suene 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 gran arquitectura utilice. Simplemente lo construyes para demostrar que funciona.

Una vez que lo haya creado y lo haya descartado, estaría dispuesto a apostar que le resultaría más fácil tomar esas decisiones.

Yo también sufro este problema. Lo que diría es que no tienes suficiente incentivo de finalización.

Por ejemplo, cuando estaba escribiendo código de renderizado, tenía un gran incentivo de finalización porque sabía que si seguía adelante, 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 refactorizando (intento 4, si quieres saberlo) entonces estoy sufriendo porque es mucho trabajo e incluso si termino, solo veré el mismo viejo quad. Y realmente no quiero tener que refactorizar de nuevo y estoy harto de ver el mismo viejo quad una y otra vez, y ya no es una recompensa para mí.

Debe dividirlo en componentes y recompensarse por terminarlos, incluso si es solo con alguna consola de E / S que muestra que está funcionando.

Estaba leyendo su pregunta y pensando en la línea de los otros carteles: no es apto para este trabajo; date un límite de tiempo; Haz algo más por un momento. Después de reflexionar, no estoy seguro de que alguna de las respuestas sea realmente tan ú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, también lo eres sin experiencia para considerar que su primera opción fue la correcta todo el tiempo, o estresarse demasiado por hacerlo bien. ¿Por qué más te preocuparías por tales trivialidades?

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

Entonces 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 anterior que usé la última vez que necesitaba una de estas cosas. Lo mismo vale para todo, ¿quiero una cola? Claro, vamos a cortar y pegar mi código de cola 'estándar' (filmado desde el último proyecto en el que trabajé, o cualquiera que pueda recordar usando una de estas cosas). Resultado final ... Solo me preocupan las 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 enviarme correos electrónicos a mí mismo y ponerlos en una carpeta, pero lo que sea que trabaje es lo mejor, y luego comenzará a saber qué hacer cada vez. Siempre irá al código anterior que ha escrito y eliminará el problema, listo para el siguiente problema. Encontrarás que te conviertes en un desarrollador mucho más rápido (en serio, esta es la única forma de ganar productividad para el programador) y con suerte encontrarás tiempo para los momentos divertidos, no las cosas tristes del día a día que ya has resuelto muchas veces terminado.

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 ( inicio simple, refactorización ) y ammoQ ( timeboxing ):

1. Date un límite de tiempo bastante estricto para una primera solución que simplemente funcione. Por ejemplo, 30 segundos para un nombre de variable. Primero puede encontrar algo como x, luego refinarlo y stringluego namehasta que se acabe el tiempo.
2. Luego proceda a otras tareas durante un tiempo específico, por ejemplo, 10 minutos.
3. Solo entonces permítase otro intervalo de tiempo para mejorar aún más su decisión, por ejemplo, parauserHandle

Posibles beneficios de este enfoque:

• el conocimiento de volver a esto más tarde puede facilitar el abandono del problema por ahora
• Mientras continúa con otras tareas, puede encontrar una buena solución satisfactoria sin necesidad de mucho tiempo.
• Después de haber dejado ir el paso 1 y 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, simplemente elegir una solución decente y aceptarla.

Cuando he realizado la investigación y no tengo una mejor opción clara, me doy un límite de tiempo (generalmente 5 minutos) para elegir una, luego simplemente avanzo con ella. Incluso cuando te topas con obstáculos, en este punto, no hay garantía, no habrías topado con un obstáculo igual al tomar una decisión diferente. No puedo pensar en un momento en que me haya arrepentido de 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 tener opciones razonables a considerar. No decidas cuál todavía. Al final del tiempo, elija una (al azar si no hay una 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 elegida ya es. Comience a codificar y refactorice si claramente se equivocó. Si el jefe pregunta por qué, diga "He lanzado una moneda, ¿tiene una mejor manera?"

En el caso b), necesita más información, y sentarse con su gran grasa A ... todo el día no la 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. Hagas lo que hagas, no duermas demasiado tiempo.

A menudo, la mejor solución es tratar de explicar su decisión a un colega. Sin embargo, dado que no desea hacer esto con mucha frecuencia, lo mejor es pensar en papel, ya sea con un papel / bolígrafo o una ventana vacía de 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 papel" y luego continuar con una corriente de conciencia. Después de unos segundos, estarás al ritmo de la escritura, así que presiona Intro varias veces y comienza a explicar tu dilema.

Indique el problema, luego indique las posibles soluciones, qué tiene de bueno cada una, etc.

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

Sufro del mismo problema. Para pequeños problemas, la forma en que trato de resolverlo 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 se te ocurra sin escribirlo. A medida que codifique, encontrará que puede hacer pequeñas mejoras. Bien hecho, encuentro que es bastante fácil converger en una solución razonablemente buena de esta manera.

Para los problemas más grandes, creo que es conveniente pensar primero en sus opciones, pero con timebox. Los grandes problemas tienen grandes espacios de solución, no puede evaluar todas las posibilidades, ni debe intentarlo.

TLDR; Elija una solución razonable, mejórela sobre la marcha.

Esto también es relevante:

El maestro de cerámica anunció el día de la inauguración que estaba dividiendo la clase en dos grupos. Dijo que todos los que estaban en el lado izquierdo del estudio serían calificados únicamente por la cantidad de trabajo que producían, todos los que estaban a la derecha únicamente por su calidad. Su procedimiento fue simple: en el último día de clase traería las básculas de baño y sopesaría el trabajo del grupo de "cantidad": cincuenta libras de macetas calificadas con una "A", cuarenta libras con una "B", y así sucesivamente. Sin embargo, aquellos que fueron calificados en "calidad", necesitaban producir una sola maceta, aunque perfecta, para obtener una "A".

Bueno, llegó el momento de calificar y surgió un hecho curioso: los trabajos de la más alta calidad fueron producidos por el grupo que se calificaba por cantidad. Parece que si bien el grupo de "cantidad" estaba ocupado produciendo montones de trabajo, y aprendiendo de sus errores, el grupo de "calidad" se había sentado teorizando sobre la perfección, y al final tenía poco más que mostrar por sus esfuerzos que grandiosas teorías y Un montón de arcilla muerta.

de http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

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 sentara como un conejo paralizado por los faros. Yo simpatizaría preguntando 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ías.