Cómo lidiar con la frustración cuando las cosas no funcionan [cerrado]

Aunque este es un problema real, no es específico de la programación. Sin embargo, es IMHO tan importante que merece un lugar en este foro.

Mis sugerencias: ten un descanso . Salga a caminar, medite, duerma, haga actividad física *: haga algo completamente diferente para permitir que su cerebro se relaje y salir de la rutina mental , mientras deja que su subconsciente trabaje en el problema en paz. Por lo general, brinda resultados sorprendentemente rápidos, solo necesita informarle al respecto. Pero mientras tu mente consciente repite desesperadamente los mismos ciclos de pensamientos una y otra vez, no podrá escuchar nada más.

  

¿Qué puedes hacer para evitar llegar a este punto?

Las técnicas de relajación y atención plena son clave para superar las reacciones de estrés y permitir que su mente se enfoque con claridad. Y practicar esto realmente vale la pena. Cuando alguien tiene experiencia en esto, (s) ya puede notar que el nivel de estrés aumenta antes de que la frustración pueda hacerse cargo . Entonces uno puede interrumpir el ciclo de pensamientos por ej. respirando profundamente unas cuantas veces o practicando un par de minutos de relajación. Esto puede ser todo lo que se necesita en ese momento.

* bese a su pareja, acaricie a su mascota - sugerencias de mi esposa :-)

  

ahora han pasado 3 horas cuando esto debería haber tomado 10 minutos.

La palabra mágica es debería . Golpea eso desde tu vocabulario.

¿Quién dijo que debería tomar 10 minutos? ¿Quién específicamente? ¿Cuál fue la base fáctica de su reclamación?

Si lo has hecho 3 veces antes, y cada vez que estuviste cerca de 10 minutos, tienes una base racional para un debería .

Si nunca lo has hecho antes, decir que debería solo se está configurando para fallar. Debes dejar de usar should hoy.

Encuentra a alguien para usar como caja de resonancia

Incluso si nadie tiene experiencia en exactamente en qué estás trabajando, es una buena idea hablar de estas cosas con frecuencia. El mero hecho de usar a alguien como caja de resonancia puede hacer que tu mente comience a girar. Te encontrarás pensando en cosas nuevas para probar. También aliviará su estrés para desahogarse un poco y potencialmente hacer un nuevo amigo. También es saludable en general que el equipo se sienta cómodo compartiendo y compadeciéndose entre sí para generar un ambiente orientado hacia el equipo para resolver este tipo de problemas.

Tengo algunos pasos cuando llego a este punto. Normalmente puedo encontrar una solución si me tomo el tiempo para dar un paso atrás y reflexionar.

Paso 1: Aléjate del problema y despeja tu cabeza. Vuelve cuando no te sientas frustrado y puedas verlo con una mente fresca.

Paso 2: vuelva al código y vea si faltó algo. Haga que alguien venga y sea un segundo par de ojos si no puede hacer cara o cola.

Paso 3: Eliminar el código de la ecuación. ¿Cuál es el problema que estás tratando de resolver? Escríbelo en una hoja de papel o pizarra. Hable del problema con alguien para conocer sus opiniones sobre el problema y la solución.

Paso 4: Comuníquese con la comunidad para ver si tienen una solución o si alguien más ha golpeado el mismo muro.

Básicamente, estos se pueden resumir como 'Detener la piratería y alejarse del código'.

Aléjate un rato y haz otra cosa. Duerma bien y vuelva al problema por la mañana.

Además, no te castigues. Su estimación de diez minutos es claramente incorrecta, y eso sucede todo el tiempo.

Haría una pregunta aquí y que la comunidad lo ayude a resolverlo. Menos estresante de esa manera.

¡Tengo un tipo de solución diferente - DORMIR !

Cuando estás frustrado con un problema, no puedes salir de él fácilmente. Por lo tanto, es mejor si te cansas tanto de resolver el problema y luego te duermes.

Cuando te despiertes, tendrás una sensación fresca y, de nuevo, podrás pensar claramente con el problema. Lo hago a veces.

Encontrar algo que ayude a reconstruir algo de confianza es lo que tiendo a hacer cuando llego a este punto. Esto podría ser resolver un rompecabezas de Sudoku o Kenken, hacer alguna tarea administrativa simple y sin sentido, como completar mi hoja de horarios o salir a caminar. La clave aquí es para mí tener una sensación de logro en lo que sea esta pequeña distracción lateral, es ayudarme a animarme lo suficiente como para volver a montar al caballo y adentrarme en el salvaje azul, para mezclar algunas metáforas allí.

En cuanto a evitar ser tan malo, es probable que sugiera una estrategia de boxeo de tiempo para que, si crees que tomará 10 minutos, y de repente una hora más tarde no haya mucho progreso, detente y descansa un poco en lugar de tratar de seguir golpeando mi cabeza contra la pared.

Tengo un nombre especial para este tipo de situación: batalla de programación épica .

Si no he tenido al menos una batalla de programación épica con un lenguaje o herramienta de programación específico, y resolví el problema, no puedo decirme a mí mismo que puedo usar dicho lenguaje de programación o herramienta.

Así que ahí está mi solución: mentalízala como una pelea y una prueba de coraje y resistencia . Si no puedo resolver el problema, entonces " vivo para luchar otro día ".

Puede sonar un poco ridículo, pero será más divertido y gratificante pensar en ello en estos términos (como si fuera una especie de juego que debes ganar) en lugar de sufrir todo el tiempo porque tienes que enfrentarte a la hecho que no sabes todo .

Bueno ... creo que necesitas una nueva carrera o un conjunto de expectativas completamente nuevo. Si bien ciertamente no es frecuente, tomar 3, 4, 8, 10 o 40 horas para hacer lo que originalmente pensó que sería un trabajo de 10 minutos no es raro en el negocio del software. Estoy seguro de que la mayoría de los desarrolladores que trabajan en algo de complejidad moderada han hecho que las tareas de 2 días se conviertan en tareas de 1 mes una vez que lo hayan profundizado y comprendido el problema.

Parte de ser un buen desarrollador implica ser paciente, de lo contrario, la computadora va a ganar y terminarás incorporando algún tipo de truco de solución rápida que apenas parece funcionar pero que inevitablemente romperá algo en lo que no pensaste. Si los retrasos menores le causan mucho estrés, entonces probablemente no debería estar en esta línea de trabajo.

Dos sugerencias:

1. La persona más inteligente que conozco, que tiene dos doctorados y tiene el título de trabajo "Research Fellow", en una pequeña empresa privada, dice esto

   Si lo has pensado durante 15 minutos y no tienes la respuesta, lo estás haciendo mal.

   Deja de pensar en ello.

   Toma una siesta. (ir a caminar o algo así)

   La respuesta estará allí cuando despiertes.

2. Obtenga el libro de David J Agan "Debugging" . Probablemente le enseñará más sobre la depuración, de modo que cuando las cosas no funcionen, puede hacerlo rápidamente.

Siempre que me enfrento a algo que no funciona, siempre recuerdo esta cita:

  

Cuando estés en el infierno, sigue caminando, ya que es lo mejor que se puede hacer en ese momento.

     

Tómate un descanso, intenta refrescarte y enfócate en un problema con un nuevo nivel de energía.

haciendo eco de las recomendaciones de otros:

• esta situación es casi siempre algo trivial que simplemente no ves ; tomar un descanso
• otro par de ojos o simplemente explicarle el problema a su gato puede ayudar

y añadiendo:

• reexamine sus suposiciones, especialmente las no declaradas; es probable que haya estado ladrando al árbol equivocado
• revertir la situación: asuma que el comportamiento actual es el resultado deseado, entonces, ¿qué tendría que hacer con el código para que eso suceda?
• escriba algo de código de prueba (afirmaciones o registros, o puntos de interrupción condicionales; sea sencillo) para verificar sus suposiciones a lo largo de la ruta de ejecución

A veces, es mejor no solo intentar solucionar un problema. Tómese un tiempo y escriba en pseudo código lo que debe hacer. Sé que hay presión para hacer las cosas lo más rápido posible, pero por lo que he visto, ese estilo de codificación conduce al tipo de situación que describe. Si alguien escribe un código que solo funcionará dado un pequeño conjunto de condiciones y que establece cambios, el código se romperá o hará cosas inesperadas.

También (odio admitir que mis profesores tenían razón en esto ...), la documentación y las pruebas de unidad ayudan. Esto haría que sea más fácil saber lo que se publicará una sección de código dado el conjunto de entradas. Entonces, sería más fácil ver qué efecto causará un cambio en la entrada de esas secciones.

La fatiga o la falta de sueño nunca es un problema para mí. Estoy más frustrado por la falta de organización dentro de la industria en general y por los bajos estándares que nos hemos fijado. Aquí hay cinco cosas que me frustran:

1. API que tienen un diseño complicado. Es como aprender un nuevo lenguaje de programación. De hecho, algunas API son mucho más difíciles de aprender que aprender nuevos lenguajes de programación. Admiro su inteligencia, pero podría haberme ahorrado tiempo al poner en la documentación que necesitaba un doctorado en ingeniería de software o ciencias de la computación para entenderlo.

2. Falta de buena documentación. Nunca puedo olvidar el hecho de que tantos diseñadores de API dedican mucho tiempo a crear una API solo para lanzarla con documentación mínima. Gracias, pero ¿cómo uso esto? ¿Qué hacer en esta situación? etc.

3. Implementaciones propietarias. Alguna implementación patentada está bien, pero si existen normas, por el bien de la humanidad, siga esas normas. Nada más frustrante que pasar tiempo preguntándose por qué algo no funciona solo para descubrir que la implementación no cumple con los estándares normales.

4. Entornos de caja de arena / Restricciones. Ok, tal vez esto ayude a mantener fuera a la gente mala, pero en mi opinión, las restricciones sobre lo que puede hacer un programador solo limitan la creatividad y el progreso tecnológico. Muchas de las grandes ideas que he tenido han sido destrozadas después de descubrir que no tengo permitido hacer algo. La industria de la programación está realmente hecha para producir aplicaciones cotidianas, no un software innovador e innovador. Entonces, si decides ser un programador, realmente eliges ser un gruñido moderno, a menos que quieras convertirte en un académico solitario.

5. Discusiones modernas. La gente hoy en día aún debate sobre la fealdad del paréntesis de Lisp, el mérito de la limpieza de los Pythons, o cómo algunos idiomas como Cobol o Fortran se están extinguiendo, etc. ¿Realmente la gente? ¿De esto es de lo que debatimos? Hablemos de paralelismo, o mejores formas de diseñar sistemas más seguros, o cómo la programación lógica puede mejorar nuestras vidas. Dejemos de pensar como programadores y empecemos a pensar como diseñadores del mundo del mañana.

Por lo tanto, personalmente ya no programo mucho debido a estas frustraciones. Hasta que la industria decida que quiere hacer más que simplemente crear el próximo Facebook, o reinventar el procesador de textos, estoy listo. Se lo dejo a ustedes, chicos. Sinceramente, sin ofender, es buen dinero.