¿Tiene algún ritual de calentamiento mental que haga antes de abordar una tarea difícil de desarrollo de software?

He presentado aquí un proceso general y la idea de un árbol como metáfora del código que desea escribir o ‘crecer’.

  1. Equilibrate a ti mismo. Desarrolla una sensación de paz. Cuando tiene equilibrio, es más fácil mantener una perspectiva amplia, y también es más fácil permanecer en un estado de flujo para una mayor concentración y productividad.
  2. Entender. Resuma los requisitos clave, idealmente como una historia de pasos conectados.
  3. Métete en el código. Renueve su contacto con cualquier código existente. Ejecute sus pruebas y tal vez desarrolle una nueva prueba pequeña o dos.
  4. TDD para el tronco de la solución. Escriba un caso de prueba que defina alguna parte de nivel medio-alto de un requisito que desea implementar. El caso de prueba lo ayudará a aclarar y consolidar su comprensión de los requisitos detallados. Implemente trozos y simulacros (por ejemplo, fuentes de datos o los resultados de algoritmos complejos) para que pueda trabajar rápidamente y no distraerse con detalles de bajo nivel de otros aspectos.
  5. Refactorizador Desarrolle y use sus habilidades de refactorización, de modo que a medida que comprenda mejor el problema, pueda remodelar y estructurar el código para que se ajuste a su modelo mental.
  6. Ponga hojas y flores en el árbol de solución. Desarrolle los detalles y reemplace gradualmente los simulacros con implementaciones reales. Ponga en los comentarios de “todo” para que pueda mantener las cosas lo más simple posible por ahora, y para que pueda poner detalles menores fuera de su mente activa y en el código para encontrarlos más tarde.
  7. Poda el árbol. Cuando el código esté tan completo como lo necesita por ahora, elimine cualquier simulación temporal restante y comentarios innecesarios.
  8. Barrer las hojas. Revise el código y escriba algunas tareas / problemas adicionales para parte del trabajo restante, incluida la eliminación de cualquier ‘deuda técnica’ (por ejemplo, casos extremos o enfoques ineficientes o no escalables que haya utilizado en la primera implementación de trabajo)

Este proceso y metáfora pueden resultar útiles para ayudarlo a entrar en flujo y permanecer allí durante todo el proceso de programación.

A2A

Esto no es exactamente un ritual, sino un hábito arquitectónico. Miro el diseño del sistema y me hago algunas preguntas críticas:

  • ¿Puedo invertir alguno de los elementos aquí? Por ejemplo, ¿puedo convertir una colección en una observable? ¿Puedo convertir una llamada API para que los sistemas se llamen entre sí en la dirección opuesta? (Por ejemplo, aplicar capas en lugar de patrones de integración)
  • ¿Puedo cambiar la arquitectura de tal manera que cualquiera de los componentes pueda eliminarse? Esta aplicación de la Navaja de Occam es increíblemente valiosa.
  • ¿Realmente, realmente entiendo los requisitos?
  • ¿He ido y hablado con al menos una o dos personas para conocer su enfoque?
  • ¿Las personas adecuadas han firmado esto?
  • ¿Estamos realmente resolviendo el problema correcto para el negocio aquí?
  • ¿Cuál es la versión mínima viable de esto que no apesta?

HTH. Aclamaciones.

Lo más importante es no tener una visión de túnel o concentrarse tanto en una forma de encontrar una solución que pierda algo o cierre su mente a otras ideas. También trato de mantener todo mi código en foco y trato de no quedar demasiado enterrado en ningún ámbito en particular. Después de algunas horas de desconexión, encuentro que alejarse y regresar con una mente fresca una hora más tarde realmente ayuda.

Además, el aporte de otros colegas es muy valioso, pero tampoco se apegue a los consejos de una persona para que no se quede atrapado en una sola forma de encontrar una solución. En la codificación hay muchas formas de obtener lo que desea … y algunas formas son definitivamente más difíciles (y mucho menos eficientes) que otras. Si no sabe qué es la programación DRY, búsquela. Ayuda un poco con la perspectiva.

Ah, y café. Mucho café

Sé que los rituales son solo tácticas dilatorias. Paso solo un par de minutos para asegurarme de que estoy cómoda. Voy al baño, tomo un refrigerio si tengo hambre o una bebida si tengo sed, verifico que mi silla esté en la posición correcta, todo para no distraerme una vez que me vaya. Es posible que revise mi correo electrónico antes de comenzar, pero eso no es productivo, por lo que solo lo hago si la necesidad realmente me está molestando. No voy a internet para leer nada que no esté directamente relacionado con lo que estoy trabajando. He estado en esa madriguera de conejos muchas veces, así que sé que es una distracción deliberada.

Abro un nuevo documento en mi IDE, y lo primero que hago es escribir comentarios. ¿Qué sé sobre el problema? Qué condiciones existen antes de llamar al objeto, qué invariantes deben mantenerse, qué estructura de datos usar. Si no puedo escribir estos comentarios rápidamente, indica cosas que no sé, así que las resuelvo. Es un sustituto de tener una larga conversación con un colega. Deja un registro, así que si me interrumpen (lo que sucede todo el tiempo en la mayoría de los lugares de trabajo), puedo leer mi estado mental rápidamente en mi cabeza. Esto me ha ahorrado incontables cientos de horas en una carrera, porque nunca tienes un día ininterrumpido, incluso si los únicos descansos son para el almuerzo y el baño.

Una vez que se hacen los comentarios, la codificación generalmente pasa rápidamente. Durante la fase de codificación soy relativamente inmune a la interrupción. Intento tomar un descanso una vez por hora cuando estoy entre cosas, levantarme y caminar, tomar refrigerios, ir al baño, etc., porque si no lo hago, después de un par de horas, me daré cuenta Me duele estar sentado en la misma posición, tengo los ojos secos y picazón por no parpadear, y necesito orinar. Un descanso se convierte en obligatorio en ese momento porque no puedo volver al flujo, y si estoy justo en el medio de algo, pierdo el contexto.

En realidad no … Creo que el mejor “calentamiento” si quieres es un buen comienzo gradual.

Comience tratando de definir el problema, luego mejore y amplíe su definición hasta que sea muy precisa.

Luego comience a mapear la solución.

Simplemente escribir cosas es más fácil que escribir código, y evitará que solo se ejecute y escriba una gran cantidad de código que tendrá que desechar porque era una solución demasiado miope o estrecha.

Gracias por el A2A, pero la respuesta corta es no.

Respuesta un poco más larga: no es un ritual per se, un conjunto repetido de acciones hechas a propósito … pero trato de asegurarme de que estoy despierto decentemente, de haber estado despierto durante al menos una hora más o menos, pero no tanto tiempo que yo ‘ Ahora estoy cansado y después de una noche de sueño reparador. También trato de despejar mi mente de otras preocupaciones y prevenir posibles interrupciones.

¿Rituales de calentamiento? No, no lo creo. Por lo general, comienzo mi día de trabajo con una taza de café mientras reviso el horario del día y me ocupo de cualquier asunto urgente en mi correo electrónico. Luego tomo otra taza de café y retomo donde lo dejé el día anterior.

A2A