Lo que aprendí en el día 1 de la Starsconf 2017 SCL

Hoy asistí al evento Starsconf en la cual se tocaron muuuchos temas interesantes relacionados al mundo de la tecnología (UX, Programación, DevOps, Metodologías, etc etc etc).

Si bien en algunas charlas tuve expectativas más altas, aprendí mucho de cada exposición 👍

Si no tuviste la oportunidad de ir, o si fuiste y quieres un resumen, continúa leyendo 😉 ya que es precisamente de lo que se trata este post.

1) Technical Diagramming: From Doodles to Data Flows

You learn when you teach — Una Kravets

Cuando utilizamos librerías, muchas veces nos enfrentamos a documentación compleja, en la cual no paramos de ver cosas como “y es así de simple” (haciéndonos sentir algo tontos 😅).

Una nos expone que hay otras formas de enseñar que son más didacticas y fáciles de digerir por nuestro cerebro, como el uso de Doodles y Diagramas de flujo:

Y nos deja la invitación abierta a que compartamos lo que vamos aprendiendo (por eso estoy escribiendo esto 😄)

2) Microsoft’s Agile Transformation Story

Technical debt is like finantial debt — Donovan Brown

Espectacular la historia de cómo pasaron de releases 3 años (para producto mediocre) a releases más continuos de 3 semanas (para un producto excelente).

Si bien esta transformación fue fenomenal, me quedaron dando vuelta los siguientes insights:

• Antes de agregar nuevas funcionalidades, debes solucionar los bugs o mejorar aquel código que cuando lo escribiste pensaste “esto podría haber sido hecho mejor”. Cada vez que postergas incluir mejoras de calidad, estás acumulando una deuda técnica que tarde o temprano va a explotar en tu cara 😅
• ¿Eres desarrollador o Ingeniero? Si prefieres levantarte a las 3am para corregir un problema en vez de escribir testing unitario, entonces eres desarrollador.
• ¿Cómo comenzar a aplicar testing? Cada vez que encuentras un bug, haz un test que lo reproduzca (haz que falle y soluciónalo). No gastes tiempo en agregar tests para todo el código que no has testeado.

3) De Chile a Silicon Valley: Mitos, realidades y desafíos

Buscar inversionistas en Silicon Valley es un juego de números — Alvaro Echeverría

Latino, moreno, en un país como USA, con inglés de colegio municipal… aún con todo esto, Alvaro fue capaz de levantar capital para su startup SimpleRoute. No fue fácil, ya que para sus primeros 2 “sí”, hubo 100 otros “no”.

¿Qué pasa si hubiese “tirado la toalla” al décimo “no”? Lo cual me recuerda a …

4) VR/AR en Dispositivos Móviles

Chihau Chau nos expuso sobre Realidad virtual y Realidad aumentada, y nos presentó muy buenos ejemplos de lo que es posible realizar gracias a esta tecnología (hizo hasta un guitarra eléctrica y lentes de VR con cartón!!)

En particular encontré genial uno de los videos que mostró, en los cuales podemos utilizar AR para ver cómo se vería un mueble (como un sillón o un ropero) en nuestra casa.

Además, nos dejó la invitación abierta para dudas de proyectos propios sobre la temática.

5) ¿Sabemos por qué estamos Desarrollando Software?

Esta temática me encanta 😃 @Agustin Villena reflexiona sobre el por qué estamos desarrollando software… y no es sólo para escribir líneas (y producir bugs 😂)

Estamos desarrollando para solucionar problemas reales, para agregar valor a las personas y a las organizaciones.

Muchas veces perdemos el “norte”, de aquello que queremos solucionar y nos centramos en las features.

Antes de hacer cualquier cosa, debemos pensar en aquello que queremos lograr y en cuánto queremos mejorarlo (aumentar ventas? reducir costos?).

Teniendo claro el norte (a dónde queremos llegar) hay muchas soluciones posibles que nos llevan a dicho destino, y el software puede ser una de ellas.

El software es caro (recursos, esfuerzo, etc), por lo que los resultados que debemos mejorar deben ser considerablemente buenos para que la inversión de pague.

6) Haciendo visible lo invisible — Experiencias únicas para una cultura organizacional saludable

Esta presentación me pareció más publicidad para trabajar en Globant que otra cosa… sin embargo, hay cosas que rescato 👍

¿Cómo pasaron de ser una empresa de 4 personas a una de 6.500? Haciendo las cosas diferentes. Por allá en los años 2000s las empresas de desarrollo de software en Argentina eran muy locales, pero Globant logró posicionarse internacionalmente, teniendo su primer cliente en USA.

Al 5to año, se preguntaron sobre los principios y valores que los caracterizaban como empresa… y pudieron crear un sistema de evaluación entre pares que potenciaran dichos valores. Al día de hoy, esto evolucionó a aplicaciones móviles gamificadas (starmeup).

(Un claro ejemplo de la importancia de alinear el why de una empresa con el why de cada uno de sus integrantes… aunque insisto, me pareció una presentación más de publicidad para trabajar en Globant que otra cosa).

7) La importancia del Why en el diseño de productos

No hay nada más improductivo que producir algo eficiente que nadie usa

Yeah… cuando hacemos productos, debemos ir centrándonos en aquello que realmente importa.

Para esto, utilizaron una variación del Golden Circle de Simon Sinek, en la cual cada posible decisión pasa por el siguiente cuestionamiento:

¿Por qué? → ¿Cómo? → ¿Qué?

Ejemplo:

Gracias a estar 3 preguntas, se dieron cuenta que “optimizar la cantidad de registros” no les ayudaba a mejorar su métrica de “ser dueños de su propio tráfico”, ya que el engagement de los usuarios registrados era bajo (en palabras simples, se registraban pero no usaban la app):

• Why → ser dueños de nuestro propio tráfico
• How → aumentando la cantidad de “bookmarks” de los usuarios registrados
• What → mejorando la UX

PD: No se dijo explícitamente en la presentación, pero supongo que a mayor bookmarks mayor engagement, y a mayor engagement mayor boca a boca, y con ello mayor cantidad de usuarios referidos en la página (y menos provenientes de Facebook y Google → tráfico pagado).

8) Lightning Talks

1. Hay más cosas que programar… lee libros, estudia, lee “De animales a dioses”. Ten vida 🏃 !
2. Participa en SoCraTes (por desarrollo de software de calidad)! Y plz, usa TDD
3. Piensa bien antes de usar un Framework web… considera todos los factores!
4. Sonda… también usa agile.
5. La creación de software no es un proceso estandarizado de fábrica, dejemos de llamarle “factories” a las agencias digitales y rompamos con ese paradigma.

9) Pragmatic Internal Software Quality

Dado que:

• El cambio es difícil de anticipar
• Las arquitecturas de software han sido históricamente difícil de cambiar

Se hace muy difícil y costoso reaccionar al cambio… sobre todo a nivel de arquitectura.

No podemos hacer mucho para anticipar, ya que no contamos con bolas de cristal 🔮. Lo que sí podemos hacer es construir software cuya arquitectura sea construida de manera incremental y que sea fácil de cambiar. Esto es el principio de “Evolutionary Architecture”

Durante la presentación, también se reforzaron principios relacionados a “Continuos delivery” (en cualquier momento, podemos llevar código a producción), “Continuous Design” (diseñar nuestros sistemas mientras vamos desarrollando en vez de diseñar la totalidad del sistema en un comienzo), “TDD” (test-driven-development, escribir tests antes de la funcionalidad).

10) Onboarding: The Ecosystem, Not the Afterthought

La charla estaba totalmente centrada al Onboarding de trabajadores nuevos a las empresas.

El Onboarding es un proceso que parte desde cuando un postulante presenta cierto interés en comenzar a trabajar hasta que ya no se siente taaan nuevo.

La mayoría de las empresas buscan por postulantes que tengan un conjunto de skills (“conocimientos en mysql, php, js, título universitario”) en vez de un perfil basado en resultados (“ser capaz de trabajar en múltiples proyectos a la vez”).

Cuando nos basamos en “perfomance profiles”, nos aseguramos de contratar a la persona correcta para la posición correcta (lo cual a su vez mejora la retención, y los resultados que puede lograr).

Palabras finales

Gracias a StarsConf por organizar este evento que nos entregó tanto valor a la comunidad de tecnología en Chile! 😄 y también al esfuerzo de los speakers por transmitirnos aquellos conceptos que han aprendido con esfuerzo, estudio y sudor.

Para finalizar, un listado de los consejos accionables del día 1 del evento:

• Enseña lo que aprendes! (documenta tu aprendizaje, y compártelo)
• Comienza a testear tu código. Parte testeando los bugs que tienes que resolver, primero haz un test para reproducirlo y luego modifica el código para corregirlo.
• Ante un requerimiento, asegúrate de comprender bien la problemática antes de comenzar a escribir código (pregunta muchas veces “por qué” para llegar hasta la raíz del problema).
• Define bien lo que quieres lograr antes de comenzar a trabajar.
• Usa TDD.
• Escribe código que sea fácil de modificar!