miércoles, enero 18, 2017

Aprender o morir

Las cosas no son las mismas desde que aprendí a programar, los conceptos básicos son los mismos; pero las bibliotecas, plataformas, herramientas e incluso los lenguajes han cambiado. Aun así se espera que seas experto en poco tiempo, constantemente tenemos que estar aprendiendo para poder usar lo que tenemos disponible para sacar el proyecto adelante. Incluso dentro de la misma plataforma y lenguaje las cosas cambian. En el caso de JavaScript es fácil ver que en cuanto te distraes un poco las cosas ya cambiaron y lo que usan los cool kids ahora no es lo que tú conoces, en lo que aprendes lo que usan ellos ya cambiaron a otra cosa. Pero no debemos molestarnos por eso, es parte del trabajo.

Si no te gusta aprender constantemente, quizás el desarrollo de software no es para ti. Asumo que en todas las carreras es importante mantenerse al día, conocer las tendencias, los últimos adelantos. Pero en el desarrollo de software en particular, la velocidad con lo que van y vienen tecnologías es alta. Con internet y el OpenSource hay más opciones. Ya no basta comprar un libro y conocer el IDE actual mientras sale la nueva versión.

Como profesionales del desarrollo de software es nuestra responsabilidad conocer las nuevas bibliotecas, marcos de aplicaciones, lenguajes, plataformas y aprenderlas en caso de que sirvan para la solución del problema. Si no sabes, está bien decirlo, nadie sabe todo; pero eso no te justifica para no hacer tu trabajo. No digas: "es que eso no me gusta" cuando en realidad le sacas la vuelta porque no te has dado el tiempo de aprenderlo. Por lo menos debemos tratar de saber qué es lo que no sabemos para poder investigarlo cuando veamos la necesidad.

Aprender es parte del desarrollo de software (y del programador). Si no estás aprendiendo algo nuevo, lo estás haciendo mal.

miércoles, enero 11, 2017

Define las tareas antes de empezar

Es divertido iniciar proyectos e ir agregando funcionalidad que se nos va ocurriendo. Intentar usar nuevas tecnologías, nuevas formas de resolver problemas. Equivocarnos, aprender y volver a empezar.  Esto lo podemos realizar en un proyecto personal, en un super happy dev house o cualquier otro día.

Pero cuando se trata de entregar un proyecto con presupuesto fijo a tiempo, vale la pena definir desde un principio las tareas por realizar. Pensar qué es lo que queremos lograr y definir los pasos necesarios para llegar a esa meta. Esto no quiere decir que no podemos ajustar el plan después, el plan cambia. Para eso hacemos las iteraciones en el desarrollo. Revisamos como vamos y decidimos qué sigue.

Ha habido ocasiones que por sentir que tenemos el tiempo encima iniciamos el desarrollo del proyecto sin tener el backlog definido completo. Esto con la idea de que en cada iteración podemos irlo modelando, agregando elementos y definiendo el trabajo necesario. Para algunos proyectos ha funcionado más o menos; pero me he dado cuenta que durante el desarrollo del proyecto sentimos que vamos un poco sin rumbo. No sabemos cuánto nos falta o que porcentaje llevamos avanzado.

En cambio, cuando nos tomamos el tiempo de definir los objetivos y tareas necesarias a realizar. Aun cuando parece que no tenemos tiempo que perder y que debemos simplemente ponernos a programar en lugar de estar definiendo tarjetitas en un programa para administrar proyectos. Incluso cuando el proyecto ya se pasó del tiempo de entrega, vale la pena detenerse a pensar y definir eso que vamos a realizar. Con esa información podemos "saber" cuánto tiempo más necesitamos para completar el proyecto. Aunque nos fallen los estimados podemos revisar donde estuvo el error y mejorar el próximo proyecto. Sin tareas definidas y solo codificar es difícil medir el progreso e identificar áreas de oportunidad.

Tener el trabajo definido ayudará también a trabajar más rápido. Se evitan los tiempos muertos que surgen cuando al programar pensamos: "Ya terminé esta tarea... ¿ahora qué sigue?". Si ya tenemos un backlog de cosas por hacer bien definido podemos seguir programando en lugar de detenernos a pensar. Como ya no tenemos que pensar en detalles no técnicos podemos concentrarnos en lo que nos gusta. Disfrutar el viaje programando con nuestra dosis de motivación diaria.

viernes, enero 06, 2017

Si no sabes, no mientas

Hace tiempo necesitábamos sacar un proyecto que sería una prueba de concepto, algo rápido para probar una idea. La meta era sacar el proyecto en 2 semanas, el cliente solo quería saber si ese sería el mejor camino para resolver el problema. Le pedí a un programador que me ayudará con cierta tarea y al mismo tiempo le explique la importancia de tener algo listo en el menor tiempo posible. Al explicarle lo que debía de hacer le pregunté si ya lo había hecho antes, si sabía usar la herramienta. Porque si no, yo podría explicarle sin problema en una hora como hacerlo. De ese modo él iba poder seguir desarrollando. Me contestó que ya lo conocía y que no habría problema.

Al otro día revisé el repo y no estaba lo que había pedido. Le pregunté sobre el commit y me comentó que se le había pasado subirlo; pero que lo haría en ese día. Sin embargo al otro día seguía sin ver los cambios. No me gusta estar preguntando cada rato el clásico "cómo vas"; pero si no se ve avance en el proyecto no queda de otra más que preguntar. Me dijo que en un momento se lo aventaba... después de un rato me pidió ayuda porque no sabía como hacer lo que le había pedido. Esto fue casi tres días después de cuando le asigné la tarea y le pregunté si sabía.


No me hubiera molestado, para nada, que no supiera como realizar algo, porque pude haberle explicado y contemplar el tiempo necesario para aprender; pero como me dijo que sí sabía, no había planeado esos 2 días y ahora con dos días menos debía planear el tiempo que le llevaría aprender aquello que quizás pensó que podría googlear y sacar sin que me diera cuenta que no sabía.

Si necesito algo nuevo ¿Confiaré en que esa persona dará una solución? No. Ahora sé que no puedo confiar en que hará el trabajo, aunque diga que lo sabe hacer. No había necesidad de mentir, ni de tratar de hacer creer a los demás que sabía lo que no sabe. No está mal no saber, lo que sí está mal es mentir. Si no queremos decir "no sé", lo que debemos hacer es tratar de estar preparados para lo que se pueda necesitar, aprender lo nuevo lleva su tiempo y debemos estar en constante capacitación para mantenernos al día y ser útil cuando se necesite usar algo nuevo.

No debes tener miedo a decir que no sabes hacer algo o que no haz usado cierta herramienta. Nadie sabe todo. Lo más importante es la actitud, las ganas de aprender y tener sentido común. Si crees que perderás reputación por decir que no sabes algo, de nada sirve mentir, al final se va a notar que no sabes y va a salir peor. No solo serás la persona que no sabe, también serás alguien en quien no se puede confiar. Aprender algo nuevo es fácil, recuperar la confianza de los demás no tanto.