El lado B de la profesión

Hoy en día tengo 3 profesiones: consultor, profesor e investigador. Cada una de estas tres profesiones tiene un lado B que no siempre vemos.

Como consultor trabajo de forma independiente y eso implica que más allá de hacer el trabajo para el cual los clientes me contratan tengo que encargarme de una serie de cuestiones no tan divertidas pero necesarias que podrían resumirse como: ventas y cobros. Muchas veces, cuando uno trabaja en relación de dependencia, no se preocupa por estas cuestiones porque en general hay alguien más que se encarga. Pero trabajando de forma independiente es uno mismo quien debe encargarse de vender. La venta en general implica alguna reunión de relevamiento a partir de la cual uno arma una propuesta de servicio. Si la propuesta es aceptada entonces se procede a la realización de trabajo y posteriormente a la facturación y cobro del mismo.

Como docente a cargo de una materia tengo que dictar clase y evaluar a los alumnos. Esto implica la preparación de clases, materiales de estudio, ejercicios, etc. Pero adicionalmente a todo esto están las cuestiones administrativas de la materia: gestión de actas, verificación de correlatividades, coordinación del equipo docente, resolución de pedidos de equivalencia, etc, etc.

Como investigador uno lee, analiza, lee, experimenta, lee, escribe, asiste a conferencias, lee, etc. Pero también hay una parte administrativa que tiene que ver con la formulación de proyectos, la gestión de presupuesto y la rendición de cuentas.

Escribo de esto porque mis fines de año tienen mucho de estas tareas “lado B” y no son de lo más divertido (por eso hago un poco de procrastinación escribiendo en el blog 🙂 )

Cosecha de libros 2019 (en papel)

De mi reciente viaje a Barcelona me traje algunos libros en formato físico.

Refactoring to Patterns es un clásico que tenia pendiente hace mucho tiempo. Había leído capítulos sueltos y me habían gustado mucho, así que finalmente decidí comprar un ejemplar el papel. En términos estéticos el libro es fantástico: es tapa dura y tiene dos piolines para usar de señaladores.

Building Evolutionary Architectures es un libro relativamente nuevo y lo compré porque el planteo me resultó muy interesante. Cuando trabajamos en la definición de una arquitectura lo hacemos prestando atención a la funcionalidades y a ciertos atributos de calidad. El libro plantea que en los tiempos que corren resulta cada vez más importante poder plantear arquitecturas que puedan evolucionar, o sea: agregar “la capacidad de evolucionar” a los posibles atributos de calidad. Al mismo tiempo esa capacidad de evolucionar debe ser acompañada por cierta guía de cómo hacerlo.

Lecture Notes in Computer Science es un serie de libros de la editorial Springer que agrupa artículos científicos publicados en conferencias. En este caso me trabaje el libro de esta serie correspondiente a la conferencia Profes 2019 que contiene el artículo de usabilidad de procesos que publicamos con DiegoF y el mini artículo de mi Tutorial de Prácticas DevOps.

Practices for developing maintainable infrastructure code

Este es el título de la charla que expuse el martes pasado en el Meetup de Infra as Code en la UTN.BA. Los slides están disponibles aquí. La idea de la charla estuvo motivada por el hecho de que en los últimos año el uso de esta práctica se ha popularizado mucho y en varios casos he visto que no se la ha prestado la suficiente atención a la forma de escribir el código. El código “no cuidado” puede no tener efectos negativos en lo inmediato, pero en el mediano/largo plazo puede representar un dolor de cabeza. Dicho esto, la idea de la charla era llamar la atención sobre la importancia de escribir “código feliz” y junto con ello compartir algunas técnicas y herramientas para poder hacerlo.

Al comienzo de la charla, hice un breve encuesta de un par de preguntas para entender la audiencia, por un lado pregunté el rol de los participantes y por otro pregunté quién escribía el código de infraestructura. Los resultados a estas preguntas se ven en los gráficos a continuación.

Un dato que me parece interesante analizar es que el ~35 % de los participantes indicó no estar usando InfraAsCode aún. Por otro lado el ~17% indicó que dicho código lo escriben los developers, en este grupo me encontraría yo :-).

El polémico perfil del Ingeniero DevOps

El polémico perfil del Ingeniero DevOps

Ayer estuve participando del Meetup de Infrastructure as Code. Hubo un par de presentaciones y luego un panel de debate con los disertantes. En ese contexto un participante planteó una consulta sobre la formación de perfiles DevOps. Yo di una respuesta que me parece resultó polémica para algunos: no creo en un perfil DevOps.

A esta altura claro está que DevOps es un mindset que busca remover las fricciones típicas entre las áreas de Desarrollo y Operaciones a partir de un trabajo colaborativo y la implementación de ciertas prácticas. No creo que esto implique un nuevo perfil ya que me parece que no hay nuevas responsabilidades ni tareas. Es cierto que entre las prácticas “novedosas”que propone DevOps está el manejo de infraestructura como código, pero no creo que amerite un nuevo perfil, pues la infraestructura ya era una cuestión que teníamos que administrar, la novedad está en todo caso en la forma en que lo haremos: ahora quienes esten a cargo de la administración de la infraestructura deben escribir código ¿vamos a contratar nuevos perfiles para eso o vamos a pedir a los sysAdmins o developers que se encarguen? Yo voto por esto último.

Por otro, si uno mira las búsquedas de perfiles DevOps, en general se encuentra con una extensa lista de conocimientos técnicos y de herramientas, pero casi nada sobre “soft-skills”, o sea: DevOps tiene que ver con colaboración, supongamos por un momento que generamos un nuevo perfil (Ingeniero DevOps) para que facilite que la organización pueda trabajar de en una cultura DevOps ¿no debería entonces ese perfil de Ingeniero DevOps tener ciertas habilidades de facilitación, generación de acuerdos, vocación de servicio, etc? Pues para varios parece que no, pues estas cuestiones son muchas veces omitidas en las búsquedas de DevOps.

Continuará…

Review of my DevOps Tutorial @ Profes 2019

I delivery this tutorial yesterday morning. Seven people participated on it: 2 from Austria, 2 from Spain, 2 from Finland and 1 from Germany.

The tutorial flowed as expected but I would have like to have 30 extra minutes to cover the Continuous Delivery part with a hands-on exercise.

Participants evaluated the tutorial with 5 points out of 5 🙂

Here is the formal summary of the tutorial.

Prácticas DevOps para todos y todas

Este fue el título de la charla que estuve dando el lunes pasado en el meetup de Software Crafters Barcelona. La charla estuvo basada en el material de mi charla “No contrates Ingenieros DevOps”, pero decidí darle una dinámica distinta. Inicialmente hice una introducción al mindset DevOps y luego debatimos sobre el rol del Ingeniero DevOps usando una dinámica de Fishbowl. Finalmente cerramos revisando algunas prácticas para intentar acercar y mejorar el flujo de la gente de Dev y gente de Ops.

Me gustó mucho la forma en que fluyó la actividad. Luego de la charla nos quedamos compartiendo unos tragos con los participantes. Agradezco a la comunidad de Crafters, a la gente de Voxel Group y a Adrián Perreau porque hicieron posible el meetup.

Comparto aquí algunos recursos que mencioné durante la charla:

Investigación formal sobre TDD ¿queréis participar?

Hace unos dos meses comenzamos, con el grupo de Prácticas y Procesos de UNTreF, a trabajar en un estudio sobre Test-Driven Development (TDD).

TDD es un de las prácticas ágiles más populares pero comparativamente con otras prácticas ágiles es muy poco utilizada. Cuando digo que es popular me refiero a que es muy conocida (se sabe de que se trata) pero curiosamente hay varios estudios que muestran que su uso es mucho menor al de otras prácticas ágiles como las Restrospectivas e Integración continua. Dos fuentes que confirman esto son el reporte anual de VersionOne y nuestro propio estudio sobre Prácticas Agiles en Latam.

Con mi colega @dfontde tenemos la sospecha de que esta baja adopción de TDD puede deberse a issues de usabilidad de la práctica. Esto es precisamente lo que vamos a intentar probar (o descartar) en este estudio. Para ello utilizaremos el Modelo de Usabilidad de Práctica y Procesos que @dfontde está desarrollando como parte de su doctorado.

Para realizar esta investigación vamos a necesitar la colaboración de practicantes con al menos 5 años de experiencia en el uso de TDD. Los interesados pueden contactarme dejando un mensaje aquí.