El consejo es también valioso para quienes planeen hacer un doctorado en Chile, pero hay una pequeña diferencia: Puedes conocer a los profesores antes de postular. Eso es difícil con profesores que trabajan afuera.

No voy a describir qué requisitos tienes que cumplir para postular. Varían de universidad a universidad, y es fácil de googlear.

Estos consejos no es una lista de requisitos, sino que consejos a nivel general.

El resumen de este ensayo es muy directo: Los alumnos aceptados son los que tienen credibilidad.

Nunca te van a aceptar porque sólo porque tienes buenas notas, porque tu tesis está bien escrita o porque hayas hecho muy buenas respuestas en su formulario de postulación. Ninguna de esas cosas por sí sola genera credibilidad.

Hay 3 maneras de generar credibilidad.

Papers

Un doctorado es una posición de trabajo. Las universidades aceptan alumnos no porque sean inteligentes, agradables o muy emocionados por ir a esa universidad. La universidad acepta alumnos por su capacidad de hacer investigación.

Cuál es la credibilidad de un postulante que nunca ha hecho investigación? Ninguna.

La mejor manera de tener credibilidad es teniendo un paper publicado. Esto significa que has hecho investigación, y que ha sido de suficiente calidad como para que otra gente lo publique. Es decir, otra gente ya te dio credibilidad.

Pero los papers no es la única manera. Necesitas mostrar que puedes hacer investigación, y no necesariamente siempre implica papers.

Hay que mostrar tu trabajo de investigación, entre más mejor. Las investigaciones con malos resultados también generan credibilidad (todos los profesores también tuvieron malos resultados en sus propios proyectos), o proyectos novedosos pero no necesariamente tienen que ser en formato de una publicación.

Lo que sí es importante, es dar fuentes externas para mostrar este trabajo. Idealmente, tienes un link en donde se pueda encontrar más información de tus proyectos que mencionas. Si no tienes eso, también puede ser útil (pero en menor medida) mencionar con mucho detalle con quienes trabajaste y explícitamente en qué. Los detalles son importantes. En los detalles está la credibilidad.

Relaciones personales

Muchos candidatos aceptados a un doctorado ya conocían a gente cercana al profesor al que postularon.

Esto es muy razonable. Si el profesor leyendo tu postulación le puede preguntar a sus conocidos acerca de ti. Tiene una manera directa de confirmar lo que dices y quién eres. No existe ninguna respuesta en un formulario que sea más confiable que el juicio de un conocido.

Esto es más fácil de lo que suena. Hacer investigación no es sólo hacer experimentos, sino que es difundir los resultados y conocimiento que tiene. En este proceso, es inevitable que conozcas gente del área que te interesa investigar. Naturalmente vas a conocer personas que tu profesor al que postulas también conoce.

Algo importante es que este proceso de conocer gente no tiene que ser forzado. Si te interesa la investigación de una persona es muy bueno hablarle y comentarlo.

En cambio, si te interesa una persona sólo por quiénes conoce, eso daña gravemente tu credibilidad. El falso interés se nota a kilómetros. No lo intentes.

Por lástima en Chile estamos en la punta del mundo, y resulta difícil conocer a muchos de los autores de las investigaciones que nos interesa. La mejor solución es saliendo de Chile, a conferencias, charlas y eventos. Obviamente, eso implica un costo económico no menor. Muchas universidades tienen fondos para asistir, y recomiendo postular (es más factible ganárselo de lo que parece). Aún sin tener fondos de tu universidad, es importante pensar estos viajes como una inversión y aceptar el costo. Nacen más oportunidades de las que uno se imagina.

Todo el resto

Es trampa poner “todo el resto” como el tercer punto, pero es la verdad.

Al generar credibilidad, es importante que no hayan red flags. Esto abarca todo el rango posibles cosas que podrían afectar tu postulación.

Tener malas notas, escribir una mala tesis o hacer malas respuestas en los formularios son pequeños red flags. Levantan preguntas como: Por qué esta persona tiene buena investigación, pero malas notas? Lo grave no es la pregunta, sino que no hay respuesta. Puede que haya una explicación muy razonable, pero la persona leyendo la postulación no tiene cómo saber.

La manera ideal de evitar estas preguntas sin respuestas es evitando que se levante la pregunta en primer lugar. Dedica mucho tiempo a escribir muy bien tu postulación, y que no salten dudas al leer tus respuestas.

De todas maneras, no podemos predecir las preguntas que podrían surgir al leer nuestra postulación. Si esas personas pueden preguntarle a alguien de su confianza al respecto, sabemos que esas preguntas van a tener una respuesta. Por eso es importante conocer gente.

De igual manera, las cartas de recomendación tienen que ser consistentes con tu postulación. Elige personas que te realmente te conocen, y que te hayan visto dedicarte a investigación.

Elegir un profesor que no te conoce sólo porque tiene renombre, no vale la pena.

Un muy buen tip que leí una vez decía que es malo preguntarle a alguien:

“Me puedes escribir una carta de recomendación?”

Esta pregunta no dice cómo debiera ser la carta de recomendación. Puede que esa persona tenga un template preparado, y que simplemente rellene tu nombre.

En cambio, lo que se proponía preguntar es:

“Me puedes escribir una carta de recomendación exageradamente buena?”

Si no sientes la confianza de preguntarle a alguien esta pregunta, es poco probable que su carta de recomendación hubiera sido buena de todas maneras.

Esta pregunta comunica que realmente te importa lo que ellos escriban. Te importe porque… es verdad. Las carta de recomendación son importantes, y es bueno dar a entender esto es algo que te afecta.

El resumen de todo el consejo es que: Los alumnos aceptados son los que tienen credibilidad.

Por qué este consejo es particularmente para gente en Chile? Nosotros estamos empezando con las chances en nuestra contra.

Casi nadie conoce la investigación que se hace en Chile. Casi nadie conoce universidades chilenas. Casi nadie conoce Chile.

Por qué un profesor te tendría que aceptar a ti, y no al alumno de China/EEUU/Francia/etc? Existen miles de investigadores exitosos de esos países, y es fácil sentir confianza con alumnos de esas partes del mundo.

Es mucho más riesgoso aceptar el alumno chileno, y los profesores no siempre están dispuestos a tomar riesgos.

Si diseñas tu postulación con el foco en la credibilidad, tu postulación va a ser buena.

Por supuesto, eso no signifique que quedes aceptado. Siempre hay cosas que no podemos prevenir, y es mejor postular a varias universidades y profesores para disminuir el riesgo.

Pero es esencial enfocarse en la credibilidad. Empezamos desde una base muy baja, y hay que disminuir la sensación de riesgo que va a tener quien lea nuestra postulación.

Notas extra:

• Todavía no he postulado a doctorado, sino que lo voy a hacer este año. He investigado mucho del proceso, y siento confianza de todo lo que afirmo aquí a pesar de todavía no estar aceptado en un programa de doctorado. Si hay puntos para discutirme, felizmente recibo feedback y puedo cambiar cosas del ensayo.
• Está pensado para la postulación a doctorados en computación. Dentro de mi conocimiento es similar en otras áreas.
• Para postular a un doctorado en Chile el consejo es similar, pero no hay tantas barreras. Es importante conocer al profesor al que postulas, y ellos generalmente están abiertos a conocer gente interesada en su investigación.
• Escribí consistentemente “profesor”, en lugar de “profesor o profesora”. No es un intento de mostrar un sesgo, sino que se hace verboso escribir tantas palabras de más. Mi objetivo es únicamente maximizar la claridad del mensaje del ensayo.

Maintaining focus on what to research on, is much more important than working hard in research (although working hard is also necessary). It might be harder, but it will be much more rewarding in the long term.

And while I am by no means the leading expert on knowing the way forward in LLMs (or foundational models in general), I wanted to write my list of “technical debts” these current models have. This list is focused on problems which might improve the capabilities of these models.

Multimodality

Well, this one is not a shocker. A lot of researchers are already working to add more modalities (generally images) into these models.

Although I have not dived deep into this area of research, current approaches sound like “stitching” two models together and hope they work together well. I have not read an approach which feels like an elegant solution to the multimodality problem, and we definitely need multimodality for these models to have a wide range of applications, rather than just a chat bot.

Removing auto regression

We call this LLMs to be “generative models”, but I do not quite agree. These LLMs were trained to predict the next token, not to generate large portions of text. Of course, if you predict the next word enough times, you can produce large portions of text, but this seems to be a hacky way of producing text.

This autoregressive strategy of predicting token after token does not feel right. It wastes a lot of compute (having to essentially make a forward pass with each token) and it is slow. This does not seem like a long term solution.

Our current use case of these LLMs is text to text, not text to word. We should somehow figure out how to do that task efficiently (instead of next-word prediction).

This does not mean that the next-word prediction pre-training is bad (it has proven to be quite impressive). But leveraging these models into a text-to-text objective is a potentially fruitful area of research.

Adaptive computation

There are questions which are inherently harder to answer. Some questions require many steps of reasoning to answer correctly.

The problem with current LLMs, is that they have a fixed amount of compute. Easy questions have the same amount of computation as harder. How can we expect these models answer correctly these hard questions if they get the same amount of compute each time?

Current models are resorting to memorization, instead of leveraging some sort of systematic process, because they cannot even implement these systematic processes.

Adding some sort of adaptive computation, with repeating computation steps, might be a way to improve the lack of systematic thinking in these models. Figuring out how to do that efficiently is not easy, but it is definitely a huge area of improvement in these models.

Continual Memory

We want these models to have some sort of memory. We want them to remember our conversations, even if they happened days ago.

Currently we are trying to extend the context window. If we put our whole history in this prompt, then the model does not have to explicitly remember anything.

I do not think that is the correct approach. It is computationally expensive, and also does not feel right. We definitely do not remember everything, but rather keep in our heads the most important information that we remember of events that happen.

Search instead of predict

Next-word prediction limits the creativity of these models. They learn to predict what a human might answer, but we want to be better than humans. It is like training a chess engine to predict human moves. It would never be able to beat a grandmaster.

As in chess (or go), the models which superseded human performance used some sort of search.

In these algorithms, they search in the space of possible moves, and evaluate how good is it. That is how Alpha Go made the move 37. If Alpha Go was just trained to predict human professional go players moves, then it would have never predicted that move.

Of course, implementing some sort of notion like that in LLMs is not easy, but it is an area of research that could change the state of the art of these models.

And given this, what should you work on?

There are no clear answers.

I believe the most important thing, is to work on something that interests you. Research is hard, and there is no point in making it harder by researching something you fundamentally do not care about.

But you should not ignore how important a problem is. It probably is a frustrating experience to work on something no one (besides you) really cares.

Finding a problem which is both important and interesting might be the real key behind any good career in research.

This post was very much inspired in “How to do Great Work” by Paul Graham, but directed to Machine Learning research (and much more scoped).

I have not seen (as of yet) an easy explanation for the Transformer. Most of the explanations assume you have got a good background in deep learning, and they get tangled up in details which are not essential for the architecture.

I’ll try to give the most basic explanation on the how and the why the Transformer is such a good architecture.

For this, I will show a variation of the Transformer: the Minimalist Transformer. You’ll just need to know the basics of neural nets, and some basic linear algebra to understand it.

This architecture will, however, leave out some details of the architecture. These details are important, but are not essential in understanding the core functionality of the transformer.

But first, lets understand why the Transformer was necessary.

Before the Transformer

This is 2017. The deep learning models in NLP (natural language processing) were bad. Do you remember Google Translate in 2017? It was terrible.

The architecture used for NLP tasks were mostly variations of LSTMs (Long Short Term Memory Architecture) which had two big problems:

• Sequential execution: LSTMs “read” one word at a time. Consider if we wanted to read the entire Wikipedia (29 billion words), and lets consider 0.01 seconds for each word. That would sum up to more than 200,000 days.
• Terrible long term dependencies: LSTMs are made to “remember” everything they read, without ever going back. That implies if the word “John” is said at the beginning of a text, and only mentioned again much later, the LSTM might struggle to recognize it is the same person.

Recognizing these problems, many papers attempted to implement a notion of attention. We refer as attention to our notion of focusing on different parts of a text at different times.

Attention is this notion of ignoring unimportant details, and paying attention to what really matters in our objective. The Transformer leverages this notion, by using self-attention.

Self-Attention

Self-attention means that each word of the input, pays attention to other words of the same input. This is extremely useful for natural language, as a word might gain substantial meaning when seeing its context.

For example, the word “spring” means different things in different contexts. This way, “spring” might mean something when it is paying attention to words like “mechanics” or “force” , while having another meaning when seeing “winter” or “summer”.

To understand the implementation, its better to use an analogy to databases. You’ll need just a bit of lineal algebra (and attention).

Key-value Databases

Lets say that we want to query this database. Suppose we query the value 1 (Q=1). Then, the associated value would be 4, because when it exists the key 3, such that its value is 4.

What would happen if we query the value Q=1.1? That exact key does not exist, so it would not return any value. But, there is a sense that we might want something between the values of 4 and -1, because 1.1 exists in between their respective keys (1 and 2).

Better yet, lets suppose the keys and values are no longer integers, but vectors.

We might want to query this table by another vector, lets say Q=(1,0). It would be great if we compared this vector to every key and know if the key is similar or not.

If you remember your linear álgebra, you might recall that dot-product actually does this. A dot-product of two same length vectors is greater when the vectors have similar direction.

Lets compute this.

So we now have a notion of which vector is more similar to the query vector. But, it is not simple to determine what to return as a value. We would like for every value to be between 0 and 1, and for the sum of the values to be 1. That way it would be easy to interpretate this as proportions.

For that, we use Softmax. Softmax maps a range of values as if it were a probability distribution.

So now we multiply can each value with its corresponding probability.

So we computed what that (3.2147, 1) is the value associated to the query of Q=(1,0).

Imagine we not only want a single query, but rather many queries at the same time. Then we can represent that as an array of the queries. Such for example, if we were to query (1,0) and (0,1), we would say that:

(we computed the result of querying (0,1) by the same process as before)

It would be nice to actually do this by managing matrices, rather than going each query and computing its value. And actually, we can.

So now, we rearrange our queries, keys and values on the following way.

Now to compute that exact notion as before, we have to do:

See that Q multiplied by K transposed is actually the same as doing a dot multiplication for every pair of query-values.

So, after applying the Softmax along the vertical axis in this new matrix, we can just multiply by the values to compute the final matrix.

This is the notion behind self-attention. For the input we will compute three matrices: query, key and value. Each word in the input, will compute a query vector, a key vector, and a value vector. The array of these vectors will be the Q, K and V matrices.

This way each word will be compared to each word’s key. If the comparison shows that they are similar to another words key, the value vector that key will be represented strongly in the output.

We can put this in code simply by

Now, these results are passed through a feedforward layer. If you do not remember this layer, it is basically just two linear layers, separated by an activation function.

These Layers add the capability of computing between the outputs of the self attention module. Now the words can be used together to form new vectors which represent a much richer understanding of the input.

And with this, we have everything to put together our Minimalist Transformer.

We note that we use Residual connections (fancy way of saying we sum the input with the output of a layer). That is useful, because the layer does not have to try and “remember” the input, which might be useful later, but rather it tries to enhance the input with additional information. In practice it works pretty well.

Remember the 2 problems for which the transformer was created?

• Sequential execution: The transformer can execute everything in parallel, due to using matrix multiplication for every operation. This way, enormous amounts of text can be processed in parallel.
• Terrible long term dependencies: Transformers can recognize long term dependencies in the self attention module. It does not matter if the words are far apart, they will still be a place for computing the attention between these words in the Q by K^T matrix.

But the greatest achievement is shown only in practice. As in most things in deep learning, outcomes are hard to predict. The greatest thing the transformer has done is to continue to perform consistently in data. GPT, DALL-E, LLaMa would not have existed if this architecture was not able to scale.

But as I said before, this architecture is not exactly the Transformer architecture. If you have read and understand everything of the Minimalist Transformer, I do not suggest reading the real Transformer architecture.

On the other hand, if you got the idea of this architecture, you might want to research on:

• Positional encodings: They add information about the words/inputs position before the first transformer layer. This way the attention model might understand how the order of words matter.
• Encoders/Decoders: We might not want for every word to be able to pay attention to any other word. This is leveraged in the difference between encoders and decoders.
• Multi-head attention: We can actually compute several query, key, value vectors for a single word.
• Normalization layers and dropout layers: They tend to improve the generalization of the net, and prevent overfitting.

If you have read this far, I hope I was able to help you through your journey starting to understand Deep Learning :)

El hombre se detiene a observar al leñador, viendo cómo sierra febrilmente un árbol enorme.

La sierra del leñador se mueve, de lado a lado, sin descanso. A pesar de esto, no parece avanzar mucho a través del árbol.

El hombre nota que la sierra del leñador está tan afilada como un cuchillo de mantequilla, por lo cual dice:

“Perdone, señor leñador, pero no he podido evitar darme cuenta de lo duro que está trabajando en ese árbol, pero sin llegar a ninguna parte”

“Sí… lo sé. Parece que este árbol me está dando problemas” responde el leñador, mientras una gota de sudor se le cae de la frente.

“Pero señor leñador, su sierra está tan desafilada que es imposible que corte nada”.

“Lo sé”, dice el leñador, “pero estoy demasiado ocupado aserrando como para dedicar tiempo a afilar mi sierra”.

Todos estamos ocupados. Tenemos más cosas por hacer que tiempo para hacerlas.

Pero siempre va a ser así, y no siempre priorizamos lo importante un lugar de lo “urgente”.

Creo que esto es particularmente importante para un dev.

Estamos constantemente trabajando para hacer ciertos procesos más eficientes, rápidos y confiables. Sin embargo, pocas veces nos detenemos a pensar si nuestro propio proceso de trabajo es eficiente, rápido y confiable.

Si bien nuestras sierras no se desafilan con el uso, sí se pueden afilar. Se pueden afilar cada vez más, sin tener un límite.

Hay muchas actividades que nos hacen mejores desarrolladores de software. Son esas actividades que constantemente pensamos “debería hacer más de esto, pero ahora no tengo tiempo”.

La razón por la cual no solemos hacer estas actividades, es porque el beneficio de hacerlas es en un largo plazo.

Es muy fácil enfocarse en programar todo el día, y construir cada vez más código. Eso da una sensación de satisfacción productividad inmediata.

Sin embargo, probablemente mejoraríamos más como ingenieros dedicando nuestro tiempo de otra manera.

Voy a hacer énfasis en una manera de “afilar la sierra” siendo dev. Es la importancia de programar… rápido.

Programa… rápido ⚡️

Como es de esperar, un dev pasa una cantidad considerable de tiempo programando.

Sin embargo, el tiempo que gastamos programando, es decir, físicamente apretando teclas del teclado, nunca es el cuello de botella. En general, pasamos más tiempo pensando y diseñando soluciones.

A pesar de eso, programar rápido tiene más ventajas de lo que uno podría esperar.

Primero, si bien la mayoría del tiempo no estamos programando, sí lo hacemos una cantidad considerable. Podrían ser simplemente 2 horas al día, pero si podemos hacer esas 2 horas en 1 hora y media o incluso 1 hora, ahorramos mucho tiempo. Pero ese efecto diría que no es lo más importante.

La gran ventaja que tiene programar rápido, es que el teclado termina siendo una extensión de tus pensamientos.

Una vez te acostumbras a programar extremadamente rápido, el cambio de contexto de pensar una solución a tenerla en código es cada vez menor.

Eso hace que podamos pensar más profundamente en nuestras soluciones. En lugar de tener una idea, y después pensar “¿Cómo agrego una indentación a todo este bloque?”, uno puede tener la cabeza absolutamente enfocada en el problema, y que las manos, de manera casi automática, implementen lo que pensaste.

Hay varias maneras de aumentar la velocidad a la que programas, voy a mencionar algunas que creo que valen la pena.

Dedica tiempo a tu editor de texto

Estamos casi todo el tiempo con nuestro editor de texto abierto.

La gran mayoría de nosotros, estamos estancados en la cantidad de funcionalidades que utilizamos de él.

Llegamos a una especie de punto de inflexión, en donde decidimos que no vale la pena seguir aprendiendo más cosas del editor. Estamos acostumbrados a lo que usamos y creemos que estamos bien.

Sin embargo, esta visión no toma en cuenta lo mucho que escala sentirse cómodo con tu editor de texto.

Cosas sencillas, como saber cómo borrar toda una línea con un par de teclas, o saber cómo copiar la palabra con la que estás o cómo indentar una selección de líneas, puede terminar ahorrando algunos segundos por día.

¿Segundos por día? Meh…

Pero, si aprendes en 10 minutos algo que te acelera 1 segundo todos los días, en 10 años más habrás ahorrado 60,8 horas.

Pero eso no es lo realmente importante. Cuando aprendes algo nuevo de tu editor, te sientes más cómodo con él.

Esa comodidad se traduce en que ya no sientes que debes “pensar” para programar. La actividad de programar pasa a ser un mero trámite, que no te quita mucha capacidad mental.

Así puedes probar más cosas, implementar ideas más rápido, y todo sin tener el costo mental de pensar cómo hacerlo. Te puedes enfocar en hacer mejores soluciones, con mejor código, en lugar de enfocarse en cómo escribirlo.

Si quieres mejorar en tu editor de texto hasta no tener límites, recomiendo Vim. Si bien hay muchos otros editores de texto muy buenos, creo que el paradigma de Vim es el que más escala en términos de velocidad y comodidad para programar.

Herramientas externas de código

Pero programar no sólo implica tu editor de texto. Tenemos muchas herramientas que usamos cuando programamos: desde googlear, buscar archivos, revisar monitoreos, etc.

En general, existen numerosas herramientas para hacer todo eso más eficiente. Algunas herramientas que yo uso en mi día a día (y recomiendo profundamente) son:

• Arc
• Copilot
• LF
• Akiflow
• Merlin
• Vimium

Cada uno de esos siento que me ha logrado ser más rápido en términos marginales. Pero todas juntas, y soy por lo menos el doble de rápido de antes.

Es por eso que siempre vale la pena investigar nuevas herramientas. Puedes encontrar nuevas herramientas para usar, simplemente:

• Pregunta a otros devs las herramientas que usan en su día a día.
• Revisa Product Hunt.
• Googlea (parece obvio, pero muchas veces estamos acostumbrados a resolver los mismos problemas de la misma manera, sin investigar si hay mejores formas).

Automatiza tu workflow

Finalmente, me parece siempre curioso que no usamos la misma filosofía del código para nuestra propia manera de programar.

Todo dev, si ve que unas mismas líneas de código se repiten una y otra vez, generalmente nos cuestionamos si debiésemos abstraerlo en una función, y reutilizar esa función.

La misma filosofía aplica para cuando programamos.

Si haces una serie de cosas una y otra vez, ¿No debiera existir una manera de abstraer eso?

Un ejemplo, es git. Usamos una serie de comandos de git una y otra vez, y se puede automatizar mucho con eso. Algunas Cosas que yo tengo automatizadas con git son:

• git ca: Es una alias para git commit --amend . Además, tiene la ventaja que tiene la flag -reuse-message=HEAD , de tal forma que no tengo que volver a confirmar el mensaje del commit.
• git fix : En lugar de hacer git commit --fixup cada vez que quiero cambiar una cosa de un commit viejo, simplemente uso git fix
• git wip: Hay varias veces que quiero guardar lo que hice, pero no me gusta la abstracción del stash . Con git wip hago un commit de nombre wip de absolutamente todos mis cambios. Además tiene la ventaja que no llama callbacks de commits (yo en particular tengo un callback que revisa errores de linter, el cual tarda 1 o 2 segundos).
• git dewip: Como uno esperaría, es lo contrario a git wip. Deshace el último commit, pero no descarta los cambios.

Cada una de estas me ahorra unos segundos. Considerando que uso cada una unas cuantas veces al día, me ahorra mucho tiempo.

Pero hay otras maneras de automatizar tu workflow, como:

• ¿Tienes que correr 3 comandos sólo para correr localmente lo que desarrollas? ¿Por qué no automatizar en un sólo comando que corra las 3?
• ¿Monitoreas activamente cierta métrica de tu aplicación? ¿Por qué no poner una alerta cuando llegue a los valores extremos en lugar de estar constantemente pendiente?
• ¿Usas demasiado el mouse para ciertas acciones básicas? ¿Por qué no investigas cómo aprender (o incluso programar) un shortcut para hacer esa acción?

Por último, cabe mencionar que hay otras maneras de afilar la sierra, que no involucran programar más rápido, pero que de todas maneras nos hacen muchos mejores ingenieros. Algunas de estos son:

• Aprender lenguajes/frameworks nuevos
• Leer libros técnicos
• Leer (y escribir) blogs de ingeniería

Lo único importante que quiero que te lleves de este post, es que vale la pena dedicar tu tiempo a afilar la sierra.

Al igual que el leñador terminaría más rápido de talar el árbol si se diese el tiempo para afilar la sierra, tu vas a avanzar más como dev si le dedicas tiempo a las cosas importantes, en lugar de siempre priorizar lo urgente.

1. Ir al colegio
2. Ir a la universidad
3. Conseguir un trabajo estable
4. Tener una familia
5. The end

O por lo menos eso es lo que a mi me enseñaron.

Yo llegué a terminar el colegio. En aquel entonces pensaba que mi vida iba a seguir esta receta.

Es difícil cuestionar las cosas que uno aprende de pequeño. Pero si uno no lo cuestiona, puede perderse oportunidades que uno ni conoce.

Empecé a trabajar estando en la universidad. Lo hice por aburrimiento más que nada, la pandemia limitaba bastante lo que podía hacer.

De mera casualidad, entré a trabajar a un ecosistema de personas que no siguen la receta.

Pensé que todos terminaban la universidad, ¿Por qué la empezaste si no es para terminar? Pero conocí a una multitud de gente que se fue de la universidad sin ningún cartón.

Vi a niños*, hacer una startup que hoy tiene más de 80 personas, a lo largo de latinoamérica. Obviamente, ninguno había ido a la universidad.

Conocí a devs que rechazaron sueldos millonarios en Silicon Valley, para vivir la emoción de una startup.

Todas estas personas, se habían desviado de la receta.

No digo que seguir la receta esté mal. Hay gente que quiere tener una vida tranquila, segura, relajada. Esta receta asegura eso, y no hay nada malo en ello.

Pero hay otro tipo de personas. Personas que no aguantan estar encerradas en una sala de clases. Personas que no soportan la cotidianidad de un trabajo estable. Personas que no quieren seguir la receta.

Me di cuenta que no quiero seguir la receta. La vida es una, y para mí no vale la pena hacer lo estándar.

Tampoco es que tenga claro qué es lo que quiero hacer. En una de esas quiero viajar por todo el mundo. O quizás algún día quiera hacer mi propia startup. Ni siquiera descarto volver a estudiar.

Lo que tengo claro, es que estando en la universidad no lo iba a averigüar.

Así que sí. Perdón mamá. Soy un dropout.

¿Es una buena decisión? No tengo idea… pero veremos.

:)

*No realmente niños, pero tampoco están tan lejos

**Llegué a obtener una licenciatura en ciencias de la ingeniería, así que me fui con alguna especie de cartón (fue para que mi mamá no me rete tanto)