Sobre cultura de trabajo en equipos remotos

El pasado jueves estuve en la primera sesión del grupo MADnagers in tech y el tema de conversación era “Gestionando equipos en remoto”, presentado por Pablo Carranza, Head of Engineering en Cabify.

Aunque tuve la mala suerte de llegar un poco tarde y perderme los primeros minutos de presentación, lo que pude ver me resultó realmente interesante, así que no quería perder la ocasión de compartir mis notas y aprendizajes de esta sesión.

Dos ritmos de trabajo en paralelo

Una de las ideas más interesantes que se comentó fue la de los dos ritmos de trabajo a los que nos enfrentamos en una organización, y que funcionan a la par:

El primero se refiere al aquí y ahora, las características, bugs, y problemas a los que se está enfrentando el equipo a fecha de hoy. Este ritmo es el que se suele ver diariamente en las standups, en los correos “urgentes” y en la cola de tickets que nos vienen de atención al cliente. El responsable de llevar este ritmo es el propio equipo, que tiene todo el contexto sobre el aquí y ahora, siendo la labor del líder del equipo la de desbloquear situaciones, pero no la de controlar cada tarea.

El segundo se refiere al futuro, aquí es donde están las nuevas peticiones, el estado de los proyectos que se ejecutarán más adelante, las nuevas iniciativas, las migraciones, y todo lo que no tenga el carácter de “Urgente”. En este caso el responsable de llevar este ritmo es el líder del equipo, de fijar el contexto y mantener la conversación sobre el futuro, especialmente a la hora de encontrar bloqueos que afecten al equipo

Uno de los puntos en los que más incidió Pablo fue en la necesidad de que tanto el presente como el futuro convivieran, idealmente, en el sistema de control de tareas, ya sea Jira, Github, Gitlab u otros.

Esto es debido a que el sistema de control de tareas permite mantener una conversación de manera asíncrona y pública y en diferentes hilos. Esto es especialmente importante en el caso de equipos remotos, ya que por una parte, no todos los miembros del equipo tienen que estar disponibles a la misma hora, y por otra, garantiza que en el futuro cualquier miembro del equipo pueda acceder a este historial, especialmente nuevos miembros.

Roadmaps permanentes y controlados

Otro punto destacado fue la gestión del Roadmap, en la que pasamos de un documento de Word compartido por email a un sistema controlado y versionado.

Un roadmap es importante en cuanto a que define la dirección a la que vamos, y por tanto es un documento que debería cambiar lentamente y de manera controlada. Si un roadmap está cambiando constantemente se convierte en un documento que no es fiable, y por tanto se le deja de presentar atención.

Es por ello que una idea que plantea Pablo es la de mantener el roadmap de manera controlada y controlar qué cambios se hacen al mismo. La manera más fácil de hacer esto es mantener el roadmap en un fichero markdown dentro de nuestro control de versiones, que las actualizaciones del mismo se realicen vía pull request, y que se pueda tener una conversación sobre la misma de manera pública y asíncrona.

Esto además nos permitiría mantener el histórico de donde estábamos hace 1 año, 6 meses, y ver si lo que queríamos hacer entonces lo queremos hacer ahora.

Si no está escrito, no pasó

En este punto, mencionaba dos ceremonias que suelen ocurrir cuando tenemos un equipo parcialmente remoto, las reuniones formales, como por ejemplo la standup, y las reuniones informales, como las conversaciones de pasillo.

Por lo general, salvo que exista una agenda definida y unos minutos tras la reunión, no se suele dejar constancia de que lo que se ha contado en una reunión, especialmente si la información solamente se comparte en ese momento y no queda en una tarea.

Esto es especialmente delicado en lo que respecta a las conversaciones de pasillo, ya que suelen ir acompañadas por una toma de decisiones que no suele quedar documentada, ni la decisión, ni las razones de la misma.

Pensando en este tema me ha venido a la memoria el año 2012, cuando formaba parte del equipo de Códice Software haciendo PlasticSCM, que durante las standups un miembro del equipo tomaba nota del estado que compartía cada miembro del equipo, y luego ese estado se actualizaba en una wiki de manera pública.

De esta manera, al final del sprint se podría comprobar cómo había sido el progreso del mismo, y habría un registro. Por otra parte, si alguien se incorporaba después de unos días de vacaciones, era tan sencillo como ir al registro del sprint, leer el estado y ponerse al día de manera asíncrona,

Cuidado con los Silos

Otro de los puntos comentados se refería a cómo el no compartir la información de manera pública puede acabar provocando silos de información, cuando solamente ciertas personas conocen el estado de un sistema porque lo diseñaron ellos, o peculiaridades de una integración que no están documentadas porque es conocimiento tribal.

Para ello es muy importante tomarle el pulso al equipo, ver cómo están hablando, cómo se están comunicando y encontrar los mejores canales para ello, wikis, sistemas de tareas, repositorios y otros mecanismos más allá de reuniones, chats o email.

Equipos remotos y la ley de Conway

La importancia de mantener unos niveles de comunicación adecuados en un equipo va más allá de que sea más sencillo seguir el rastro a tareas, de que el equipo no tenga que estar preocupado de lo que va a decir en la standup, o que las reuniones de sincronización se extiendan durante varias horas hasta que el estado quede claro.

De acuerdo con la ley de Conway, esto afecta directamente a cómo producimos el software en nuestras organizaciones:

Las organizaciones dedicadas al diseño de sistemas […] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones

Melvin Conway

Por tanto, si formamos parte de equipos remotos y nuestra estructura de comunicación es pública y asíncrona acabaremos haciendo mejor software.

Conclusiones

  • Tenemos muchos sistemas a nuestra disposición para compartir el estado de nuestras tareas más allá de una reunión de 15 minutos en la que cada miembro del equipo tiene 30 segundos para hablar.
  • Compartir información de tal manera que no necesitemos a todos los miembros del equipo presentes a la misma vez nos permite ganar tiempo, ya que la información se mantiene en un punto común y de manera estable, especialmente a la hora de tomar decisiones, documentando las decisiones tomadas y las razones para las mismas.
  • Mantener la información públicamente accesible y simplificar canales de comunicación sencillos permite mitigar la aparición de silos de información, en las que solamente un subconjunto del equipo conozcan cierta información que todos deberían conocer.
  • Conseguir un sistema que permita que el estado esté fácilmente disponible, y que los canales de comunicación estén claros, no solamente afecta a la actitud del equipo, sino que tiene un impacto directo sobre el software que producimos.

Lecturas adicionales

Pablo escribió un artículo en su blog en el que habla de estos temas y los desarrolla con un gran nivel de detalle, además durante el evento mencionó el Remote Manifesto de Gitlab, y la teoría de las limitaciones (theory of constraints) que se hizo conocida en el ibro The Goal y que se ha llevado al campo de IT en el libro The Phoenix Project, que comenté el pasado año.

Creando diagramas de manera efectiva con el modelo C4

En nuestro día a día empleamos múltiples niveles de abstracción para referirnos a los sistemas de información que construimos, manipulamos o mantenemos, nos referimos a sistemas, aplicaciones, servicios, APIs, llamadas, funciones, almacenamiento, memoria, ficheros, eventos, etc.

Muchas de estas abstracciones las comentamos de manera informal, las describimos a través del código que escribimos y que ejecutamos, las describimos en prosa, o empleamos la herramienta favorita de los arquitectos y la más temida por los desarrolladores, los diagramas.

Un diagrama, ya sea de componentes, de secuencia, de interacción o de clases, no es más que otra abstracción en la que describimos como es o cómo pretendemos que sea nuestro sistema. El diagrama nos puede permitir pasar por ciertas capas de descubrimiento, descubrir o fijar los límites de nuestro servicio en comparación con otros, y es una herramienta que nos permite mantener una conversación.

Esta herramienta es crítica cuando tenemos que interactuar con otros equipos, o compañeros que pueden no tener todo el contexto. Es por ello que es importante tener en cuenta el público, el objetivo, y el nivel de abstracción que queremos mantener. al crear dichos diagramas y representar contextos

Una metodología para la representación de diagramas que he estado poniendo en práctica recientemente es el modelo C4 por Simon Brown, en el cual, siguiendo ciertas prácticas e iterando sobre nuestros diagramas, podemos diseñar nuestro sistema utilizando varios niveles de abstracción:

  • Contexto
  • Contenedor
  • Componente
  • Código

Pese a que el modelo define 4 capas, en este artículo hablaremos de las tres capas superiores, ya que la cuarta se asemeja bastante a diagramas a los que podamos estar más familiarizados, y en ocasiones no es necesario ni siquiera llegar a ellas.

El ejemplo

A la hora de escribir el artículo pensé en algo del estilo “lista de tareas” dada mi obsesión por las aplicaciones, metodologías y otros, pero al final me decanté por un sistema que me permitiera escribir artículos en un blog.

Los requisitos son los siguientes:

  • Un lector puede ver artículos publicados y escribir comentarios.
  • Un autor puede escribir artículos, editarlos y borrarlos
  • Un autor, además, recibirá una notificación cuando se cree un nuevo comentario.

Vayamos manos a la obra:

Nivel 0: Contexto

tbe-blog-page-3

A este nivel queremos definir de manera clara quienes son los actores que interactúan con nuestro sistema, qué sistemas tenemos, y una primera idea de cómo se relacionan entre ellos.

A este nivel podemos tener una conversación con un potencial usuario del sistema, o con nuestros compañeros de negocio, ya que los casos de uso generales se definen aquí.

Es también una oportunidad para destacar qué queda fuera del sistema, y hasta qué punto se pueden modificar esos sistemas. Podemos utilizar esquemas de colores para destacar qué sistemas podemos y cuales no podemos modificar.

Nivel 1: Contenedores

Tbe Blog-Page-4

En este caso hacemos zoom en cada uno de los sistemas, y lo separamos en contenedores que tienen una función lógica. En el caso de nuestro blog tenemos dos subsistemas diferentes, uno encargado de la edición de artículos y otro de la visualización, así como una API entre la que interactúan ambos sistemas.

A este nivel podemos tener conversaciones a nivel técnico con diferentes equipos involucrados en el proyecto, el nivel de abstracción es menor, y podemos tomar decisiones como cuantos subsistemas construimos y cómo se reparte el trabajo de los mismos.

Nivel 2: Componentes

Tbe Blog-Page-5

Este nivel es el más profundo al que llegaremos en este artículo, aquí podemos establecer una separación más clara, en el caso de la UI podemos separar las diferentes páginas que existirán, y en el caso de la API backend los diferentes componentes que podemos emplear, en el que cada componente puede ser una librería, un paquete, un proyecto o una unidad semántica de código.

En este nivel podemos tomar decisiones de arquitectura directamente a nivel de equipo, entender las diferentes relaciones entre los diferentes componentes y modularizar más, si fuese necesario.

Evolución

Una de las características más interesantes de este estilo de modelado es que es iterativo, una vez que empiezas y vas pasando por las diferentes capas descubres que estabas empleando el modelo erróneo de abstracción, y mueves “cajitas” entre las diferentes capas.

El primer diagrama que hagamos nunca será perfecto, pero el hecho de tener tres diagramas diferentes e iterar entre ellos nos permitirá descubrir nuestra arquitectura, encontrar límites y tener una mejor idea del alcance de los productos que vamos a construir.

Desde el punto de vista práctico, recomiendo utilizar una herramienta que nos permita tener los tres tipos de diagramas visibles a la vez, ya que nos veremos en la situación de estar cambiando componentes entre los diferentes niveles de abstracción.

Retrospección

Podemos utilizar estos diagramas no solamente como una manera de crear software, sino también de familiarizarnos con software existente. A la hora de enfrentarnos a un nuevo proyecto, entender el sistema en el que nos encontramos nos permite mitigar el factor ”Pulpo en garaje” y ser más productivos desde el principio.

Conclusiones

En general los diagramas son otra herramienta que podemos utilizar tanto para descubrir, explorar o enterarnos de donde nos hemos metido, no son el fin, ni mucho menos, sino un medio para construir mejores sistemas. Metodologías como C4 nos permiten crear mejores diagramas y con ello, mejores sistemas.

Más información sobre el modelo C4 en la web de Simon Brown: The C4 model for software architecture

Imagen por Kaleidico vía Unsplash

Libro: ¿Cuando? La ciencia de encontrar el momento preciso

Soy de esas personas que, además de tener libros en casa que no han empezado, tengo muchos que empiezo y dejo por la mitad. En este mes de marzo he intentado ponerme al día en los libros que tengo empezados, algunos de ellos he tenido que volver a empezar desde el principio pero otros los he retomado por donde estaba.

Uno de los libros que he retomado es ¿Cuando?, de Daniel H. Pink (When: The Scientific Secrets of Perfect Timing en su versión en inglés).

Es un libro que habla de muchas cosas, pero sobre todo es un libro que habla del tiempo, desde la manera en la que somos productivos a lo largo del día, la diferencia entre búhos y alondras, pasando por los principios, los intermedios y los finales, hasta temas como el concepto del tiempo y del futuro, que no está presente de manera tan fuerte en todos los lenguajes y modifica no solamente la manera de interactuar, sino la manera de ver el mundo.

El libro se divide en tres bloques. Cada bloque, además, consta de una parte que podríamos denominar teórica o divulgativa, y una parte más práctica que Daniel denomina “Manual del Hacker del Tiempo” con consejos prácticos para poner en uso lo enseñado en el apartado anterior.

  • El día: En ella habla de cómo definimos nuestro día, cómo y cuando dormimos, cómo algunos somos de levantarnos pronto y otros de quedarnos hasta tarde, cómo afecta eso a nuestras decisiones, y cuando tomar decisiones importantes.
  • Comienzos, finales y mitades: En este bloque habla de diferentes tipos de comienzo, la importante de volver a empezar en algunos momentos de nuestra vida, la importancia de los finales, de por qué hacemos locuras o cosas intensas en el último año de cada década o cómo varían las relaciones entre la edad adulta y la vejez.
  • Sincronizar y pensar: Finalmente, usando como ejemplos a los dabbawalas, los miembros de un coro, y de un equipo de remo, habla de la importancia y la necesidad de mantener sincronía con aquello que marca el tiempo (que puede ser una persona, un reloj, una situación), sincronía con el grupo y finalmente, lo que denomina sincronía del corazón, es decir, la razón última de por qué hacemos las cosas, en el coro puede ser por motivos religiosos, en el remo por el esfuerzo conjunto, y en el caso de los dabbawalas, por la importancia de lo que están transportando, comida hecha en casa.

Un libro interesante, que te puede hacer pensar y reflexionar, siendo mi parte favorita la de los comienzos, finales y mitades. Todo lo que hacemos, inexorablemente tiene un principio, una mitad, y un final, como también lo tiene este artículo que comparto contigo, querido lector.

Si sientes curiosidad, tienes el libro disponible aquí: ¿Cuándo?: La ciencia de encontrar el momento preciso o si lo prefieres en versión original: When: The Scientific Secrets of Perfect Timing (English Edition)

Libro: The End of Procrastination

Procrastinar
Del lat.procrastināre.
1. tr. Diferir, aplazar.

RAE

Una de las cosas que intento hacer siempre que estoy en un aeropuerto es pasar por la sección de libros de las tiendas de Duty Free, si veo algo interesante en un idioma que entiendo y me puedo beneficiar de algún cambio de moneda, no lo dudo y compro un ejemplar, aunque tenga una pila infinita de libros por leer, con la errónea suposición de que leeré el libro mientras vuelo.

Así, casi dos meses después de su compra, te traigo “The End of Procrastination”, un libro corto (apenas 240 páginas de contenido) y pequeño que nos trae algunos trucos sobre cómo combatir la tendencia que tenemos algunos de postergar cosas, especialmente si son importantes o aburridas.

En un formato diferente a otros libros (cuadrado para ser exactos) y lleno de ayudas visuales, el libro nos provee con varias herramientas para intentar superarnos poco a poco.

Partiendo de un análisis personal, utilizando métodos como SWOT o DAFO para ver cuales son nuestras fortalezas y debilidades, una lista de lo que creemos que puedan ser nuestros mayores logros, así como una visión personal, podemos tener una idea más realista de donde estamos y a donde queremos llegar, siendo el principal objetivo limitar el espectro de opciones a nuestro alcance a aquellas que nos ayuden a lograr esa visión, ya que está demostrado que tener demasiadas opciones bloquea nuestra capacidad de elegir, y ante la frustración de no poder elegir, elegimos no hacer nada.

A partir de ahí, el libro pasa a temas más de nuestro día a día, como mantener actualizada una lista de hábitos, planificar las tareas diarias de manera visual, encadenando unas con otras y agregando marcadores de importancia, maneras de organizar aquellas tareas que no requieren acción inmediata, cómo tener listas de ideas en las cuales actuar a futuro, y cómo salir de nuestra zona de confort para poder hacer más.

Finalmente, el libro pasa a temas más complejos, como qué pasa cuando nos vemos en una situación de bloqueo, en el cual nos vemos atados a un presente o a una situación pasada negativa y no podemos salir de ahí, mencionando cómo tenemos el control sobre la manera en la que respondemos a estímulos, por mucho que puedan ser negativos, o cómo mantener una lista de cosas positivas que han pasado durante el día (otros autores lo mencionan como las tres gratitudes)

Personalmente me ha gustado el formato, aunque, tras haberlo intentado, no esté del todo convencido del formato de organización de tareas diarias, para ello me quedo con el método de Cal Newport que recomienda tanto en su blog Deep Habits: The Importance of Planning Every Minute of Your Work Day como en su libro Deep work, que ya comenté en este blog en 2016.

Como estas, muchas más herramientas y muchos más dibujos en The End of Procrastination: How to stop postponing and live a fulfilled life

Espero que te resulte interesante (y a diferencia de mi, tardes menos de dos meses en terminarlo).

De vuelta de WeCodeFest 2019

Este año he vuelto a Valladolid a aprender y compartir con compañeros de batallas en un evento con charlas, talleres y debates durante dos días siguiendo un formato mixto de agenda cerrada + open space.

Durante el evento tuve tanto la oportunidad de escuchar y comentar en varios foros que iban entre el uso de frameworks, el trato con clientes complicados, los procesos de onboarding… , así como facilitar dos sesiones, una relacionada con productividad y distracciones, y la otra relacionada con libros, eventos y charlas que nos han marcado o han cambiado nuestra manera de ver problemas.

Esta fue fue una ocasión más para volver a ver a los compañeros de Códice Software, creadores de PlasticSCM, y la casa que me acogió cuando salí de la carrera y donde realmente aprendí a construir software, a hacer tests y a descubrir la diferencia entre programa y producto. Después de más de 10 años siguen luchando contra viento y marea por hacer el mejor sistema de control de versiones del mundo.

A continuación resumo algunas ideas que me han parecido interesantes de las sesiones a las que he asistido:

Microservicios

Me llevo deberes, concretamente este artículo: the Twelve-Factor App que da una definición de qué constituye un microservicio. Durante la conversación se debatió además el hecho de utilizar microservicios como una manera de organizar equipos, y aislar funcionalidad para intentar mejorar problemas de comunicación entre equipos.

Motivación

Me llevo varios conceptos relacionados con motivación intrínseca, qué es lo que nos lleva a hacer lo que hacemos y a mantenerlo, que va en línea con lo que he estado leyendo últimamente y de lo que espero escribir pronto, y echar un vistazo a este libro Drive: de Daniel H. Pink.

Productividad y distracciones

Entre los puntos que discutimos en esta sesión me gustaría destacar.

  • La necesidad de proteger nuestra concentración (auriculares con cancelación de ruido, sonido de ambiente, ambientes silenciosos si es posible) y la de nuestros compañeros, (manda una pregunta por chat, y cuando él pueda contestará, y así el compañero controla cuanto quiere ser interrumpido).
  • El uso de técnicas como revisar el correo en momentos puntuales del día, desconectar notificaciones, cerrar Slack o usar técnicas como pomodoro para tener momentos de no molestar, que podemos combinar con herramientas como Cuckoo para que el equipo sea consciente de si otros compañeros están ocupados en ese momento.
  • Ls emociones que genera la música y cómo afecta a nuestra capacidad de concentración, y cómo herramientas como Noisli pueden generar ruidos “de ambiente” o directamente ruido blanco pueden ser más útiles que canciones, especialmente canciones con letra. Dichas emociones, por otro lado nos pueden ayudar a desconectar, relajarnos o directamente “sacarnos de la caja”.
  • El hecho de cuán interesante o aburrida sea la tarea constituye un factor importante a la hora de que nuestra mente esté buscando activamente distraerse, y que el aburrimiento provoque no solo que nos distraigamos sino que distraigamos a otros.

Libros que nos han marcado

En esta sesión hablamos de diversos tipos de fuentes de inspiración:

  • Libros de teoría y arquitectura de software o de gestión de equipos de desarrollo, entre los que están Extreme Programming, Scrum from the trences, Refactoring, Clean Code, Clean Architecture, Design Patterns, POSA, Documenting Software Architecture, The Pragmatic Programmer…
  • Libros y ejercicios prácticos como Learn You a Haskell for Great Good!, Go by Example o las Ruby Koans que son ejercicios prácticos que te obligan a terminar un código para aprender a usar el lenguaje.
  • Podcasts como Software Engineering Daily o Agile in 3 Minutes

Y ahora qué?

Seguir leyendo, seguir escribiendo y tener siempre presente una frase compartida en la sesión sobre motivación de equipo que decía: todo lo que has aprendido es inútil si no lo usas, y estéril si no lo compartes.

De momento, comparto, con la intención de usar los conocimientos aprendidos.

¡Gracias a la organización por hacer este evento posible!

18. Echando la vista atrás

Hace más de 7 meses desde mi última entrada en este blog, y no ha pasado mes en el que me diga “debería escribir más”, y siempre he encontrado excusas interesantes para no escribir, pero sobre todo, y la más importante, es que he tenido relativamente poco que compartir. Pero no podía dejar de hacer balance un año más de cosas que han pasado y poner un la vista en lo que queda por venir, así que aquí va mi retrospectiva.

En el ámbito profesional ha sido verdaderamente intenso, análisis de requisitos, diseño de arquitecturas, alineamientos con equipos de todas partes del mundo (a horas intempestivas tanto para los que trabajamos en GMT+1 como para los de otras zonas horarias), muchísimo código en Java 8, JavaScript y Kotlin, incontables líneas de test unitarios, de integración, de carga, varias horas de presentaciones ante compañeros, unas sesenta horas entre aviones y aeropuertos entre España, USA y el Reino Unido, muchos litros de café y de tinta tomando notas.

Siguiendo con el gremio pero fuera de “horas de oficina”, este año me perdí la BilboStack, con entrada, vuelo y hotel comprados :(, (este año lo intentaremos otra vez) aunque sí que me pude dejar caer por la MindCamp, a la Pamplona SW Craftmanship, a WeCode y LechazoConf en Valladolid, y a DotNet 2018, donde tuve la oportunidad de volver a ver a algunos amigos y compañeros de batallas. Entre otros eventos memorables, pude ver en directo a Martin Fowler hablando, entre otras cosas, de la importancia de la entrega continua, el valor de los tests, y cómo se podía implementar entrega continua en productos existentes (este habría sido un buen candidato para escribir del tema).

Algunos de los que me leéis sabréis que tengo la suerte de compartir profesión y pasión por la tecnología con mi madre, y que en algunos eventos yo me presento como “el hijo de Ana” y en otros ella se presenta como “la madre de Rober”. Este año he visto con el orgullo que solo un hijo puede ver como Microsoft le reconocían sus méritos a la comunidad al nombrarla Most Valuable Professional (MVP).

Para aquellos que no os suene, es un reconocimiento que entrega Microsoft a profesionales que hagan aportaciones significativas a la comunidad, como eventos, ayuda en los foros, artículos en blogs o revistas, contribuciones de código a proyectos Open Source… Ana lleva desde hace más de quince años formando parte de diversas comunidades relacionadas con tecnologías Microsoft, desde FoxPro, SQL y ahora Power BI. Como testigo de esa evolución, y de su capacidad de reinventarse, es todo un reconocimiento a tantos años de trabajo y dedicación a la comunidad.

En el ámbito deportivo, este año ha habido obligaciones profesionales y familiares que me han brindado una excelente excusa para no hacer más deporte, aunque he hecho un esfuerzo por acabar el año haciendo más kilómetros. De acuerdo con Endomondo en 2017 corrí entre calle y cinta unos 249 km, este año 267, un poco más que el año anterior, pero menos de lo que habría querido. Este año sin embargo me ha traído un éxito en parte inesperado, que ha sido un récord personal de 58:32 en la San Silvestre Vallecana el 31 de diciembre, superando la barrera de una hora que llevaba un par de años intentando conseguir.

Volviendo al blog, he escrito cuatro artículos, dos relacionados con AWS en mi intención de aprender para examinarme de Solutions Architect, un tercero como revisión del libro “The Phonenix Project” y el resumen de 2017. Es el segundo año consecutivo que escribo menos de un artículo al mes, lejos de aquel año 2014 en el que este blog cosechó 60 entradas, más de una semanal.

Finalmente, respecto a los objetivos fijados el pasado año, este año no he sido capaz de cumplir ninguno de ellos, así que listarlos parece un poco repetitivo.

Dicho lo cual, este año voy a listar no tanto objetivos específicos sino ciertos hábitos que estoy intentando incorporar en mi vida diaria.

  1. Conseguir concentrarme en bloques de, al menos, 15 minutos: Tras leer técnicas como Pomodoro, que hablan de fijar bloques para tareas de unos 25 minutos, o libros como Deep Work donde recomiendan bloques más largos de varias horas, creo que 2019 será un año para poner estos métodos en práctica, Leí recientemente este artículo How to Multitask Without Breaking Your Brain – Member Feature Stories – Medium y me llamó mucho la atención la idea de mantener la concentración durante al menos 15 minutos antes de cambiar de actividad, llevo unos días usándolo y es sorprendentemente poderoso.

  2. Correr cada semana: Había pensado originalmente en fijar algo así como “correr 500 km, pero el truco está en buscar el hábito de correr semanalmente, y que no sea algo puntual antes de cada carrera. Idealmente quiero estirar la cantidad de kilómetros que hago en cada sesión y reducir el ritmo cardiaco, para poder preparar mayores distancias sin que el cuerpo sufra demasiado.

  3. Mejorar mi organización: Me encantan las listas de tareas y los diferentes sistemas de organización, mi favorito sigue siendo GTD ya que me permite tenerlo todo en un único lugar, aunque en 2018 he vuelto a utilizar Bullet Journal para tomar notas en papel de reuniones, ideas, tareas que van surgiendo y otras. En este año quiero agregar el hábito de la revisión semanal que propone GTD para mantener tareas y proyectos al día.

  4. Desconectar activamente: Buscar o potenciar hobbies para mantener ocupado el cerebro cuando no estoy trabajando. Montar legos, tocar el piano, pintar, escribir, correr, o todas las anteriores.

  5. Agregar a mi rutina diaria más tiempo para leer: La combinación de Audible + Correr es increíblemente motivadora para ponerme al día con libros de acción como la saga de “The Gray Man” de Mark Greaney, aunque la literatura técnica, ya sea relacionada con el software, el trabajo corporativo o el mundo de los negocios, es más conveniente leerlas más que escucharlas. En un mundo donde hay cientos de artículos en medium de cualquier tema, sigo prefiriendo la estructura y el orden de un buen libro (en papel o en Kindle), por ello, me gustaría dedicar unos 15 minutos al día para leer. Habrá días que pueda dedicar más, habrá días que pueda dedicar menos. Además como motivación adicional, quiero escribir en el blog acerca de los libros “de trabajo” que lea.

  6. Buscar activamente nuevas oportunidades para aprender y mantener conocimiento: Inscribirme en un examen de certificación para buscar una excusa para estudiar, asistir a un evento de una tecnología que no conozca, hacer un pet-project que involucre algún concepto relacionado con IA, construir mejores interfaces aprendiendo de mis compañeros de UX, aprender a escribir documentos técnicos pidiendo ayuda a compañeros más experimentados…, hay muchas maneras de seguir aprendiendo, mantener nuestros conocimientos y mejorar en lo que hacemos.

  7. Respirar: Vivimos en un mundo frenético, con múltiples estímulos que vienen en forma de e-mail, mensajería instantánea, nuestro jefe, nuestros compañeros, la familia, amigos, y obligaciones que muchas veces requieren una respuesta inmediata. En mi caso he vivido más de una vez cómo no tomar una bocanada de aire y soltarlo antes de responder ha dado como resultado una respuesta tosca, agresiva, defensiva o simplemente equivocada por no pararme a pensar en la pregunta. Para ello este 2019 pienso respirar más, sobre todo antes de hablar.

2019 se presenta como un año cargado de retos personales, profesionales y deportivos. Espero poder compartir parte de lo aprendido en este blog que lleva siendo mi casa en las nubes desde hace ya 10 años.

Feliz año nuevo.

Aprendiendo AWS: Nube privada Virtual o VPC

Desde hace ya unos días estoy empezando a preparar el examen de certificación de AWS Solutions Architect, y eso me permite aprender sobre los diferentes componentes que forman la plataforma cloud de Amazon. En este artículo veremos uno de los pilares de estos componentes, la nube privada virtual o VPC.

Hasta hace relativamente poco, mi idea era que en cualquier proveedor de nube, tenías máquinas virtuales y servicios, y podías realizar ciertos ajustes para detectar desde donde se puede acceder a tu instancia, y poco más. Uno de los componentes al que había prestado poco o nulo interés era el concepto de VPC (llamado también Virtual Network en Azure).

Básicamente una VPC nos permite crear nuestra propia topología de red en la nube como si tuviéramos nuestro propio CPD. Con topología nos referimos de la posibilidad de crear una red, diferentes subredes, decidir cómo se conectan entre ellas, cómo se conectan a internet, y a qué recursos tienen acceso.

Esto también nos permite tener diferentes recursos en diferentes subredes, y poder aplicar directivas de seguridad y control de acceso a nivel de subred, en vez de tener que aplicarlas a recursos individuales.

Cuando gestionamos redes privadas en AWS podemos hacer uso de diferentes componentes, entre los que destacan:

  • Subnets: Permiten aislar varios recursos dentro de la misma VPC (i.e. Servidor Web, Base de datos)
  • Internet Gateway: Necesaria para que una VPC pueda acceder a internet.
  • Elastic IP Address: Necesaria para poder servir tráfico a internet desde nuestra VPC. Podemos tener direcciones IP elásticas asociadas a una VPC o a un recurso específico (una instancia de EC2, por ejemplo).
  • Route Tables: Permiten definir una tabla de origen y destino, y direccionar el tráfico que proviene de una subred tanto a la red interna o al Internet Gateway, para dar acceso a internet.
  • Security Groups: Asociado a una instancia, permite establecer que rango de IPs puede acceder a puertos específicos. Por ejemplo, un servidor web puede permitir tráfico entrante para todo internet en el puerto 80, pero sin embargo limitar el tráfico de conexiones SSH (puerto 22) a máquinas específicas.
  • NAT Gateway / NAT Instance: Permiten que una subred tenga acceso a internet y limitar el acceso a la misma desde internet. Se puede configurar como servicio o manualmente utilizando una máquina virtual dedicada.

Recursos