Cómo me gano la vida (2017)
Intro
Este post es una continuación de Cómo me gano la vida que explica como me ganaba la vida en 2009.
En el medio me la gané de otras dos maneras distintas, pero no entremos en detalles, porque este post es sobre cómo me la gano ahora. Me parece interesante contarlo porque hablando en eventos con gente más joven o estudiantes, muchas veces no tienen idea de como funciona una empresa de software. Y si vas a laburar en esto, está bueno saberlo.
Antes que nada: mi trabajo oficialmente es "Software Architect" en Onapsis una empresa que hace software. Exactamente qué software y cosas así las podés ver en la página de la empresa, y hace exactamente ninguna diferencia con respecto a lo que voy a describir.
¿Qué se supone que hace un "Software Architect"?
Un software architect es un experto en software que toma decisiones de diseño de alto nivel y dicta standards técnicos, incluyendo standards de código, herramientas y plataformas.
Gracias Wikipedia! Bueno, no está mal como descripción de lo que hago en este momento. Si bien, seamos honestos, no es que uno tiene que decidir plataformas o herramientas todos los días, así que en realidad mi tiempo se llena de una manera ligeramente distinta.
Consultoría interna
Como se supone que soy un experto (más al respecto más adelante) soy una especie de último recurso. Si te trabás mucho con algo, rompé el vidrio y hablá con Roberto. Para mí es una de las cosas más importantes. No soy un desarrollador espectacular, pero he visto cosas y no me molesta que la gente me hable. Entonces a veces laburo de patito de goma, a veces tengo alguna idea de por adonde encararlo, a veces googleo, y a veces realmente sé lo que me están preguntando. Ocasionalmente esto lleva a una sesión informal de Pair Programming o a que adopte el problema como propio. Dado que soy finito (en espacio y tiempo, no de ancho) esta última opción no escala y se usa lo menos posible.
Prototipado
La etapa más complicada de muchos proyectos es la primera semana. La primera semana es cuando convertís un repo vacío en algo que muestra indicios de poder convertirse, con transpiración, en lo que necesitás. Normalmente involucra una cantidad de "tanteo" y de pensar con los dedos borrar, tirar casi todo lo que se escribe, probar herramientas, etc.
Si te gustan esa clase de cosas, es muuuuy divertido. Si no te gusta, es horrible. Y es una de las áreas en las que haber hecho cosas parecidas antes garpa. Por eso la experiencia ayuda.
Tooling
Escribir software es una cosa. Hacer que se testee automáticamente, buildee, shipee, etc es otra muy distinta. Para poder hacer que tu programita llegue a los clientes necesitás hacer todo lo otro, y todo eso se hace (graciadió) con software que ya escribió otra gente. Entonces necesitamos elegir que software usar para todas esas cosas cuando surge un requerimiento nuevo. Y ahí pruebo, opino, y participo de elegirlo.
Capacitación
Cuando veo que los que trabajan conmigo no saben algo que creo que les sería útil, hablo con Recursos Humanos y armo un training. Tengo la enorme suerte de que la empresa en que trabajo dice siempre que sí a la capacitación!
Si sé sobre el tema: doy un training. Si no sé sobre el tema y parece que nadie sabe, lo aprendo y doy un training. Si no sé sobre el tema, y otro sabe, le pido que dé un training y voy al training.
Aprender
Y acá voy a declarar en contra de mis propios intereses. Se acuerdan que al principio decía que un software architect es un "experto en software" ... bueno. Les tengo buenas y malas noticias.
- La mala noticia: no sé si existe tal cosa.
- La buena noticia: eso quiere decir que en una de esas vos sos un experto!
El chiste es que nadie es experto en todo. Yo soy experto en algunas cosas. Pero no sabía nada de como hacer lenguajes. Ni de como hacer paquetes Debian. Ni un millón de otras cosas. Y a veces uno en el trabajo se cruza con cosas que sabe, pero el 70% del tiempo se cruza con cosas que uno no sabe. O por lo menos, en las que uno sabe poco, o sabe de verlas hace 5 años, o sabe lo que leyó en un blog el otro día. Uno puede ser experto en una cosa. O uno puede ser generalista. Pero no puede ser experto en todo. Y un arquitecto de software ... medio que sí? Recuerden que la incumbencia incluye "software", "herramientas", "prácticas", "diseño" ...
La diferencia que te hace un "experto" es como salís. Cuando encuentro algo que no sé, mi proceso es:
- Es algo que no sé, pero lo voy a ver todas las semanas?
Entonces lo aprendo. Agarro un libro, o la documentación, o lo que sea, y lo aprendo. Tengo la ventaja enorme de que en mi trabajo me puedo hacer tiempo para esto. Tener que hacerlo después de hora es desalentador. Aprendo lo suficiente como para poder tomar decisiones informadass / arreglarlo si se rompe / saber si está roto.
- Es algo que no sé, lo voy a ver todas las semanas, y me interesa?
Entonces lo voy a aprender aún en mi tiempo libre, porque me interesa. Y sí, después de un tiempo, voy a ser un experto en eso. Normalmente lleva a un training. Y si me gusta mucho, lleva a que escriba acá. O a que dé una conferencia. Algo va a salir.
- Es algo que no sé, pero lo voy a ver una vez al año?
Aprendo lo mínimo indispensable, y el año que viene veremos.
Hay muchas otras combinaciones, como "realmente quiero aprender eso, no sería mejor que lo hiciera otro, ok, listo, hacelo y escribime un reporte", o "es algo que veo que se hace todos los dias y quiero reemplazarlo con un script", pero no vienen tanto al caso.
Conclusiones
Entonces, resulta que la cosa que ayuda, en este laburo, es ser curioso. Ayuda absorber info rápido, ayuda tener ganas de probar cosas y romperlas, ayuda (mucho) que no te moleste hablar con gente, cosa que para mí tiene cierta historia conflictiva, ayuda que te guste contar lo que estás haciendo.
Y acá tienen, les estoy contando lo que estoy haciendo.