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.

Mentiras y Estadísticas, edición Martin Tetaz

Nota: No soy economista. Martín Tetaz sí. Si yo sé esto que escribo en esta nota, no les quepa duda que Martín Tetaz también lo sabe. La diferencia es que él prefiere no decirlo, por motivos que él sabrá.

Hace unos días el conocido economista Martín Tetaz dijo esto:

Y es, literalmente, cierto (de hecho, no sé si es cierto porque no me calenté en verificarlo, pero asumamos que lo es). Mas o menos. O sea, es cierto que CFK asumió con esa cantidad de deuda y se fué con esa cantidad de deuda. Hasta ahí es "cierto".

Hay algunos detalles, claro.

Primero: no son lo mismo 144.000 millones de dólares en 2007 que 144.000 millones de dólares en 2015. De hecho, 144.000 millones de dólares de 2007 son 167.500 millones de dólares de 2015. Porque el dólar pierde valor con el tiempo. Y esos 250.000 millones de 2015 son 214.853 millones de 2007.

O sea que si tenemos en cuenta algo tan básico como usar una vara constante para medir la deuda, ese aumento del 74% que dice Tetaz en realidad fué del 50%.

Por otro lado, esos 144.000 millones los debían 40 millones de personas (39,97 millones, para ser exactos), mientras que en 2015, esos 250.000 millones los debían 43,42 millones de personas.

Así que saquemos algunas cuentas. A valor constante:

Per cápita, en 2007, cada argentino debía 3602,70 dólares.

Per cápita, en 2015, cada argentino debía 4951,64 dólares.

O sea, si tomamos una medida un poquito mas razonable que peras con bananas, da que ese incremento en la deuda del 74% resulta ser en realidad más o menos 37%. O sea, la mitad.

Pero en realidad, para saber si una deuda es mucha o poca, importa la capacidad de pago. Si gano $1.000 y debo $5.000 es un montón. Pero si gano $100.000, $5.000 es una cena con amigos.

Y para países, eso se hace calculando la deuda como porcentaje del PBI. Y el PBI fue, en 2007, 287.500 millones de dólares. En 2015, fué de 584.700 millones de dólares. Eso no es a dólar constante, por lo que volvemos a los 250.000 millones de dólares de deuda en 2015.

Y resulta que medido como porcentaje del PBI, pasamos de deber 50% del PBI a deber el 42.7%.

O sea que la deuda, medida de la manera en que tiene sentido medirla, bajó un 15%

Y no hablemos de que cambió a quién le debíamos plata, porque eso es opinable, pero lo que sí está claro es que Tetaz sabe que lo que dijo lo dijo de manera tendenciosa. Porque si yo sé estas cosas, Tetaz también las sabe. La diferencia es que él no te las dice.

Trabajar Gratis no es Gratis, o Meritocracia mis Polainas.

A veces uno hace cosas gratis. Yo lo hago, vos lo hacés, todos lo hacemos. A veces esas cosas que hacemos gratis traen un pago por otro lado:

  • Te hacés conocido, y eso te permite obtener algo.
  • Te deben un favor, y te lo terminás cobrando.
  • Simplemente te sentís bien por hacer eso, gratis.

Pero siempre, siempre, siempre, alguien paga.

  • Paga el que te da exposición, dándotela.
  • Paga el que te debe el favor, devolviéndolo.

Pero cuando hacés algo gratis solamente porque te hace sentir bien hacerlo ... ¿quién lo paga? ¿Ese no es tan obvio, no? Si doy un curso gratis, si hago un programa open source, si pinto una escuela, si paseo al perro de un vecino, si te cuido a tu hijo... ¿quién paga?

Porque alguien siempre paga. En particular, siempre alguien paga si uno labura gratis. Si me quedo dos horas tarde sin pedir horas extra (cosa que no sucede), pago yo. Tal vez no enseguida, pero lo pago en no pasar esas dos horas con mi familia, o en no hacer algo que yo quería hacer.

Si hago un trabajo que normalmente se pagaría pero lo hago "de onda", lo paga el que no lo va a hacer cobrándolo. Si le hago un soft a alguien entonces ellos no se lo van a comprar a nadie.

Todo ese software open source que vos ves, flotando por la internet como si surgiera de una fuente inagotable de software gratis, está pagado, está pagado con los fines de semanas y las noches de un millón de desarrolladores que lo pagaron. Está pagado con las quiebras de miles de empresas de software que no existen más porque sus productos ahora son commodities.

Sí, probablemente valió la pena. Yo tal vez no iba a hacer nada más interesante en mis 20s y mis 30s, pero sabés qué, tal vez lo hubiera hecho. Tal vez hubiera tomado cosas que no tomé, viajado a lugares que no viajé, conocido gente que no conocí. A cambio, hay unos cuantos proyectos abandonados en Github y alguno que no.

Sí, por otro lado cobré, porque hace 17 años que cada trabajo que tengo en parte lo he conseguido por todo eso que hice "gratis".

Pero también se paga de otra manera: se paga en que se espera que pase. Se paga en que hoy en día por lo menos yo siempre busco que todo el software sea gratis. ¿Y qué pasaría si en 2025 nos damos cuenta que era todo una burbuja? ¿Qué hacemos si de golpe resulta que no, que esta manera de producir software no funciona? ¿Buscamos otra?

Se espera que hagas proyectos gratis para probar tu valor. Los posibles empleadores esperan poder ver un proyecto tuyo en Github, y yo soy culpable de decirle a pibes "hagan un proyecto, ayuda a conseguir laburo" ... ¡porque es cierto! ¡ayuda! Si hacés un proyecto con código no horrendo, medianamente organizado, etc. es casi fácil conseguir un puesto en alguna empresa.

Vamos de linkedin a toptal cargando nuestros proyectos igual que un aprendiz de herrero iba de un pueblo a otro con su yunque, que era su "masterpiece", lo que probaba que sabía lo que hacía.

Y, lo peor de todo, lo pagan los que no pueden tomarse sus 20s produciendo código "visible" para impresionar a sus futuros patrones. Trabajar gratis es un privilegio que tenemos algunos, y los que no pueden hacerlo arrancan en desventaja. Es como ser "meritorio judicial". Si podés trabajar gratis unos años (porque te bancan, o lo que sea) hacés eso, y te va a ser más fácil entrar al poder judicial. Y los que no pueden, bueno, no serán judiciales. O no tendrán la misma carrera en software.

Porque no tenían ese privilegio. Porque no pudieron tirar sus fines de semana en eso, o invertirlos en su futura carrera, o como quieras decirle.

Y después, claro, para los que reclutamos es muy fácil decir "claro, este muchacho mirá, tiene esto en GH, y esto otro, y participó acá, es groso" ... y nos compramos la idea de meritocracia, de que obviamente, estamos midiendo una cosa real, que un candidato la tiene y otro no, entonces no estamos discriminando. ¿Cómo podríamos estar discriminando si estamos midiendo cosas objetivas?

Y nos molestamos si alguna vez nos dicen que tal vez, que se yo, estamos discriminando contra los que no son como nosotros, contra los que no tenían libres las noches después de la facu para boludear con la compu, o contra los que empezaron a estudiar más tarde por lo que fuera y ya tenían un laburo, o contra las mujeres, o contra los de otra clase social, etc.

¿Nosotros? Que locura. Como que discriminamos nosotros. Nosotros somos racionales. Somos meritocráticos. Somos objetivos. Y sobre todo, somos buenísimos mintiéndonos.

Gyro 0.3

Gyro grows some legs

It was just a few days ago that I started an experimental wiki project called Gyro ... it's always fun when a project just grows features organically. It does this, so it makes sense to make it do that, and then this other thing is easy, and so on.

So, here is what happened with Gyro:

  • Federico Cingolani made it run on docker
  • I added some features:
    • UI for creating new pages
    • UI for deleting pages
    • Support for multilevel pages (so you can have "foo" and "foo/bar")
    • Autocompletion with titles in search
    • Breadcrumbs so you can actually follow the multilevel pages
    • Lots of code cleanup
    • Themes (via Bootswatch)
    • Custom fonts (via Google WebFonts)
    • Automatic linking for WikiWords if you like that kind of thing

And, I published it as a Google Chrome Extension ... so you can now have a wiki on your chrome. If you saw how it worked before, you may wonder how it became an extension, since those are pure Javascript. Well... I made it have pluggable backends, so it can either use the older Sanic-based python API or use LocalStorage and just save things inside your browser.

The behavior is identical in both cases, it's just a matter of where things are saved, and how they are retrieved. The goal is that you should not be able to tell apart one implementation from the other, but of course YMMV.

And since I was already doing a chrome extension ... how hard would it be to run it as an electron "desktop" app? Well, not very. In fact, there are no code changes at all. It's just a matter of packaging.

And then how about releasing it as a snap for Ubuntu? Well, easy too, just try snap install gyro --beta

All the Gyros

Is it finished? Of course not! A non exhaustive list of missing MVP features include:

  • Import / Export data
  • A syncing backend
  • General UI polish (widget focus, kbd shortcuts)
  • Better error handling
  • General testing

But in any case, it's nice to see an app take shape this fast and this painlessly.

New mini-project: Gyro

History

Facubatista: ralsina, yo, vos, cerveza, un local-wiki-server-hecho-en-un-solo-.py-con-interfaz-web en tres horas, pensalo

Facubatista: ralsina, you, me, beer, a local-wiki-server-done-in-one-.py-with-web-interface in three hours, think about it

/images/gyro-1.thumbnail.png

The next day.

So, I could not get together with Facu, but I did sort of write it, and it's Gyro. [1]

Technical Details

Gyro has two parts: a very simple backend, implemented using Sanic [2] which does a few things:

  • Serve static files out of _static/
  • Serve templated markdown out of pages/
  • Save markdown to pages/
  • Keep an index of file contents updated in _static/index.js

The other part is a webpage, implemnted using Bootstrap [3] and JQuery [4]. That page can:

  • Show markdown, using Showdown [5]
  • Edit markdown, using SimpleMDE [6]
  • Search in your pages using Lunr [7]

And that's it. Open the site on any URL that doesn't start with _static and contains only letters and numbers:

  • http://localhost:8000/MyPage : GOOD
  • http://localhost:8000/MyDir/MyPage: BAD
  • http://localhost:8000/__foobar__: BAD

At first the page will be sort of empty, but if you edit it and save it, it won't be empty anymore. You can link to other pages (even ones you have not created) using the standard markdown syntax: [go to FooBar](FooBar)

There is really not much else to say about it, if you try it and find bugs, file an issue and as usual patches are welcome.


[1] Why Gyro? Gyros are delicious fast food. Wiki means quick. Also, I like Gyros. to check it out. So, since this was a toy project, why not?
[2] Why Sanic? Ever since Alejandro Lozanoff mentioned a flask-like framework done with the intention to be fast and async I wanted
[3] Why bootstrap? I know more or less what it does, and the resulting page is not totally horrible.
[4] Why JQuery? It's easy, small and I sort of know how it works.
[5] Why Showdown? It's sort of the standard to show markdown on the web.
[6] Why SimpleMDE? It looks and works awesome!
[7] Why Lunr? It works and is smaller than Tipue which is the only other similar thing I know.

La Importancia de los Dedos en el Pensamiento Informático

Pensar con cosas que no sean el cerebro es descalificatorio: vos pensás con el culo, vos pensás con el pene. Es una variante de hacer cualquier cosa con la parte incorrecta del cuerpo, porque yo escribo con los codos, ella programa con las patas, etc. Tal vez por eso me siento incómodo cuando empiezo un proyecto nuevo, porque siento una picazón indecente de empezar a pegarle a las teclas con las yemas, como si las ideas de como implementar cosas no salieran de mi cabeza, como si brotaran de mis dedos, como si fluyeran por mis brazos, como Palpatine electrocutando a Darth Vader, con esa prepotencia Arltiana de no poder conversar sino tipear en orgullosa soledad programas que encierren la violencia de un cross a la mandíbula, y "que los eunucos bufen".

Y no, no es la manera ideal de hacer las cosas, sospecho, en el mismo sentido que chapar en la primera cita o tocar ese culo consentido en el primer lento de Air Supply fueron decisiones que parecieron buenas en el momento pero muchos hemos vivido para lamentar, pensar demasiado con los dedos produce código de mierda, como era de mierda el noviazgo que empezó en aquel asalto, pero es realmente código de mierda si es código que existe comparado con el teórico noviazgo con la chica que no quiso bailar con uno? No, es código copado, es código gauchito, es código con savoir faire.

Pensar demasiado es someterse al waterfall interior, que es el peor waterfall, y sí, a veces he pensado un programa muy lentamente durante cinco años, dejándolo madurar en mi interior como una Tahina spectabilis que florece cada cien años, pero recuerden que la flor que produce huele como un cadáver y la planta muere inmediatamente. Los proyectos maduros son proyectos pudriéndose, es un equilibrio fino que no cualquiera puede caminar, no somos todos Philippe Petit, no sabemos cruzar de una torre a la otra sobre una soga, nos caemos como King Kong, trepados a una torre que no entendemos pensando en Jessica Lange.

La programación no es prog rock, no es Lark Tongues in Aspic, programar es, el 90% del tiempo, los mismos cuatro acordes de Sheena is a Punk Rocker, cambiados de lugar, más rápido o más lento, mientras hacés temas de dos minutos porque tu papá no te quiso cuando eras chico, es recordar que el primero se tira, como el mate, que el primero te lo regalan el segundo te lo venden, que por eso el primero lo regalás, el segundo lo hacés bonito y lo regalás también, que carajo.

Y mientras tanto, escuchen "Como salvajes" de Attaque 77, que dura tres minutos, te da ganas de salir a patear bolsas de basura por la calle, y es un cuento de scifi medianamente decente, no perfecto, pero mucho mejor que el que no escribiste.

Changes in this blog

I have made a few changes in how this blog is generated and what features are enabled.

Similarity Plugin

I have enabled the similarity plugin and disabled the equivalent feature provided by Disqus. In general, it seems this plugin produces more whimsical connections which is a big plus. It may lead you to discover very random things I wrote. I know it reminded me of things I did not remember writing!

Continuous Import

I have enabled the continuous import plugin which will automatically merge some other aspects of my online presence with this blog. Currently it has support for goodreads (which I already mentioned before) and youtube (which I have not), so you will see short book reviews and random videos I make.

Examples: goodreads and youtube

This plugin can theoretically support anything that provides a RSS/Atom feed and lets you apply custom templates to the content so you end up with pretty posts in all cases. If you are interested in using it for some other service, feel free to ask me about it.

Front Page

For the first time ever, the front page of this site is no longer the blog, but a landing page.

Theme

At some point in the future I may switch to a more customized theme, but that's not in any specific roadmap, it will happen when it happens. In the meantime, this is now using the Lumen bootswatch and am experimenting with using FlowType for a more readable automatic font size.

I am now using almost an IDE

I have long been a proponent of simple text editors.

Not for me was emacs, with its multitude of modes and magical elisp code to do everything.

Not even vim with its multitude of extensions achieving magical productivity with three keystrokes.

Not even would I use the ubiquitous jetbrains IDE with magic refactoring that writes code on its own.

No, for twenty years or so I have written my code using a plain text editor. Until recently, that meant kwrite. Not even kate. Kwrite, the one that is slightly more powerful than notepad.

But then I got a new job, and everyone uses an IDE so I started thinking... I must be missing something.

Because if everyone is doing it differently from you, then one of the following things is likely to be true:

  • everyone is wrong
  • it's purely an opinion thing and it doesn't matter much
  • you are missing out

You know you are old once you assume the first. Since I am going through some sort of weird mid life crisis I am forcing myself to choose the last option most of the time. So, I started trying out stuff. Which is why I no longer use bash. Or unity. Or KDE. But those are stories for some other bonfire, this one is about my text editor midlife crisis.

Atom

It's huge. And slow. Like, really slow. And the extension quality is very uneven. For example, all the terminals felt wrong.

Once it started dragging after being open for a couple of days... well, I removed it and smugly went back to my old workflow.

And then I tried...

Pycharm

The extension quality was soooo much better! And some are just awesome. The way you can choose a virtualenv interpreter for a project is awesome.

Compared to Atom it's downright snappy!

The only things I did not like were:

  • So much magic in place, sometimes things only worked in the IDE.
  • Too slow to start, so I still had to use a plain text editor for casual edits.
  • At one point, things started to rot, and functions that had been working fine started to misbehave.

So then I had my goldielocks moment...

VSCode

I was expecting to hate it. It's called Visual Studio! It comes from Microsoft! It's electron-based like Atom!

Yet, I loved it at first sight.

Not going to go over many details because I am not in the business of convincing people of things but here are some of the highlights:

  • Good python support, including virtualenvs, formatting, autocomplete, refactoring, debugger, etc.
  • Good Go support.
  • Nice terminal gadget! Ctrl+click to open files mentioned in the terminal!
  • Good markdown/reSt support including previews
  • The "compared to working tree" view is genious
  • If you run "vscode somefile" in the terminal, it opens in the current vscode.
  • The settings mechanism and UX are a great idea.
  • It's fast enough
  • The UI is fairly minimal, so most of the time it will look like my previous workflow used to look: two text files open side by side.
  • Test runner integration is neat.
  • In Ubuntu you can install it as snap install vscode --classic ... takes all of 30 seconds. And it's updated forever.
  • Lots and lots and lots of decent quality extensions.

So, all in all it does all the things I liked from the IDE side of the universe while not making the things I liked from text editors less convenient. And that's why I use it now.

Cumulus

  • Author: Eliot Peper
  • Rating:
  • See in goodreads
  • Review:

    So, Alphabet owns Uber and they are actually Waymos. And Alphabet is owned by this daughter of chinese immigrants that likes basketball, and Steph Curry is a druglord. More or less that's the idea. Not really my cup of tea, but not horrible by any means.