Volver a Entradas

escribe código cada día

Colocado en Traducciones

Nota: Ésta es una traducción del texto titulado «Write Code Every Day», escrito originalmente por John Resig.

Durante el otoño pasado, el trabajo en mis proyectos alternos llego a un estado critico: no estaba haciendo el progreso adecuado y no podía encontrar una forma de hacer más sin sacrificar mi habilitad de hacer un trabajo efectivo en Khan Academy.

Había algunos problemas importantes en cómo estaba trabajando en mis proyectos alternos. Principalmente, estaba trabajando en ellos sólo durante los fines de semana y algunas veces por las tardes entre semana. Resultó que ésta no es una estrategia que funcione bien para mí. Estaba bastante éstresado por tratar de completar la mayor cantidad posible de trabajo de calidad durante el fin de semana (y sí no era capaz de hacerlo, sentía que había fracasado). Esto era un problema porque no había la garantía de que cada fin de semana estaría libre - no es que quisiera programar todo el día por dos días seguidos (removiendo cualquier oportunidad de relajación o hacer algo divertido).

Estaba también el problema de que trabajar en código en lapsos con una semana de espacio entre ellos es en tiempo largo, siendo muy fácil olvidar en que estabas trabajando o que ibas a hacer a continuación (aún dejando notas). Sin mencionar que si pierdes un fin de semana terminas con un hueco de dos semanas cómo resultado. Éste contexto de interrupción masiva por varias semanas puede ser mortal. (He tenido muchos proyectos alternos que murieron por falta de atención debido a esto).

Inspirado en el increíble trabajo que Jeniffer Dewalt completo el año pasado, en el que ella se enseño a si misma a programar construyendo 180 sitios web en 180 días, me sentí orillado a intentar una táctica similar: trabajar en mis proyectos alternos todos los días.

Ilustración: Robot triste y robot contento

Decidí ponerme algunas reglas:

  • Debo escribir código todos los días. Puedo escribir documentos, o entradas de bitácora u otras cosas, pero debe ser adicional al código que escribo.
  • Debe ser código útil. No cambios de sangrías, no cambios en el formato ni refactorización del código. (Todas esas cosas están permitidas, pero no deben ser el trabajo exclusivo del día).
  • Todo el código debe ser escrito antes de media noche.
  • El código debe ser abierto y estar disponible en GitHub.

Algunas de esas reglas eran arbitrarias. Técnicamente el código no necesita ser escrito antes de media noche, pero quería evitar estar despierto hasta tarde, escribiendo código inconsistente. El código tampoco tiene que ser abierto y estar disponible en GitHub, esto sólo me forzó a meditar más en el código que estaba escribiendo (como el pensar en la reutilización y el decidir crear módulos al principio del proceso).

Hasta ahora he tenido bastante éxito, estando cerca de conseguir 20 semanas consecutivas de trabajo. Quise escribir acerca de ello y como ha cambiado completamente la forma en que escribo código y ha tenido un impacto substancial en mi vida y mi mente.

Ilustración

Con esto en mente, varias cosas interesantes ocurrieron como resultado de éste cambio en mis hábitos:

  • Código mínimo viable

Fui forzado a escribir código por no menos de 30 minutos al día. (Es realmente difícil escribir código útil en menos tiempo, especialmente después de tener que recordar donde que quedaste el día anterior). Algunos días, entre semana, trabajo un poco más (usualmente no más de una hora), y los fines de semana algunas veces puedo trabajar un día completo.

  • Escribir código como un habito

Es importante hacer notar que yo no me preocupo particularmente por la percepción superficial de la gráfica de GitHub. Creo que lo más importante de éste experimento es cambiar lo que estás haciendo en tu vida para ti mismo, no cambiar lo que estás haciendo para satisfacer la percepción de alguien más sobre tu trabajo.

  • Combatiendo la ansiedad

Antes de comenzar el experimento, con frecuencia sentía un alto nivel de ansiedad por no haber completado “suficiente” trabajo o haber hecho “suficiente” progreso (ambos relativamente no cuantificables ya que mis proyectos alternos no tienen fechas limite especificas). Me di cuenta que el sentimiento de realizar un progreso es tan importante como hacer el progreso mismo. Esto me abrió los ojos. Una vez que comencé a hacer un progreso consistente cada día, la ansiedad comenzó a disiparse. Me sentí en paz con la cantidad de trabajo que estaba realizando y ya no tenia el deseo sobrecargado de completar algo frenéticamente.

  • Fines de semana

Completar algo los fines de semana solía ser absolutamente critico para la construcción de un impulso hacia adelante (ya que era, típicamente, el único momento en el que realizaba código significativo en mis proyectos alternos). Ahora no es el caso - y eso es algo bueno. Construir expectaciones con el peso de semanas sobre lo que debería completar el fin de semana sólo terminaba por dejarme decepcionado. Con pocas excepciones no era capaz de completar todo el trabajo que quería y me forzaba a rechazar otras actividades que disfrutaba (comer dim sum, visitar museos, ir al parque, pasar tiempo son mi pareja, etc.) en favor de hacer algo más de trabajo. Tengo el fuerte sentimiento de que los proyectos alternos son importantes, pero no deben significar el excluir la vida en general.

  • Procesos en segundo plano

Un interesante efecto paralelo a escribir código para proyectos alternos cada día es que la tarea en curso está frecuentemente presente en tus pensamientos. Así que, cuando salgo a caminar, o tomo una ducha, o realizo alguna de las otras actividades que no requieren un gran esfuerzo mental, estoy pensando en que código voy a escribir más tarde y busco buenas maneras de resolver los problemas. Esto no pasaba cuando trabajaba en el código una vez a la semana o cada dos semanas. En vez de eso, ese tiempo era ocupado en pensamientos sobre otras tareas o, usualmente, con la ansiedad de no completar el trabajo de mis proyectos alternos.

  • Cambio de contexto

Siempre hay un costo por el cambio de contexto cuando se retoma el trabajo de un proyecto alterno. Desafortunadamente es extremadamente duro el continuar las ideas sobre un proyecto después de una semana entera trabajando en otras cosas. El realizar el trabajo todos los días ha sido de bastante ayuda con esto, debido al que el tiempo entre el tiempo de trabajo es mucho más corto, haciendo más fácil recordar en que estaba trabajando.

  • Balance en el trabajo

Uno de los aspectos más importantes de éste cambio fue simplemente el aprender como balancear mejor el trabajo, mi vida y mis proyectos alternos. Con la idea en mente de que tenía que trabajar en el proyecto todos los días, tenía que administrar mejor mi tiempo. Si agendaba una salida por la tarde y no regresaría hasta tarde, entonces tendría que trabajar en mi proyecto más temprano ese día, antes de comenzar mi trabajo principal en Khan Academy.

Adicionalmente, si aún no había terminado mi trabajo y saldría tarde, entonces me apuraba a llegar a casa a terminar (en lugar de perder el día). he tenido menos oportunidades de practicar mis pasatiempos (como la impresión en bloques de madera), pero es un intercambio razonable con el que tendré que vivir.

  • Percepción exterior

Esto ha tenido el beneficio adicional de comunicar éste nuevo habito al exterior. Mi pareja entiende que debo terminar éste trabajo cada día y que aveces otras actividades tienen que ser programadas alrededor de ese tiempo. Es muy confortable poder decir “sí, podemos salir/ver una película/etc. pero tengo que terminar mi trabajo más tarde” y ser comprendido y tomado en consideración.

  • ¿Cuanto código fue escrito?

Me ha resultado difícil creer la cantidad de código que he escrito en los últimos meses. He creado un par de nuevos sitios web y un montón de módulos nuevos. He escrito tanto que algunas veces olvido las cosas que he hecho —el trabajo de hace unas semanas parece una memoria distante—. Estoy extremadamente complacido con la cantidad de trabajo que he completado.

Considero que éste cambio de hábito ha sido un masivo éxito y espero continuar con ello mientras sea posible. Mientras tanto, haré lo que pueda para recomendar ésta técnica a quienes quieran completar un trabajo sustancial en sus proyectos alternos. Déjame saber si ésta técnica funciona o no para ti —¡estoy muy interesado por escuchar anécdotas adicionales!


Ilustración por Steven Resig.

Foto: Kike Díaz presenta a Paco Solsona de Google frente al primer batch de Dev.f.

David O' Rojo —Ciudadano del mundo, recorriendo el largo camino a la maestría en Desarrollo de Software. Interesado en lenguajes dinámicos, herramientas para el desarrollo web y proyectos enfocados al beneficio de la sociedad.

A Continuación

comienza a jugar con swift en ubuntu linux