Colas Techos y Lluvia

El otro día, un compañero de laburo sacó una foto y puso este tweet:

Ya había visto otros parecidos antes, así que me pareció una cosa interesante para analizar un cacho, porque para eso uno es nerd, vio?

En breve, la intriga es:

Habiendo cien metros de techo, por qué la gente hace cola para el lado de la calle?

Creo que el motivo principal por el cual sorprende que esto pase es que tiene una solución obvia, no? Hay que hacer cola para el otro lado. Esa es la mirada ingenua del que va por la otra vereda y los ve ahí parados mientras esperan el colectivo.

También hay otras soluciones ingenuas: usen taxi. Vayan en auto. Quédense en su casa que andar en bondi es un embole. Vayan a tomar un café hasta que escampe si está feo.

Esas "soluciones" también evitan que se mojen esperando el colectivo o esperen en la rampa, no? Entonces por qué no se usan?

La respuesta es que tienen un costo. Cada una de esas "soluciones" implica un costo monetario o de oportunidad, entonces entendemos que la gente va a hacer cola para el colectivo, a pesar de tener soluciones perfectamente razonables a su alcance.

Pero cambiar de lado la cola no tiene costo! O si?

Bueno, sí, tiene un costo! Alguien que llega y está décimo y quiere cambiar la dirección de la fila como lo haría? Necesita convencer a los nueve que tiene adelante de que cambien y vayan al otro lado. Convencer a un grupo de extraños en la calle es generalmente una actividad desagradable e ingrata, por no decir ligeramente peligrosa. Eso es un costo. Entonces el que llega décimo tal vez prefiera no tomarse la molestia y quedarse un par de minutos del lado "equivocado", a menos que llueva mucho, o algo así.

Pero entonces, por qué la fila no se hace al revés desde un principio? De esa manera no habría que pagar ese costo para reordenarla!

Porque hacer la cola de esa manera tiene un costo para los que llegan primero y ellos prefieren hacerla de la manera que se ve en la foto.

Si no hay nadie haciendo cola, obviamente me voy a parar en el punto donde para el colectivo mirando para el lado de donde viene (la derecha en la foto).

Si soy el segundo que llega y hay alguien parado esperando el colectivo mirando hacia la derecha, donde me voy a parar? Adelante de él? No, porque me va a decir que me estoy colando en la fila! Me voy a parar atrás de él.

Si soy el tercero y veo dos personas haciendo cola mirando hacia la derecha, donde me voy a parar? Detras de los dos, para que no me digan que me estoy colando. Y ya está. Tres personas mirando a la derecha son una cola que crece del lado que hay poco techo y donde está la rampa de acceso.

Según esa foto, las primeras siete personas no ganan nada haciendo fila hacia la derecha y pierden algo (hacen la fila mirando hacia atrás o no pueden ver cuando llega el colectivo, por ejemplo).

Esperar que los que llegan después paguen el costo de rotar la fila es donde está el verdadero problema, porque pone el costo sobre las espaldas de unos y no de otros, de esa manera creando una desigualdad. Y en esa foto, las personas en los puestos octavo y posteriores simplemente eligieron no hacerlo.

Y cuál es la solución?

La solución es poner la parada al principio de la cuadra, no al final. Y asumir que los demás son idiotas es parte del problema.

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.

Run Program

  • Author: Scott Meyer
  • Rating:
  • See in goodreads
  • Review:

    I wanted to love this book like I love the author's previous ones. But I could not.

    It's probably me, not him, since I am having a hard time finishing books lately, which means I am sort of forcing it. So, don't worry Scott!

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.