La pasada semana hicimos una ronda de lightning talks con el objectivo de introducir a los compañeros de la empresa en tecnologías que no habían usado hasta ahora. Además sirvieron para hacer un poco de team building y romper un poco el hielo, cosa importante en un equipo _muy_ distribuído. Lo empecé a ver a la gente de aspgems y me pareció interesante.
Por mi parte hice un par de charlas que puede que resulten interesantes:
- Introducción al testing con python y django (pdf). Repasa conceptos muy básicos del testing y trata de explicar como testear una aplicación en django. Es muy muy básico, pero puede servir de ayuda si no estás familiarizado.
- Introducción a fabric (pdf). Fabric es una herramienta para facilitar la automatización de los “deploys”. Es similar a capistrano en ruby o ant (salvando las distancias) en java.
Como curiosidad las transparencias están creadas con una aplicación llamada landslide, que transforma sintáxis markdown a una presentación HTML5 o PDF. Muy simple de usar y fácilmente “maqueable”.
Me gusta mucho dar charlas de este tipo -a pesar de mi nula capcidad comunicativa- y creo que dice mucho el que un equipo de desarrollo monte charlas de este tipo para estar al día. A ver si mis compañeros se animan a subir las suyas.
Primero de todo decir que no soy ni jefe de proyecto ni nada que se le acerque. La palabra jefe, gestor, responsable se usa con demasiada soltura, ser un gestor competente es muy difícil y requiere mucho tiempo, exactamente igual que ser bueno en otros ámbitos más un toque de sensibilidad con el prójimo.
En España los títulos de gestión (jefe de proyecto, jefe de sección, gestor de blabla) se usan como complemento a los absurdos salarios, “fulanito, vas a ser responsable jefe del proyecto amoeba-ultra-2.0, vas a llevar toda la gestión, sabemos que podemos confiar en ti, blablabla…”, pero realmente no responden a una experiencia por parte de la persona que está en ese puesto, en la mayoría de los casos (*).
Nuestro scrum manager de cabecera en la empresa estaba de vacaciones, así que decidí tratar de hacer un sprint como mandan los canones de scrum, bueno, realmente como yo lo aprendí de @jmnavarro en mi estancia en unkasoft, con su reunión con cliente, elección de tareas del backlog, estimación, su avance, su burndown chart y finalmente la retrospectiva.
Decir que el desarrollo fue bien, se terminó en plazo, con calidad más que suficiente, pero eso no le interesa a nadie, aquí lo interesante es ver en donde metí la pata hasta el fondo, ¿no?:
- Puñetazos encima de la mesa: He tomado elecciones en base a mi experiencia por encima de las decisiones de mis compañeros, lo cual puede estar bien, pero no deja de ser un error. No dejar elegir su camino a tus compañeros es un grave error, aunque sepas sí o sí que hay formas mejores de hacer las cosas. Si la idea es formar un equipo de desarrollo a un buen nivel todo el mundo debe aprender y la mejor forma de aprender es afrontando problemas tú solito.
- Meterme en las tareas de mis compañeros: En un momento puntual decidí terminar a machete una tarea de un compañero (además de gestor, programo, ¿te suena?) ya que estaba bloqueando el desarrollo. Desde el punto de vista del proyecto es lógico hacerlo, pero no me paré a pensar que mi compañero se podría sentir ofendido, dolido por haber terminado algo en lo que estaba trabajando. Mil veces prefiero llegar tarde un sprint a tener un roce absurdo.
- Notificar los errores: no hay cosa más difícil que decir a alguien que la ha mangado. Y no quiero decir hacerlo sin que se sienta ofendido.
En resumen, si no tienes un poco de tacto, mano izquieda, inteligencia emocional, como lo quieras llamar, es mejor que te quedes como un buen técnico.
No hay nada mejor que las curas de humildad que la vida te da de gratis y que la memoria te recuerde los malos ratos que hiciste pasar a algún que otro gestor de forma innecesaria, mis disculpas atradas.
(*) En mi corta-pero-intensa vida laboral solo recuerdo a un par de personas haber estado a la altura de un puesto así, y cada día que pasa me acuerdo más de alguno de ellos :)
Para empezar, una frase:
Más hacer y menos hablar
es un ejemplo que define muy bien lo que está pasando ahora mismo. Nos hemos hartado de montar castillos sobre las nubes y cuando ya no podíamos llegar más algo nos la hemos pegado.
Estamos en un punto en el que una persona hace 1 año sin apenas saber sumar podía comprar una vivienda y sacarla un 30% sin despeinarse o que nos vendan la leche por que tiene calcio “de leche” -esta misma noche he visto un anuncio de pascual en TV, se habrán parado a verlo, alejandose unos metros de la pantalla, los creadores?-
Estoy hasta las narices de humo, quiero que cuando vaya al taller con mi coche venga un técnico y que sin pensar sepa lo que es ese ruido que apenas se escucha, y me da igual que el taller cumpla la norma de turno, quiero que cuando vaya al médico éste tenga los huevos pelados de tratar con pacientes, que sepa que me pasa o como mínimo que tenga recursos para saber qué hacer, quiero que cuando llame al banco a preguntar no me insten a hablar con “fulanito de tal” que es el que “lleva estas cosas”.
Quiero que haya gente que sepa, gente preparada, que sepa hacer, que me solucione, que me aporte.
Pero claro, para hacer todo eso necesitamos muchos años de preparación -sí, de esas cosas que nunca valen para nada en la universidad-, mucha experiencia, dedicación, gusto por hacer las cosas bien… y una recompensa (social, económica, del tipo que sea), pero para que me voy yo a esforzar si puedo pasar de #ponga aquí su puesto vendehumista de moda# una temporada y eso de escornarse no está bien visto -menudo pringao que diría aquel-
Cada vez que veo a alguien haciendo bien su trabajo me resulta imposible no soltarle un “da gusto pagar cuando la gente hace las cosas bien”
Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.
Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como “IDE” y las razones son las siguientes:
- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc
- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.
- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac… fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar…
- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.
- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras… sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.
Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.
Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep… lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones… pero los buenos programadores nunca nos confundimos :P
Este es un pequeño “truco” para testear métodos o funciones que usen datetime.now. Se podrían usar trucos aprovechando que python es un lenguaje muy dinámico, pero siempre que se pueda hacer explícito y simple, para qué complicarnos?
def method(param1, param2, now=None):
now = now or datetime.now()
# do something with now
pass
En el uso normal la llamaremos normalmente, pero en el test podremos pasarle un datetime concreto para testear.