Apple Podcast (iTunes) | iVoox | Spotify | Suscríbete al podcast

Me abro las carnes y confieso acerca de lo aprendido sobre los malos hábitos en las últimas semanas de trabajo y el reto de #100DaysOfCode.

Este es un episodio en forma de retrospectiva que tiene mucho que ver con los episodios 87 y 83, donde hablamos del código que te gustaría generar y de cómo es un proceso de aprendizaje. Quizás en este terminemos de descubrir el Santo Grial Developer.

Esta semana se lanza el nuevo desafío de la Zona Premium: Aprende Vue desaprendiendo jQuery. Trazaremos un paralelismo entre lo que sabemos de jQuery y como podemos enganchar esos conocimientos con el nuevo y flamante framework progresivo Vue JS.

Pizarrín y audiocursos

Además la semana pasada se publicó una entrevista en audio y vídeo donde David y Francesc me invitaron a hablar del formato de los audiocursos. Puedes verlo todo en Instructores Online.

Más de uno me ha preguntado por la pizarra que puede verse durante la entrevista en el fondo. Hablamos de ella hace tiempo, me sigue siendo muy útil e inspiradora, aunque no la use todos los días. Puedes comprarla en Amazon.

Retrospectiva

Hace varias semanas comenzaba el reto de los 100 días de código. Cuestiones de organización y falta de tiempo interrumpieron el reto en el día 35 (aunque el diario sólo llega al 29).

De una experiencia así se puede hacer una gran retrospectiva, para analizar los malos hábitos descubiertos en la faceta de programación, compartirlos contigo y buscar solución a los mismos.

Los malos hábitos detectados

Falta de planificación

Uno de las sugerencias del reto es que no planifiques demasiado. A mi esto no me ha funcionado. Si a los clientes y jefes les pedimos que concreten como quieren los desarrollos, ¿por qué no deberíamos hacer lo mismo en nuestros proyectos?

Es muy fácil aprender

Los primeros pasos son siempre sencillos, porque las guías y tutoriales están creados para generarnos confianza. El problema viene cuando avanzamos un poco más y nuestra aplicación empieza a tener más detalles a tener en cuenta.

Ignorar los "baby steps"

Los “baby steps” son aquellos que nos parecen muy pequeños pasos cuando tenermos que darlos pero muy grandes cuando los vemos desde la distancia

Pensar en tests cuando realmente no los usas

Lo sé, este es un problema recurrente que hay que atajar de raíz. El coste de oportunidad de un producto bien hecho no se puede evaluar solo en base al tiempo que hay que invertir en aprender a manejar el paradigma de la programación guiada por pruebas.

No hace falta documentar el aprendizaje

Soy un firme defensor de los "diarios de aprendizaje" o "cuadernos del programador" donde se apuntan pequeñas notas rescatables para crear una base de conocimiento. Recomiendo usar jrnl y no complicarse la vida tanto como yo.

También hay cosas buenas

No todo es tremendo y horrible. Hay un espacio para la esperanza.

  • Capacidad de aislar un problema en un proyecto específicamente creado (y luego destruido) para aprender un nuevo concepto.
  • React, Redux y esta nueva forma de programar son apasionantes y merecen cada minuto dedicado a su aprendizaje.
  • Desplegar tu código con un sólo un git push sigue siendo algo sorprendente para mi. Heroku, Gihub o Gitlab fueron las herramientas empleadas para este menester.
  • Creación de un hábito constructivo de programación guiada al aprendizaje.
  • Eliminar de la ecuación la "muerte por funcionalidad" y el efecto "tutorial hasta amargar".
  • Contarlo en el diario, aunque fuera un trabajo extra no asumible a día de hoy

Si quieres estar al tanto de mis andanzas no dejes de suscribirte al canal de telegram o a la cuenta de twitter @webreactiva.

¡Nos escuchamos el próximo martes!

¿Quieres ser mejor desarrollador?

Escrito por Dani

Soy programador web freelance. Especialista en frameworks basados en PHP como Drupal, aunque también me gusta trabajar con microframeworks en varios lenguajes y, por supuesto, tengo a Javascript de gran aliado. aquí.
comments powered by Disqus